《测试路上你问我答》（98）什么样的测试报告才算得上是合格呢？

【背景】

有同学问过我，是不是只要我能在负责的功能模块里找到很多 Bug，就算是一个合格测试人员了？我回复他说，那只能说明你是一个达到及格线的测试人员，如果你想做到七八十分，或者是九十分的测试人员，还有很多找 Bug 之外的技能需要掌握，今天我们要说的如何编写测试报告就是其中之一。

【你问】

什么样的测试报告才算得上是合格呢？

【我答】

先用一句话来回答：能达到预期目标，实现相应作用的测试报告就是合格的。

通常我们所说的测试报告大致上分两类：一类是过程类报告，另一类是结果类报告。

过程类报告

【概念】

就是针对测试过程的状态、进度和中间结果的报告，我们最常见的就是测试进度报告，有些公司也称之为项目日报（Daily Project Report）、项目周报（Weekly Project Report）等等。

【合格要素】

1. 项目信息：项目名称、版本；
2. 资源信息：项目负责人、项目参与人；
3. 时间信息：当前项目里程碑阶段、下一个里程碑节点；
4. 进度信息：总的项目进度，通常用已完成 xx% 直观表示；
5. 任务清单：按测试计划里的任务分解表，列出主要任务或重点任务的概要清单，并逐一标注出未开始、进行中、已完成的状态；
6. 问题清单：按严重程度列出主要问题的清单，但不能只列问题，最重要的是要写出问题的解决进度和解决方案。报告里的问题只有两类：
   （1）一类是已经解决的，只需要写出影响程度、解决方案和结果即可；
   （2）另一类就是正在解决的，需要写出影响程度、解决方案，以及进度；
   并不存在未开始解决的问题，因为如果到了写报告的时候，问题还未开始解决，只能说明该问题并不严重或紧急，那也就没必要写在报告里了。

结果类报告：

【概念】

就是针对整个项目的测试结果的总结分析报告，也可以是某些特定测试的测试结果，我们最常见的就是测试发布报告（QA Release Report），还有安全测试报告、性能测试报告、兼容性测试报告等等。

【合格要素】

1. 基本信息：报告日期、项目名称、版本信息、项目类型、项目负责人、联系方式、评审人信息等等；
2. 项目背景：
   （1）主项目的 WIKI link 或者主项目计划的存储地址；
   （2）PRD、UI mock-up 或 SPEC 文档的存储地址；
   （3）项目的测试对象和测试范围；
   （4）项目的测试环境，包括软硬件环境和测试包的组成，比如服务端、管理后台、Android 和 iOS等；
   （5）测试版本的依赖关系：主要是发布版本的后端依赖组件及相应版本，例如：这次只是发布 Android 和 iOS 的客户端版本，那就在这里列出对应的服务端及版本；
3. 需求/功能测试信息：
   （1）项目里程碑计划表；
   （2）按测试计划执行的轮次表；
   （3）已测试范围详情（测试计划里已经列出的和未列出的）；
   （4）计划内的测试任务清单，包括任务责任人和相关功能检查、性能检查和安全检查测试结果（Done/Passed）；
   （5）未测试的范围详情：肯定有人会问，既然是最后的测试报告，为什么还会有未测试的，因为不同的项目有不同的情况（范围和时间），我们并不能保证在每个项目里都能做很完整的测试，所以罗列出哪些是因为什么原因没有测试的也很重要，这可以供项目经理参考做判断，即使有些测试没有做，是否也可以正常发布上线；
   （6）测试覆盖率和风险分析：一般用 xx% 来表示，对应着上面的（3）（4）（5）项，作用也同上；
   （7）缺陷数据统计摘要；
4. 系统级测试信息：
   （1）安装部署测试；
   （2）升级测试；
   （3）性能测试；
   （4）兼容性测试；
   （5）安全性测试；
5. 主要问题信息：这里说的问题等同于缺陷，因为理论上说，项目里通过测试发现的所有问题都应该以缺陷的形式记录下来；
   （1）未解决的问题级别分布概要，按级别和数量绘制的。优先级分为高、中、低；
   （2）未解决的问题类型分布概要，按类型和数量绘制的，类型分为已知问题、延后解决等；
6. 整体的质量评估：
   （1）发布质量标准；
   （2）整体的质量评估；
   （3）是否可发布的结论：Passed，Not Passed，or Passed with risk；
7. 附件信息：
   （1）发布版本的存储路径，包括发布版本包和测试报告等；
   （2）缺陷列表；

《测试路上你问我答》里的 Q&A 98，如果是你要的，甚好！如果不是，你问，我答！

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