init. project

This commit is contained in:
2026-04-13 11:34:23 +08:00
commit c7c0659a85
202 changed files with 31196 additions and 0 deletions

View File

@@ -0,0 +1,46 @@
---
name: decompose-test-items
description: "当需要基于需求类型把需求文本分解为可执行的正常/异常测试项时使用。"
---
# decompose-test-items
## 目标
基于用户需求文本和已识别需求类型,生成测试项列表。
## 输入
- user_requirement_text
- requirement_type
## 输出
- normal_test_items完整、可执行的正常测试项列表。
- abnormal_test_items完整、可执行的异常测试项列表。
## 强制规则
1. 每个软件功能至少应被正常测试与被认可的异常场景覆盖;复杂功能需继续细分。
2. 每个测试项必须语义完整、可直接执行。
3. 覆盖必须包含:正常流程、边界条件(适用时)、异常条件。
4. 粒度需适中,避免过粗或过细。
5. 对未知类型必须执行通用分解,并保持正常/异常分组。
6. 对需求说明未显式给出但在用户手册或操作手册体现的功能,也应补充测试项覆盖。
## 14类最小分解检查点
- 功能测试:正常覆盖功能主路径、基本数据类型、合法边界值与状态转换;异常覆盖非法输入、不规则输入、非法边界值与最坏情况。
- 性能测试:正常覆盖处理精度、响应时间、处理数据量与模块协调性;异常覆盖超负荷、软硬件限制、负载潜力上限与资源占用异常。
- 外部接口测试:正常覆盖全部外部接口格式与内容正确性;异常覆盖每个输入输出接口的错误格式、错误内容与异常交互。
- 人机交互界面测试:正常覆盖界面风格一致性与标准操作流程;异常覆盖误操作、快速操作、非法输入、错误命令与错误流程提示。
- 强度测试:正常覆盖设计极限下系统功能和性能表现;异常覆盖超出极限时的降级行为、健壮性与饱和表现。
- 余量测试:正常覆盖存储、通道、处理时间余量是否满足要求;异常覆盖余量不足或耗尽时系统告警与受控行为。
- 可靠性测试:正常覆盖典型环境、运行剖面与输入变量组合;异常覆盖失效等级场景、边界环境变化、不合法输入域及失效记录。
- 安全性测试:正常覆盖安全关键部件、安全结构与合法操作路径;异常覆盖危险状态、故障模式、边界接合部、非法进入与数据完整性保护。
- 恢复性测试:正常覆盖故障探测、备用切换、恢复后继续执行;异常覆盖故障中作业保护、状态保护与恢复失败路径。
- 边界测试:正常覆盖输入输出域边界、状态转换端点与功能界限;异常覆盖性能界限、容量界限和越界端点。
- 安装性测试:正常覆盖标准及不同配置下安装卸载流程;异常覆盖安装规程错误、依赖异常与中断后的处理。
- 互操作性测试:正常覆盖两个或多个软件同时运行与互操作过程;异常覆盖互操作失败、并行冲突与协同异常。
- 敏感性测试:正常覆盖有效输入类中典型数据组合;异常覆盖引发不稳定或不正常处理的特殊数据组合。
- 测试充分性要求:正常覆盖需求覆盖率、配置项覆盖与代码覆盖达标;异常覆盖未覆盖部分逐项分析、确认与报告输出。
## 未知类型容错
- 当 requirement_type 无法确定时,仍需输出正常/异常两组测试项。
- 通用正常项至少包含:主流程正确性、合法边界值、标准输入输出。
- 通用异常项至少包含:非法输入、越界输入、资源异常或状态冲突。

View File

@@ -0,0 +1,45 @@
---
name: generate-test-cases
description: "当需要根据已分解测试项生成包含操作步骤与测试内容的具体测试用例时使用。"
---
# generate-test-cases
## 目标
按测试项生成测试用例,每个测试项至少对应 1 条用例。
## 输入
- normal_test_items
- abnormal_test_items
## 输出
- normal_test_cases
- abnormal_test_cases
每条测试用例必须包含:
- operation_steps
- test_content
- expected_result_placeholder
## 规则
1. 测试项与测试用例应保持一一对应关系。
2. 每个测试项必须至少生成 1 条测试用例。
3. 必须区分正常测试用例与异常测试用例。
4. 操作步骤应可顺序执行,避免歧义。
5. 操作步骤必须包含明确动作、对象和输入条件,禁止笼统动作词。
6. test_content 必须包含可验证条件,便于后续生成可度量预期成果。
## expected_result_placeholder 映射
- {{return_value}}:接口或函数返回值验证。
- {{state_change}}:系统状态变化验证。
- {{error_message}}:异常场景错误信息验证。
- {{data_persistence}}:数据库或存储落库结果验证。
- {{ui_display}}:界面显示反馈验证。
## 禁止模糊描述
- 错误示例:"检查功能正常";正确示例:"验证返回状态码为200且响应体包含status=success"。
- 错误示例:"输入合法数据";正确示例:"在用户名输入框输入长度为8的字母数字字符串并提交"。
- 错误示例:"系统提示错误";正确示例:"触发非法输入后显示错误码E400和字段级提示文案"。
## 预期结果耦合
- 每条用例必须可在下一步绑定一条明确、可验证的预期成果。

View File

@@ -0,0 +1,62 @@
---
name: identify-requirement-type
description: "当需要在测试项分解与测试用例生成之前识别需求类型时使用。"
---
# identify-requirement-type
## 目标
将用户需求文本识别为明确的测试需求类型,为后续测试项分解与测试用例生成提供分类依据。
## 输入
- user_requirement_text用户原始需求文本。
## 输出
- requirement_type以下之一
- 功能测试
- 性能测试
- 外部接口测试
- 人机交互界面测试
- 强度测试
- 余量测试
- 可靠性测试
- 安全性测试
- 恢复性测试
- 边界测试
- 安装性测试
- 互操作性测试
- 敏感性测试
- 测试充分性要求
- 未知类型
- reason简要判断依据。
- candidates当 requirement_type 为未知类型时,给出 1-3 个最接近候选类型。
## 类型识别信号
- 功能测试:关注功能需求逐项验证、业务流程正确性、输入输出行为、状态转换与边界值处理。
- 性能测试:关注处理精度、响应时间、处理数据量、系统协调性、负载潜力与运行占用空间。
- 外部接口测试:关注外部输入输出接口的格式、内容、协议与正常/异常交互表现。
- 人机交互界面测试:关注界面一致性、界面风格、操作流程、误操作健壮性与错误提示能力。
- 强度测试:关注系统在极限、超负荷、饱和和降级条件下的稳定性与承受能力。
- 余量测试:关注存储余量、输入输出通道余量、功能处理时间余量等资源裕度。
- 可靠性测试:关注真实或仿真环境下的失效等级、运行剖面、输入覆盖和长期稳定运行能力。
- 安全性测试:关注危险状态响应、安全关键部件、异常输入防护、非法访问阻断和数据完整性保护。
- 恢复性测试:关注故障探测、备用切换、系统状态保护与从无错误状态继续执行能力。
- 边界测试:关注输入输出域边界、状态转换端点、功能界限、性能界限与容量界限。
- 安装性测试:关注不同配置下安装卸载流程和安装规程执行正确性。
- 互操作性测试:关注多个软件并行运行时的互操作能力与协同正确性。
- 敏感性测试:关注有效输入类中可能引发不稳定或不正常处理的数据组合。
- 测试充分性要求:关注需求覆盖率、配置项覆盖、语句覆盖、分支覆盖及未覆盖分析确认。
## 规则
1. 优先依据需求文本中的显式表述进行分类。
2. 分类应以语义意图为主,不能只做关键词机械匹配。
3. 置信度不足时输出未知类型,并提供候选类型。
4. 判断依据需简洁、可追溯到文本证据。
## 容错
- 当需求描述过于笼统或跨多类型混合时,输出未知类型,并在 candidates 给出最接近类型。
- 当识别不稳定时,优先保守分类,不强行归入单一类型。
- 未知类型不阻断后续流程,应继续执行通用测试项分解。
## 调试
- debug 模式下返回每个类型的分类分数 classification_scores。

View File

@@ -0,0 +1,57 @@
---
name: testing-orchestrator
description: "当用户要求测试项分解或测试用例生成且需要完整工具调用链时使用。"
---
# testing-orchestrator
## 目标
严格执行测试生成调用链,并显式传递每一步上下文。
## 标准调用链
1. identify-requirement-type
2. decompose-test-items
3. generate-test-cases
4. build_expected_results
5. format_output
## 编排规则
1. 优先使用 Skill 与 Tool不使用临时硬编码逻辑替代。
2. 除非用户明确要求,否则不得跳过任何步骤。
3. 每一步必须显式接收上一步输出。
4. 分类失败时输出未知类型并继续执行通用分解。
## 输出模板
最终输出必须严格遵循以下分组结构:
**测试项**
**正常测试**
1. [测试项 N1]...
**异常测试**
1. [测试项 E1]...
**测试用例**
**正常测试**
1. [用例 N1](对应测试项 N1...
**异常测试**
1. [用例 E1](对应测试项 E1...
**预期成果**
**正常测试**
1. [预期 N1](对应用例 N1...
**异常测试**
1. [预期 E1](对应用例 E1...
## 调试模式
当 debug=true 时,输出步骤日志并包含:
- step_name
- input_summary
- output_summary
- success
- fallback_used