Appearance
AI 辅助 C# 测试与回归（V10）
测试的目标不是“尽可能多跑”，而是用最便宜、最稳定、最接近当前风险的证据证明这次修改没有偏离目标。
V10 先确定 affected scope 和 Verification Level，再决定要不要写测试、跑哪些测试。
1. 先看 V0–V4
| 等级 | 常见任务 | 测试策略 |
|---|---|---|
| V0 | 文案/静态资源 | 通常不需要单测 |
| V1 | XAML/普通局部代码 | affected build；有明确 focused test 才跑 |
| V2 | 设备/通信/MES/存储/共享约束 | focused unit/fake/replay |
| V3 | 状态机/联锁/并发/恢复 | focused workflow tests + WorkflowSmoke |
| V4 | 发布/大范围兼容 | full checkpoint |
详细定义见 AI 开发验证体系。
2. Focused First
推荐：
text
affected project
→ relevant test project
→ narrow test filter
→ build 已成功时使用 --no-build / --no-restore不要默认：
text
改一处代码
→ 整个 solution build
→ 整个 UnitTests
→ 整个 IntegrationTests
→ 全流程 smoke除非这次修改确实需要 V4。
3. 0 个测试匹配不是通过
过滤命令如果返回：
text
Total tests: 0应记录：
text
NoTestsMatched而不是 TestPassed。
下一步可以修正 filter、找已有更合适测试、写 NoRelevantFocusedTest，或使用 Fake/Replay/手工检查。不要因为 filter 没匹配就自动跑整个测试仓库兜底。
4. 什么代码适合单元测试
| 场景 | 适合程度 |
|---|---|
| 纯计算/换算 | 高 |
| 协议解析 | 高 |
| 状态转换 | 高 |
| 数据格式转换 | 高 |
| 阈值/连续 N 次判定 | 高 |
| ViewModel 可观察行为 | 中高 |
| 串口/TCP 真实链路 | 模拟高，真机另验 |
| UI 像素布局 | 低，build + 人工查看更合适 |
5. Stable Seam：测行为，不绑死实现
优先验证 parser 输入输出、application service、workflow 状态转换、fake device、captured replay、ViewModel state/command。
不推荐为了断言私有方法、局部变量或调用次数而暴露新的公共 API。
6. BehaviorPatch 的测试模板
例如“连续 5 次高电流才 AlarmOnly”：
text
1~4 次越限 → 不触发
第 5 次 → 触发一次
中间一次正常 → 连续计数清零
下一窗口 → 重新计数
触发后 → 不 Stop
日志 → 含连续帧证据和单位测试名称表达业务行为，不写实现细节。
7. Measurement Semantics 的测试
固定 Raw 输入，验证：
text
RawValue
→ Conversion
→ EngineeringValue
→ ThresholdBasis
→ LoggedUnit再覆盖刚好等于阈值、略低/略高、无效值、单位和日志格式。
详见 测量值语义。
8. 协议/通信优先 Replay
真实设备不稳定、现场不方便时，优先保存：原始 HEX、SCPI 命令/返回、时间戳、设备状态、错误队列。
用 Captured Replay 复现解析和状态逻辑，比反复连真机“碰碰运气”更稳定。
但测试矩阵应按当前协议选择。SCPI 文本、厂商 SDK、自定义二进制 TCP 需要的异常样本并不相同，不机械要求每个通信模块都测半包/粘包/CRC。
9. WorkflowSmoke 和 WorkflowFull 不一样
WorkflowSmoke
只覆盖本次高风险改动的关键路径：
text
启动
→ 目标状态转换
→ 修改后的行为
→ 恢复/停止WorkflowFull
覆盖更广泛完整业务流程，适合 V4、发布、重大重构。
V3 默认先 Smoke，不自动 Full。
10. EnvironmentBlocked 与 HardwarePending
这两个状态不要混用。
EnvironmentBlocked
验证本应在当前软件环境执行，但被工具/权限/环境阻塞，例如：
- E-SafeNet 导致 build 文件污染；
- CI 缺 SDK；
- 构建目录无权限。
示例：
text
Build: EnvironmentBlocked
StaticCheck: Verified
Reason: E-SafeNet generated-file pollutionHardwarePending
软件侧证据已经做到当前可做范围，但真实设备/HITL 尚未执行，例如：
- 真机不在现场；
- 高压动作尚未授权；
- 需要客户现场网络/设备；
- 保护链需要现场联调。
示例：
text
Build: Verified
FocusedTests: Verified
Replay: Verified
HardwareVerification: HardwarePending不要为了得到全绿自动连接真实设备。
详见 真实设备操作安全。
11. Bug 修复没有自动回归测试怎么办
不要为了形式强行写低价值测试。可以选择：
text
现有 focused test
Fake / Simulation
Replay
日志时间线
known-good diff
最小 harness
手工复现步骤关键是保留以后能证明“这个 Bug 是否重新出现”的反馈方式。
12. 性能修复怎样回归
性能任务不能只有“功能没坏”。至少保留同一场景的前后基线：
text
Scenario
Before CPU / Memory / Latency
After CPU / Memory / Latency
Correctness Evidence短时改善不能自动写成长稳通过。
详见 性能与长稳诊断。
13. 测试 Prompt
设计 focused test
text
$host-computer-dev
根据当前 Diff 和 affected scope 设计最小测试。
要求：
1. 先判断 Verification Level；
2. 优先已有 stable seam；
3. 不为测试小改创建新公共接口；
4. 先给最小 focused filter；
5. 0 tests matched 不能算通过；
6. 真机验证单独列为 HardwarePending/HITL。回归清单
text
请根据本次改动输出：
- affected projects
- focused automated tests
- Fake/Replay
- UI/manual checks
- EnvironmentBlocked（如有）
- HardwarePending（如有）
- explicitly not required
- residual risk14. 验收输出建议
text
VerificationLevel: V2
Build: Verified
FocusedTests: 7/7 Verified
Replay: Verified
EnvironmentBlocked: None
HardwareVerification: HardwarePending
ResidualRisk: 真实设备断线恢复尚未现场验证不要只写“测试通过”。
下一步
一句话原则
先根据改动风险找最小有效证据；软件环境阻塞写 EnvironmentBlocked，真机尚未执行写 HardwarePending，只有发布和广泛兼容问题才默认走全量验证。