【落叶111】“老兵聊测试”之你分的清测试报告和质量报告吗？

文/秋之川

【目录】

这是《落叶》文集里第 111 片落叶，希望你能喜欢，不为别的，只为这份坚持。

你分的清测试报告和质量报告吗？

你也许会跟我说，你当然能分的清楚，都做了这么多年项目了。

可我如果让你去写一份测试报告，可能你就会不那么清楚了，你可能会详细的罗列出了项目中的所有缺陷以及缺陷产生的原因分析，或者你会把因为开发自测质量不高而导致的某个需求提测时间延迟的问题也罗列其中，等等诸如此类的测试结果数据和问题分析混杂其中，洋洋洒洒几十页。

在此，我先不对这种报告做任何正确与否的评判，因为我一直觉得很多东西都没有什么明确的对错之分，有的其实只是合适与否。我先阐述一下我是依据什么去将测试报告和质量报告区分对待的，我们再回过头来看看上述的报告是否合适吧。

我认为，阅读对象的角色就决定了这两份报告本质上的区别。

测试报告，阅读对象主要为负责产品版本发布的经理，在我之前的公司，职位名称叫 Release Manager，他阅读这份报告的目的是想从其中获取到相应版本的质量，是否已经达到了可发布的标准，Pass, Faile or Pass with Risk，当前遗留的未解决 Bug 还有多少，已知问题有哪些等等，当然，他也想从中知道这个版本有哪些需求和改动；

质量报告，阅读对象主要为负责产品研发的经理，在一些规模很大的企业，还有一个岗位的人员会看这份报告，那就是 EPG，他们阅读这份报告的目的是想从罗列的问题和原因分析中找到所有可以改进的点，有可能是流程上的，也有可能是技术方法上的，当然，也可能就是人的问题，总之，他们就是想通过这份报告里的问题，找到可改进的地方，然后对其进行有计划地、循序渐进的改进。

我们再回到前文提到的那个“混合型”的报告，你现在应该能告诉我，它是否是一份合适的报告了吧？

对于产品研发经理或者 EPG 来说，要么就是对版本需求和改动很熟悉了，要么就是只关注整个研发过程，并不关注产物本身的，你在报告里花大量篇幅罗列了需求和改动，没有任何意义。

对于发布经理来说，我只想你告诉我，当前质量是否能发布了，其他的问题都是你们研发过程或者研发团队的问题，我不关心（如果站在产品研发团队的经理角度来说，那些研发过程或研发团队的问题其实都是“家丑”，那你觉得该“外扬”吗？）

最后，附上我个人觉得比较理想的两种报告里，各自的一些关键项，并不是全部必备项。

测试报告：

1、版本信息：包括所有发布组件的名称和版本号；

2、依赖关系：所有组件之间的依赖关系，是强依赖，还是弱依赖；

3、测试环境配置：包括服务器的系统版本、中间件的版本、数据库的版本、客户端的浏览器类型/版本，OS 类型/版本等等；

4、已完成的测试类型和方法，以及结果，如果做了性能测试，附上性能测试结果，如果做了安全测试，附上 APPScan 的扫描结果等等；

5、测试结论：版本发布标准是什么？该版本是否已经达到了可发布标准，或者未达到（原因），或者是可带着风险发布，风险有哪些；

质量报告：

1、同期的历史质量数据比对；

2、质量结论；

3、经过统计归纳过的问题清单；

4、针对问题清单里每个问题的 WWW 分析：

   What's the problem？

   What's the root cause？

   What's the solution？

作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵

【目录】