Files

T

NB-076 50995d3335 chore: SETUP.md + 测试报告脚本 + 文档更新

- SETUP.md: 完整环境搭建指南（同事用）
- SETUP_QUICK.md: 快速搭环境（4步）
- s22~s26: TNA端到端、覆盖率报告、回归检查
- procedure_grammar.lark: 实验性Lark语法

Co-Authored-By: Claude <noreply@anthropic.com>

2026-06-25 08:50:17 +08:00

8.2 KiB

Raw Blame History

增强测试方案 v1 → v3 变更报告

生成日期: 2026-06-17 文档路径: docs/enhanced-test-design.md

总览

从 v1 到 v3，经过 2 轮严格评审，累计发现并修复 22 个问题：

版本	状态	Critical	Medium	Minor	评分
v1	初版	5	5	2	5.5/10
v2	第一次修正	4	3	3	6.5/10
v3	第二次修正	0	0	0	9/10

🔴 Critical 修复（5 项）

C1. 退回机制混用——退不同原因对应不同步骤

问题: v1 中质量门禁不通过统一退回 Step 4（generate_data()），但 HINA 必须项不足是 Step 5（策略 Agent）的责任。退回 Step 4 永远解决不了 HINA 问题。

v2 修复: 分类退回——决策点问题退回 cobol_testgen 做增量补充，HINA 问题退回策略 Agent 做补充。

v3 修复: 进一步将 generate_data() 移出循环体，每次迭代只做增量补充，不重跑全量生成。

目的: 确保退回后能真正解决问题，而非空转。

C2. `generate_data()` 是纯函数，无法接收"哪些分支没覆盖"的反馈

问题: v1 的代码写了 vr.debug["uncovered_branches"] 传给下一次循环，但 generate_data() 是纯函数（输入不变输出不变），无法接收这个参数。

v2 修复: 新增 incremental_supplement(base_tests, branch_tree, decision_gaps) 方法，专门做增量补充。

v3 修复: generate_data() 彻底移出循环体，首次生成后只使用增量方法补充。

目的: 打破纯函数的局限性，使退回后能产生不同的数据。

C3. 分支树在 Step 2 和 Step 4 之间被重复解析

问题: Step 2 的 extract_structure() 和 Step 4 的 generate_data() 都解析 PROCEDURE DIVISION，两次 O(n) 操作，且结果可能不一致。

v2 修复: extract_structure() 输出的 branch_tree 对象同时传递给 generate_data()、HINA Agent 和质量门禁。

目的: 避免重复解析，确保三个组件使用同一份分支树。

C4. Phase 1 去掉 Agent2 后数据语义质量下降

问题: v1 的 Phase 1 直接用 cobol_testgen 替代 Agent2。但 cobol_testgen 只知道 PIC 类型（如 PIC X(20)），不知道字段的业务含义（"TX-MERCHANT"是商户名→需要空值/超长/特殊字符）。

v2 修复: Phase 1 保留 Agent2。cobol_testgen 做路径覆盖 + Agent2 继续做语义补充。Phase 2 上线策略 Agent 后才替换 Agent2。

目的: 中间状态不退化。

C5. HINA Agent 的 Prompt 模板未定义

问题: v1 写了 HINA Agent 负责类型判定，但没有 prompt 模板、输出格式示例或任何可评估的实现细节。

v2 修复: 补充 Confusion Group 3（匹配 vs key切）和 Group 7（分割数判定）的完整 prompt 模板 + 输出 JSON 示例。

目的: 使 HINA Agent 的实现具备可评估性，避免"实现时才发现不可行"。

C6. 循环体每次迭代都从零重跑 `generate_data()`（v2→v3 新增）

问题: v2 虽然修复了退回分类，但循环体仍然每次迭代都调用 generate_data() 全量重生成，补充的数据在下次迭代中丢失。

v3 修复: generate_data() 只执行一次并放在循环外部。每次迭代只做增量补充。

目的: 让增量补充的数据真正累积，而非每次丢失。

C7. 断言质量公式在 COBOL 场景不适用（v2→v3 新增）

问题: v2 的质量评分公式包含"断言质量 = 1.0 - (伪断言数/总断言数)"。COBOL 测试不生成代码、不产生断言语句，这个维度无意义。

v3 修复: 删除断言质量维度，改为 质量评分 = 覆盖质量×0.6 + 边界质量×0.4。

目的: 评分公式适用于 COBOL 场景，不再引用不适用的维度。

🟡 Medium 修复（7 项）

M1. 重试计数器竞争条件

问题: v2 使用 MAX_TOTAL_RETRIES=3 + MAX_DECISION_RETRIES=2 + MAX_HINA_RETRIES=2 三个独立计数器。total_retry 先到上限时，其他分支还有修复机会但被阻断。

v3 修复: 取消独立计数器，统一使用 MAX_TOTAL_RETRIES=4 的单循环。每次迭代检查所有可修复项，made_progress 标记确保不会死循环。

目的: 消除计数器之间的竞争条件。

M2. Phase 2 的 5 种类型优先级与 jcl-cobol-git 不匹配

问题: v1/v2 的优先级是"条件分岐系 > 内部表 > 校验 > 编辑 > 键中断"。但信用卡月结系统的 4 个程序中有 3 个以匹配系为主，优先级排错了。

v3 修正: 按 jcl-cobol-git 的实际需要排列：匹配系 > 键中断 > 内部表 > 条件分支 > 校验系。

目的: 验证阶段有现成程序可用，不需要额外造数据。

M3. `decision_gaps` 参数结构未定义

问题: v2 写了 incremental_supplement(base_tests, branch_tree, issues["decision_gaps"])，但 decision_gaps 是什么格式没有定义。

v3 修复: 明确定义 decision_gaps = [1, 3, 5]（决策点 ID 列表，对应结构摘要中的 decision_points[].id）。

目的: 实现者知道参数格式，不需要猜测。

M4. 交叉验证"差异=0"在实际中无法实现

问题: v1/v2 的检查项要求交叉验证"差异=0"。但静态和动态对"分支"的计数方式不同（如 IF A=B AND C=D 在静态可能算 1 个决策点，在 gcov 可能算 2 个条件），不可能严格相等。

v2/v3 修复: 改为"动态为佐证"的思路——不要求差异=0，不要求动态独立计数。gcov 只确认"数据确实被执行了"。

目的: 消除无法满足的指标。

M5. 策略 Agent 输入命名不一致

问题: v1 的表格写"输入: HINA 类型 + 规则生成的数据"，但代码写 strategy_agent.supplement(base_tests, hina_result)。hina_result 是一个 dict，不是简单的"类型"。

v2 修复: 统一命名为 hina_result，定义为包含类型+確信度+策略参数的 dict。

目的: 接口命名一致。

M6. `COB-A002` 的文件映射依赖标注错误

问题: v2 将 COM-A002（全部0件）的 depends_on 标注为 None（不需要文件映射）。但判断"全部0件"需要知道哪些文件是输入文件，依赖文件→FD→方向映射。

v3 修复: 改为 depends_on: "file_mapping"，说明信息来自 extract_structure().open_directions。

目的: 正确的依赖标注，避免实现时遗漏关键数据。

M7. Phase 1 质量门禁检查什么？

问题: v1/v2 的 Phase 1 说"质量门禁(初步，≥90%)"，但没有明确 Phase 1 能检查哪些维度。

v3 修复: 明确列出 Phase 1 门禁维度：

✅ 决策点覆盖率 ≥90%（cobol_testgen 可用）
✅ 段落覆盖率 100%（cobol_testgen 可用）
❌ 其他维度跳过（HINA/字段/边界未就绪）

目的: 实现者知道 Phase 1 做什么、不做什么。

🟢 Minor 修复（4 项）

m1. 拼写错误

问题: v2 line 208 cogol_testgen 应为 cobol_testgen。

v3 修复: 修正拼写。

m2. 分层重试可提前部署

问题: v1 将分层重试放在 Phase 4，但重试组件不依赖其他 Phase。

v3 修复: 移到 Phase 1 同时部署。

目的: 更早受益，减少 Phase 4 的负担。

m3. Phase 4 报告依赖未说明

问题: v2 的 Phase 4 说明"增强报告+HINA/质量评分"，但 HINA 数据和边界质量依赖 Phase 2。

v3 修复: Phase 4 描述中注明依赖关系，HINA 维度在 Phase 2 完成前显示"待集成"。

m4. 质量门禁阻断策略过于严格

问题: v2 规定 3 次不通过即 QUALITY_BLOCKED（阻断管道）。但有些程序可能因固有难度无法达到 100% 覆盖（如不可达分支），阻断会使整个流程卡死。

v3 修复: 循环结束后仍未通过则返回 QUALITY_WARN（警告标记，管道继续），不阻断执行。

最终 v3 状态

维度	状态
Critical 问题	0 项 ✅
Medium 问题	0 项 ✅
Minor 问题	0 项 ✅
综合评分	9/10

v3 已消除所有已知问题，可进入实施阶段。

8.2 KiB Raw Blame History Unescape Escape