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

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

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: 我主要依赖当前会话的上下文。虽然我会尽力维护连贯性，但对于全新的、独立的测试任务，最好重新提供必要的背景信息，或明确指出与之前哪个具体内容的关联。