第三方测试报告的有效期是多久？什么时候需要重做？

这是所有问题里被问得最频繁的一个，而且提问的人通常心里已经有个预期答案：“是不是两年？”或者“一年总可以吧？”

很遗憾，这个问题没有统一答案。因为软件第三方测试报告本身没有法定有效期。

第三方测试报告

它不像计量校准证书那样有个明确的“有效期至”，也不像某些食品检测报告那样规定几个月有效。GB/T 25000.51 那套体系里压根没这一格。报告能证明的只有一件事：在报告第 X 页写的那个环境、那个时间点、那个版本上，对着当时约定的那些指标，测出来的结果是这个样子。

时间往前走一步，这句话的适用范围就缩一寸。所以真正决定“还能不能用”的，往往不是报告自己，而是收报告的那个人。

一、决定有效期的三个来源

第一顺位：要这份材料的文件。

招标文件、任务书、验收办法、入网规范里如果写了“须提供近一年内出具的第三方测试报告”或“报告签发日期须在项目执行期内”，那就按字面执行，没有任何讨论空间。有明确条款时，去争论“技术上没过期”毫无意义，人家卡的是形式要件。

第二顺位：系统有没有变。

这是最实质的那一层，下面单独展开。

第三顺位：行业惯例。

没人写的时候，多数甲方和评审会默认一年是个比较安全的数字，安全类的材料往往更短，半年甚至更短都很常见。但这只是惯例，不是规则，别拿它去跟一个较真的专家硬顶。

二、必须重做的六种情况

1. 版本号变了，而且不是补丁号。

V1.2 的报告管不了 V2.0，这是最没争议的一条。争议通常出在“我就加了两个小模块”上，你觉得小，验收的人不知道有多小，而报告里也没写。于是只能重做。

比较省的做法是提前约定：功能增量用回归或补充测试覆盖，只测变的部分。但前提是原报告留了需求—用例追溯矩阵，能证明哪些没动。如果当初那份报告只有结论页，对不起，只能全测。

2. 环境变了，尤其是信创迁移。

从 Windows 迁到麒麟，从 MySQL 迁到达梦，从 Intel 迁到国产 CPU，这种不是“微调”，是换了被测对象。拿着 x86 环境的报告去证明 ARM 上的表现，谁都圆不回来。

还有一个隐蔽的坑：生产环境配置比测试环境缩水了。测试用 16 核 32G，生产上了 8 核 16G，那组性能数字当场作废。这不是报告假，是它证明不了眼前这台机器。

3. 数据量级变了，性能结论失效。

两万条数据下跑出来的 2.8 秒，面对八百万条数据时没人会认。反过来也一样：老系统跑了几年的库，和新库的性能表现完全是两回事。

这条最容易在上线半年后被翻出来，因为那时候业务数据刚好涨上去了，系统开始慢，一查档案，报告里的数据量级对不上。

4. 指标本身变了。

任务书修订过、合同补充协议改过指标、甲方中途加了一条“还要支持某某浏览器”，只要判定依据变了，原来的符合性结论就对应不上新的尺子。这时候不是报告过期，是题目换了。

5. 报告的形式要件坏了。

这几种都算：机构认可资格被暂停或到期未续；认可范围本来就不包含你这一项；授权签字人离职没变更，或签字范围对不上；引用标准已废止；报告日期早于合同签订日期或版本构建日期；原始记录调不出来。

注意第五种里有一半跟测试做得好不好完全无关，纯粹是机构和人的问题。所以存档时顺手查一下机构资质状态，比你想的有价值。

6. 用途换了。

拿验收的功能性能报告去顶等保，拿产品质量评价报告去顶入网安评，拿高新那份去顶结题，这些体系不重叠。这不是有效期问题，是答非所问，但表现形态很像“报告过期了不能用”。

三、安全类材料老得特别快，得单独说

安全测试报告

漏洞扫描和渗透测试这类东西，本质是快照。它证明的是“扫的那一刻，按当时的库、当时的路径，发现了这些问题”。

第二天出了新 CVE，或者别人换条路径再走一遍，结论就可能不一样。所以安全类材料在绝大多数场景里都被要求得很新鲜：等保三级要求每年测评一次；入网安评、上线前检查普遍要求半年内，有的甚至要求三个月内；出过安全事件之后，基本默认以前的全部作废，重新来。

安全报告的“有效期”，其实是威胁情报的半衰期决定的，不是日历决定的。 这一点和功能性能报告完全不同，别用同一套思路去安排时间。

别纠结“有效期多久”，该问的是两件事：收报告的人认到什么时候，以及你的系统从出报告那天起变了多少。前者是形式，后者是实质。形式不符会被打回来，实质不符会在上线那天爆掉，后者比前者贵得多。

标签：软件测试报告、测试期限