一份软件验收测试报告用一系列可量化、可追溯的数据，回答了这个软件到底能不能验收。

一、报告结构

封面和声明

包含报告名称、软件版本、委托方和测试方信息，以及 CMA、CNAS 等资质印章。

摘要

供决定者快速阅读。直接给出通过、有条件通过或不通过的结果并汇总数据和风险。

测试概述

说明测试目的、测试范围、根据文档和测试环境。

测试执行情况

包含功能、性能、安全等各项测试的详细结果和数据。

缺陷统计和分析

所有发现问题的分级统计、修复状态和趋势分析。

遗留问题和风险

未解决问题的影响考虑和应对建议。

测试结果和建议

结果并给出确定的发布或整改建议。

二、数据逐项解读

测试用例通过率

数据一般包括总用例数、通过数、失败数、阻塞数、不适用数。如：共设计用例 500 条，通过 480 条，通过率 96%。

解读时不能只看总体数字。业务模块的通过率一般要求不低于99.5%。总体96%如果包含大量不重要模块，可能可以接受；但如果重要模块也只有96%，就是严重问题。

失败用例指向确定的功能缺陷。阻塞用例说明测试无法执行，可能由环境或前置功能失效导致。

缺陷统计

缺陷会按致命、严重、一般、建议分级。

致命和严重缺陷必须全部修复并回归通过，否则结果不可能是通过。如果报告中列有高危漏洞却结果为通过，这份报告基本可决定为无效或造假。

一般和建议缺陷可以协商是不是在本次版本修复，但要有确定处理计划。

理想趋势是测试后期新发现缺陷数量显著下降并趋于收敛。如果趋势线不断高企不降，说明软件质量远未稳定。

缺陷密度是缺陷总数除以软件规模，比如每千行代码缺陷数或每个功能点缺陷数。用于横向比较和趋势对比没有绝对统一标准。

缺陷修复率是已关闭缺陷除以发现缺陷总数。对于致命和严重缺陷，修复率必须为 100%。

性能测试标准

响应时间不要只看平均值，更要P95或P99响应时间。

举例：99 个请求耗时 0.1 秒，1 个请求耗时 10 秒，平均响应时间约 0.199 秒，看起来很好，但那1%的用户体验极差。P95 响应时间意味着 95% 的请求都在这个时间内完成，更能反映大多数用户的真实体验。验收标准应确定规定以 P95 或 P99 作为考核标准。

吞吐量是TPS或QPS，即系统每秒能成功处理的事务或查询数。要结合并发用户数来看，如在1000并发下TPS达到 980。同时要判断系统是不是达到性能拐点或饱和点，即吞吐量不再随压力增加而上升，反而下降的临界点。

资源利用率包括 CPU、内存、磁盘 I/O 的峰值使用率。如果 CPU 在测试中不断维持在 90% 以上，即便响应时间达标，系统也缺乏应对突发流量的余量，风险很高。

错误率指请求失败的比例，比如超时、5xx 错误。在高并发下错误率上升是系统过载的信号。

安全测试结果

报告中会列出高危、中危、低危漏洞的数量。

高危漏洞必须清零。只要存在未修复的高危漏洞，验收结果就只能是不通过或存在重大风险，不存在有条件通过的可能。

中危漏洞一般也要求在验收前修复，或制定确定的修复计划并考虑风险。

低危漏洞可以协商，但需记录在案，作为后续优化项。

需求包括率

需求包括率等于已测试需求数除以需求总数再乘以 100%。它通过需求追踪矩阵来体现，证明每一条需求都有对应的测试用例包括，一般要求达到 100%。

但注意用例包括率100%不等于场景包括率100%。测试用例一般根据需求文档设计，能包括所有已知功能点，但上线后的 Bug 往往来自异常场景、组合场景和大数据量场景。

三、结果和风险

通过：所有约定的标准均达标，无遗留的严重问题，建议立即发布。

有条件通过：非重点标准有遗留问题，但风险可控，且已制定确定的整改计划。报告中必须附有遗留问题清单和风险规避措施，并由建设方签字确定。放行前需完成特定缺陷的修复。

不通过：重点标准未达标，或存在未解决的致命、严重缺陷，或存在高危安全漏洞。需分析根本原因，进行整改后重新测试。

如果报告结果中出现基本通过、大致符合等词汇，一般意味着存在未解决的缺陷或标准偏差，在严格的验收中会被质疑甚至退回。