回归测试与验收清单

内容类型：方法说明难度：进阶适合：需要证明修改正确且没有破坏旧行为的人阅读时间：约 12 分钟

回归测试不是“每次把整个软件重新测一遍”。先确定改了什么、可能影响什么，再选择能区分“修改前/修改后”的最小有效证据。

1. 风险等级和验证等级分开

本站用 R1–R5 表示修改风险/影响范围，V0–V4 表示验证强度：

验证级	典型范围	默认做法
V0	纯文案/静态内容	diff/static
V1	XAML/普通局部代码	affected build；focused test 仅在明确相关时
V2	通信/MES/存储/共享约束	affected build + focused fake/replay/unit
V3	状态机/联锁/并发/告警后果	affected build + focused + WorkflowSmoke
V4	发布/广泛兼容	完整 checkpoint

R1 文案             → V0
R1 XAML样式          → V1
R2/R3 局部代码       → V1/V2
R4 设备/MES/存储     → V2
R4 状态机/联锁       → V3
R5 发布              → V4

不要写成“R1 也必须项目构建 + 程序启动 + 全套单测”。

2. 每次回归先问四个问题

1. 本次实际改了哪些文件和行为？
2. 哪些旧行为共享同一状态、数据源、通信链路或约束？
3. 哪一种失败最容易被当前修改遗漏？
4. 最便宜的证据是什么：静态、focused test、模拟、回放、WorkflowSmoke 还是真机？

3. UI / MicroPatch

纯文案通常 V0：git diff --check、readback、旧文案残留检查。

XAML、样式和局部显示逻辑通常 V1：受影响 App/项目构建一次；只有存在明确相关测试时才跑 focused test。

不要因为改一个 DatePicker 颜色默认跑整个 UnitTests。

4. DomainConstraint：一个数字可能跨层

正式约束变化沿固定链检查一次：

UI → Domain/Application → MES/API → DeviceApply → FocusedTests

如果只是提示文字，可能是 DisplayOnly；如果真正改变正式业务约束，通常至少 V2。

5. BehaviorPatch 回归

按 Behavior Contract 验证：

Trigger
Condition
Action
Reset
Record
NonGoals

重点检查：

• 连续 N 次是否真的连续；
• 正常帧/无效帧如何重置；
• 事件后果是 InterlockFault / AlarmOnly / Advisory / Information 中哪一种；
• 日志记录的是 RawValue 还是 EngineeringValue；
• NonGoals 是否保持。

涉及报警后果、联锁、启动/停止或连续状态计数时，默认 V3 focused + WorkflowSmoke。

6. RegressionFix：先证明差异，再证明修复

用户说“以前正常、最近改后异常”时，回归验证至少包含：

known-good vs current
修复前 vs 修复后

如果问题重试后自恢复，当前结论只能是 SuspectedTransient，下一次优先抓时间戳、原始命令/报文、错误队列和状态变化。

回退到旧版本恢复时应写 RolledBackToKnownGood，不能自动等同 RegressionFixed。

7. 通信专项：按当前协议选择样本

不同通信模型需要的异常样本不同。

通用检查

场景	验证证据
正常连接/断开	状态 + 日志
正常收发	TX/RX/PARSE 对照
超时	超时结果、状态恢复、日志
断线/重连	不重复创建资源，状态正确
高频接收	缓存、CPU、内存、错误数
SCPI 状态残留	命令序列、错误队列、输出状态、时间戳

仅在协议相关时增加

• 自定义流式二进制协议：半包、粘包、帧边界；
• 有 CRC/Checksum 的协议：校验错误样本；
• 有 Sequence/Transaction ID：乱序、重复、关联错误；
• Modbus：功能码、异常码、寄存器范围、端序；
• SCPI：命令顺序、OPC/状态寄存器、错误队列、会话状态。

不要为了“通信测试完整”把与当前协议无关的 CRC/粘包测试机械加入。

能用 Fake/Replay 验证的先不碰真实设备；需要现场确认的内容留到 HardwarePending/HITL。

8. 数据、长稳和异常路径

按影响范围选择：

• 字段完整、单位、时间；
• 写入失败；
• 查询/导出兼容；
• 断线/重连；
• 大数据量；
• 重复开始/停止；
• 磁盘空间；
• 设备忙/超时/取消。

Advisory 检查要同时验证“提示发生”和“流程继续”，避免意外变成启动门禁。

性能/长稳结论必须有同场景基线；短时运行不能写成长稳通过。

9. 需求追踪和验收证据

推荐矩阵：

需求编号	要求	验收方法	结果状态	证据位置
R-001	连接指定设备	Fake + 真机	SoftwareVerified / HardwarePending	Replay/现场记录
R-002	显示实时数据	注入/Replay	Verified	截图/Replay
R-003	保存结果	完成一次测试	Verified / Unverified	样例文件

没有测试证据时，文档里不能把 DesignOnly 写成“已测试通过”。

10. DEV / SIT / FAT / SAT / Trial

层级	目的	典型证据
DEV	开发自测	build、focused test、模拟数据
SIT	系统集成	UI/通信/数据/日志闭环
FAT	交付前	需求逐条、异常路径、版本与配置
SAT	客户现场	真实设备、现场网络、权限、环境
Trial	试运行	长稳、错误数、数据完整性、问题闭环

FAT 的软件侧验证通过不自动替代 SAT；没有现场证据时保持 HardwarePending。

11. 完成判定

至少确认：

• 实际 Diff 与目标一致；
• 计划外行为没有改变；
• 验证等级与风险匹配；
• NoTestsMatched 没有被写成 TestPassed；
• EnvironmentBlocked 没有被写成代码失败或通过；
• 需要真机但未执行的内容明确 HardwarePending；
• ExperimentalChange 写清恢复方式；
• RegressionFix 写清 known-good 差异和 EvidenceGrade；
• 性能/长稳有实际基线时才写对应结论。

下一步

验证体系 Bug / 回归定位 真机安全 V10 Skill 说明