第三十章 项目的测试报告和质量报告，你分的清吗？
临近测试执行阶段的尾声，我开始做功课研究怎么写测试报告，在做功课的过程中，看到好几个概念，于是，跑去跟老大请教：软件测试报告跟回归测试报告有何区别？测试细则又是什么呢？
老大说，如果简单说来，软件测试报告你可以理解成一个统称，而回归测试报告只是其中一个子项。而测试细则，它其实是测试计划里的具体测试策略和步骤，是用于执行参考的，如果把它放到测试报告中，那应该就是表示测试的执行步骤和细节。
老大问我，你做了不少功课，现在知道怎么写测试报告了吗？
我说会了，不就是罗列出项目中的所有测试环节、步骤、方法，发现的所有缺陷，以及缺陷产生的原因和分析，在各个环节中遇到的问题，比如因为开发自测质量不高而导致需求提测时间延迟的问题等等。
老大说，这是一份常见的测试报告和质量报告的混合体，我先不评判你这种报告做的是否正确，我先跟你说说测试报告和质量报告的区别吧，然后，我们再回过头来看看上述报告是否合适吧。
1. 报告的阅读对象决定了这两种报告本质上的区别：
测试报告，阅读对象主要为负责产品版本发布的经理，在我们公司，叫 Release Manager，他阅读这份报告的目的是想从其中获取到相应版本的质量，是否已经达到了可发布的标准，Pass, Faile or Pass with Risk，我们完成了哪些测试工作，当前遗留的未解决 Bug 有多少，已知问题有哪些等等，当然，他也需要从这份报告中了解到这个版本有哪些需求和改动。
质量报告，阅读对象主要为负责产品研发的经理，在一些规模很大的企业，还有一个岗位的人员会看这份报告，那就是 EPG，他们阅读这份报告的目的是想从罗列的问题和原因分析中找到所有可以改进的点，有可能是流程上的，也有可能是技术方法上的，当然，也可能就是人的问题，总之，他们就是想通过这份报告里的问题，找到可改进的地方，然后对其进行有计划地、循序渐进的改进。
我们再回到前文提到的那个“混合型”的报告，你现在应该能告诉我，它是否是一份合适的报告了吧？
对于产品研发经理或者 EPG 来说，要么就是对版本需求和改动很熟悉了，要么就是只关注整个研发过程，并不关注产物本身的，你在报告里花大量篇幅罗列了需求和改动，没有任何意义。
对于发布经理来说，我只想你告诉我，当前质量是否能发布了，其他的问题都是你们研发过程或者研发团队的问题，我不关心。换个角度，如果站在产品研发团队的经理角度来说，那些问题其实都是“家丑”，那你觉得该“外扬”吗？
2. 报告的编写人角色决定了这两种报告直观上的区别：
测试报告，编写人是测试经理或测试项目负责人，也就是你现在所承担的角色。
质量报告，编写人是独立的 QA 工程师，在 QA 由测试兼任的公司，也是由测试经理或测试负责人编写。
- 最后，我再跟你说说两种报告中较为关键的条目，但可以因地制宜，不全是必选项：
测试报告：
版本信息：包括所有发布组件的名称和版本号；
依赖关系：所有组件之间的依赖关系，是强依赖，还是弱依赖，如果有依赖关系，就一定要说清楚上线的部署顺序和原因，以免出现问题；
测试环境配置：包括服务器的系统版本、中间件的版本、数据库的版本、客户端的浏览器类型/版本，OS 类型/版本等等；
已完成的测试范围、类型和方法，包括结果，如果做了性能测试，附上性能测试结果，如果做了安全测试，附上 APPScan 的扫描结果，如果执行了手工用例，附上用例的 Run Infomation 等等；
测试结论：版本发布的标准是什么？依据标准，该版本是否已经可发布，如果不可发布，原因是什么？如果是可带着风险发布，那风险有哪些？
已知问题清单：该版本截止到发布日期，还有哪些是未在当前版本得到修复的仍然存在的缺陷；
质量报告：
同类型项目的历史质量数据比对；
当前版本的质量期望目标；
经过统计分析过的缺陷分布图和缺陷修复曲线图；
针对过程中遇到的问题，所做的 3W 分析：
What's the problem？
What's the root cause？
What's the solution？
- 针对当前版本的质量问题（数据的和过程的）所作的总结分析和改进建议；
《告诉你如何从执行测试到管理测试》带你迈出第（30）步！，点击这里可查看完整地图
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
