文/秋之川
这是《落叶》文集里第 321 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【背景】
有同学问过我，是不是只要我能在负责的功能模块里找到很多 Bug，就算是一个合格测试人员了？我回复他说，那只能说明你是一个达到及格线的测试人员，如果你想做到七八十分，或者是九十分的测试人员，还有很多找 Bug 之外的技能需要掌握，今天我们要说的如何编写测试报告就是其中之一。
【你问】
什么样的测试报告才算得上是合格呢？
【我答】
先用一句话来回答：能达到预期目标，实现相应作用的测试报告就是合格的。
通常我们所说的测试报告大致上分两类：一类是过程类报告，另一类是结果类报告。
过程类报告
【概念】
就是针对测试过程的状态、进度和中间结果的报告，我们最常见的就是测试进度报告，有些公司也称之为项目日报（Daily Project Report）、项目周报（Weekly Project Report）等等。
【合格要素】
- 项目信息：项目名称、版本；
- 资源信息：项目负责人、项目参与人；
- 时间信息：当前项目里程碑阶段、下一个里程碑节点；
- 进度信息：总的项目进度，通常用已完成 xx% 直观表示；
- 任务清单：按测试计划里的任务分解表，列出主要任务或重点任务的概要清单，并逐一标注出未开始、进行中、已完成的状态；
- 问题清单：按严重程度列出主要问题的清单，但不能只列问题，最重要的是要写出问题的解决进度和解决方案。报告里的问题只有两类：
（1）一类是已经解决的，只需要写出影响程度、解决方案和结果即可；
（2）另一类就是正在解决的，需要写出影响程度、解决方案，以及进度；
并不存在未开始解决的问题，因为如果到了写报告的时候，问题还未开始解决，只能说明该问题并不严重或紧急，那也就没必要写在报告里了。
结果类报告：
【概念】
就是针对整个项目的测试结果的总结分析报告，也可以是某些特定测试的测试结果，我们最常见的就是测试发布报告（QA Release Report），还有安全测试报告、性能测试报告、兼容性测试报告等等。
【合格要素】
- 基本信息：报告日期、项目名称、版本信息、项目类型、项目负责人、联系方式、评审人信息等等；
- 项目背景：
（1）主项目的 WIKI link 或者主项目计划的存储地址；
（2）PRD、UI mock-up 或 SPEC 文档的存储地址；
（3）项目的测试对象和测试范围；
（4）项目的测试环境，包括软硬件环境和测试包的组成，比如服务端、管理后台、Android 和 iOS等；
（5）测试版本的依赖关系：主要是发布版本的后端依赖组件及相应版本，例如：这次只是发布 Android 和 iOS 的客户端版本，那就在这里列出对应的服务端及版本； - 需求/功能测试信息：
（1）项目里程碑计划表；
（2）按测试计划执行的轮次表；
（3）已测试范围详情（测试计划里已经列出的和未列出的）；
（4）计划内的测试任务清单，包括任务责任人和相关功能检查、性能检查和安全检查测试结果（Done/Passed）；
（5）未测试的范围详情：肯定有人会问，既然是最后的测试报告，为什么还会有未测试的，因为不同的项目有不同的情况（范围和时间），我们并不能保证在每个项目里都能做很完整的测试，所以罗列出哪些是因为什么原因没有测试的也很重要，这可以供项目经理参考做判断，即使有些测试没有做，是否也可以正常发布上线；
（6）测试覆盖率和风险分析：一般用 xx% 来表示，对应着上面的（3）（4）（5）项，作用也同上；
（7）缺陷数据统计摘要； - 系统级测试信息：
（1）安装部署测试；
（2）升级测试；
（3）性能测试；
（4）兼容性测试；
（5）安全性测试； - 主要问题信息：这里说的问题等同于缺陷，因为理论上说，项目里通过测试发现的所有问题都应该以缺陷的形式记录下来；
（1）未解决的问题级别分布概要，按级别和数量绘制的。优先级分为高、中、低；
（2）未解决的问题类型分布概要，按类型和数量绘制的，类型分为已知问题、延后解决等； - 整体的质量评估：
（1）发布质量标准；
（2）整体的质量评估；
（3）是否可发布的结论：Passed，Not Passed，or Passed with risk； - 附件信息：
（1）发布版本的存储路径，包括发布版本包和测试报告等；
（2）缺陷列表；
《测试路上你问我答》里的 Q&A 98，如果是你要的，甚好！如果不是，你问，我答！
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
