这两年做软件测试的朋友应该都能感受到一个趋势越来越多的第三方测评机构、软件质量实验室甚至企业内部的质量保障团队都在琢磨CNAS认可这件事。一提到CNAS躲不开的就是CL01而CL01真正让人头疼的核心就是那一大堆程序文件。很多人卡就卡在这里不是不想写而是不知道到底需要写哪些写多少才算“全面覆盖认可要求”。我最早接触软测实验室的CNAS认可时也走过一段弯路。当时把CL01从头到尾翻了好几遍却仍然对“程序文件清单”没有一个整体概念结果就是东一榔头西一棒子地写写了改、改了删文件倒是不少但一到现场评审就被老师问出“这条要求你的程序在哪”的尴尬局面。这篇博文就是想把我后期整理出的思路完整讲清楚从CL01条款反推出一份软件测试实验室适用的程序文件清单并把每类文件的核心编制要点也一并拆开讲。无论你是准备首次申请CNAS认可还是正在为复评审改版文件这份梳理逻辑都可以直接拿去做对照。1. 为什么软件测试实验室要跟CL01“死磕”1.1 认可准则、应用说明与软件测试的关系CNAS-CL01《检测和校准实验室能力认可准则》是CNAS对实验室认可的基础文件它的实质内容等同于国际通行的ISO/IEC 17025。也就是说不管你是做化学检测、机械检测还是软件测试想要拿到CNAS认可都绕不开这套准则。但是这里有个很容易被软测团队忽略的关键点软件测试实验室除了要满足CL01通用要求之外还需要满足CNAS-CL01-A019《检测和校准实验室能力认可准则在软件检测领域的应用说明》。我习惯把这两份文件的关系理解成“宪法”和“部门规章”CL01是所有实验室都必须遵守的通用框架A019则是针对软件检测这个具体领域细化出来的执行规则。A019里会补充很多软件测试特有的要求比如测试人员的专业背景、测试环境真实性、测试工具和脚本的管理、测试数据集的处置、测试记录的完整性等等。所以你在梳理程序文件时不能只盯着CL01正文要把A019也一起逐条过一遍否则很容易漏项。提到“软件测试和CNAS”很多团队的第一反应是“我们是开发转测试的搞那么正规有必要吗”。说实话如果只是做内部冒烟测试、回归测试确实没必要上CNAS但如果你要对外出具具有公信力的软件测试报告或者你的客户是政企、金融、医疗这类强监管行业CNAS认可几乎就是入场券。认可本身也倒逼实验室把测试流程从“靠个人经验”变成“靠体系约束”。1.2 程序文件在整个质量体系里的定位很多初次接触实验室管理体系的人会被“质量手册、程序文件、作业指导书、记录表格”这一堆文件分层搞得一头雾水。我用一个不太严谨但特别容易懂的类比来解释如果质量体系是一个人的话质量手册就是“人设”——告诉别人你是什么样的人、你的总体目标是什么程序文件是“行为规范”——规定你具体遇到某一类事情时该按什么步骤做作业指导书是“操作手册”——细化到某台设备怎么调、某个测试工具怎么配记录表格则是“证据”——证明你真的做了而不是嘴上说说。在这套体系里程序文件扮演的是承上启下的角色。它不能像质量手册那样只写“我们要保证公正性”“我们要持续改进”这种大方向也不能像作业指导书那样啰嗦到“你点这个按钮再点那个按钮”。程序文件要解决的是“谁来做、先做什么后做什么、卡点在哪、做完留什么记录”这个层面的事情。软件测试实验室之所以在程序文件环节特别容易翻车是因为大部分测试工程师没有受过文件化体系训练写出来的“程序文件”要么是质量手册的复述要么直接写成了测试方案或者操作手册两者都偏离了程序文件的功能定位。认清这个定位之后我们再去看CL01条款就会明白每一份程序文件到底在回应什么要求。2. 从CL01条款反推程序文件清单一份能直接抄的作业2.1 怎么从准则里找“程序”线索我梳理程序文件清单的方法很简单把CL01全文里所有出现“程序”“应有程序”“应制定文件”“应保持记录”之类关键词的条款全部标记出来再结合A019的应用说明逐条对照最后把同样主题的条款合并成一个程序文件。这样做的好处是每一份程序文件都能对应到明确的认可条款评审老师来查时你能非常快速地说出“这个文件回应的是你查的那一条”。这个“条款—文件”的映射关系在文审阶段尤其好用。不过要注意CL01里有些要求虽然没有直接写上“程序”二字但隐含了文件化需求。比如“实验室应持续识别影响公正性的风险”没有出现“程序”一词但你不写一份公正性风险识别与控制程序现场评审时就会很被动。所以我的原则是显式要求必须落成程序隐式要求也要尽量落成程序只是内容可以灵活合并。2.2 管理支撑类程序文件管理支撑类程序文件是所有CNAS实验室的“标配”软件测试实验室一个也跑不掉。我列一个常用清单同时给出对应的CL01主要条款。这里需要说明条款号以CNAS现行有效版本为准不同年份版本可能会有调整参照时要留心。程序文件名称对应主要条款核心要回应的问题公正性风险识别与控制程序CL01 4.1怎么识别影响公正性的风险怎么防范利益冲突保密和保护客户信息程序CL01 4.2客户源码、测试数据、缺陷信息怎么保护谁能接触文件控制程序CL01 8.3体系文件怎么编制、审批、发布、修订、作废记录控制程序CL01 8.4技术记录和质量记录怎么标识、存储、保护、保存期人员培训与授权管理程序CL01 6.2测试人员能力怎么确认怎么授权上岗设施与环境控制程序CL01 6.3测试机房、服务器区、保密区域怎么管设备管理程序CL01 6.3、6.4测试服务器、网络设备、性能测试工具怎么管理、校准、期间核查外部服务和供应品管理程序CL01 6.6外包测试、外购工具、云服务商怎么评价和控制不符合工作与纠正措施控制程序CL01 8.7发现偏离怎么办怎么追溯、纠正、防止再发风险和机遇管理程序CL01 8.5影响体系目标的风险怎么评估和应对改进控制程序CL01 8.6改进机会怎么识别、筛选和落地内部审核程序CL01 8.8内审怎么做、内审员怎么要求、不符合怎么闭环管理评审程序CL01 8.9管理层怎么定期评审体系适宜性、充分性、有效性投诉处理程序建议增加客户书面异议或投诉怎么受理、反馈、闭环可能有人会问投诉处理在CL01正文里没有单列条款为什么还要写我的经验是虽然CL01正文没有专门写但CNAS的其他认可规范以及对实验室运行的完整要求里都对客户投诉或申诉有明确期望。而且从实际业务角度看软件测试报告结论一旦受到客户质疑没有一套处理流程会非常被动。与其等评审老师问不如主动补上。2.3 技术过程类程序文件技术过程类程序文件是软件测试实验室区别于其他检测实验室的地方也是申CNAS时最容易写偏的部分。这组程序直接对应测试业务的完整链条从接单到出报告每一个环节都要有程序支撑。程序文件名称对应主要条款核心要回应的问题合同评审程序CL01 7.1客户需求怎么确认、能力是否匹配、非标方法怎么处理测试方法的选择、验证和确认程序CL01 7.2选什么标准、标准方法怎么验证、非标方法怎么确认测试过程控制程序A019相关条款测试计划、用例设计、执行、缺陷记录怎么受控被测物品处置程序CL01 7.4被测系统的版本、介质、数据集怎么接收、标识、保护、归还技术记录与数据管理程序CL01 7.5原始记录怎么记、电子数据怎么防篡改、数据备份怎么管测量不确定度评定程序CL01 7.6性能指标响应时间、吞吐量的不确定度怎么评结果有效性监控程序CL01 7.7内部比对、复测、回归、能力验证怎么做测试报告管理程序CL01 7.8报告谁编制、谁审核、怎么修正、怎么防止非授权修改测试环境搭建与配置管理程序软件测试补充测试环境怎么搭、怎么保持真实性、变更怎么审批这里多提一句CL01 7.3是关于抽样的。软件测试绝大多数情况下并不涉及传统意义上的抽样但如果你做的是海量数据场景下的性能测试或者从生产库中抽取样本数据构造测试集那就要考虑是否应补充一份数据抽样或样本管理的要求。A019对此也有相关要求比如测试数据集的选择应该能代表真实使用场景。这个点容易被忽略实际业务里却很容易被评审老师当作现场提问。2.4 对照A019应用说明需要补充的“软件味”程序通用检测实验室的程序文件拿来改个title是行不通的因为A019里塞了大量软件测试特有要求。我在实际梳理时至少会额外补上以下几份测试工具管理程序测试工具包括开源的JMeter、Selenium、LoadRunner这类商业工具也包括自研脚本和工具平台。程序里要写清楚工具的选型评估、安装授权记录、版本管理、环境兼容性检查以及工具本身是否需要进行有效性验证。测试数据和数据资产保护程序软件测试过程中会用到真实用户数据客户也会提供源程序、数据库脚本、接口文档。程序里要写清楚数据脱敏规则、访问权限管理、传输加密要求、用后销毁机制。软件版本和测试环境配置管理程序被测软件版本、操作系统补丁、中间件版本、数据库版本都要有记录。评审老师经常问的问题是你怎么证明这套测试环境能代表客户的真实运行环境没有配置管理程序这个问题根本答不利索。缺陷管理程序软件测试的核心交付物之一就是缺陷记录。缺陷怎么分级、怎么流转、怎么回归验证、关闭标准是什么这些要在程序里写清楚。严格来说缺陷管理可以作为“测试过程控制程序”的子章节也可以单独成文关键是内容不能缺席。以上四份是软件测试实验室最有识别度的程序文件也是现场评审时的重点抽查对象。把这四份写扎实A019的大部分要求就有落地的载体了。3. 核心程序文件到底该写什么逐份拆解编制要点3.1 保密和公正性程序软件测试里的数据“红线”软件测试实验室经手的数据非常敏感客户往往会把源码、数据库、业务账号、内部文档一股脑给你。我见过一些实验室的保密程序写得很笼统翻来覆去就一句话“实验室对客户信息保密”。这样的程序文件交上去评审老师不扣分才奇怪。一份能落地的保密和公正性程序至少要覆盖五件事第一人员的保密责任包括入职保密协议、项目级保密承诺、离职后的数据归还义务第二客户数据的访问权限管理谁能访问源码构建服务器、谁能访问生产数据备份必须按岗位最小授权第三数据使用边界客户数据只能用于合同约定的测试目的不能复制到个人电脑、不能用于其他项目第四数据处理过程的可追溯谁在什么时间访问了哪个客户的数据要有日志或审批记录第五测试结束后的数据处置该删的要删、该归档的要归档、该归还的要归还并且要有处置记录。公正性风险这块软件测试实验室主要面对的风险往往是“既当运动员又当裁判员”。比如你给一家软件公司做了开发又接这家公司产品的第三方测试这就是典型的公正性风险。程序里要写明公正性风险的识别频率、评估维度、应对措施以及出现利益冲突时的申报和回避机制。关键不是你完全不出问题而是出了问题有制度能兜住。3.2 合同评审程序别等签完约再谈止损软件测试的合同评审最忌讳的是只评审商务条款不看技术条款。很多矛盾都出在“客户说我要做个测试”这句话上客户想要的究竟是一个简单的功能验证还是一个符合国标GB/T 25000.51的整套测评测试范围是全部功能点还是核心交易链路性能测试的指标是多少500并发还是5000并发测试环境由谁提供测试数据谁准备这些不在合同评审阶段问清楚后面做起来一定扯皮。我建议合同评审程序里至少包含这些环节客户委托信息和测试需求的书面确认、实验室能力与资源的匹配评估、测试方法和判定标准的确定、非标方法确认需求的判断、可能存在的技术风险和商务风险告知、报价和工期达成一致。评审记录不是内部走走流程就完事要把关键判断写清楚尤其是“接或不接”的理由。比如因为当前没有合适测试环境而拒绝某个项目这种记录在评审老师眼里就是真实的体系运行证据。软件测试的合同评审还有一个特殊性很多项目是从售前方案阶段就开始的售前人员口头承诺了客户一些东西比如“我们能在十天内给出完整性能报告”但执行层其实做不到。程序里要明确一条任何影响到测试范围、周期、成本的承诺都必须走合同评审确认不能由售前单独拍板。3.3 设备与测试环境管理虚拟机也要“溯源”我看到很多软测实验室的设备程序文件写得像“服务器管理制度”通篇在讲服务器不能随便关、机房要装门禁。方向对了但密度不够。CL01对设备管理的要求是精准到每一台影响测试结果的设备都要有唯一性标识、状态标识、使用记录、维护记录、核查记录。这个要求在软件测试领域一样适用。影响测试结果的设备包括什么呢至少包括跑压力测试的负载机、被测系统的应用服务器和数据库服务器、存储设备、网络设备、以及提供时间的NTP服务器。性能测试工具本身也需要校准或核查比如JMeter脚本里的延迟设置、LoadRunner的计时基准这些都会直接影响响应时间数据的可信度。程序文件里要写清楚这些工具的验收方式、版本锁定、周期核查方法。测试环境管理这块我特别吃过大亏一测试就发现被测系统的数据库密码过期了、中间件版本跟上次不一致了得出一个结论根本复现不出来。后来在程序里强制要求环境配置基线文档和变更审批任何测试环境变更小到数据库参数调整大到迁移服务器都要记录在案。环境配置管理做得好的实验室不仅评审好过日常测试效率也会提升一个台阶。3.4 方法验证与确认标准方法也要过一次脑子软件测试实验室适用的标准通常包括GB/T 25000系列、GB/T 38639、ISO/IEC 25010等。很多团队觉得“我用的是国家标准直接照做就行还需要验证什么”这是一个很大的误区。CL01要求的是即使是标准方法实验室也必须验证自身具备正确运用该标准的能力。简单说标准是别人写的但你得证明你能把它用对。验证动作在软件测试语境下可以这样落实首先确认人员能力至少有一个熟悉标准且具备测试设计能力的技术骨干其次确认测试工具和环境满足标准要求再次准备一个已知结论的样本项目用标准规定的流程跑一遍检查测试结果与预期是否一致最后记录验证过程包括验证日期、参与人员、验证对象、验证结论。如果是非标方法比如客户自定的测试流程、或者你们自己设计的一套安全测试方法论那就需要做方法确认。确认的维度和标准方法不同要重点回答“这个方法适用边界是什么、结果可信度有多高、有没有与参考方法作过比对”。这部分对软件测试实验室的要求其实很高因为很多自创测试方法缺少行业共识作支撑评审老师会盯得很紧。3.5 质量监控程序没有“参考样品”也能做质控传统检测实验室做质量监控可以买标准物质、参加能力验证、做留样再测。软件测试领域既没有标准物质能力验证项目也比传统领域少得多所以很多实验室干脆不写质量监控程序或者写得非常空。这是特别可惜的因为软件测试虽然没有标准物质但完全有替代方案。我梳理过软测实验室常用的质量监控手段分享几个实操下来靠谱的第一内部比对同一份测试需求由两位测试工程师独立设计和执行用例最后比对结果。这种方式能有效暴露用例覆盖不一致、判断标准不统一的问题。第二代码走查与测试资产评审测试用例、测试脚本、测试数据准备是否合理由项目组之外的技术专家做同行评审本质上就是一种质量监控。第三缺陷复测与回归验证对已关闭的缺陷进行抽样复测确认修复确实生效且没有引入新的问题这既是对产品质量的监控也是对测试执行质量的监控。第四利用历史数据做比对将当前项目的缺陷密度、用例通过率、需求覆盖率等指标与实验室历史基线进行比对出现明显偏离时启动调查。第五参加实验室间比对或行业能力验证虽然软件测试的PT项目少但并非完全空白CNAS认可的软件测试能力验证计划偶有开放。哪怕没有抢到名额主动参加一次行业机构组织的软件测评比对也能作为质控证据。这些手段写进“结果有效性监控程序”评审老师会眼前一亮的。4. 从清单到体系落地程序文件怎么“织成一张网”4.1 质量手册、程序文件、作业指导书和记录表单怎么分层很多实验室的程序文件清单列出来之后仍然存在两层皮的毛病质量手册一个大方向程序文件一个流程到了具体操作层面又找不到对应的指导书。我在梳理文件体系时坚持用“手册—程序—指导书/记录”三层对应法则来校验每条质量手册承诺必须有程序承接每个程序的输出必须有记录或表单证明。举个例子质量手册里写“实验室应对影响测试结果的数据传输进行完整性保护”这还只是一个承诺。到了“技术记录与数据管理程序”这一层就要写清楚数据传输用哪种校验方式、加密通道用什么协议、备份频率是多久一次。再往下可能还需要一份《测试数据备份操作作业指导书》和一张《数据备份执行记录表》。这样一层层套下来文件之间就是一张网而不是一堆散纸。软件测试实验室因为业务形态比较数字化很多人会产生一个错觉“我们数据都是自动备份的不用写记录吧。”实际上程序文件强调的是“有明确的责任人”和“有可追溯的证据”系统自动备份日志可以当作证据但你仍然要在程序里写明由谁检查备份有效性、多久检查一次。否则“自动备份”就成了无人负责的盲区。4.2 程序文件编制的先后顺序和节奏一口气把所有程序文件都写完既不现实也容易写废。我自己操作时一般按四步走第一步先定编号体系和记录表格模板。文件编号规则、版本号规则、表单编号规则这三件事不确定后面每份文件都会打架。建议用统一的代码规则比如质量手册用QM程序文件用QP作业指导书用WI记录用FR再按顺序编号。第二步先写两个“元程序”文件控制程序和记录控制程序。因为其他所有程序文件的修订、版本更新、记录归档都要依据这两个程序来运行。不先把它们定下来后续文件越写越多版本管理就会失控。第三步沿测试业务主线上写合同评审、测试过程控制、方法验证确认、测试环境管理、测试报告管理。这五份写完实验室的日常测试业务就有了完整闭环。第四步再补管理支撑类程序人员培训、设备管理、内部审核、管理评审、纠正措施、风险和机遇等。到这一步清单基本就全了剩下的是根据A019逐条自查补漏。这个顺序的背后逻辑是先让核心测试业务能够在新的文件体系下运转起来再逐步完善管理链条。如果你一上来就写内部审核程序和管理评审程序反而是最不着急的因为这两份程序的输出依赖其他程序执行后产生的记录。4.3 一份经得起外审的程序文件模板和常见失分点我见过一些写得很漂亮的程序文件格式无可挑剔但外审时照样被开不符合项。原因往往不是格式而是内容经不起追问。一份靠谱的程序文件应该包含七块内容目的与范围、职责分工、工作流程、具体操作要求、记录要求、相关文件、附录表单。工作流程是整份文件的灵魂。我建议用“输入—活动—输出—记录”的链条来组织。以合同评审程序为例输入是“客户需求/委托单”活动包括“需求沟通—能力评估—方法确认—报价—签订合同”输出是“评审记录/合同”记录对应“合同评审表”。这样写任何人都能看懂整个流程从哪开始、在哪结束、留下什么痕迹。常见失分点有三个都是我在评审现场见到的真实情况。第一程序与前一层文件内容矛盾质量手册承诺“年度管理评审”程序里却写“每半年一次”这种不一致是最低级也最扎眼的错误。第二流程描述太抽象缺少最终负责岗位和时限要求比如写了“发现问题应及时上报”但“及时”是多及时、上报给谁完全没说。第三没有跟记录表单对接程序文件里说“做好记录”但到底哪张表单对应这个记录翻遍全文件也找不到。如果能在文审前用这三点自查一遍很多低级问题都能提前拦住。5. 软件测试实验室入坑实录这些问题评审老师最容易揪出来5.1 常见问题速查表我在跟同行交流时发现大家踩过的坑高度相似。整理一张速查表出来你可以直接对着排查。问题现场背后原因解决办法程序文件有但找不到对应记录文件写完没有同步设计表单逐份程序梳理输出记录形成“文件—表单”对照表质量手册和程序文件说法不一致文件由不同人分头写缺乏统一审查安排专人做一致性审查或开文件评审会文件编号和表单编号对不上编号体系没有提前统一设计重定义编号规则建立受控文件清单程序写得像作业指导书混淆了流程层和操作层把设备操作这类细节下沉到作业指导书程序文件只留流程测试环境变更无记录环境配置管理意识弱建立环境变更审批单强制留痕人员培训做完没评价程序里只写了培训没写考核和授权培训程序里补上“能力确认—授权上岗”环节能力验证没参加又没说明软测领域能力验证项目确实少但没留替代证据用实验室间比对、内部比对作为替代质控证据并保留记录设备台账里没有性能测试工具只想到硬件设备忽略工具类资产把测试工具纳入设备管理体系做版本记录和功能验证这张表里的问题基本覆盖了软测实验室文审中被开不符合项的高频区。遇到问题不要慌不符合项的核心是后续整改整改最讲究的是举一反三。某个环节被抓到一次就说明相关程序在实际执行中存在系统性问题不能只补一个记录就了事。5.2 三个独家避坑技巧最后分享三个我自己的实操技巧也算是踩过不少坑之后总结出来的。第一个技巧做“条款—文件—记录”三级对照矩阵。把CL01和A019的每条要求逐条列在一张表里右边填上对应程序文件名称和记录表单编号再标明“已覆盖”或“待补”。这个矩阵既是文审自查工具也是内审员的检查清单。评审老师问任何一条你都可以三秒定位到文件和记录。第二个技巧文审之前做一次“纸上演练”。坐在会议室里把一份合同从接收、评审、测试计划、用例设计、执行、缺陷管理、报告编制到记录归档整个过程按照程序文件一步步模拟走一遍过程中凡是出现“这里程序没说清楚”“这里记录表单没有”的地方全部标记出来修订。不要觉得麻烦这套演练至少能帮你发现三成以上的文件缺陷。第三个技巧程序文件在发布前给一线测试工程师审一遍。很多实验室的程序文件是质量负责人一个人写完的测试工程师翻都没翻过。程序文件落地不了最大的原因就是执行的人不认可、不知道。与其事后反复培训解释不如在编写阶段就让工程师参与意见哪怕他们只是指出“这步骤不合理”“这东西没法落地”文件的执行阻力都会小很多。我自己在推进CNAS认可的过程中最大的感触是程序文件不是写给评审老师看的而是写给下个月刚入职的那个新人看的。如果一份流程文件能让完全没参与过认可准备的新人照着做不跑偏这份文件就大概率写得合格了。软件测试团队通常不缺聪明人缺的是一套能把每个人的聪明转换成稳定组织能力的方法而程序文件恰恰就是这套方法的载体。希望这份从CL01条款反推出来的清单能让你在准备文件时少走一些弯路、少熬几个夜。