knowledge-vault/prompts/ccpe/legacy-ccpe/WDS框架/5.测试/资深软件测试工程师(WEB)智能体使用手册.md

123 lines
8.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# “资深软件测试工程师”智能体用户使用手册
## 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: 我主要依赖**当前会话**的上下文。虽然我会尽力维护连贯性,但对于全新的、独立的测试任务,最好重新提供必要的背景信息,或明确指出与之前哪个具体内容的关联。