Appearance
回归测试与验收清单
这份文档分两件事：
- 回归测试：确认本次修改没有把旧功能改坏，重点补那些开发过程中不容易触发的问题。
- 验收清单：把最终结果和前面的需求说明书、技术要求、功能项、性能项逐条对齐。
回归测试和验收不是一回事。回归偏“改完有没有引入新问题”，验收偏“是否满足一开始说好的要求”。
1. 回归测试的真实作用
开发和调试过程中，很多明显问题已经被消灭了。比如编译错误、按钮点不了、页面打不开、明显报错，通常在开发时就会发现。
回归测试重点关注剩下那部分不容易暴露的问题：
- 触发条件没达到，所以开发时没发现。
- 操作顺序不同，问题才出现。
- 数据量变大后才出现。
- 通信断开、超时、异常帧时才出现。
- 长时间运行才出现。
- 换电脑、换设备、换配置后才出现。
- 修改 A 功能后，B 功能被间接影响。
所以回归测试不应该机械地全测一遍，而应该根据本次修改影响范围选择重点。
2. 按修改等级选择回归范围
| 修改类型 | 示例 | 回归范围 |
|---|---|---|
| L1 小改 | 文案、按钮位置、简单样式、明显编译错误 | 编译 + 当前页面/当前功能 |
| L2 快速修复 | 绑定字段、按钮事件、简单空值、路径错误 | 原问题 + 相关页面/相关功能 |
| L3 普通功能修改 | 新增按钮、新增页面字段、修改保存逻辑 | 当前功能 + 上下游功能 + 数据检查 |
| L4 通信/数据/线程修改 | 协议解析、接收缓存、数据保存、UI 刷新 | 通信链路 + 数据链路 + 异常路径 |
| L5 交付/高风险修改 | 真实设备、生产数据、数据库结构、发布版本 | 按需求和技术要求做系统验收 |
3. 回归测试先问三个问题
每次修改后，先问：
- 这次改了什么？
- 这次可能影响什么？
- 哪些问题开发时不容易触发？
示例：
| 修改内容 | 可能影响 | 不容易触发的问题 |
|---|---|---|
| 改连接按钮状态 | 连接/断开/UI 状态/日志 | 断线后按钮状态不恢复 |
| 改协议解析 | 接收缓存/数据解析/显示/保存 | 粘包半包、异常帧、CRC 错误 |
| 改数据保存 | 保存路径/字段/导出/查询 | 权限不足、磁盘满、大数据量 |
| 改实时曲线 | UI 刷新/内存/性能 | 长时间运行后卡顿 |
4. 通用冒烟检查
小改也至少做这些：
| 检查项 | 结果 | 备注 |
|---|---|---|
| 项目能编译 | 通过 / 不通过 | |
| 程序能启动 | 通过 / 不通过 | |
| 修改目标能看到效果 | 通过 / 不通过 | |
| 原问题已消失 | 通过 / 不通过 | |
| 没有明显新报错 | 通过 / 不通过 |
5. 按影响范围选择回归项
UI 回归
| 检查项 | 什么时候测 |
|---|---|
| 页面能打开 | 改页面、改样式、改导航 |
| 按钮状态正确 | 改按钮、连接状态、流程状态 |
| 数据能刷新 | 改绑定、ViewModel、数据源 |
| 页面切换正常 | 改导航、窗口、Tab |
| 长文本/异常值不撑坏布局 | 改显示字段、表格、日志 |
通信回归
| 检查项 | 什么时候测 |
|---|---|
| 能连接/断开 | 改连接逻辑、状态机 |
| 能收发数据 | 改发送、接收、协议 |
| 粘包半包能处理 | 改解析、缓存、TCP |
| 超时有提示 | 改请求回复、等待逻辑 |
| 断线状态正确 | 改重连、心跳、连接状态 |
| 原始日志可追踪 | 改通信、协议、异常处理 |
通信专项回归矩阵
涉及串口、TCP、Modbus、自定义协议、心跳、重连、缓存或解析时，不要只测“能收到一条正常数据”。
| 场景 | 验证方法 | 通过标准 | 证据 |
|---|---|---|---|
| 正常连接 | 打开串口或建立 TCP 连接 | UI 状态、日志、内部状态一致 | 连接日志截图或文本 |
| 正常收发 | 发送一条命令，接收正常响应 | 原始报文和解析结果一致 | TX/RX/PARSE 日志 |
| 半包 | 用模拟器分两次发送一帧 | 第一次不误解析，第二次解析成功 | 分包日志 |
| 粘包 | 一次发送两帧或多帧 | 能连续解析多帧 | 多帧解析日志 |
| CRC/校验错误 | 发送故意错误校验帧 | 不输出错误业务数据，有错误日志 | 错误帧日志 |
| 未知命令 | 发送未定义命令字 | 不崩溃，不污染正常流程 | 未知命令日志 |
| 超时 | 发送命令后不回复 | UI 提示或状态正确，日志有超时记录 | 超时日志 |
| 断线 | 拔线、关串口、停止 TCP 服务 | 状态恢复，禁止继续误操作 | 断线日志 |
| 重连 | 断线后恢复设备或服务 | 按规则重连，不重复创建连接 | 状态切换日志 |
| 高频接收 | 按目标频率连续发送数据 | UI 不卡，缓存不持续增长 | 运行时长、错误数、CPU/内存 |
如果没有模拟器，可以先用固定报文单元测试或日志回放验证协议解析；最终交付前再补真实设备验证。
数据回归
| 检查项 | 什么时候测 |
|---|---|
| 数据能保存 | 改保存逻辑、字段、路径 |
| 保存字段完整 | 改数据模型、导出、数据库 |
| 查询结果正确 | 改查询、过滤、时间范围 |
| 导出文件可打开 | 改导出、格式、路径 |
| 保存失败有提示 | 改异常处理、权限、路径 |
长时间和异常触发回归
| 检查项 | 什么时候测 |
|---|---|
| 连续运行一段时间不卡死 | 实时曲线、高频数据、通信接收 |
| 数据量变大不明显卡顿 | 表格、曲线、日志、保存 |
| 断线/重连后状态正确 | 串口/TCP/设备通信 |
| 异常帧/错误数据不崩溃 | 协议解析、数据处理 |
| 重复操作不出错 | 连接/断开、开始/停止、保存/导出 |
6. 验收清单要和需求对齐
验收不是凭感觉列一堆通用项，而是要和前面的需求说明书、技术要求、功能项、性能项对应起来。
建议把验收做成这种表：
| 需求编号 | 需求/技术要求 | 验收方法 | 通过标准 | 结果 | 备注 |
|---|---|---|---|---|---|
| R-001 | 软件能连接指定设备 | 连接真实设备或模拟设备 | 状态显示在线，日志有连接记录 | 通过 / 不通过 | |
| R-002 | 能显示实时数据 | 设备发送测试数据 | 界面数值和设备发送值一致 | 通过 / 不通过 | |
| R-003 | 能保存测试结果 | 完成一次测试 | 文件/数据库字段完整 | 通过 / 不通过 | |
| P-001 | 连续运行 8 小时 | 长时间运行测试 | 无崩溃、无明显卡顿 | 通过 / 不通过 |
如果前面没有需求编号，可以先让 AI 根据第一版需求方案生成编号。
6.1 验收证据怎么留
验收结论不要只写“通过”。至少保留能复查的证据。
| 验收类型 | 建议证据 |
|---|---|
| UI 功能 | 操作截图、关键状态截图、异常提示截图 |
| 通信功能 | 带时间戳的 TX/RX/PARSE 日志、模拟器记录、设备返回截图 |
| 数据保存 | 文件样例、数据库记录截图、导出文件、字段对照表 |
| 异常处理 | 超时、断线、保存失败、参数错误的日志或截图 |
| 性能稳定 | 运行时长、数据量、错误次数、CPU/内存记录 |
| 发布交付 | 版本号、配置文件、运行环境、旧版本备份位置 |
建议在验收报告里加一列“证据位置”：
| 需求编号 | 验收方法 | 通过标准 | 结果 | 证据位置 | 备注 |
|---|---|---|---|---|---|
| R-001 | 连接设备 | 状态在线，日志有连接记录 | 通过 / 不通过 | 日志文件或截图路径 |
7. 验收项分类
| 类型 | 对应内容 |
|---|---|
| 功能项 | 连接、采集、显示、控制、保存、查询、导出 |
| 通信项 | 收发、解析、异常帧、超时、断线、重连 |
| 数据项 | 字段完整、时间正确、查询正确、导出正确 |
| UI 项 | 页面可操作、状态清晰、关键数据可见 |
| 异常项 | 错误参数、设备断线、保存失败、通信异常 |
| 性能项 | 刷新频率、数据量、连续运行、不卡顿 |
| 文档项 | 使用说明、配置说明、测试记录、交付说明 |
7.1 工控交付测试分层
工控软件和上位机项目不要把“开发电脑上能跑”直接当成交付通过。更稳妥的分层是：
| 层级 | 名称 | 主要目的 | 典型环境 | 通过标准 |
|---|---|---|---|---|
| DEV | 开发自测 | 确认功能基本可运行 | 开发电脑、模拟数据、少量固定报文 | 编译、启动、核心功能跑通 |
| SIT | 系统集成测试 | 确认 UI、通信、数据、日志能串起来 | 测试环境、模拟器、部分真实设备 | 正常流程和异常路径通过 |
| FAT | 出厂/交付前测试 | 在交付前按需求验收软件和设备联动 | 公司内部、客户可远程或现场见证 | 需求项、通信项、数据项、异常项有记录 |
| SAT | 现场验收测试 | 确认软件在客户现场或产线环境可用 | 客户现场、真实设备、真实网络和权限 | 现场流程通过，环境和配置确认 |
| Trial | 试运行 | 验证一段时间内稳定性和问题闭环 | 产线或真实使用环境 | 长稳、错误数、数据完整性、问题记录可接受 |
不是每个项目都需要完整 FAT/SAT。简单自用工具可以只做 DEV + 关键回归；客户交付、产线、真实设备控制建议至少做 FAT 和 SAT。
FAT 检查重点
| 检查项 | 证据 |
|---|---|
| 需求编号逐条验收 | 需求追踪表、验收表 |
| 通信正常和异常场景 | TX/RX/PARSE 日志、模拟器或设备记录 |
| 数据保存和导出 | 数据文件、数据库截图、字段对照 |
| 配置文件和运行环境 | 配置说明、版本号、运行环境记录 |
| 已知风险 | 未测项、限制条件、客户待确认项 |
SAT 检查重点
| 检查项 | 证据 |
|---|---|
| 现场电脑和系统环境 | Windows、.NET、驱动、权限、路径 |
| 真实设备连接 | 端口/IP、线缆、设备状态、连接日志 |
| 现场操作流程 | 操作截图、客户确认、异常处理记录 |
| 数据保存路径和权限 | 实际路径、写入测试、导出样例 |
| 回滚方案 | 旧版本、旧配置、恢复步骤 |
8. 发给 AI 的回归 Prompt
text
请根据本次上位机修改内容，生成回归测试清单。
不要机械列全量清单，请先判断影响范围。
修改内容：
【写本次改了什么】
可能影响：
【如果不确定，请让 AI 判断】
请输出：
1. 修改等级：L1/L2/L3/L4/L5。
2. 必须回归的功能。
3. 开发时不容易触发、但需要补测的场景。
4. 正常路径测试。
5. 异常路径测试。
6. 需要保留的验收证据。
7. 安全检查点。
8. 发布前检查点。
9. 最小验证步骤。9. 发给 AI 的验收 Prompt
text
请根据下面的需求方案/技术要求，生成上位机项目验收清单。
要求：
1. 验收项必须和需求功能项、技术要求、性能要求一一对应。
2. 不要只给通用清单。
3. 每个验收项要包含：需求编号、验收方法、通过标准。
4. 如果需求里没有编号，请先自动编号。
需求方案/技术要求：
【粘贴需求方案或技术要求】
请输出：
1. 功能验收表。
2. 通信验收表。
3. 数据验收表。
4. UI 验收表。
5. 异常处理验收表。
6. 性能和稳定性验收表。
7. 仍需人工确认的验收项。10. 验收报告模板
text
项目名称：
验证日期：
验证人员：
验证环境：
需求版本：
一、验收范围
本次验收对应哪些需求编号/功能模块：
二、验收结果汇总
- 功能项：
- 通信项：
- 数据项：
- UI 项：
- 异常项：
- 性能项：
三、未通过项
| 需求编号 | 问题 | 影响 | 处理建议 |
四、已知风险
1.
2.
五、结论
通过 / 有条件通过 / 不通过11. 测试分层
不要把所有测试都理解成“手工点一遍界面”。不同风险对应不同测试层级。
| 层级 | 测什么 | 适合什么时候用 |
|---|---|---|
| 单元测试 | 纯逻辑、协议解析、校验、格式转换 | 改算法、CRC、报文解析、数据模型 |
| 集成测试 | 通信服务、存储服务、配置读写 | 改串口/TCP、数据库、文件保存 |
| UI 手工测试 | 页面操作、按钮状态、数据显示 | 改界面、绑定、命令、流程状态 |
| 模拟器测试 | 用模拟设备或测试报文验证链路 | 真实设备不方便、协议需要反复测 |
| 真实设备测试 | 和实际硬件联调 | 涉及真实动作、最终交付、客户现场 |
| 长稳测试 | 连续运行、数据量、内存、卡顿 | 高频采集、曲线、日志、保存、产线使用 |
建议：
- 协议解析优先做单元测试或固定报文测试。
- 通信链路优先用模拟器补正常帧、异常帧、断线重连。
- 涉及真实设备动作时，先模拟器，再低风险设备，再现场流程。
- 长稳测试要记录时间、数据量、错误数、CPU/内存趋势。
12. 安全检查
上位机虽然常见于测试和调试，但也可能控制真实设备。以下情况必须做安全检查。
| 检查项 | 什么时候必须检查 | 通过标准 |
|---|---|---|
| 危险动作确认 | 控制电机、继电器、电源、气缸、加热等 | 操作前有明确确认或互锁 |
| 参数范围限制 | 写入电压、电流、频率、速度、温度等 | 超范围不能下发，并有提示 |
| 通信命令确认 | 新增或修改控制命令 | 命令码、长度、校验、方向确认无误 |
| 断线状态 | 设备连接中断 | UI 状态恢复，禁止继续误操作 |
| 日志追踪 | 涉及设备动作或数据追溯 | 有时间、命令、结果、错误记录 |
| 权限和路径 | 保存到系统目录、网络目录、客户电脑 | 权限不足时不崩溃，有明确提示 |
| 数据隐私 | 日志或导出包含客户、设备、工艺信息 | 交付前脱敏或确认可保存 |
| 配置保护 | 修改配置文件、数据库连接、设备地址 | 旧配置可备份，新配置可回退 |
安全检查不通过时，不允许进入真实设备验证或现场交付。
13. 长稳测试记录
如果项目涉及实时采集、曲线刷新、连续保存、产线使用，建议做长稳测试。
| 项目 | 记录 |
|---|---|
| 测试日期 | |
| 测试环境 | 电脑、系统、.NET、设备或模拟器 |
| 软件版本 | |
| 运行时长 | |
| 数据频率 | |
| 总数据量 | |
| 通信错误次数 | |
| CRC/异常帧次数 | |
| 保存文件大小 | |
| CPU/内存变化 | |
| 是否卡顿或崩溃 | |
| 结论 | 通过 / 有条件通过 / 不通过 |
长稳测试不是越长越好。第一阶段可以先做 30 分钟或 1 小时；交付或产线使用再按需求做 4 小时、8 小时或更长。
13.1 长稳测试分级
| 场景 | 建议时长 | 适合阶段 |
|---|---|---|
| 快速验证 | 10 到 15 分钟 | 刚改完高频接收、曲线或保存逻辑 |
| 阶段验收 | 30 分钟到 1 小时 | 功能基本完成，准备给客户或同事试用 |
| 交付前验证 | 4 到 8 小时 | 产线、客户现场、连续采集、自动测试 |
| 专项压力 | 按项目要求 | 高频数据、大文件保存、长时间日志、数据库写入 |
长稳测试期间至少记录：
- 开始时间和结束时间。
- 数据频率和累计数据量。
- 通信错误次数、CRC 错误次数、超时次数。
- CPU 和内存的大致变化。
- UI 是否卡顿、日志是否持续增长、保存文件是否正常。
- 断线或异常恢复是否符合预期。
14. 发布前检查
准备把软件发给客户、现场或产线前，至少确认：
| 检查项 | 结果 | 备注 |
|---|---|---|
| 发布版本号明确 | 通过 / 不通过 | |
| 编译配置正确 | Debug / Release | |
| 运行环境明确 | 通过 / 不通过 | Windows、.NET、驱动 |
| 配置文件已说明 | 通过 / 不通过 | 串口、IP、路径、数据库 |
| 日志路径可写 | 通过 / 不通过 | |
| 数据保存路径可写 | 通过 / 不通过 | |
| 旧版本已备份 | 通过 / 不通过 | |
| 旧配置已备份 | 通过 / 不通过 | |
| 已知风险已记录 | 通过 / 不通过 | |
| 人工审核完成 | 通过 / 不通过 | 真实设备和危险动作必须审核 |
15. 可回滚检查
改动越靠近交付，越要提前想好回滚。
| 回滚对象 | 检查内容 |
|---|---|
| 程序版本 | 是否保留上一版可运行程序 |
| 配置文件 | 是否备份旧配置，是否能恢复默认配置 |
| 数据库 | 是否有迁移脚本和备份，是否能兼容旧数据 |
| 协议配置 | 新旧命令是否兼容，设备端是否同步 |
| 数据文件 | 新字段是否影响旧工具打开 |
| 现场说明 | 如果新版本失败，谁负责恢复，怎么恢复 |
如果没有回滚方案，不建议在生产环境或客户现场直接替换。