# “资深软件测试工程师”智能体用户使用手册

## Profile

* **author**: Wantsong
* **version**: V1.0
* **date**: 2025-05-30

欢迎使用“资深软件测试工程师”智能体！本智能体旨在协助您高效地完成软件测试相关的核心任务，特别是测试用例的设计与评估。为了充分发挥其潜力，请仔细阅读以下使用指南。

## 1. 智能体概述

* **我是谁？** 一位拥有多年Web应用（尤其管理类软件）测试经验，并具备能源行业业务背景的资深软件测试工程师。
* **我的目标？** 以提升软件质量、保障系统稳定为首要目标，辅助您进行全面、准确、高效的测试工作。
* **我能做什么？**
  * 辅助生成**功能测试用例**。
  * 辅助生成**接口测试用例**。
  * 辅助生成**UI测试点/测试用例**。
  * **检查现有测试用例的完整性** (对照需求/设计文档)。
* **我如何工作？** 我严格依赖您在**当前会话中提供的信息和文档**进行分析和设计。我不会凭空臆断或使用超出您提供范围的知识（通用测试方法论除外）。

## 2. 核心交互原则与最佳实践

与我高效协作的关键在于提供清晰、结构化的输入：

1. **明确您的任务意图：**
    * 在对话开始时，请清晰说明您希望我做什么。例如：
        * “请基于[文档A]为[功能X]生成功能测试用例。”
        * “这是[API文档B]，请帮我设计接口测试用例。”
        * “请根据这份[UI设计稿C]和相关需求，列出主要的UI测试点。”
        * “我有这份[用例文档D]和对应的[需求文档E]，请帮我检查用例是否完整覆盖了需求。”
    * 如果您的意图不明确，我会主动提问以澄清。

2. **提供结构化和相关的输入材料：**
    * **质量胜于数量：** 我依赖您提供的具体信息。确保文档与当前任务紧密相关。
    * **分门别类：** 如果可能，将不同类型的信息分开提供或清晰标注。
    * **一次聚焦一个核心任务/模块：** 对于复杂的系统，建议将测试任务拆分为更小的、可管理的单元（例如，按功能模块、主要用户故事或API集合）。每个单元可以作为一个独立的会话任务。
    * **上下文的重要性：** 我主要基于当前会话的上下文工作。若新任务与之前讨论的内容紧密相关，请明确指出。

3. **理解我的提问：**
    * 当我提问时（例如，关于需求细节、文档中的矛盾点），这通常意味着我需要更多信息才能准确完成任务。您的清晰回答对我至关重要。

4. **提供具体有效的反馈：**
    * 如果对我生成的测试用例或分析结果不完全满意，请提供具体的反馈。例如：
        * “这个用例的步骤3不够清晰，能否详细描述一下？”
        * “预期结果中似乎遗漏了对[某某状态]的校验。”
        * “我认为还需要考虑[某种异常场景]，请补充相关用例。”
    * 我会根据您的反馈进行修改和优化。

## 3. 如何准备输入材料

我能处理多种类型的输入信息。以下是建议的准备方式：

* **通用基础材料 (通常在任务开始时提供):**
  * **系统/模块/功能概述：** 简要描述被测对象的基本功能、目标用户、核心业务流程。这将帮助我理解上下文。
  * **相关的数据库设计 (如适用):**
    * 提供与当前测试任务**直接相关**的SQL建表语句。
    * 如果业务逻辑依赖特定的初始数据状态，请提供相关的SQL初始化脚本。
    * (对于大型数据库，请您摘录与当前任务最相关的部分。)

* **针对功能测试用例生成：**
  * **核心输入：** 需求规格说明书、用户故事（含验收标准）、业务流程图、详细的功能描述文档。
  * **关键信息点：** 明确的业务规则、输入项及其校验规则、输出项及其格式、不同用户角色的权限差异、状态转换图（如果复杂）。

* **针对接口测试用例生成：**
  * **核心输入：** 详细的API设计文档（如Swagger/OpenAPI规范文档，或包含清晰定义的自定义文档）。
  * **关键信息点：**
    * API端点URL、HTTP请求方法 (GET, POST, PUT, DELETE等)。
    * 请求头参数（如Content-Type, Authorization）。
    * 请求体参数（JSON/XML结构，各字段名称、数据类型、是否必填、校验规则、示例值）。
    * 响应体结构（JSON/XML结构，各字段含义）。
    * 所有预期的HTTP状态码及其含义（200, 201, 400, 401, 403, 404, 500等）。
    * 认证和授权机制。

* **针对UI测试点/用例生成：**
  * **核心输入：** UI设计稿（截图、线框图、原型链接）、相关的交互说明文档。
  * **关键信息点：**
    * **单个界面聚焦：** 建议一次交互主要围绕一个或一组紧密相关的UI界面进行。
    * **元素描述：** 清晰指出界面上的主要元素（按钮、输入框、下拉菜单、链接、文本、图片等）。
    * **交互逻辑：** 描述用户与这些元素交互时系统的预期行为（例如，“点击‘提交’按钮后，若表单校验通过，则跳转到A页面，否则提示错误信息X”）。
    * **视觉要求：** （可选）如果对布局、颜色、字体等有特殊要求，请说明。
    * **数据展示：** 界面上动态数据的来源和显示规则。

* **针对测试用例完整性检查：**
  * **核心输入1：** 您现有的测试用例文档（请确保其结构清晰，至少包含用例标题/目的）。
  * **核心输入2：** 与这些用例对应的原始需求文档、API设计文档或UI设计稿。
  * **您的目标：** 明确您希望我重点检查哪些方面（例如，是否覆盖所有需求点？是否包含必要的异常场景？）。

## 4. 理解我的输出

* **输出格式：** 我将主要以 **Markdown 表格** 的形式输出测试用例。
* **测试用例字段：**
  * `用例ID`: 我会留空，由您根据您的管理规范填写。
  * `模块名称`: 基于您提供的概述或指定。
  * `标题`: 简明扼要地概括用例的测试目的。
  * `优先级`: 如果您未指定，我会根据预设规则初步设定（高/中/低），并将其视为建议。
  * `前置条件`: 执行测试前系统必须满足的状态。
  * `操作步骤`: 清晰、可执行的测试步骤。
  * `预期结果`: 明确、可验证的期望系统行为或状态。
  * `备注`: 相关的额外说明。
* **内部检查：** 我在生成输出前，会根据一系列内部检查项（如需求覆盖、描述清晰性、正反例包含等）进行初步自查。
* **建议性内容：** 如果我提供了超越纯测试用例的建议（例如，关于开发或产品设计的建议），这些内容会明确标注为“建议”，供您参考。

## 5. 与我高效协作的技巧

* **从小处着手，逐步迭代：** 对于复杂功能，可以先让我针对核心路径生成用例，然后根据您的反馈，逐步补充边界、异常等场景。
* **利用我的专业知识：** 我了解多种测试方法论（场景法、边界值、等价类等）并具备能源行业背景。您可以在提问或要求时，引导我应用这些知识（例如，“请针对这个输入框，使用边界值分析方法设计测试数据点”）。
* **明确指定“模块名称”：** 在开始一个新模块的测试用例设计时，请告诉我模块的准确名称，这有助于我更好地组织输出。
* **耐心与清晰：** 我是一个AI，尽管努力做到最好，但有时可能需要您更具体或换种方式表达您的需求。

## 6. 常见问题 (FAQ)

* **Q: 我给的指令很简单，为什么你要求我补充信息？**
  * A: 为了生成高质量、有针对性的测试用例，我需要足够具体的上下文和细节。我的提问是为了确保我准确理解您的需求和被测对象的特性。
* **Q: 你生成的用例不完全符合我的要求，怎么办？**
  * A: 请提供具体的反馈！告诉我哪些地方需要修改、补充或删除，我会尽力根据您的指示进行调整。
* **Q: 我有一个非常大的系统需要测试，能一次性都交给你吗？**
  * A: 为了保证质量和效率，我强烈建议您将大型任务拆分为若干个较小的、聚焦于特定模块或功能的子任务，然后我们逐个处理。
* **Q: 你能帮我执行测试吗？**
  * A: 我目前的核心能力是辅助您**设计和分析**测试用例/测试点，以及检查用例的完整性。我不能实际执行测试操作。
* **Q: 你会记住我上次会话说的所有内容吗？**
  * A: 我主要依赖**当前会话**的上下文。虽然我会尽力维护连贯性，但对于全新的、独立的测试任务，最好重新提供必要的背景信息，或明确指出与之前哪个具体内容的关联。