1、医用软件测试概述：IEC 62304对测试的要求、测试级别、测试文档体系
大家好，我是老张。做医疗嵌入式软件这行，一晃十几年了。今天咱们聊聊测试——这个在IEC 62304里占了大头的环节。
说实话，我刚入行那会儿，对测试的理解就是「写完代码跑一跑，没崩就行」。直到有一次，我们一款监护仪在注册审核时被发补，原因就是测试文档不完整。嗯，从那以后，我再也不敢小看测试了。
1.1 IEC 62304对测试的核心要求
IEC 62304把测试当作软件生命周期里不可或缺的一环。它不关心你用什么工具，也不规定你必须写多少行测试代码。它只关心一件事：你有没有证据证明你的软件是安全的。
我个人习惯把62304对测试的要求总结成三点：
- 可追溯性：每个测试用例都要能追溯到对应的需求。说白了，你测的东西得是有来源的，不能拍脑袋想出来的。
- 独立性：测试人员最好不是写代码的那个人。我在项目里见过太多「自己测自己」的坑——写代码的人总觉得自己的逻辑没问题，结果漏掉一堆边界情况。
- 文档化：测试计划、测试用例、测试报告，一个都不能少。审核老师看的就是这些纸面证据。
重点提醒：IEC 62304对测试的要求是分安全等级（A/B/C级）的。C级最宽松，A级最严格。但不管哪个等级，测试文档都是硬性要求。
1.2 测试的三个级别
62304把测试分成三个级别：单元测试、集成测试、系统测试。这三个级别不是随便分的，它们对应着软件开发的不同阶段。
1.2.1 单元测试
单元测试，说白了就是测最小的代码单元。在嵌入式领域，通常是一个函数或者一个模块。
我记得有一次，我们做输液泵的流速控制算法。单元测试时发现一个PID参数溢出问题——如果用户设置的流速特别小，积分项会一直累加，最终导致电机突然猛转。这种问题，系统测试根本发现不了，因为触发条件太特殊了。
单元测试的关键点：
- 覆盖所有分支路径（if-else、switch-case）
- 边界值测试（最大值、最小值、空值）
- 异常输入测试（非法参数、越界数据）
我的小技巧：单元测试最好在代码提交前就跑一遍。我团队里有个规矩——单元测试没过，代码不许合并。刚开始大家觉得麻烦，后来发现bug率降了至少一半。
1.2.2 集成测试
集成测试，就是把各个单元拼起来，看它们能不能好好配合。嵌入式软件里，最常见的问题是接口不匹配。
举个例子，我们做过一个心电采集系统。ADC驱动模块和信号处理模块是两个人写的。ADC驱动输出的是原始电压值，信号处理模块却期望输入的是经过校准的毫伏值。单元测试各自都过了，一集成就崩。这就是集成测试要抓的问题。
集成测试的策略有两种：
- 大爆炸集成：所有模块一次性拼起来。快，但出了问题很难定位。
- 增量集成：一个一个模块往上加。慢，但安全。我个人推荐这种方式，尤其是安全等级B级以上的软件。
1.2.3 系统测试
系统测试，是在真实或模拟的硬件环境下，验证整个系统是否满足需求。这时候测的不只是软件，还有软硬件交互。
系统测试要关注：
- 功能完整性（所有需求都实现了）
- 性能指标（响应时间、吞吐量、内存占用）
- 异常场景（断电、通信中断、传感器故障）
- 压力测试（长时间运行、高负载）
注意：系统测试不能替代单元测试和集成测试。我曾经见过一个团队，为了赶进度跳过单元测试，直接做系统测试。结果呢？系统测试发现的问题，定位花了两周，修起来只花了半天。得不偿失。
1.3 测试文档体系
说到文档，很多工程师觉得烦。但没办法，医疗软件审核就是看文档。你代码写得再漂亮，没有文档，审核老师不认。
IEC 62304要求的测试文档体系，我习惯用一张表来概括：
| 文档名称 | 内容 | 什么时候写 |
|---|---|---|
| 软件测试计划 | 测试范围、策略、资源、进度、通过准则 | 测试开始前 |
| 软件测试描述 | 具体的测试用例、测试步骤、预期结果 | 测试执行前 |
| 软件测试报告 | 测试结果、发现的缺陷、通过/失败统计 | 测试完成后 |
这里有个坑，我踩过。测试计划里一定要写清楚「通过准则」。什么叫通过？是所有测试用例100%通过？还是允许有已知的、已评估风险的缺陷？
我个人建议：对于安全等级B级以上的软件，所有与安全相关的测试用例必须100%通过。非安全相关的，可以允许有少量已知缺陷，但必须在测试报告里明确说明，并且经过风险评估。
1.4 测试与软件安全等级的关系
不同安全等级的软件，测试要求不一样。我整理了一个对照表：
| 测试活动 | A级 | B级 | C级 |
|---|---|---|---|
| 单元测试 | 必须，100%语句覆盖+分支覆盖 | 必须，100%语句覆盖 | 建议 |
| 集成测试 | 必须，包含接口测试 | 必须 | 建议 |
| 系统测试 | 必须，包含压力测试 | 必须 | 必须 |
| 测试文档 | 完整的三件套 | 完整的三件套 | 至少测试报告 |
你想想看，C级软件可能只是一个辅助功能，比如记录日志。但A级软件直接关系到患者生命安全，比如呼吸机的通气控制。要求严格，是应该的。
1.5 我的经验总结
做了这么多年医疗软件，我最大的体会是：测试不是找bug，而是证明软件是安全的。
这个思路很重要。如果你把测试当成找bug，你会觉得「差不多就行了」。但如果你把测试当成「证明安全」，你就会认真对待每一个测试用例，每一份文档。
最后分享一个避坑指南：
- 测试用例要写清楚「预期结果」，不能模棱两可
- 测试报告里要记录测试环境（硬件版本、软件版本、工具版本）
- 发现缺陷后，要记录复现步骤，方便开发人员定位
- 测试文档要版本控制，和软件版本对应起来
好了，这一章就聊到这儿。下一章咱们深入讲讲单元测试的具体做法，包括怎么搭测试框架、怎么写测试用例。到时候我会拿一个真实的血压测量算法来举例，敬请期待。