目　录

一、核心结论：不强制“签维保合同”，但强制“建立受控闭环”

实验室最常见的误读是：准则要求所有设备必须签外部维保合同。这个理解是错误的。CNAS 与 CMA（现行评审准则）均未要求实验室对每一台设备签订外部维保/维修合同；真正的要求是：对“影响检测结果有效性的设备”（含软件工具）建立并运行一套完整的控制闭环。

1.1 一句话结论

是否“必须维保”取决于风险判定，而非设备名称。只要设备/软件的输出会进入检测结果、或影响结果有效性，就必须纳入“维护—验证—溯源/核查—故障处置—记录”的受控流程。至于这个维护由谁做（原厂、代理商、实验室自己），准则不做强制；实验室具备相应能力时，完全可以自维护并留存证据。

1.2 软件测试工具的定性

软件测试工具（性能、安全、功能自动化、兼容性、静态/动态分析、仿真、测试管理，以及自研脚本、开源工具、客户提供的工具等）在 CNAS-CL01-A019 中明确属于“软件测试设备”（6.4.1）。因此：

它必须纳入设备/设施管理，建立台账并赋予唯一性标识；

投用前必须核查/确认（6.4.4、A019 6.4.1、6.4.4）；

必须做版本管理与配置控制，防止误用（A019 6.4.3）；

必须保留设备档案（A019 6.4.13）；

不等于“必须做计量校准”——多数纯软件工具不产生可溯源物理量，改用功能/性能确认与定期核查即可，这正是软件实验室与硬件实验室最大的差异。

1.3 判定矩阵：什么才叫“必须做”

关键原则：“维保”在软件领域的内涵被替换为“维护（maintenance）+ 验证（verification）”。评审员不看你有没有维保合同，看你能不能证明工具在整个生命周期内始终适用、可信、可追溯。

二、法规依据：CNAS 与 CMA 双线对照

本章给出可直接写入体系文件“编制依据”章节的权威来源。

2.1 CMA 现行依据

现行文件：《检验检测机构资质认定评审准则》（市场监管总局 2023 年第 21 号公告），2023 年 12 月 1 日起施行。

配套释义：市场监管总局认可检测司《关于印发〈检验检测机构资质认定评审准则〉条文释义的函》（市监检测〔司〕函〔2023〕37 号）。管理体系建设可参照 GB/T 27025-2019（等同 ISO/IEC 17025:2017）。

2.2 核心条款逐条对照

注：软件测试实验室还需关注《软件检验检测机构资质认定评审补充要求》（2026 年 4 月 17 日发布征求意见稿，计划 2026 年 9 月 1 日起施行）。正式发布后，其设备条款（第十三条至第十七条）与 A019 高度对齐，可作为更细化的落地依据——但成文时仍应以正式发布版本为准。

三 、软件测试工具的具体管控要求

以下要求同时覆盖 CNAS-CL01-A019 与 CMA 现行评审准则，可视为软件实验室的“最小合规集”。

3.1 “正式软件”与版本正确性（A019 6.4.1）

测试环境中所有测试软件应为正式软件或与客户约定的软件，且版本正确。

正式软件：按程序得到验证、通过批准的货架软件（商用，有官方授权与版本号）；或经同行专家技术鉴定的非货架软件（开源、自研）。

版本正确性：每个项目使用的工具版本必须与测试方法/作业指导书规定的一致，不同版本唯一性标识，禁止生产环境混用。

快速验证：可运行一小组测试，验证工具（含嵌入式工具配套硬件）已正确安装（A019 6.4.1 注 2）。

3.2 投用前确认（A019 6.4.4 + CL01 6.4.4）

有指标要求的工具，初次使用前核查其使用范围（如宣称支持 500 并发的性能工具，须验证其达到要求）；

商用、开源、自研、客户提供工具一律做适用性确认（CMA 补充要求第十三条/十四条精神）；

租赁/借用工具：每次投用前核查，且须有合法许可/授权协议（A019 结合 CL01-G001 6.4.1 a）。

3.3 版本管理与配置控制（A019 6.4.3）

版本升级、打补丁、插件变更、配置改动须申请、评审、再确认；

旧版本封存或标注，禁止与现行版本混用；

配套项：测试脚本、测试用例、测试数据、配置文件一并纳入配置管理，保证与工具版本一致。

3.4 无法传统溯源时的有效性验证（A019 6.5.3）

新工具或重大更新无法溯源到国家或国际测量标准时，用替代方案证明“溯源性效果”，证据可包括：

对特定测试样例软件测试，审查预埋问题的复现情况并确认偏差；

溯源至权威测试集规范，提供所得结果与预期结果比较，列出已知缺陷；

适用时在报告中标明结果溯源至国际标准测试集/权威测试集；

规范与测试用例实现存在重大差异时，说明每个用例如何真实来源于规范，保留判定/测量信息。

3.5 环境与隔离（A019 6.3.3/6.3.4 b）

测试机、测试网络与项目外网络有效隔离；防病毒软件及时升级并记录；测试前核查环境；

多个项目并行时保持测试环境有效分离；远程测试时控制网络与运行条件；

测试环境与运行环境不一致时，做差异性分析并说明对结果的影响。

3.6 自动化软件正确性验证（评审准则第十二条(八)）

对数据采集、处理、记录、报告、存储、检索类自动化软件，验证其正确性并保留记录；

含信息化管理系统（LIMS）、数据采集/处理系统；

体系文件须含数据完整性、安全性、防伪造篡改措施，防止未授权访问。

四、实验室具体应对方案（可直接落地）

本章给出“程序—台账—计划—记录”四件套，实验室可直接照此建立或修订现有体系。

4.1 第一步：设备/工具分类与风险分级

按“是否影响结果 + 是否输出物理量”分为四类，决定控制强度：

分级结论：A 类走“校准”主线，B/C/D 类走“确认 + 核查”主线。绝大多数软件工具落在 B 类，因此“不需要校准、不需要外部维保”是常态，但“必须确认、必须留证”是底线。

4.2 第二步：建立台账与唯一性标识

每一工具/设备一条档案（A019 6.4.13 + 评审准则第十一条），建议字段：

• 基本信息：工具类型、名称、生产厂商、版本号、用途与性能、启用时间、主要选件；

• 合规信息：许可证书/授权文件、合同文件、技术文件、运行平台；

• 受控信息：唯一性编号、状态标识（在用/停用/测试中/封存）、责任人、存放/部署位置；

• 溯源信息：确认/核查方式、周期、最近日期、结论、下次计划日期；

• 变更信息：版本升级、配置改动、再确认结论、批准人。

标识要求：正在测试的设备贴“测试中”标识（A019 6.4.12），屏保设置标识，避免误调整；需检定/校准或有有效期的设备，标识须让使用人一眼识别功能状态与有效期。

4.3 第三步：编制维护与核查计划

计划按风险制定，而非一刀切。频次参考下表（实验室可据稳定性、使用频率、故障史调整，并在程序中说明判定理由）：

举证责任提醒：评审逻辑是“你需要时你就要做”，举证责任在实验室。对于关键、高频、高精度、历史故障多的设备，若不安排期间核查，必须在风险评估中书面说明理由——不能只写“不需要”。

4.4 第四步：投用前确认与变更再确认的实施方法

按工具类型给出可执行的确认手段：

输出物：每项确认形成《测试工具确认报告》，含工具标识、版本、确认方法、标准/样例来源、结果、结论、批准人、再确认触发条件。

4.5 第五步：故障、异常与不符合处置闭环

• 发现异常/可疑结果 → 立即停用该工具/设备，贴“停用”标识并隔离；

• 评估该异常对已出具结果的影响（影响区间、是否需通知客户/撤回报告）；

• 维修/修复 → 修复后通过确认/核查/校准正常，方可解除停用；

• 重大变更或无法判定时→ 走不符合工作控制，必要时复测受影响项目；

• 全部过程记录并归档，作为内审与管理评审输入。

4.6 第六步：外部维保的决策规则（要不要签合同）

实验室可自行维护，也可外包。按下表决策，并在《设备管理程序》中写明：

五、记录表单清单（最小集）

以下表单构成“做过且有效”的证据链，建议纳入受控记录清单：

• 《检测设备/软件工具总台账》

• 《测试工具软件版本/配置变更记录》

• 《设备/工具投用前确认报告》《期间核查计划与报告》

• 《检定/校准结果确认表》《计量溯源计划》

• 《设备维护保养记录》《设备使用记录》《设备状态标识（标签/屏保）》

• 《测试工具软件更新/再确认记录》《设备软件更新记录》

• 《设备停用/报废申请》《维修申请与修复验证记录》

• 《不符合工作（设备/软件类）处置记录》《受影响结果评估记录》

• 《租（借）用设备情况表》《委托方提供设备登记表》

• 《自动化软件正确性验证记录》《数据完整性与访问权限控制记录》

5.1 台账关键字段示例（可直接建表）

六、迎审要点：评审员会怎么查

把证据组织成“评审员逻辑”，做到随时可答、可查、可追溯：

6.1 高频提问与应答要点

6.2 评审现场检查清单

• 随机抽 3–5 个在用工具，能立刻调出：台账 + 版本 + 确认报告 + 最近核查记录；

• 抽查一个版本升级/配置变更，确认有申请、评审、再确认、批准闭环；

• 抽查一台故障/停用设备，确认标识、隔离、影响评估、修复验证齐全；

• 核对需溯源硬件的证书有效期与状态标识，确认修正信息已利用、更新、备份；

• 核查自动化软件（LIMS/数据处理）正确性验证记录与数据访问控制；

七、常见不符合项与风险提示

7.1 一句话风险提示

最大风险不是“没签维保合同”，而是“无法证明工具输出可信且全程受控”。只要台账、确认、版本、核查、故障、记录六条证据链完整，无论自维护还是外包维保，都可通过评审。

附录　实施路线图（建议 4 周完成）