1.软件缺陷的定义
软件缺陷，常常又被叫做Bug，从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病
等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
格蕾丝·赫柏（GraceMurrayHopper），是一位为美国海军工作的电脑专家，也是最早将人类语言
融入到电脑程序的人之一。而代表电脑程序出错的“bug”这名字，正是由赫柏所取的。1947年9月9
日，赫柏对HarvardMarkII设置好17000个继电器进行编程后，技术人员正在进行整机运行时，它突然
停止了工作。于是他们爬上去找原因，发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾，这
显然是由于飞蛾受光和热的吸引，飞到了触点上，然后被高电压击死。所以在报告中，赫柏用胶条贴上飞
蛾，并把“bug”来表示“一个在电脑程序里的错误”，“Bug”这个说法一直沿用到今天。
2.软件缺陷的种类划分
按照软件缺陷的产生原因，可以将其划分为不同的缺陷类别：
1、功能不正常
简单地说就是所应提供的功能，在使用上并不符合产品设计规格说明书中规定的要求，或是根本无法
使用。这个错误常常会发生在测试过程的初期和中期，有许多在设计规格说明书中规定的功能无法运行，
或是运行结果达不到预期设计。最明显的例子就是在用户接口上所提供的选项及动作，使用者操作后毫无
反应。
2、软件在使用上感觉不方便
只要是不知如何使用或难以使用的软件，在产品设计上一定是出了问题。所谓好用的软件，就是使用
上尽量方便，使用户易于操作。如微软推出的软件，在用户接口及使用操作上确实是下了一番功夫。有许
多软件公司推出的软件产品，在彼此的接口上完全不同，这样其实只会增加使用者的学习难度，另一方面
也凸显了这些软件公司的集成能力不足。
3、软件的结构未做良好规划
这里主要指软件是以自顶向下方式开发，还是以自底向上方式开发。如果是以自顶向下的结构或方法
开发的软件，在功能的规划及组织上比较完整，相反以自底向上的组合式方法开发处的软件则功能较为分
散，容易出现缺陷。
4、提供的功能不充分
这个问题与功能不正常不同，这里指的是软件提供的功能在运作上正常，但对于使用者而言却不完整。
即使软件的功能运作结果符合设计规格的要求，系统测试人员在测试结果的判断上，也必须从使用者的角
度进行思考，这就是所谓的“从用户体验出发”。
5、与软件操作者的互动不良
一个好的软件必须与操作者之间可以实现正常互动。在操作者使用软件的过程中，软件必须很好地响
应。例如在浏览网页时，如果操作者在某一网页填写信息，但是输入的信息不足或有误。当点击“确定”
按钮后，网页此时提示操作者输入信息有误，却并未指出错误的哪里，操作者只好回到上一页重新填写，
或直接放弃离开。这个问题就是典型的在软件对操作互动方面未做完整的设计。
6、使用性能不佳
被测软件功能正常，但使用性能不佳，这也是一个问题。此类缺陷通常是由于开发人员采用了错误的
解决方案，或使用了不恰当的算法导致的，在实际测试中有很多缺陷都是因为采用了错误的解决方法，需
要加以注意！
7、为做好错误处理
软件除了避免出错之外，还要做好错误处理，许多软件之所以会产生错误，就是因为程序本身对于错
误和异常处理的缺失。例如被测软件读取外部的信息文件并已做了一些分类整理，但刚好所读取的外部信
息文件内容已被损毁。当程序读取这个损毁的信息文件时，程序发现问题，此时操作系统不知该如何处理
这个情况，为保护系统自身只好中断程序。由此可见设立错误和异常处理机制的重要性！
8、边界错误
缓冲区溢出问题在这几年已成为网络攻击的常用方式，而这个缺陷就属于边界错误的一种。简单来说，
程序本身无法处理超越边界所导致的错误。而这个问题，除了编程语言所提供的函数有问题之外，很多情
况下是由于开发人员在声明变量或使用边界范围时不小心引起的。
9、计算错误
只要是计算机程序，就必定包括数学计算。软件之所以会出现计算错误，大部分出错的原因是由
于采用了错误的数学运算工时或未将累加器初始化为0.
10、使用一段时间所产生的错误
这类问题是程序开始运行正常，但运行一段时间后却出现了故障。最典型的例子就是数据库的查
找功能。某些软件在刚开始使用时，所提供的信息查找功能运作良好，但在使用一段时间后发现，进行信
息查找所需的时间越来越长。经分析查明，程序采用的信息查找方式是顺序查找，随着数据库信息的增加，
查找时间自然会变长。这就需要改变解决方案了！
11、控制流程的错误
控制流程的好坏，在于开发人员对软件开发的态度及程序设计是否严谨。软件在状态间的转变是
否合理，要依据业务流程进行控制。例如，用软件安装程序解释这类问题最方便直观。用户在进行软件安
装时，输入用户名和一些信息后，软件就直接进行了安装，未提示用户变更安装路径、目的地等。这就是
软件控制流程不完整导致的错误问题。
12、在大数据量压力下所产生的错误
程序在处于大数据量状态下运行出现问题，就属于这类软件错误。大数据量压力测试对于Server
级的软件是必须进行的一项测试，因为服务器级的软件对稳定性的要求远比其它软件要高。通常连续的大
数据量压力测试是必须实施的，如让程序处理超过10万笔数据信息，再来观察程序运行的结果。
13、在不同硬件环境下产生的错误
这类问题的产生与硬件环境的不同相关。如果软件与硬件设备有直接关系，这样的问题就是数量
相当多。例如有些软件在特殊品牌的服务器上运行就会出错，这是由于不同的Server内部硬件了不同的处
理机制。
14、版本控制不良导致的错误
出现这样的问题属于项目管理的疏忽，当然测试人员未能尽忠职守也是原因之一。例如一个软件
被反映有安全上的漏洞，后来软件公司也很快将修复版本提供给用户。但在一年后他们推出新版本时，却
忘记将这个已解决的bug-fix加入到新版本中。所以对用户来说，原本的问题已经解决了，但想不到新版本
升级之后，问题又出现了。这就是由于版本控制问题，导致不同基线的merge出现误差，使得产品质量也
出现了偏差。
15、软件文档的错误
最后这类缺陷是软件文档错误。这里所提及的错误，除了软件所附带的使用手册、说明文档及其
它相关的软件文档内容错误之外，还包括软件使用接口上的错误文字和错误用语、产品需求设计PD、UISpec
等的错误。错误的软件文档内容除了降低产品质量外，最主要的问题是会误导用户！
软件缺陷是计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义:从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题;从产品外部看,缺陷是系统所需要实现的某种功能的失效或违背。在软件开发生命周期的后期,修复检测到的软件错误的成本较高。缺陷的表现形式不仅体现在功能的失效方面,还体现在其他方面。
主要类型:
软件没有实现产品规格说明所要求的功能模块;
软件中出现了产品规格说明指明不应该出现的错误;
软件实现了产品规格说明没有提到的功能模块;
软件没有实现虽然产品规格说明没有明确提及但应该实现的目;
软件难以理解,不容易使用,运行缓慢,或从测试员的角度看,最终用户会认为不好。
注意
发现缺陷后,要尽快修复缺陷。其原因在于错误并不只是在编程阶段产生,需求和设计阶段同样会产生错误。也许一开始,只是一个很小范围内的错误,但随着产品开发工作的进行,小错误会扩散成大错误,为了修改后期的错误所做的工作要大得多,即越到后来往前返工也越远。如果错误不能及早发现,那只可能造成越来越严重的后果。缺陷发现或解决的越迟,成本就越高。
3.软件缺陷的属性
1.1.14.按照严重程度分:
一般分为5个等级:
系统崩溃，严重，一般，次要，建议
在软件缺陷中不仅仅只是严重极别，更多的则是功能没有做到。说到这里也许大家都理解了，就是需求没有考虑到，可需求不会一次就很完美的，需要大家的共同努力，来不断的完善。那么怎样才能让测试人员提出的好的建议得到有效的执行？这就是我下面想说的。在软件缺陷中还有一种分法，跟据缺陷内容来分，主要分为需求Bug与程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都知道是由相关开发人员进行处理。下面主要讨论一下需求Bug,需求Bug从名称上来就知道是要交由需求人员进行处理，可怎么处理，怎样在处理的过程中有效的让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求Bug.
这样处理有以下好处，首先需求Bug再不象以前，没有人进行确认，需求的处理人员本来就是需求人员，由他们确认与跟踪是最好不过的，因为他们对需求有绝对的权威。同时测试人员其实就是最早的用户，他们的需求就是用户的需求，这种方法加强了需求人员与测试人员的沟通，使需求得到有效的补充，从而让产品更加完善。还有测试人员从本质上来说与程序员还是对立的，这里如果为了这样一个不是软件本身问题的问题形成与开发人员的对立，则会出现赢得战役而丢失整个战争的情况，测试人员协调好与开发人员的关系，让他们更有效的对软件本身的缺陷形成有效的关注是最好的。还有最为关键的一点，测试人员的激情是最重要的，如果他们的想法没有得到体现，这时会渐渐的失去对测试的兴趣，从而软件的质量则会无法得到保证，通过这种方法可以让他们看到自己的建议可以通过对需求人员的反映得到实现，让他们时时觉得自己的想法是可以通过这种方法来有效的推行，这样工作的积极性才会有保障。
不过从实施的角度来说，还是有一定的困难的，首先要让大家改变以前那种凡是Bug就是由开发人员负责的观念，其次需求人员的工作量是要加大的，不过广泛的了解需求是他们的本份工作，想来不会很困难，还有必需要有有效的Bug管理工具，比如BugManage等等，不要出现那种对需求人员说了，可过两天就忘的情况出现，这时需求Bug的生命周期会出现跨越两个软件开发周期，因为有些需求会在下一版实现，这时测试人员需要延长对这些需求Bug的管理，不过我想这些需求是他们提出的，会有兴趣对这些Bug进行管理的。
1.1.15.按优先级分:
修正优先级：高，中，低
