全自动微流控化学发光免疫分析仪软件测试计划与测试报告
软件描述文档191025/ 子目录附件3+附件4合并整理：测试计划（WLK01-0102）+ 测试报告（WLK01-0101）
文思海辉技术有限公司测试团队编制，对应 NMPA 注册申报软件描述文档附件3、4
一、测试计划（附件3）
1.1 基本信息
| 项目 | 内容 |
|---|
| 计划标识符 | WLK01-0102 |
| 项目背景 | 全自动微流控化学发光免疫分析仪软件，中科院苏州医工所提需求，文思海辉开发 |
| 测试范围 | 全部系统测试：功能测试 + 易用性 + 性能/压力 + 可移植性 + 接口 + 恢复 + 回归 |
| 测试方法 | 黑盒测试为主，边界值+等价类划分，手工执行 |
1.2 六大测试项及优先级
| 功能模块 | 优先级 | 说明 |
|---|
| 样本检测 | 高 | 样本录入、过程监控、结果处理 |
| 试剂耗材 | 高 | 试剂内/外部扫描管理、耗材管理 |
| 质量控制 | 高 | 质控方式、结果显示与查询 |
| 校准 | 高 | 校准、定标新增与查询 |
| 维护 | 高 | 仪器维护指令返回正确性 |
| 系统设置 | 中 | LIS设置、默认设置、用户账号、操作日志 |
1.3 测试类型全览
功能测试
- 数据项测试：输入正确数据是否按预期显示；错误输入能否识别并给出正确提示
- 业务流程测试：检查业务流程是否正确
- 数据流测试：验证各阶段数据是否按正确业务流程流动
易用性测试（4项）
- 界面设计友好性、符合用户习惯
- 易学习性
- 易操作性
- 错误提示信息的准确性与友好性
性能与压力测试
- 效率测试：PCT 项目从仪器复位到读出光子数时间要求 25-30 分钟
- 实施方法：手工测试
可移植性测试
- 硬件：产品技术要求的硬件环境下运行正常（飞凌嵌入式-FETMX6X-C 终端）
- 软件：产品技术要求的软件环境下运行正常（嵌入式操作系统）
- 均与功能测试一并执行
其他测试方法
- 接口测试：与 LIS 系统对接，可手动或实时上传样本数据
- 恢复测试：停机后按恢复规程进行恢复
- 回归测试：每一新版本均进行回归，验证 bug 是否修复、是否引入新 bug
- 系统测试：业务流程 + 数据流双维度
1.4 测试项通过准则
必须符合全自动微流控化学发光免疫分析仪软件系统开发标准和规程中的系统通过/失败标准。
1.5 暂停与恢复
- 暂停准则：系统无法开启或出现严重 bug 影响数据流程
- 恢复要求：新版本交付测试组后继续执行
1.6 测试任务安排（1人，共 33 工作日）
| 编号 | 活动 | 人员 | 工作日 |
|---|
| 1 | 测试环境搭建 | 1 | 5 |
| 2 | 编写测试说明和测试用例 | 1 | 5 |
| 3 | 执行测试 | 1 | 15 |
| 4 | 汇总结果、编制测试报告 | 1 | 8 |
1.7 测试环境
| 类别 | 配置 |
|---|
| 硬件 | 飞凌嵌入式-FETMX6X-C 终端 ×2、惠普 LaserJet 1020 plus 打印机、扫码枪 |
| 软件 | 嵌入式操作系统 |
| 通信 | 中位机 YGS_SerialTool |
1.8 人员与交付项
- 人员配备：测试经理 1 人 + 测试人员 2 人
- 风险：测试人员与开发理解不同步→持续关注需求并及时沟通；进度落后→加班安排
- 交付物：测试计划、测试用例、Bug 清单、测试报告
二、测试报告（附件4）
2.1 基本信息
| 项目 | 内容 |
|---|
| 报告标识符 | WLK01-0101 |
| 测试团队 | 文思海辉 Pactera 测试工程师：杨霞、赵雅丽、李小朵 |
| 测试类型 | 功能测试 + 用户界面测试 + 访问控制测试 + 可移植性测试 |
| 测试方法 | 黑盒测试，边界值方法、等价类划分，手工执行 |
2.2 四大测试类型
| 测试类型 | 测试内容 | 测试目的 |
|---|
| 功能测试 | 试剂/耗材管理、样本检测、质控、校准/定标、基础数据维护 | 验证功能按需求正常实现、数据准确 |
| 用户界面测试 | 页面设计、导航、易操作性、提示信息准确性 | 设计风格可接受、界面友好、符合用户习惯 |
| 访问控制测试 | 三级权限登录：工程师 / 管理员 / 普通用户 | 核实权限隔离、系统访问安全 |
| 可移植性测试 | 产品技术要求的软硬件环境 | 目标环境下可正常使用 |
2.3 需求覆盖分析（6大模块全部通过）
| 需求/功能 | 测试点 | 是否测试 | 是否通过 |
|---|
| 样本检测 | 录入与检测、过程监控、结果报告 | ✅ | ✅ |
| 试剂耗材 | 扫描录入、更换记忆提示 | ✅ | ✅ |
| 质量控制 | 新增质控方式、结果显示查询 | ✅ | ✅ |
| 校准 | 校准/定标新增、结果查询 | ✅ | ✅ |
| 维护 | 指令返回正确性 | ✅ | ✅ |
| 系统设置 | 账户设置、日志显示 | ✅ | ✅ |
2.4 测试用例执行统计（349 用例，全部执行）
| 模块 | 用例数 | 执行数 | 通过数 | 未通过数 | 通过率 |
|---|
| 样本检测 | 120 | 120 | 109 | 11 | 90.83% |
| 试剂耗材 | 28 | 28 | 28 | 0 | 100% |
| 质量控制 | 25 | 25 | 24 | 1 | 96% |
| 校准 | 43 | 43 | 43 | 0 | 100% |
| 维护 | 86 | 86 | 86 | 0 | 100% |
| 系统设置 | 47 | 47 | 46 | 0 | 97.8% |
| 合计 | 349 | 349 | 336 | 12 | 96.3% |
未通过用例集中在样本检测模块（11个），为主要功能风险点。
2.5 Bug 统计分析（共 131 个 Bug）
按模块分布
| 模块 | Bug 数量 | 占比 |
|---|
| 公共 BUG | 65 | 49.62% |
| 样本检测 | 25 | 19.08% |
| 校准 | 13 | 9.92% |
| 试剂耗材 | 10 | 7.63% |
| 质量控制 | 7 | 5.34% |
| 系统设置 | 7 | 5.34% |
| 维护 | 4 | 3.05% |
公共 BUG（近半数）反映系统架构层面的共性问题较多，样本检测模块 BUG 数第二，与用例未通过率最高一致。
按严重程度分布（A严重 / B功能缺陷 / C不影响但需修改 / D建议）
| 模块 | A级(严重) | B级(功能缺陷) | C级(需修改) | D级(建议) | 合计 |
|---|
| 公共BUG | 16 | 28 | 15 | 3 | 65 |
| 样本检测 | 6 | 8 | 7 | 4 | 25 |
| 校准 | 0 | 4 | 8 | 1 | 13 |
| 试剂耗材 | 0 | 4 | 2 | 5 | 10 |
| 质量控制 | 0 | 3 | 3 | 1 | 7 |
| 系统设置 | 0 | 2 | 3 | 2 | 7 |
| 维护 | 0 | 1 | 2 | 1 | 4 |
| 合计 | 22 | 50 | 40 | 17 | 131 |
A 级严重 Bug 共 22 个，其中 16 个集中在公共 BUG 中，6 个在样本检测模块。
Bug 状态（关闭 / 未关闭）
| 模块 | Bug 总数 | 已关闭 | 未关闭 |
|---|
| 公共BUG | 65 | 50 | 15 |
| 样本检测 | 25 | 7 | 18 |
| 校准 | 13 | 7 | 6 |
| 试剂耗材 | 10 | 4 | 6 |
| 质量控制 | 7 | 3 | 4 |
| 系统设置 | 7 | 2 | 5 |
| 维护 | 4 | 0 | 4 |
| 合计 | 131 | 73 | 58 |
备注：未关闭 Bug 多为页面优化、建议与偶现问题。
维护模块 4 个 Bug 全部未关闭，样本检测模块 7/25 关闭率最低（28%）。
2.6 测试结论
经过多轮测试，虽遗留了一些缺陷没有解决，但系统功能已趋于稳定，且项目确定的范围、策略和计划均已实现。
2.7 四大问题与建议
| 类别 | 问题描述 | 改进建议 |
|---|
| 变更控制 | 需求变更多口头传达，未及时更新文档，确认周期长 | 加强需求沟通确认，口头变更及时文档化 |
| 版本控制 | 各版本管理不善，测试版本与发布版本一致性难保证 | 建立清晰版本管理机制 |
| 测试环境 | 飞凌终端电源经常松动，测试中频繁重启影响效率 | 保证软硬件质量，提升环境稳定性 |
| 人员管理 | 测试人员变动大，职责不清晰 | 尽量保持人员稳定性 |
三、关键发现与观察
- 样本检测是风险核心：用例通过率最低（90.83%）、Bug 数第二多、A 级严重 Bug 6 个、关闭率最低（28%），是后续迭代的首要优化目标
- 公共 Bug 占比近半（49.62%）：反映系统架构层和通用组件存在较多共性问题，需从底层统一整改而非各模块修修补补
- 维护模块反差大：用例通过率 100% 但 4 个 Bug 全部未关闭，说明 Bug 可能集中在非核心路径或优先级较低
- 试剂耗材/校准/维护三大模块用例 100% 通过，质量相对稳定
- 22 个 A 级严重 Bug：16 个在公共层 + 6 个在样本检测，需优先闭环
- 测试团队配置偏轻：计划 1 人执行 33 工作日，实际 3 名测试工程师并行，反映实际测试工作量大于原计划
- 变更管理薄弱：需求口头变更 + 版本管理混乱是医疗器械软件研发的典型通病，也是 NMPA 注册核查的重点风险点
相关笔记