84 lines
4.4 KiB
Markdown
84 lines
4.4 KiB
Markdown
---
|
||
name: generate-test-cases
|
||
description: "当已有 normal/abnormal 测试项且需按统一规范生成可执行测试用例时使用；不负责测试方法选择，输出测试用例与合规校验报告。"
|
||
---
|
||
|
||
# generate-test-cases
|
||
|
||
## 目标
|
||
按测试项生成测试用例，每个测试项至少对应 1 条可重复执行、可评估通过的测试用例。
|
||
|
||
## 输入
|
||
- normal_test_items
|
||
- abnormal_test_items
|
||
- requirement_type（可选）
|
||
|
||
## 输出
|
||
- normal_test_cases
|
||
- abnormal_test_cases
|
||
- case_compliance_report
|
||
|
||
每条测试用例必须包含：
|
||
- case_id
|
||
- case_name
|
||
- test_traceability
|
||
- case_summary
|
||
- initialization_requirements
|
||
- test_inputs
|
||
- operation_steps
|
||
- expected_result_placeholder
|
||
- evaluation_criteria
|
||
- preconditions_constraints
|
||
- termination_condition
|
||
- pass_criteria
|
||
|
||
## 规则
|
||
1. 测试项与测试用例应保持一一对应关系。
|
||
2. 每个测试项必须至少生成 1 条测试用例。
|
||
3. 必须区分正常测试用例与异常测试用例。
|
||
4. 操作步骤应可顺序执行，避免歧义。
|
||
5. 操作步骤必须包含明确动作、对象和输入条件，禁止笼统动作词。
|
||
6. `case_summary` 与 `evaluation_criteria` 必须包含可验证条件，便于后续生成可度量预期成果。
|
||
7. 测试用例应符合可重复执行原则，初始条件和参数必须可复现。
|
||
8. 测试输入必须标识有效值/无效值/边界值性质、输入来源、真实或模拟属性及事件顺序。
|
||
9. 每个操作步骤应包含测试输入、动作、中间期望、评估准则与异常终止信号。
|
||
10. pass_criteria 必须明确是否通过的判定条件，禁止模糊描述。
|
||
|
||
## 统一生成规范（与测试方法无关）
|
||
1. 字段完整性：每条用例必须包含本 Skill 规定的全部字段，缺失字段不得省略，应给出“待补充”占位。
|
||
2. 可执行性：`operation_steps` 必须按可顺序执行的步骤组织，单步只表达一个核心动作，避免多动作混写。
|
||
3. 可复现性：`initialization_requirements`、`test_inputs`、`preconditions_constraints` 必须足以让第三方复现实验。
|
||
4. 可观测性：每条步骤必须关联可观测结果或中间检查点，避免只描述操作不描述观测。
|
||
5. 可判定性：`evaluation_criteria` 与 `pass_criteria` 必须给出明确判定阈值或布尔条件，禁止模糊词。
|
||
6. 异常完备性：异常用例必须包含异常触发条件、预期保护动作、终止条件与恢复后状态要求。
|
||
7. 去歧义：字段中禁止“适当”“正常”“合理”等无量纲表述，需替换为可验证条件。
|
||
8. 去重一致性：相同测试项下语义重复的用例应合并，保留最完整版本并保证编号稳定。
|
||
9. 追踪关系：`test_traceability` 必须指向来源测试项，保证“测试项 -> 测试用例”可追踪。
|
||
10. 结果衔接：`expected_result_placeholder` 必须可直接用于下一步预期成果展开，不得出现不可映射占位符。
|
||
|
||
## expected_result_placeholder 映射（用于 Step 4 展开）
|
||
- {{return_value}}：接口或函数返回值验证。
|
||
- {{state_change}}：系统状态变化验证。
|
||
- {{error_message}}：异常场景错误信息验证。
|
||
- {{data_persistence}}：数据库或存储落库结果验证。
|
||
- {{ui_display}}：界面显示反馈验证。
|
||
- {{precision_tolerance}}：精度与允许误差范围验证。
|
||
- {{time_constraint}}：时间上限/下限或事件间隔验证。
|
||
- {{retry_condition}}：不确定结果时重测触发条件验证。
|
||
- {{error_handling}}：出错处理流程与保护动作验证。
|
||
- {{sequence_event}}：时序、状态切换或事件顺序验证。
|
||
- {{resource_usage}}：资源占用与空间约束验证。
|
||
- {{pass_criteria}}：用例通过准则验证。
|
||
|
||
## 禁止模糊描述
|
||
- 错误示例："检查功能正常"；正确示例："验证返回状态码为200且响应体包含status=success"。
|
||
- 错误示例："输入合法数据"；正确示例："在用户名输入框输入长度为8的字母数字字符串并提交"。
|
||
- 错误示例："系统提示错误"；正确示例："触发非法输入后显示错误码E400和字段级提示文案"。
|
||
|
||
## 预期结果耦合
|
||
- 每条用例必须可在下一步绑定一条明确、可验证的预期成果。
|
||
- 每条 expected_result_placeholder 必须可映射到定量或可观察的检查项。
|
||
|
||
## 合规校验输出
|
||
- 输出 case_compliance_report，至少包含：case_id、completeness_score、executability_score、ambiguity_flags、gaps、fix_suggestions。
|