init. project

.github/AGENTS.md

@@ -0,0 +1,24 @@
+# 测试生成智能体约定
+
+## 适用范围
+- 本工作区包含基于 Tool Calling 与 Skill Calling 的测试内容生成链路。
+- 当用户提出测试项分解、测试用例生成或预期成果生成需求时，必须触发 testing-orchestrator。
+
+## 已注册技能
+- identify-requirement-type：将用户需求文本识别为明确的测试需求类型，为后续测试项分解与测试用例生成提供分类依据。
+- decompose-test-items：按需求类型规则生成正常测试与异常测试测试项。
+- generate-test-cases：按测试项生成可执行测试用例，至少 1 条/测试项。
+- testing-orchestrator：按标准顺序编排工具调用并输出结构化结果。
+
+## 强制调用链
+1. identify-requirement-type
+2. decompose-test-items
+3. generate-test-cases
+4. build_expected_results
+5. format_output
+
+## 约束规则
+- 除非用户明确要求只看中间步骤，否则禁止跳步。
+- 每一步都必须显式接收上一步输出作为上下文输入。
+- 若无法识别类型，必须输出未知类型及候选类型，并继续执行通用分解。
+- 最终输出必须严格包含测试项、测试用例、预期成果三段，并按正常测试/异常测试分组。

.github/skills/decompose-test-items/SKILL.md

@@ -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 无法确定时，仍需输出正常/异常两组测试项。
+- 通用正常项至少包含：主流程正确性、合法边界值、标准输入输出。
+- 通用异常项至少包含：非法输入、越界输入、资源异常或状态冲突。

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

@@ -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和字段级提示文案"。
+
+## 预期结果耦合
+- 每条用例必须可在下一步绑定一条明确、可验证的预期成果。

.github/skills/identify-requirement-type/SKILL.md

@@ -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。

.github/skills/testing-orchestrator/SKILL.md

@@ -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

.github/测试项分解要求.md

@@ -0,0 +1,108 @@
+5.4.5.1功能测试
+功能测试是对软件需求规格说明中的功能需求逐项进行的测试，以验证其功能是否满足要求。功能测试一般需进行：
+1. 每一个软件功能应至少被一个测试用例和一个被认可的异常所覆盖，对大的功能应进一步分解为更细的功能，使测试用例可以直接和功能对应：
+2. 用基本数据类型和数据值测试：
+3. 用一系列合理的数据类型和数据值运行，测试超负荷、饱和及其它“最坏情况”的结果；
+4. 用假想的数据类型和数据值运行，测试排斥不规则输入的能力；
+5. 每个功能的合法边界值和非法边界值都应被作为测试用例；
+6. 应考虑软件功能对操作模式、运行环境、运行状态、状态转换、运行时间等的覆盖要求；
+7. 对于在需求规格说明中没有指明，而在用户使用手册、操作手册中表明出来的每一功能及操作，都应有相应测试用例覆盖。
+
+5.4.5.2性能测试
+性能测试是对软件需求规格说明中的性能需求逐项进行的测试，以验证其性能是否满足要求。性能测试一般需进行：
+1. 测试程序在获得定量结果时程序计算的精确性(处理精度. ;
+2. 测试程序在有速度要求时完成功能的时间(响应时间. ;
+3. 测试程序完成功能所能处理的数据量；
+4. 测试程序各部分的协调性，如高速、低速操作的协调：
+5. 测试软/硬件中因素是否限制了程序的性能；
+6. 测试程序的负载潜力；
+7. 测试程序运行占用的空间。
+
+5.4.5.3外部接口测试
+外部接口测试是对软件需求规格说明中的外部接口需求逐项进行的测试。外部接口测试一般需进行：
+1. 测试所有外部接口，检查接口信息的格式及内容；
+2. 对每一个外部的输入/输出接口做正常和异常情况的测试。
+
+5.4.5.4人机交互界面测试
+人机交互界面测试是对所有人机交互界面提供的操作和显示界面进行的测试，以检验是否满足用户的要求。人机交互界面测试一般需进行：
+1. 测试操作和显示界面及界面风格与软件需求规格说明中要求的一致性和符合性：
+2. 以非常规操作、误操作、快速操作来检验界面的健壮性；
+3. 测试对错误命令或非法数据输入的检测能力与提示情况；
+4. 测试对错误操作流程的检测与提示：
+5. 如果有用户手册或操作手册，应对照手册逐条进行操作和观察。
+
+5.4.5.5强度测试
+强度测试是强制软件运行在不正常到发生故障的情况下(设计的极限状态到超出极限. ,检验软件可以运行到何种程度的测试。强度测试一般需进行：
+1. 性能的强度测试；
+2. 降级能力的强度测试；
+3. 系统健壮性测试；
+4. 系统饱和测试。
+强度测试在某种程度上可看作性能测试的延伸，测出软件功能、性能的实际极限。其详细要求可参见附录B“强度测试”。
+
+5.4.5.6余量测试
+余量测试是对软件是否达到需求规格说明中要求的余量的测试。若无明确要求时，一般至少留有20%的余量。根据测试要求，余量测试一般需提供：
+1. 全部存储量的余量；
+2. 输入、输出及通道的余量；
+3. 功能处理时间的余量。
+
+5.4.5.7可靠性测试
+可靠性测试是在真实的和仿真的环境中，为做出软件可靠性估计而对软件进行的功能测试(其输入覆盖和环境覆盖一般大于普通的功能测试. ,可靠性测试中必须按照运行剖面和使用的概率分布随机地选择测试用例。可靠性测试一般需：
+1. 测试环境应与典型使用环境的统计特性相一致，必要时使用测试平台；
+2. 定义软件失效等级；
+3. 建立软件运行剖面/操作剖面；
+4. 测试记录更为详细、准确，应记录失效现象和时间；
+5. 必须保证输入覆盖，应覆盖重要的输入变量值、各种使用功能、相关输入变量可能组合以及不合法输入域等；
+6. 对于可能导致软件运行方式改变的一些边界条件和环境条件，必须进行针对性测试。
+有关可靠性测试的详细要求参见附录C“可靠性测试”。
+
+5.4.5.8安全性测试
+A、B、C级软件需要进行安全性测试。安全性测试是检验软件中已存在的安全性、安
+全保密性措施是否有效的测试。安全性测试一般：
+1. 应进行软件安全性分析，并且在软件需求中明确每一个危险状态及导致危险的可能原因，在测试中全面检验软件在这些危险状态下的反应；
+2. 对安全性关键的软件部件，应单独测试，以确认该软件部件满足安全性需求：
+3. 对软件设计中用于提高安全性的结构、算法、容错、冗余、中断处理等方案应进行针对性测试；
+4. 测试应尽可能在符合实际使用的条件下进行；
+5. 除在正常条件下测试外，应在异常条件下测试软件，以表明不会因可能的单个或多个输入错误而导致不安全状态；
+6. 应包含硬件及软件输入故障模式测试：
+7. 应包含边界、界外及边界接合部的测试；
+8. 应包括“0”、穿越“0”以及从两个方向趋近于“0”的输入值；
+9. 应包含在最坏情况配置下的最小和最大输入数据率，以确定系统的固有能力及对这些环境的反应；
+10. 操作员接口测试应包括在安全性关键操作中的操作员错误，以验证安全系统对这些错误的响应；
+11. 应测试双工切换、多机替换的正确性和连续性；
+12. 应测试防止非法进入系统并保护系统数据完整性的能力。
+
+5.4.5.9恢复性测试
+恢复性测试是对有恢复或重置(reset. 功能的软件的每一类导致恢复或重置的情况，逐一进行的测试，以验证其恢复或重置功能。恢复性测试是要证实在克服硬件故障后，系统能否正常地继续进行工作，且不对系统造成任何损害。恢复性测试一般需进行：
+1. 探测错误功能的测试；
+2. 能否切换或自动启动备用硬件的测试；
+3. 在故障发生时能否保护正在运行的作业和系统状态的测试；
+4. 在系统恢复后，能否从最后记录下来的无错误状态开始继续执行作业的测试。
+
+5.4.5.10边界测试
+边界测试是对软件处在边界或端点情况下运行状态的测试。边界测试一般需进行：
+1. 软件的输入域或输出域的边界或端点的测试；
+2. 状态转换的边界或端点的测试；
+3. 功能界限的边界或端点的测试；
+4. 性能界限的边界或端点的测试；
+5. 容量界限的边界或端点的测试。
+
+5.4.5.11安装性测试
+安装性测试是对安装过程是否符合安装规程的测试，以发现安装过程中的错误。安装性测试一般需进行：
+1. 不同配置下的安装和卸载测试；
+2. 安装规程的正确性的测试。
+
+5.4.5.12互操作性测试
+互操作性测试是为验证不同软件之间的互操作能力而进行的测试。互操作性测试一般：
+1. 必须同时运行两个或多个不同的软件；
+2. 软件之间发生互操作。
+
+5.4.5.13敏感性测试
+敏感性测试是为发现在有效输入类中可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。敏感性测试一般需进行：
+1. 发现有效输入类中可能引起某种不稳定性的数据组合的测试；
+2. 发现有效输入类中可能引起某种不正常处理的数据组合的测试。
+
+5.4.5.14测试充分性要求
+1. 对软件需求规格说明中明确和隐含的需求(包括功能、性能、接口、质量要求等. 的覆盖率应达到100%;
+2. 配置项测试应使用与软件开发相同的编译器，全面覆盖软件需求说明文档中的所有要求。
+3. 对于A、B级嵌入式软件，对配置项源程序测试的语句、分支覆盖率均应达到100%。对用高级语言编制的A、B级嵌入式软件，应对配置项目标码进行结构分析和测试，测试的目标码语句、分支覆盖率均应达到100%。对覆盖率达不到要求的软件，应对未覆盖的部分逐一进行分析和确认，并提供分析报告。
+