软件测试——缺陷报告的编写

1 软件缺陷

• 缺陷是一种泛称，它可以指功能的错误，也可以指性能低下，易用性差等
• 并不是所有的测试人员都能提交被开发认可的缺陷，也不是测试人员在任何时候都能提交被开发认可的缺陷

2 什么是软件缺陷

• 软件未达到产品说明书标准的功能
• 软件出现了产品说明书指明不会出现的错误
• 软件功能超出产品说明书指明范围
• 软件未达到产品说明书虽未指出但应达到的目标
• 软件测试员认为软件难以理解，不易使用，运行速度缓慢，或者最终用户认为不好

3 缺陷产生的原因

4 发现缺陷

• 用户体验不够好
• 界面上有明显的错误信息
• 功能不完备，没有按照需求说明编写代码，致使某些功能缺失
• 功能不完善，不能正常运行或者运行的过程中出现程序崩溃、停止运行的情况
• 逻辑不正确，与需求说明书，测试用例不符
• 模块之间的交互性不好，与其他的模块做集成测试的时候遇到问题
• 程序的性能不够好，不能承载压力考验

5 BUG处理的流程

6 缺陷报告

BUG重现

• 不要想当然的接受任何假设，要做好记录
• 查找时间依赖和竞争条件的问题
• 边界条件软件缺陷、内存泄漏和数据溢出等白盒问题可能会慢慢自己显露出来
• 状态缺陷仅在特定软件状态中显露出来
• 考虑资源依赖性和内存、网络、硬件共享的相互作用

7 无法重新的BUG

8 缺陷报告包含的信息

1 易于搜索软件测试报告的缺陷

2 报告的软件缺陷进行必要的隔离、报告的缺陷信息具体、准确

3 软件开发人员希望获得缺陷的本质特征和复现步骤

4 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度

9 缺陷报告的写作准则(5C)

1 correct(准确)：每个组成部分的描述准确，不会引起误解

2 clear（清晰）：每个组成部分的描述清晰，易于理解

3 concise（简洁）：只包含不可少的信息，不包括任何多余的内容

4 complete（完整）：包含复现该缺陷的完整步骤和其他本质信息

5 consistent (一致)：按照一致的格式书写全部缺陷报告

10 缺陷报告的组织架构

1 缺陷的标题

2 缺陷的基本信息

3 测试的软件和硬件的环境

4 测试的软件版本

5 缺陷的类型

6 缺陷的严重程度

7 缺陷的处理优先级

8 复现缺陷的操作步骤

9 缺陷的实际结构描述

10 期望的正确结果描述

11 注释文字和截图的缺陷图像

11 RART3-3缺陷报告原则

1 组织Structure：测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对待测试系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问题的地方

2 重现Reproduce：测试人员在编写缺陷报告之前必须在检查问题是否可复现。如果错误不可再重新，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写缺陷报告之前反复尝试3次

3 隔离lsolate：在尝试编写缺陷报告之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路

4 归纳Generalize：发现了一个已隔离的，可重现的问题之后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否更加严重的问题

5 对比compare：如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件以前的测试是否通过。如果是的话，那么这个问题就像是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。

6 总结Summarize:在缺陷报告的第一行写上错误的总结是非常关键的。测试人员要花一些时间思考已发现的错误对客户有什么影响。这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。

7 精简Condense：在缺陷报告的初稿完成后，测试人员应该反复阅读它，集中剔除没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节。

8 消除歧义Disambiguate：测试人员在精简空话的同时或其之后随即应该在仔细检查报告是否会产生误解的地方。

9 中立Neutralize：作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，独立的缺陷报告在措辞方面应该保持公正。

10 检查Review：一旦测试人员感觉缺陷报告是他能够编写的版本，他应该将报告再给一个或多个同行进行检查，在允许的时间内，尽量提交一份最好的测试报告。