rag_agent/.github/skills/generate-test-cases-whitebox/SKILL.md

name, description

name	description
generate-test-cases-whitebox	当 recommended_test_methods 命中 M13-M18 时使用，按路径/数据/变异/插桩证据链生成可追踪测试用例并输出 method_alignment_report。

generate-test-cases-whitebox

目标

对输入测试项应用白盒方法（M13-M18），生成带可追踪执行证据的测试用例。

输入

• normal_test_items
• abnormal_test_items
• requirement_type（可选）
• recommended_test_methods（可选，格式建议 Mxx|方法名）

输出

• normal_test_cases
• abnormal_test_cases
• method_alignment_report

白盒方法范围

• M13 控制流测试
• M14 数据流测试
• M15 程序变异
• M16 程序插桩
• M17 域测试
• M18 符号求值

通用规则

1. 白盒用例必须包含证据锚点（路径编号、DU对、变异体、插桩点、域编号、约束编号）。
2. test_inputs 应能触发目标证据链，禁止只描述功能输入。
3. operation_steps 必须包含证据采集或比对动作。
4. case_summary 必须标注 Mxx|方法名。
5. 白盒用例可结合 {{pass_criteria}}、{{resource_usage}}、{{state_change}} 进行结果绑定。

方法详细说明（M13-M18）

• M13 控制流测试：依据控制流图生成用例，目标是覆盖不同控制结构。常用覆盖包括语句覆盖、分支覆盖、条件覆盖、条件组合覆盖、MC/DC 和路径覆盖。标准步骤为：流程图转控制流图、路径表达式求解、路径树生成、路径编码与译码、按目标路径枚举测试用例。method_alignment_report 应记录覆盖准则与未覆盖路径原因。
• M14 数据流测试：在控制流图上分析变量定义、使用和消除，重点发现“未定义就使用”与“定义后未使用”等数据流异常。建议步骤为：构建控制流图、标注链路数据操作符、选择数据流覆盖策略、导出测试路径、再生成输入与用例。除静态分析外，可结合动态数据流检查提高真实性，但要说明路径覆盖局限。
• M15 程序变异：以错误驱动方式定义变异算子并生成语法合法的变异体，通过测试数据逐个执行变异体判断检测能力。可区分强变异与弱变异，并在报告中统计“杀死率、存活率、等价变异占比”。该方法既用于找缺陷，也用于评价现有测试用例集的有效性。
• M16 程序插桩：通过在程序中插入观测操作实现证据采集，但不得改变被测程序原有功能与运行语义。建议步骤为：定位插桩点、插入采样逻辑、执行测试、回收与分析数据、移除或关闭插桩。由于数据记录量通常较大，宜借助工具完成并在报告中注明插桩开销与可信度。
• M17 域测试：目标是验证程序对输入空间划分是否正确，重点检查域内、边界和跨域样本的判定一致性。该方法约束较多、使用门槛较高，通常用于有特殊质量要求的场景。用例中应保留域划分依据与判定规则，避免仅给样本值不说明域归属。
• M18 符号求值：允许变量取符号值，通过符号执行检查公式与分支约束是否满足预期，并可导出程序路径用于生成测试数据。适用于公式密集或约束明确的逻辑。复杂分支推荐工具化处理，分支较少时可人工推导并在用例中记录约束来源与推导过程。

对齐输出要求

• 在 method_alignment_report 中记录：case_id、selected_methods、alignment_score、gaps、fix_suggestions。
• 对无法构造证据链的方法，必须输出 gaps 与降级策略说明。