3. 回归测试平台需求分析

回归测试平台不是“把测试用例跑一遍”的工具，它的需求来自医疗软件特有的变更形态与合规约束。需求分析阶段要回答四个问题：变更从哪里来、哪些模块必须重测、按什么风险排序、平台要满足谁的使用诉求。这四个问题的答案，最终会沉淀为平台的功能需求与非功能需求清单。

一、医疗软件变更类型：先分类，再决定回归强度

医疗软件的变更很少是单一维度的。实践中可按“变更对象”和“影响半径”两个维度归类，常见类型如下：

• 缺陷修复型：修正算法边界、剂量计算、报警阈值判断等逻辑错误。影响半径通常局限在单个功能点，但若涉及剂量、报警等安全相关逻辑，必须扩大回归。
• 需求增强型：新增报告字段、增加设备型号支持、调整工作流。影响半径跨模块，常牵动接口与数据模型。
• 接口/协议型：HL7、DICOM、设备串口协议版本升级或字段扩展。影响半径沿数据链传播，需覆盖上下游。
• 平台/依赖型：操作系统、数据库、中间件、第三方库升级。影响半径全局，属于高风险变更。
• 配置/数据型：字典、模板、规则参数调整。看似轻量，但错误配置可能直接改变临床输出。
• 合规驱动型：为满足法规或标准而做的标识、日志、追溯性调整。

分类的目的不是归档，而是为每类变更预设回归基线。例如缺陷修复型默认执行“功能点用例 + 关联接口用例”，平台/依赖型默认触发全量冒烟加核心业务链。

二、回归范围界定：从变更点到影响域

范围界定常用“变更点 → 直接依赖 → 间接依赖 → 安全相关兜底”的扩散方式。以“修改放射治疗计划中剂量归一化算法”为例：变更点是归一化函数；直接依赖是计划计算模块与剂量显示；间接依赖是计划审批流、报告输出、DICOM 导出；安全兜底是剂量上限校验与报警。范围界定结果应形成可追溯的映射表，而不是凭经验口头圈定。

界定范围时需明确两个边界：纳入边界（本次必须回归的模块与用例集）和排除边界（明确不回归并记录理由，如“该模块本次未改动且无接口变化”）。排除项必须有依据，否则审计时无法解释。

三、风险驱动测试策略：把有限时间投到最危险处

医疗软件回归不可能每次全量执行，风险驱动是必然选择。风险值可用“失效严重度 × 发生可能性 × 可探测性”估算。严重度按临床影响分级：可能导致患者伤害的为最高级，仅影响操作效率的为最低级。发生可能性参考历史缺陷密度与变更复杂度。可探测性指问题是否容易被现有用例捕获，越难捕获风险越高。

据此形成三档策略：高风险执行全量回归并增加探索性测试；中风险执行核心业务链加接口回归；低风险执行冒烟与关键路径。策略必须与变更类型联动，例如平台/依赖型变更即使单点严重度不高，也因影响面广而整体上调一档。

四、干系人需求：不同角色要的东西不一样

需求分析要主动收集干系人诉求，否则平台上线后会出现“测试能跑但没人用”的尴尬。典型干系人及核心诉求：

五、平台功能需求与非功能需求

功能需求围绕“选、跑、看、管”四条主线：用例与需求/变更的关联管理、按风险与影响域自动推荐回归集、多环境并行执行与失败重试、结果对比与趋势分析、与缺陷系统和 CI 的集成。非功能需求则决定平台能否在医疗场景长期可用：

• 可追溯性：每次执行必须绑定代码版本、用例版本、环境配置与执行人，满足审计要求。
• 稳定性：长时间运行不丢结果，异常中断可恢复。
• 性能：核心回归集在约定时间窗内完成，例如 500 条用例在 2 小时内跑完（示例目标，需按实际环境标定）。
• 安全与权限：测试数据脱敏，操作按角色授权。
• 可扩展性：支持新增设备协议、新增用例类型而不改架构。

把上述内容落到一份可执行的需求条目上，才算完成本节任务。例如一条功能需求可写为：“平台应支持根据变更单关联的代码模块，自动推荐直接依赖与间接依赖用例集，并允许测试人员手工增减，增减记录留痕。”一条非功能需求可写为：“平台执行记录须保存不少于产品生命周期要求的期限，且支持按版本、时间、执行人检索导出。”需求写得越具体，后续平台实现与验收就越有依据。