测试报告
测试报告记录测试覆盖了哪些条件、实际执行了什么、发现了什么，以及结论还有哪些限制。它既要让读者判断当前风险，也要让开发者能够从一个失败项回到请求、数据和运行证据。
通过率是报告中的一个统计值，不能独立代表产品质量。测试范围少、关键用例被跳过或重试历史被覆盖时，数字很好看，实际证据却可能不足。
1. 面试核心
先记住这几条，再读正文- 报告应关联目标、版本、环境、范围、结果、缺陷和未验证风险，结论只能覆盖已经提供证据的条件。卡 · 范围、结果与结论
- 通过、失败、准备错误、跳过和未开始具有不同含义，通过率必须写清分母。卡 · 状态与统计分母
- 失败项需要稳定用例标识和本次运行证据，重试不能覆盖首次失败，否则无法判断稳定性。卡 · 失败证据与重试历史
- Allure 等工具组织框架输出与附件，报告生成成功不代表用例执行成功。卡 · 报告工具与执行链路
- 必要结果或产物缺失时应标记证据不足，没有失败记录不能被当成全部通过。卡 · 缺失证据与决策
2. 范围、结果与结论
测试报告先说明正在回答哪个问题，例如某次发布的关键交易流程是否满足验收条件。然后给出对应证据，避免先展示一个与目标无关的总分。
| 内容 | 需要说明 |
|---|---|
| 被测对象 | 版本、提交或不可变制品、相关配置 |
| 环境与数据 | 部署、依赖、数据基线、账号和隔离范围 |
| 测试范围 | 需求、风险、用例集合、实际选择与排除 |
| 执行结果 | 各状态数量、时间窗口、耗时与重试 |
| 问题证据 | 失败详情、缺陷、影响和复现条件 |
| 剩余风险 | 未执行、受阻、仅替身覆盖及已知限制 |
| 结论 | 对哪些条件提供了什么判断，以及需要补充什么 |
例如“订单创建和取消流程在测试版本 A、环境 B 中通过；支付回调因测试依赖不可用未执行”，比“本轮通过率 98%”更有助于判断发布风险。
报告不替代缺陷记录。失败可能来自产品、脚本、环境或预期规则，确认后再关联缺陷及处理状态，具体过程见缺陷管理。
3. 状态与统计分母
不同框架的状态名称并不完全相同，报告需要说明映射。尤其不要把所有没有成功的用例都归为同一种失败。
| 状态含义 | 典型证据 |
|---|---|
| 通过 | 目标检查已执行且满足断言 |
| 断言失败 | 实际结果与期望不符 |
| 准备或执行错误 | 夹具、依赖、脚本或执行器异常 |
| 跳过 | 有明确规则或原因决定不执行检查 |
| 未开始或未完成 | 任务中断、未调度、结果丢失等 |
| 预期失败及意外通过 | 框架对已知失败条件的专门标记 |
状态与根因要分开。一个网络异常被框架记作 error，不代表一定是环境问题；一个断言失败，也可能是预期值写错。状态描述发生了什么，根因分类需要继续分析。
假设计划有 100 个用例：80 个通过、5 个断言失败、10 个跳过、5 个尚未开始。若通过率定义为“通过数除以完成结果判定的用例数”，则是 80 / 85 ≈ 94.1%。
这个数字没有表达另 15 个用例的风险。报告还应给出计划总数、完成判定的 85 个、跳过的 10 个及未开始的 5 个，并列出关键受阻范围。不能把跳过项放进成功数，也不能因为它们没运行就从计划范围中消失。
比较两轮测试时，需要先确认用例集合、参数化展开、环境和统计单位一致。删掉困难用例后通过率提高，并不能说明产品变好。一个场景展开成多个参数用例，也会改变总数，报告应保留场景与具体用例的对应关系。
4. 失败证据与重试历史
运行标识区分每次测试执行，用例标识区分被测行为，尝试标识区分同一用例的初次执行与重试。三者共同让结果可以追踪。
失败项至少应关联当时版本、环境、输入或数据标识、期望与实际、失败阶段、时间和必要日志。接口测试可附请求关联标识、脱敏请求响应；浏览器测试可附截图和 trace；异步流程还应关联消息或任务状态。
证据要能定位，也要控制内容。密码、令牌和无关个人数据不应完整进入报告；超大响应和日志应有大小与保留限制。若内容被截断，应标明截断，避免把一段片段当成完整事实。
重试后通过需要同时保留首次失败和最终状态。可以分别报告首次通过率、最终通过率、经历重试的用例数量及重试成本，而不是用最后一轮覆盖全部记录。
例如前面 5 个失败用例重试后有 3 个通过，最终成功数变为 83，但仍有 5 个用例发生过首次失败。后续要区分产品竞态、共享数据、环境波动与脚本缺陷，不能自动把它们全部贴成“偶发，无需处理”。
5. 报告工具与执行链路
报告工具通常消费测试框架产生的结构化结果，再关联步骤、附件和历史，形成便于阅读的页面。例如 Allure 通过各框架适配器收集结果，报告展示状态、步骤、参数和附件；具体状态如何映射，取决于框架与适配器。
这条链路有多个独立成功条件：测试已发现并运行、框架产生结果、结果被完整保存、报告生成、产物上传以及门禁读取结果。任意一环失败都应保留自身状态。
可以用以下反例验证流水线：
- 故意写错一个断言，确认测试失败能传到最终任务状态。
- 选择一个不会收集到测试的范围，确认空结果不会被算成成功。
- 让报告生成或上传失败，确认执行结果仍被保留，并显示产物问题。
- 让同一用例重试，确认页面能够找到首次失败和后续尝试。
pytest 的退出状态见 pytest，JMeter 的采样结果门禁见 JMeter。工具之间处理方式不同，流水线应按实际语义读取，不能统一假设“进程退出 0 就全部通过”。
6. 缺失证据与决策
如果预期 100 个用例，只收到 60 个结果，需要先查明另外 40 个是未选择、未启动、被取消还是丢失。没有结果本身就是需要解释的状态，不能把它们从分母删掉后给出完整通过结论。
若关键截图丢失，但断言、请求和日志完整，可能仍能判断用例结果，只是定位证据不足；若主要判定结果没有保存，就不能声称测试通过。应按产物用途区分，不把所有附件都当成同样重要，也不忽略必要证据。
报告最后把结论与范围对应起来：已验证哪些行为、存在什么明确问题、哪些风险仍没有证据。发布门槛应来自项目约定和风险，而不是临时挑一个好看的通过率。高影响的单个失败，可能比大量低风险用例通过更需要先处理。
7 · 面试题卡片
本页题目与参考回答
7.1 一份接口测试报告应包含哪些内容？
考察重点：执行范围、证据与风险判断。
参考回答
包含版本、环境数据、需求与用例范围、各状态结果、失败证据、关联缺陷和未验证风险。 接口失败应能追溯脱敏请求响应、数据标识及服务端关联日志。
结论对应已执行条件，说明哪些关键流程通过、哪些失败或受阻。通过率只能作为其中一项统计，不能代替风险说明。
7.2 100 个计划用例中有 15 个未执行，怎样报告通过率？
考察重点：分母、跳过、未开始和计划范围。
相关内容：状态与统计分母。
参考回答
先明确公式，再同时报告计划、完成判定、跳过和未开始数量。 例如 80 通过、5 失败时，按已完成判定的 85 个计算为约 94.1%，但另外 15 个不能从风险说明中消失。
跳过不算通过，关键未执行项要说明原因和影响。比较轮次时还要保持用例范围和计数单位可比。
7.3 失败用例重试通过后，报告应该保留什么？
考察重点：首次结果、尝试历史与不稳定性。
相关内容：失败证据与重试历史。
参考回答
保留首次失败、每次尝试、最终状态、环境和对应证据，并单独统计重试次数和成本。 最终通过不能抹去曾经失败的事实。
随后根据日志、数据和时序定位原因。必要时区分首次与最终通过率，避免用重复运行掩盖产品竞态或测试污染。
7.4 Allure 报告在自动化流水线中承担什么职责？
考察重点：框架结果、展示产物与任务门禁。
相关内容：报告工具与执行链路。
参考回答
它组织测试框架输出、步骤、参数、附件和历史，使结果便于阅读和追踪。 测试框架仍负责执行与断言，报告生成不等于用例通过。
流水线需要分别处理执行、结果保存、报告生成上传和门禁。用断言失败、空结果及产物失败反例确认各阶段不会误报成功。
7.5 测试日志没有失败，但结果文件不完整，可以报告通过吗？
考察重点：预期数量、必要证据与未知状态。
相关内容：缺失证据与决策。
参考回答
不能直接报告通过，需要解释缺失结果并确认必要判定证据。 未运行、被取消和结果丢失都不等于成功。
对照预期用例集合和执行记录，说明已确认结果及剩余未知范围。辅助附件缺失和主要判定结果缺失的影响不同，应分别标记。
8. 参考资料
来源：Coding 101 原文 · 免费阅读，引用请保留出处。内容使用说明