夜雨聆风“张工，发补意见下来了，软件验证这块被退回重写。”
“为什么？我们不是测了吗？”
“测是测了，但审评老师说：第一，只有系统测试报告，没有单元测试和集成测试；第二，测试用例设计没说明；第三，覆盖率数据没有；第四，没做回归测试分析。”
“这么多要求？一个软件测试，怎么搞得这么复杂？”
“因为医疗器械软件，不是普通软件。普通App出Bug大不了闪退，医疗软件出Bug，可能害死人。”
这是很多医疗器械企业踩过的坑。很多人以为“软件测了就行”，但在医疗器械领域，软件验证报告是注册资料的核心组成部分，必须证明你进行了充分、系统、可追溯的测试。今天，我就用大白话讲讲：从单元测试到系统测试，软件验证报告到底该怎么写。
一、先搞清楚：软件验证不只是“跑一遍功能”
在医疗器械领域，软件验证有明确的法规定义。根据相关指导原则，软件验证是指通过提供客观证据认定软件开发某一阶段的输出满足输入要求。它包括一系列活动：源代码审核、静态分析、动态测试、单元测试、集成测试、系统测试、设计评审等。
简单理解：就像一个乐队排练曲子。你希望最终整个乐队演奏出来的效果是好的，但不能只等最后合练才发现问题。
单元测试：每个乐手单独练习自己的声部，确保自己不出错。
集成测试：两个乐手一起配合，比如钢琴和小提琴，确保配合默契。
系统测试：整个乐队合练，确保整首曲子流畅动听。
回归测试：改了一个音之后，重新再合一遍，确保改完没破坏别的地方。
缺了任何一层，都可能漏掉问题。
二、四层测试，层层递进
第一层：单元测试——每个人先把自己练好
单元测试是最小单位的测试，针对单个函数、模块或组件进行验证。通常采用白盒测试，也就是测试者要了解代码内部结构。
关注点：每个独立模块的功能是否正确？边界条件是否处理正确？异常输入是否被妥善处理？例如，一个计算输液速率的模块，输入负数时应该报错而不是算出负值。
测试方法包括两种：静态测试（代码走查、结构分析）和动态测试（逻辑覆盖，如语句覆盖、判定覆盖、条件覆盖等）。对于高风险软件，通常要求语句覆盖率不低于90%，判定覆盖率不低于80%。
操作指南：准备单元测试用例表。可以画这样一张表，一一列出测试项、输入数据、预期输出和实际结果。覆盖率数据必须逐项记录，并说明哪些代码没测到以及为什么。
第二层：集成测试——检查配合是否默契
单元测试通过后，把模块组装起来，测试模块之间的接口和交互。通常采用白盒测试、黑盒测试、灰盒测试相结合的方式。
测试内容：模块间的数据传递是否正确？接口协议是否一致？一个模块出错时，其他模块能不能正确处理？比如，血压测量模块把数据传给显示模块，传过去的值是整数还是字符串？单位是不是弄混了？
测试策略：可以从顶层往下测，先从主控模块开始；也可以从底层往上测，先测被调用最频繁的小模块；或者把两种方式混合使用。一般推荐增量式集成，每加一个新模块就测一次，问题定位快。
操作指南：记录集成策略和接口测试结果。准备接口测试记录表，列出调用模块、被调用模块、测试结果和备注。确保每次集成后都通过了测试，才能继续集成下一个模块。
第三层：系统测试——整队合练
所有模块集成完成后，对整个软件系统进行全面测试。通常采用黑盒测试，即只关注输入输出，不关注内部实现。
系统测试的内容五花八门：
功能测试：每个功能好不好用，是否符合需求规格。
性能测试：软件跑得快不快，比如心电图分析软件处理一份数据不能超过3秒。
并发测试：人多时会不会卡，比如多台监护仪同时连接中央站。
压力测试：极限负荷下会不会崩，比如同时处理1000条报警。
接口测试：跟其他系统能不能对上话，比如与医院信息系统交换数据。
内存测试：有没有越用越慢，长期运行内存泄漏。
兼容性测试：在不同操作系统、不同硬件配置下能不能跑。
安全测试：网安的防护做没做好，比如防SQL注入、防未授权访问。
用户测试与第三方测试：系统测试分为内部测试、用户测试和第三方测试。用户测试由预期用户在真实或模拟使用场景中进行测试；第三方测试由独立机构进行。对于中高风险软件，第三方测试报告会大大增强可信度。
操作指南：准备一份详细的测试结果总表，列出每个测试类别和对应的测试结果，最后附上测试环境配置单（包括操作系统版本、数据库版本、网络环境等）。每个失败的用例都要记录缺陷编号和修复状态。
第四层：回归测试——改了之后别出新问题
软件更新后，重新执行测试，确保修改没有引入新的缺陷。这层最容易忽略，但最容易被审查发现问题。
什么时候必须做：改了代码要做；改了依赖库要做；改了运行环境要做。做之前先评估改动影响范围，再决定测多深。但一个基本原则是：所有变更均需进行适当且足够的回归测试。
回归测试策略：不是全部用例重新跑一遍（那太耗时），而是先运行与修改相关的核心用例，再运行高风险功能用例，最后跑冒烟测试（基本流程走通）。如果改得很多，才需要完整回归。
三、测试文档怎么写？—— 三步走
根据相关标准和指南，软件测试过程一般包括测试策划、测试设计、测试执行和测试总结四项活动。落实到文档，可以这样组织：
第一步：测试计划
写清楚测试目标、范围、策略、资源、进度。测试计划的详细程度与软件安全性级别相关。低风险软件提供计划和报告摘要即可，中风险需要提供较完整的计划和报告，高风险还需要提供可追溯性分析报告（即每个需求都有对应的测试用例）。
计划里要写明：测什么（功能清单）、不测什么（比如兼容性只测Win10和Win11）、用什么方法（比如功能测试用等价类划分）、谁来做、什么时候完成。
第二步：测试用例和规程
设计具体的输入数据、执行条件和预期结果。测试用例要能回答“怎么测”的问题。功能性测试需从功能完备性（所有需求功能都已实现）、功能正确性（每个功能结果正确）、功能适合性（功能符合用户预期）等方面展开。
设计测试用例的常用方法：
等价类划分：把输入分成有效类和无效类，每类测一个代表。
边界值分析：测边界值（最小值、最大值、略低于最小值、略高于最大值）。
场景法：模拟真实用户操作路径。
测试规程要写清楚：每一步操作步骤、预期输出和实际输出。结果有偏差时如实记录，并说明原因和后续处理（比如已修复并回归）。
第三步：测试总结
汇总测试结果，评估软件质量。包括测试环境说明、测试结果总结（总用例数、通过数、失败数、阻塞数）、遗留缺陷分析（哪些没修、为什么不修、风险可控吗）、测试结论（通过/有条件通过/不通过）和建议。
一份有说服力的测试总结，会让审评老师觉得“这家公司测试做得很扎实”。
四、常见错误，犯一次后悔半年
错误一：只做系统测试，没有单元测试和集成测试
这种最容易被退审。系统测试发现问题时，根本不知道是哪个模块的锅。正确的做法是：单元测试证明每个模块正确，集成测试证明模块配合正确，系统测试证明整个软件正确。三层证据缺一不可。
错误二：没有覆盖率数据
审评老师追问：“你的单元测试测了多深？哪些代码没测到？”你必须回答得出来。覆盖率越高，测试越充分。一般来说，高风险软件要求语句覆盖率≥90%，判定覆盖率≥80%。如果做不到，要说明理由（比如某些异常处理代码很难触发）。
错误三：测试用例设计不说明方法
随便填几个输入就算测完了？审评老师想知道：你为什么选这些用例？用什么方法设计的？没有方法支撑的测试，在审评老师眼里就是不充分的测试。
错误四：测试记录不全
只有结论没有过程？审评老师看不到原始记录，就无法判断测试的真实性。测试记录应该精确到“谁、什么时候、测了什么、结果怎样”。最好附上截图或日志片段。
错误五：软件更新后不做回归测试
改了代码，运行一遍“应该没问题”就提交了？结果审评老师一查，上次改的地方没测，新引入的Bug没人发现。回归测试是变更后的“复查”，必须做。
五、实操自查清单
完成软件验证报告前，用这个清单过一遍：
□ 是否按软件安全性级别（低/中/高）确定了测试深度？
□ 是否进行了单元测试并记录了覆盖率数据（语句、判定）？
□ 是否进行了集成测试并记录了接口测试结果？
□ 是否进行了系统测试并覆盖了功能、性能、安全、兼容性等维度？
□ 软件更新后是否执行了回归测试？
□ 测试用例设计是否说明了方法（等价类、边界值、场景法等）？
□ 测试记录是否完整（谁、什么时候、测了什么、结果）？
□ 测试报告是否包含了计划、用例、结果总结三大部分？
□ 对于高风险软件，是否提供了需求-测试用例-缺陷的可追溯性矩阵？
□ 遗留缺陷是否有风险分析，并说明为什么不修？
六、特殊场景：独立软件怎么测？
独立软件（比如手机上的房颤检测App）的测试要求更严格。除了上述测试外，还必须考虑：
安装卸载测试：在不同系统版本上安装、升级、卸载是否正常。
兼容性测试：不同屏幕尺寸、不同安卓/iOS版本是否正常。
网络安全测试：数据传输是否加密？用户登录是否安全？
测量准确性验证：如果软件用于测量（比如AI测量肿瘤大小），必须与金标准对比，验证误差范围。
对于独立软件，一般建议委托有资质的第三方检测机构出具测试报告，这样的报告公信力更强。
七、总结：写验证报告，就是写“证据链”
软件验证报告不是在凑字数，而是在证明你作为制造商，已经对软件的每个层次、每个环节进行了充分的测试。
对审评老师而言，一份好的软件验证报告应该是层层递进、证据链完整的。从单元测试证明每个模块正确，到集成测试证明模块配合正确，再到系统测试证明整个软件正确，最后回归测试证明改完没问题——四个层次环环相扣，缺一不可。
一句话：软件验证报告写得越好，注册审评就越顺；测试做得越扎实，上市后就越安心。
