缺陷管理

认识缺陷报告

1. 缺陷报告的重要性
   软件缺陷的描述是软件缺陷报告的基础部分，须要使用简单、准确、专业的术语来描述缺陷。不然，它就会含糊不清，可能会误导开发人员，影响开发人员的效率，也会影响测试人员自身的声誉，准确报告缺陷是很是重要的。
   清晰准确的软件缺陷描述能够减小开发人员退回来的缺陷数量，能够节省开发人员和测试人员的时间。 提升软件缺陷修复的速度，使项目组可以有效地工做。
   提升测试人员的可信任程度，能够获得开发人员对有效缺陷的及时响应。 增强开发人员、测试人员和管理人员的协同工做，让他们更好的工做
2. 缺陷报告的注意事项
   尽可能确保缺陷能够重现
   若是提交的缺陷没法重现，会影响开发人员的工做效率。
   简洁、准确、完整
   测试人员在提交缺陷报告时，要站在开发人员的角度上思考问题，要确保开发人员能迅速定位问题，而不会产生理解上的歧义。
   一个缺陷一个报告
   有的测试人员喜欢在一个缺陷报告里提交多个缺陷，这种习惯不提倡，缘由有如下两点： 不便于分配。
   好比缺陷报告有2个缺陷，分别属于不一样的开发人员，到底该分配给谁呢？ 不便于验证。
   好比一个缺陷报告里面有2个缺陷，缺陷1已经解决，缺陷2尚未解决，那么这个缺陷报告该不应关闭呢？
3. 缺陷书写规范
   标题：应保持简短、准确，提供缺陷的本质信息
   尽可能按缺陷发生的缘由与结果的方式书写；
   避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起做用”等。应该使用具体文字说明缺陷的症状； 为了便于他人理解，避免使用俚语或过度具体的测试细节。
   复现步骤：应包含如何使别人可以很容易的复现该缺陷的完整步骤。
   为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。常见问题： 包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解；
   包含的信息过少，丢失了操做的必要步骤；

复现步骤的正确书写方式:
提供测试的环境信息；
简单地一步步引导复现该缺陷，一个步骤包含的操做不要多； 每一个步骤前使用数字对步骤编号；
尽可能使用短语或短句，避免复杂句型句式； 复现的步骤要完整、准确、简短；
将常见步骤合并为较少步骤；
按实际须要决定是否包含步骤执行后的结果。
实际结果: 是执行复现步骤后软件的现象和产生的行为。
实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起做用”。
指望结果:描述应与实际结果的描述方式相同。一般须要列出指望的结果是什么。
附件：对缺陷描述的补充说明，能够是如下一些类型：
缺陷症状的截图；
测试使用的数据文件;
其余：
选择合适的缺陷严重性属性；
按相应的规定，填写相应的字段信息
3.1避免常见错误
避免使用我、你等人称代词，能够直接使用动词或必要时使用“用户”代替避免使用情绪化的语言和强调符号；
避免使用诸如“彷佛”、“看上去可能”等含义模糊的词汇，而须要报告肯定的缺陷结果； 避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息；
避免提交不肯定的测试问题，本身至少须要重现一次再提交。 反面的示例：
上海人：哪能查询到的结果和查询条件不搭噶的。
北京人：哥们好不容易输入一堆我的详细信息后，点击保存后全瞎了

3.2 缺陷报告

3.3 缺陷处理流程

3.4缺陷跟踪
新提交的缺陷为新建状态，确认有效后为打开状态，经开发人员修改后，缺陷变为已修复（待验证）状态。此时就须要测试人员对缺陷进行回归测试，验证问题是否修复。
若是问题仍然存在，则测试人员将该缺陷的状态修改成从新打开；
若是问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证经过），同时添加回测说明如“该缺陷已解决”。
还有一种状况：开发人员认为缺陷在当前版本能够暂不修改，而考虑在后续版本中再作修正，缺陷的对应状态为延期。
对于这种状况，项目负责人应召集开发人员、测试人员和其余项目相关人员进行讨论，若是讨论结果为赞成则延期，若是不一样意，则从新打开缺陷。
3.5 缺陷统计
缺陷按活动分布

缺陷按严重程度分布

缺陷按引入源分布

3.6 缺陷数据分析
1）缺陷数据分析关注的问题
2）缺陷数据分析的重要性
3）缺陷数据分析的数据指标
3.7 缺陷数据分析关注的问题
正在测试的软件哪一个模块的问题最多测试人员中谁报告的软件缺陷最多
各种缺陷所占的数量百分比分别是多少开发人员能及时修复软件缺陷吗
开发人员一次正确修复缺陷的百分比是多少正在开发的软件可否在计划的时间内正常发布