问答（24） 如何区分测试报告和质量报告？
【背景】
前天，有个同学问了我一个基础问题，软件测试报告跟回归测试报告有何区别？测试细则又是什么呢？如果简单说来，软件测试报告你可以理解成一个统称，而回归测试报告只是其中一个子项。而测试细则，按我的理解，它其实是测试计划里的具体测试策略和步骤，是用于执行参考的，如果把它放到测试报告中，那应该就是表示测试的执行步骤和细节。而在实际的项目中，大家真正容易混淆分不清的其实是"测试报告"和"质量报告"。
【你问】
测试报告和质量报告应该如何区分？
【我答】
开篇先简单再补充回答一下背景中的问题，如果把软件测试报告定义成狭义的一种报告的叫法，那它就是每个项目在完成所有测试，准备发布上线时，由测试部门出具的一份测试报告，运维部门以此为上线活动的开始标志，我之前的公司就是如此，美国的发布经理不收到测试部门发出的测试发布报告，她是不会发出正式的工程发布报告的。
而回顾测试报告，其实可以理解成是跟每个测试包一一对应的回归测试总结，在很多公司，包括我之前那家公司，其实就是每日项目报告中的一项内容，并没有出具单独的报告。
言归正传，想问问你，能分的清测试报告和质量报告吗？你知道应该如何去区分它们吗？
你也许会跟我说，你当然能分的清楚，毕竟都做了这么多年项目了。
可我如果真的让你去写一份测试报告，可能你就会不那么清楚了，你可能会详细的罗列出项目中的所有测试环节、步骤、方法，发现的所有缺陷，以及缺陷产生的原因和分析，在各个环节中遇到的问题，甚至于你会把因为开发自测质量不高而导致需求提测时间延迟的问题也罗列其中，诸如此类的测试数据和问题分析混杂在一起，洋洋洒洒几十页，这是我们常见的一份"漂亮"且"充实"的测试报告。
我先不对这种报告做任何正确与否的评判，因为我一直认为，很多东西都没有明确的对错之分，有的只是是否适用于当下的场景。
还是让我先说说我是依据什么将测试报告和质量报告区分开来的，然后，我们再回过头来看看上述报告是否合适吧。
1、报告的阅读对象决定了这两种报告本质上的区别：
测试报告，阅读对象主要为负责产品版本发布的经理，在我之前的公司，职位名称叫 Release Manager（发布经理），他阅读这份报告的目的是想从其中获取到相应版本的质量，是否已经达到了可发布的标准，Pass（通过）, Faile（失败） or Pass with Risk（带着风险通过），我们完成了哪些测试工作，当前遗留的未解决 Bug 有多少，已知问题有哪些等等，当然，他也需要从这份报告中了解到这个版本有哪些需求和改动；
质量报告，阅读对象主要为负责产品研发的经理，在一些规模很大的企业，还有一个岗位的人员会看这份报告，那就是 EPG（过程改进小组），他们阅读这份报告的目的是想从罗列的问题和原因分析中找到所有可以改进的点，有可能是流程上的，也有可能是技术方法上的，当然，也可能就是人的问题，总之，他们就是想通过这份报告里的问题，找到可改进的地方，然后对其进行有计划地、循序渐进的改进。
我们再回到前文提到的那个"混合型"的报告，你现在应该能告诉我，它是否是一份合适的报告了吧？
对于产品研发经理或者 EPG （过程改进小组）来说，要么就是对版本需求和改动很熟悉了，要么就是只关注整个研发过程，并不关注产物本身的，你在报告里花大量篇幅罗列了需求和改动，没有任何意义。
对于发布经理来说，我只想你告诉我，当前质量是否能发布了，其他的问题都是你们研发过程或者研发团队的问题，我不关心（如果站在产品研发团队的经理角度来说，那些研发过程或研发团队的问题其实都是"家丑"，那你觉得该"外扬"吗？）
2、报告的编写人角色决定了这两种报告直观上的区别：
测试报告，编写人是测试经理或测试项目负责人；
质量报告，编写人是 QA，在 QA 由测试兼任的公司，也是由测试经理或测试负责人编写（我之前所在的外企就把测试和 QA 的职责合在一个岗位里，叫做 QA）
3、最后，我列出一些我认为在两种报告中较为关键的条目，但可以因地制宜，不全是必选项。
测试报告：
1、版本信息：包括所有发布组件的名称和版本号；
2、依赖关系：所有组件之间的依赖关系，是强依赖，还是弱依赖，如果有依赖关系，就一定要说清楚上线的部署顺序和原因，以免出现问题；
3、测试环境配置：包括服务器的系统版本、中间件的版本、数据库的版本、客户端的浏览器类型/版本，操作系统类型/版本等等；
4、已完成的测试范围、类型和方法，包括结果，如果做了性能测试，附上性能测试结果，如果做了安全测试，附上 应用程序Scan（一种安全扫描工具） 的扫描结果，如果执行了手工用例，附上用例的执行情况等等；
5、测试结论：版本发布的标准是什么？依据标准，该版本是否已经可发布，如果不可发布，原因是什么？如果是可带着风险发布，那风险有哪些？
6、已知问题清单：该版本截止到发布日期，还有哪些是未在当前版本得到修复的仍然存在的缺陷；
质量报告：
1、同类型项目的历史质量数据比对；
2、当前版本的质量期望目标；
3、经过统计分析过的缺陷分布图和缺陷修复曲线图；
4、针对过程中遇到的问题，所做的 3W 分析：
4.1 What's the problem？问题是什么？
4.2 What's the root cause？根本原因是什么？
4,3 What's the solution？解决方案是什么？
5、针对当前版本的质量问题（数据的和过程的）所作的总结分析和改进建议；
相关阅读：
版权声明：51Testing软件测试网获电子工业出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
