软件的缺陷

一、缺陷的基本概述

缺陷的定义 

• 软件未实现产品说明书要求的功能 
• 软件出现了产品说明书指明不应该出现的功能
• 软件实现了产品说明书未提到的功能
• 软件未实现产品说明书虽未明确提及但应该实现的目标
• 软件难以理解、不易使用、运行缓慢或者（从测试的角度看）最终用户会认为不好

缺陷的属性 

• 缺陷的类型：根据缺陷的自然属性划分的缺陷种类

缺陷类型	描述
功能	影响了各种系统功能、逻辑的缺陷
用户界面	影响了用户界面、人机交互特性、包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷
文档	影响发布和维护，包括注释、用户手册、设计文档
软件包	由于软件配置库、变更管理或版本控制引起的错误
性能	不满足系统可测量的属性值，如执行时间、事务处理速率等
系统/模块接口	与其他组件、模块或设备驱动程序、调用函数、控制块或参数列表等不匹配、冲突

注意：需求分析、设计阶段，文档类型的缺陷多；集成测试阶段，一般接口类型的缺陷多；系统测试阶段，功能、界面类型的缺陷多；验收测试阶段，更多的关注性能缺陷；实施过程，可能遇到一些软件包的缺陷

• 缺陷的严重程度：因缺陷引起的故障对软件产品的影响程度；一般有分类，每个公司和团队的分类标准或略有不同。

缺陷的严重程度	描述
致命（Fatal）	系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机、或者危机人身安全
严重（Critical）	系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响
一般（Major）	系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题
较小（Minor）	是操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题

• 缺陷的修复优先级：缺陷必须被修复的紧急程度；取决于缺陷对测试工作的影响程度

缺陷优先级	描述
立即解决（P1级)	缺陷导致系统几乎不能使用或测试不能继续，需立即修复
高优先级（P2级）	缺陷严重，影响测试，需要优先考虑
正常排队（P3级）	缺陷需要正常排队等待修复
低优先级（P4级)	缺陷可以在开发人员有时间的时候被纠正

注意:优先级的衡量，一般可以根据测试的软件系统的全业务流程划分，软件的基本功能的缺陷，优先级高，甚至需要立即解决。软件的备选流、基本功能测试中的反向测试内容，优先级低，有些甚至可改可不改 
缺陷的严重程度与优先级的关系：
1）没有任何直接关系
2）不要认为严重的缺陷，修复优先级就高。例如：QQ的帮助按钮，一按就闪退，严重程度很高，但优先级就很低。

• 缺陷的状态：缺陷通过一个跟踪修复过程的进展情况 

缺陷状态	描述
激活/打开（新建）	由测试人员进行标注
确认	确认新提交的缺陷是一个真实有效的缺陷。一般由测试主管或者质量保证（QA）、产品经理进行确认。经过确认后，有效的缺陷会指派给相关人员进行处理
已修复/修正	在缺陷被修复后，一般由开发人员进行标注
关闭/非激活	缺陷被修复完成后，经过测试人员的验证，没有问题
重新打开	缺陷被修复完成后，经过测试人员的验证，缺陷没有修复成功，需要重新打开进行再次处理和修复
推迟	缺陷现在不修复，推迟到下一个版本或阶段。测试要跟开发或者其他相关的管理人员进行确认
保留	缺陷暂时修复不了。一般也是由开发人员去设定，也需要测试人员确认
不能重现	开发不能再现这个缺陷，需要测试人员检测缺陷的复现步骤
需要更多信息	开发可以再现这个缺陷，但需要一些信息，如缺陷的日志文件、图片等
重复	这个缺陷已经被其他的测试人员发现
不是缺陷	这个问题不是缺陷
需要修改软件规格说明书	缺陷不是技术原因造成的，而是由于需求不明确或者设计不明确造成

•  缺陷的起源：缺陷引起的故障或事件第一次被检测到的阶段
•  缺陷的来源：缺陷的起因

缺陷来源	描述
需求说明书	需求说明书的错误或不清楚引起的问题
设计文档	设计文档描述不准确，和需求说明书不一致的问题
系统集成接口	系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷
数据流（库）	由于数据字典、数据库中的错误引起的缺陷
程序代码	是编码中的问题所引起的缺陷

•  缺陷的根源：发生错误的根本因素；在测试总结的时候关注

缺陷根源	描述
测试策略	错误的测试范围，误解了测试目标，超越测试能力等
过程，工具和方法	无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，没有估算规程，无效的变更控制过程等
团队/人	项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等
缺乏组织和通讯	缺陷用户参与，职责不明确，管理失败等
硬件	硬件配置不对，缺乏或处理器导致算术精度丢失，内存溢出
软件	软件设置不对，缺陷或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，千年虫的问题等
工作环境	组织机构的调整，预算改变，工作环境恶劣，如噪音过大

二、缺陷的生命周期

1. 发现缺陷：由测试人员
2. 提交缺陷：由测试人员
3. 确认缺陷：一般由测试主管、或者质量保证（QA）、由产品经理进行确认
4. 分配缺陷：经确认后，有效的缺陷会指派给相关的人员进行处理；一般由谁确认就由谁分配。分配对象可能是开发、UI也有可能是产品经理
5. 修复缺陷：主要由开发修复，也有可能是产品经理修复问题，也有可能是UI修复问题
6. 验证缺陷：测试去验证缺陷有没有修复成功 
7. 关闭缺陷：只能是测试人员进行；否则出了问题，测试一律不背锅

三、缺陷的识别

• 通过测试用例中的预期结果进行识别
• 通过需求规格说明书进行识别
• 通过用户手册及其他文档进行识别
• 通过同行业相类似成熟的商业软件来识别
• 通过和开发人员的沟通进行识别
• 通过和有经验的测试人员沟通进行识别
• 参照同行业隐式需求进行识别 

四、缺陷报告

1. 缺陷编号：Bug_项目名称_模块名称_功能名字_0001
2. 所属模块：一级模块/二级模块/三级模块
3. 优先级：缺陷的修复紧急程度。p1>p2>p3>p4（参照上面的优先级）
4. 严重程度。s1>s2>s3>s4（参照上面的严重程度等级）
5. 缺陷的概述：用一句话描述缺陷的基本情况
6. 缺陷的描述：将缺陷的复现步骤、预期结果和实际结果列出来
7. 提交人：是谁就写谁的名字
8. 备注：一般写产生该缺陷的特殊情况。将bug的截图作为备注信息 

例如; 

 缺陷报告编写目的

• 易于搜索软件测试报告的缺陷
• 报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体化、准确
• 软件开发人员希望获得缺陷的本质特征和复现步骤
• 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度