软件测试学习35-执行阶段：软件缺陷管理
1、缺陷概述
软件缺陷-基本概念主要分为：缺陷、故障、失效。
- 缺陷（Defect）：以静态形式存在于软件内部，相当于BUG；
- 故障（Fault）：软件运行中出现的状态，不处理可能会失效，以动态形式存在；
- 失效（Failure）：软件运行时产生的外部异常行为结果，与用户需求不一致。
缺陷不一定导致故障，故障也不一定会失效；缺陷导致故障，有可能导致失效，也有可能不会导致失效。
2、缺陷定义
- 软件未达到产品说明书标明的功能
- 软件出现了产品说明书指明不会出现的错误
- 软件功能超出产品说明书指明范围
- 软件未达到产品说明书虽未指出但应达到的目标
- 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好
3、缺陷识别
- 通过测试用例中的预期结果进行识别通过需求规格说明书进行识别
- 通过用户手册及其他文档进行识别通过同行业相类似成熟的商业软件识别
- 通过与开发人员的沟通进行识别通过与有经验测试人员沟通进行识别
- 通过参照同行业隐式需求进行识别
4、缺陷重现
注意事项
- 不要想当然地接受任何假设要作好记录
- 查找时间依赖和竞争条件（如：前置条件）的问题
- 边界条件软件缺陷、内存泄露和数据溢出等白盒问题可能会慢慢自己显露出来
- 状态缺陷仅在特定软件状态中显露出来
- 考虑资源依赖性和内存、网络、硬件共享的相互作用
无法重现时的处理
- 首先，应当对这样的缺陷进行详细的记录，并尽快提交给开发人员
- 其次，对于寻找难以再现的缺陷要合理地安排时间，要考虑到测试项目的整体进度，对一时难以再现的缺陷可以暂时搁置，以保证项目的正常进度
- 最后在测试过程中对未再现缺陷予以关注
5、缺陷报告(缺陷记录)
报告目的
- 保证每个缺陷都被修改
- 保证每个缺陷都被回归
- 缺陷的完整性和一致性
- 避免纠纷，降低沟通成本
报告意义
- 提高工作效率（BUG分类，状态负责人）
- 记录唯一的缺陷信息，保证BUG完整一致（通过设置权限实现）
- 记录中间环节，是BUG可追溯
- 为测试报告提供数据
写作要求
- 缺陷文案易于搜索软件测试报告的缺陷
- 报告的软件缺陷进行了必要的隔离（隔离：即错误出现的节点或原因），报告的缺陷信息具体、准确
- 软件开发人员希望获得缺陷的本质特征和复现步骤
- 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度
写作准则（5C）
Correct(准确)：每个组成部分的描述准确，不会引起误解
Clear(清晰)：每个组成部分的描述清晰，易于理解
Concise(简洁)：只包含必不可少的信息，不包括任何多余的内容
Complete(完整)：包含复现该缺陷的完整步骤和其他本质信息
Consistent(一致)：按照—致的格式书写全部缺陷报告
报告内容
- 缺陷的标题
- 尽量按缺陷发生的原因与结果的方式书写(“执行完A后，发生B，”或者“发生B，当A执行完后
- 避免使用模糊不清的词语，例如“功能中断”“功能不正确″“行为不起作用”等。应该使用具体文字说明功能如何中断，如何不正确，或如何不起作用
- 为了方便搜索和查询，请使用关键字
- 为了便于他人理解，避免使术语、俚语或过分具体的测试细节
- 测试的软件和硬件环境
- 测试的软件版本
- 缺陷的类型
- 缺陷的严重程度
- 缺陷的处理优先级
- 缺陷的重现步骤
- 复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的
- 但是实际软件测试过程中，总是存在一些不良的缺陷报告要的问题在于多余步骤、可读性差、难以理解、缺失步骤等
- 提供测试的预备步骤和信息
- 简单地一步一步地引导复现该缺陷
- 每一个步骤尽量只记录一个操作
- 每一个步骤前使用数字对步骤编号
- 尽量使用短语和短句，避免复杂句型和句式
- 复现的操作步骤要完整，准确，简短
- 没有缺漏任何操作步骤
- 每个步骤都是准确无误的
- 没有任何多余的步骤
- 将常见步骤合并为较少步骤
- 只记录各个操作步骤是什么，不需要包括每个步骤的执行结果
- 实际结果描述
- 预期结果描述
- 注释文字和截取的缺陷图像
拓展
一、缺陷报告十大原则
- 组织 Structure：测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对待测系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问题的地方
- 重现 Reproduce：测试人员在编写缺陷报告之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写缺陷报告之前反复尝试3次。
- 隔离 Isolate：在尝试编写缺陷报告之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。
- 归纳 Generalize：发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否岀现在其他的模块或其他的地方?同一个故障是否有更加严重的问题?
- 对比 Compare：如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件以前的测试是否通过。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果
- 总结 Summarize：在缺陷报告的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级另
- 精简 odense：在缺陷报告的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是缺陷报告的目标。
- 消除歧义 Disambiguate：测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。
- 中立 Neutralize：作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，独立的缺陷报告在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从提高产品质量”这个大的目标上转移开了
- 检査 Review：一旦测试人员感觉缺陷报告是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。在允许的时间里，测试小组应该尽可能提交最好的缺陷报告
浙公网安备 33010602011771号