第3章：测试计划文档编写

测试计划文档，说白了就是整个测试工作的「施工图纸」。我见过太多项目，测试做到一半才发现环境不对、用例漏了、资源不够——嗯，都是计划没做好。今天我就把这几年的经验掰开揉碎，跟你聊聊怎么写一份靠谱的测试计划。

3.1 测试计划模板

先说说模板。我个人习惯用下面这个结构，它经过了三个医疗设备项目的打磨，我觉得挺实用的。

你可能会问：「模板这么细，会不会太死板？」其实不会。模板是骨架，内容才是血肉。我在项目中遇到过，有人把模板填得满满当当，但关键信息全漏了——比如测试环境的校准证书编号没写，结果审核时被开了不符合项。

3.2 测试用例设计规范

测试用例设计，是测试计划里最见功力的部分。我总结了三句话：覆盖要全、粒度要细、可执行性要强。

3.2.1 用例编号规则

我习惯用这种格式：TC-模块名-序号-版本。举个例子：

TC-PWR-001-V1.2   // 电源模块测试用例第1条
TC-COMM-015-V2.0  // 通信模块测试用例第15条

为什么要加版本号？有一次我查一个老用例，发现它对应的是V1.0的硬件，但产品已经迭代到V2.1了——差点用错。从那以后，版本号就成了我的铁律。

3.2.2 用例优先级定义

优先级	定义	示例
P0	关键功能，不通过则不能发布	除颤仪放电功能、呼吸机报警功能
P1	重要功能，影响用户体验	数据存储、界面显示
P2	一般功能，可后续优化	日志导出格式、界面配色

这里有个坑：P0用例必须100%通过，但P2用例也不能忽视。我曾经因为一个P2的日志格式问题，被客户投诉说「数据看不懂」——嗯，后来我把P2的通过率也设成了95%。

3.2.3 用例设计要点

• 正向用例：验证功能正常。比如「按下启动键，设备应进入工作状态」
• 反向用例：验证异常处理。比如「输入超出范围的参数，设备应提示错误」
• 边界用例：验证临界值。比如「电池电压3.0V时，设备应发出低电量报警」
• 压力用例：验证极限情况。比如「连续运行72小时，内存不应泄漏」

3.3 测试环境定义

测试环境这块，我吃过不少亏。有一次，测试环境用的电源适配器和量产批次不一样，结果EMC测试全挂了——折腾了两周才发现是电源的问题。

3.3.1 硬件环境

必须明确以下内容：

• 被测设备：硬件版本、固件版本、序列号
• 测试仪器：型号、校准有效期、连接方式
• 辅助设备：比如模拟肺、心电信号发生器、血氧模拟器
• 环境条件：温度、湿度、电磁干扰等级

3.3.2 软件环境

软件环境要精确到版本号。我建议用表格记录：

软件项	版本	备注
操作系统	FreeRTOS V10.4.3	需打补丁2024-01
测试工具	LabVIEW 2023 SP1	需安装NI-DAQ驱动
自动化脚本	Python 3.11 + pytest 7.4	依赖库见requirements.txt

3.3.3 环境校准与验证

这一点特别重要。医疗设备测试，环境本身必须可追溯。我要求每次测试前做三件事：

1. 仪器自检：所有测试仪器开机自检，记录结果
2. 环境验证：用标准件验证测试系统是否正常
3. 数据记录：保存环境参数截图，作为测试附件

3.4 避坑指南

最后，分享几个我踩过的坑：

• 坑1：用例写得太笼统。比如「测试通信功能」——这算什么用例？要写成「发送1000个数据包，丢包率应小于0.1%」
• 坑2：环境定义不完整。只写了「使用心电模拟器」，没写型号和设置参数。结果不同人测出来的结果不一样
• 坑3：忽略回归测试。改了一个bug，以为只影响一个模块，结果把整个通信协议搞崩了——嗯，从那以后我坚持每次修改都跑全量回归

测试计划文档，不是写给别人看的，是给自己和团队用的。写清楚、写细致，后面执行起来才不慌。你想想看，一个连计划都写不清楚的测试，怎么能保证医疗设备的质量？