软件缺陷

一、软件缺陷：

常常又被叫做Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
从软件测试观点出发，软件缺陷有以下五大类：
功能缺陷、系统缺陷、加工缺陷、数据缺陷、代码缺陷

二、软件缺陷类别（bug组成要素）：

1、软件没有实现说明书中所列出的功能
对于“软件没有实现说明书中所列出的功能是BUG”这一点是比较好理解的。如果打开记事本软件，却无法在其中输入汉字，或者输入了文本，无法保存成文件，那么肯定是一个很严重的BUG。

2、 软件出现了说明书中提到不应该出现的事情
“软件出现了说明书中提到不应该出现的事情也是BUG”，这一点和性能测试工作有相对更紧密的关系，如果网站要求用户在浏览网站时显示页面尽可能地快，如果超出5秒钟则认为是不可接受的，这个“超出5秒钟”就是说明书中提到不应该出现的事情，实际出现肯定是一个BUG，需要开发人员找出哪里耗费了页面的显示时间并加以改正。

3、软件实现了说明书中没有提到的功能
软件实现了说明书中没有提到的功能也是BUG
这一点可能有点难于理解，一个软件功能难道不是越多越强大吗？其实不尽然，实现额外的功能有如下几个缺点：

• 代码量增大。
  由于代码可能相互影响，因此这部分额外的功能可能对其他功能的实现造成影响，带入新的BUG
• 增加额外的开发、测试时间。
  在软件项目时间固定的情况下，导致投入到其他必备功能的开发测试时间减少，可能影响它们的完成质量
• 增加了成本，与软件的宣传不完全符合
  虽然用户对于增加功能一般不会有意见，但可能影响了公司的销售策略及市场定位

4、软件没有实现说明书中没有提到但应该实现的功能
举个例子：我们在磁盘中保存大量数据，由于连日来的积累，导致磁盘没有空间了，这时再对已有的记事本进行编辑，使其内容变大，在“保存”时，系统提示无法保存，同时磁盘提示空间已满，在这种情况下记事本的行为，就属于实现了说明书中没有提到却应该实现的功能，如果没有提示，不符合绝大部分用户的使用习惯，也是一个BUG。

5、软件难于使用、性能差
软件是拿来用的，再好的界面使用不方便也不会产生多大效果。一个网站如果半天都打不开，很难想象还会有多少用户会访问它。因此这样的问题也是BUG，而且对于性能测试来说，这一个规则很重要。

三、缺陷属性：

1、缺陷标识：

缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识；

2、缺陷类型：

缺陷类型是根据缺陷的自然属性划分的缺陷种类；

3、缺陷严重程度：

缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度；
1级（Critical）：不能执行正常工作功能或重要功能，或者危及人身安全。
2级（Major）：严重的影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）
3级（Minjor）：严重的影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）
4级（Cosmetic）：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能
5级（Other）：其他错误

4、缺陷优先级：

缺陷的优先级指缺陷必须修复的紧急程度；
1级：缺陷必须被立即解决
2级：缺陷需要正常排队等待修复或列入软件发布清单
3级：缺陷可以在方便时被纠正
4级：可以忽略

5、缺陷起源：

缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段；
1.Requirement：在需求阶段发现的缺陷
2.Architecture：在架构阶段发现的缺陷
3.Design：在设计阶段发现的缺陷
4.Code：在编码阶段发现的缺陷
5.Test：在测试阶段发现的缺陷

6、缺陷状态：

缺陷状态指缺陷通过一个跟踪修复过程的进展情况；
1级：已提交的缺陷
2级：确认“提交的缺陷”，等待处理
3级：拒绝“提交的缺陷”，不需要修复或不是缺陷
4级：缺陷被修复
5级：确认被修复的缺陷，将其关闭

7、缺陷来源：

缺陷来源指引起缺陷的起因；

8、缺陷根源：

缺陷根源指发生错误的根本因素。

四、缺陷报告

1、缺陷报告的组成：

1、缺陷编号（Defect ID）：提交缺陷的顺序
2、缺陷的标题（summary）：简明扼要的描述缺陷
3、缺陷的发现者（Defected By）：测试人员
4、缺陷发现的日期（date）：一般为当天
5、缺陷所属的模块（subject）：在测试那个功能模块时发现的bug
6、发现缺陷的版本（Defected in release）：开发的软件的版本
7、指派给谁处理（Assigned to）：测试人员指派给开发经理，开发经理根据缺陷所在的模块，需要再次指派具体的开发人员
8、缺陷的状态（status）：缺陷此时所处的处理阶段或处理情况
（1）测试人员发现缺陷，提交缺陷报告，把缺陷的状态置为new（新）
（2）开发经理验证提交的bug，如果是bug，把状态改为open（打开的bug，开发组承认的bug），指派给具体的开发人员解决；如果不是bug，把状态改为rejected（拒绝的bug）
（3）开发人员看到指派给自己解决的bug，进行缺陷修复，修改完后，把缺陷状态fixed（已经修复的bug，可以返测的bug）
（4）测试人员对修复的bug进行反测，若返测成功，将状态改为closed（关闭的缺陷，归档的bug）；如果返测不成功，把状态改为reopen（重新打开的bug）

注意：
1、优先级和严重程度不是严格正比关系
2、严重程度确定好后一般就不再更改而优先级确定好后可能经常修改一般会向后推延
3、不是所有的bug在产品发布之前都能被修复，对于发布之前不修复的bug要通过缺陷讨论明确解决bug
的成本、时间以及该bug如果不解决给用户造成的影响、损失
4、不可重再现的bug也叫做随机bug也要报告，但要说明该bug不可重现，如果可能可以对bug做截图

2、缺陷报告的处理流程

说明：
（1）以上过程就是缺陷的处理流程
（2）一个缺陷的生命周期：new->open->fixed->closed

加深理解
1、缺陷的严重程度和优先级是不是成正比关系？
界面问题的严重程度一般比较低，担优先级可能很高——立即修复
某些重大的功能问题可能暂时解决不了，但不影响其他功能的使用，这时优先级可能定义的比较低——在发布之前修复
2、缺陷的严重程度和优先级确定好后，还能修改吗？
严重成度不允许改，优先级可能修复
3、是不是所有一发现的缺陷都会被修复？
有些缺陷修复的成本太高或者由于进度压力可能在发布前得不到修复，这样的缺陷一定要经过项目组的讨论，权衡成本和风险，要确保不会对用户在成重大的影响及法律纠纷。后面再通过升级软件或者打补丁的方式修复缺陷或弥补漏洞

3、缺陷报告的用途

1、记录bug
2、对bug进行分类（模块、bug状态、严重程度、版本）
3、跟踪bug
4、对bug进行分析、统计

4、如何识别bug

1、通过测试用例的预期结果判断——实际结果与预期结果不一致，就是bug
2、看需求（通过缺陷的5定义识别）
3、沟通（开发、需求、用户）

5、些缺陷报告时注意的问题

1、一个报告只提交一个缺陷
2、缺陷描述清晰、准确、易读、使用最少、必须的步骤、确保缺陷可以在现
3、对缺陷的严重性、优先级的划分准确、客观
4、在提交缺陷报告之前一定要认真审核，确保提交的缺陷是有效的，而不是因为自己的疏忽或操作不正确造成的”假缺陷“
5、不要为了引起开发人员的重视而夸大缺陷
6、小的缺陷也要报告
7、及时报告缺陷
8、对于不可重现的缺陷也要报告