专家视角｜初次申请CNAS软件测试实验室时，认可范围怎么选？是不是越大越好？

很多实验室在筹备 CNAS 认可的第一步，都会在同一个问题上有所疑虑：申报的检测能力范围，到底填多少合适？

一种想法是“多报点，反正以后总用得上，一次评审全拿下”；

另一种想法是“少报点，先把证拿到手再说，后面慢慢扩项”。

这篇文章我们把这么多项目经验中总结出来一些思路跟大家聊一聊，看看这两种思路在后期可能会带来哪些问题。

一、CNAS软件测试相关的范围

CNAS 认可证书的附件里，会明确列出实验室有资格出具带 CNAS 标识报告的检测能力清单，这份清单就是通常说的"认可范围"。它由两个维度构成：

依据标准：你按什么标准测；

检测项目/参数：在这个标准下，你具体能测哪几项。

领域划分的依据是 CNAS-AL06《实验室认可领域分类》，软件检测实验室在申请、以及在 CNAS 官网查询信息时，都会用到这个文件及其中的领域代码。你申报的每一项能力，最后都要能对应到 CNAS-AL06 的分类表和具体的标准条款上。

1. 依据标准层面：范围是"按标准划分"出来的

软件检测实验室检测能力范围的分类，主要是根据实验室技术方法的选择所依据的标准来划分的。

也就是说，CNAS-AL06 提供的是领域和分类的框架，而实验室具体能报什么，最终落点在你选用了哪些标准、以及按这些标准具备了多少能力。同一类测试内容，换一个标准依据，就是另一条申报项。

软件检测实验室常用的依据标准，较为常用的大致可以分成四类：

（1）通用软件产品质量标准

核心是 GB/T 25000.51-2016《系统与软件工程 系统与软件质量要求和评价（SQuaRE）第51部分：就绪可用软件产品（RUSP）的质量要求和测试细则》。

（2）代码测试（源代码漏洞测试）类标准

代码测试是软件安全测试的重要一支，也是近年实验室扩项比较多的方向。是按程序设计语言分列的国家标准：

这三个标准在漏洞类型上有大量交集，也各有专属项。例如 Java 标准中特有的"可序列化的类""包含敏感数据""会话永不过期""关键参数篡改"；C/C++ 标准中特有的"堆检查""缓冲区溢出""使用外部控制的格式化字符串""敏感信息存储于上锁不正确的内存空间""公有函数返回私有数组""整数溢出"。

（3）测试过程与方法类标准

如GB/T 15532-2008（软件测试文档编制规范），用于支撑测试过程的规范性和可复现性。

（4）专项/领域类标准

信息安全方向：GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》及配套的 GB/T 28448，GB/T 34975-2017（移动智能终端应用软件安全）、GB/T 38674（个人信息安全）等；

行业与嵌入式方向：GJB141（军用软件测试/嵌入式软件测试）、IEC 61508（工业功能安全）、ISO 26262（汽车功能安全）、EN 303645（物联网信息安全）等；

新兴方向：工业 APP、低代码开发平台、人工智能系统、大数据系统的专项测试要求。

2. 检测项目层面：同一标准下的项目可以拆开申请

这是初次申请时最关键的一点：标准下的项目不是"打包必选"的，可以只申请其中某一项或某几项。 

以最主流的 GB/T 25000.51-2016 为例，实验室可以根据自身能力挑选，不必全报。

GB/T 25000.51-2016 下的常见申报项及难度大致如下：

（注意：该表仅供参考！如需了解相关项目细节，可以后台私信交流）

二、不是"越大越好"，而是"匹配最好"

每一项评审组都会验证：

方法验证/方法确认记录——这个方法你们确实学过、试过、验证过；

设备与设施——测这个项目需要的工具、环境、场地，有就是有，没有就是没有；

人员能力——培训记录、能力确认、岗位授权、监督记录；

检测经历——每个申请的项目，都要有可追溯的典型报告（检测经历）；

能力验证/测量审核/实验室间比对——证明结果不只在自己家里准；

体系文件——作业指导书、原始记录表格、报告模板、不确定度评估等。

每多申请一个项目，相应的资料就要多准备一份。 而且这不是一次性的工作，拿到证书之后，每年的监督评审、到期复评，都会按认可范围逐项检查。

范围报大了，但是实际用不到，这在后期的资质维护过程中，也会产生不少工作量。

所以更推荐的做法是：初次申请时，范围应当覆盖你的主营业务的必要项目，同时不超过你现有资源能稳定支撑的边界。

三、功能最简单，性能和信息安全相对来说较难

功能性本质上是黑盒测试：验证软件功能是否与需求一致，覆盖功能完备性、功能正确性、功能适合性、功能依从性。

它主要依赖的是人力和测试用例设计能力，工具层面可能一个软件测试管理工具就能撑起来，几乎不涉及昂贵设备的购置。

对初次申请的实验室来说，这是最容易拿到、也最容易被相中的一项。

性能效率测试要验证系统在预期负载下的运行状态，关注时间特性（响应时间、吞吐率）、资源利用性（CPU、内存、磁盘占用）和容量，测试方法包括负载测试、压力测试和长时间稳定性测试。

它对实验室的要求是实打实的：

工具投入：商业性能测试工具（如 LoadRunner ）的采购费用，如果用开源方案（JMeter等）则要自己解决能力覆盖和过程受控的问题，很少有实验室能够用开源工具拿到资质；

环境投入：需要独立的测试环境、被测系统服务器、网络设备等也是一部分投入；

人员投入：光会"跑脚本"不够，还要能看懂瓶颈出在数据库、中间件、网络还是应用代码，否则报告里的分析站不住。

代码测试（源代码漏洞测试）的投入主要在静态分析工具上。

需要购置或授权支持对应语言的代码审计工具，同时要具备人工复核能力。工具只负责报出疑似漏洞，最终定级和确认还是要靠人。

人比工具关键，扫描结果的筛选、误报排除、漏洞定级都依赖经验，所以人员门槛也不低。

信息安全性测试难在三处：

工具链长：漏扫、渗透、抓包改包、代码审计，每一类都要有对应的工具；

人员稀缺：跟性能测试类似，真正有安全测试相关经验的人，相对来说比较难招，团队的组建没那么容易。

方法验证难：信息安全的结果与人员经验强相关，天然不好复现，做方法确认和能力验证的工作量远大于功能测试。

四、只申请"功能性测试"行不行？

如果功能测试最简单，那我们能不能先只申请功能测试把资质拿到手再说？通过我们多年的经验来看，不太行得通。问题主要出在 CNAS 评审的关注点上：

评审的是"检测实验室的技术能力"，而不是"会不会做测试"。设备与设施、方法确认、结果有效性是体系的硬性要求。而功能测试几乎没有对应的"检测设备"概念，单一申报功能性，评审组很容易质疑实验室的资源配置是否达到检测实验室的实质要求。

认可范围需要有"技术代表性"。只报一个纯人工、几乎零设备投入的项目，难以体现实验室在方法验证、能力验证、环境控制等方面的整体水准。

行业惯例上，初次申请一般会要求搭配至少一项需要专业设备或专业技术工具支撑的项目，如搭配性能效率一起做。

道普云，专注软件检测领域CNAS/CMA实验室建设，如需软件检测实验室质量管理体系相关文件模板、资源配置方案、项目细节交流等，可主页菜单与我交流。