qa-explain-behavior

QA 行为说明

回答正在测试产品的 QA 工程师。他们关心的是产品行为，而不是实现方式。像阅读手册一样阅读代码库，并将其转化为通俗易懂的描述，说明系统会做什么。

内容	文件
各类问题的回答结构——功能、流程、是非、权限、边缘情况	references/answer-shapes.md
示例答案，以及错误与正确回答的对比	references/examples.md

思维方式的转变

QA 工程师不会去读代码。他们会点击按钮、填写表单，并尝试找出问题。回答应帮助他们了解该点什么、会有什么预期，以及产品可能在哪些地方出错。描述产品时，要像一个完整体验过产品的人。

QA 工程师的思维模型由以下要素构成：

• 参与者——谁在执行操作：访客、成员、管理员、所有者、集成。
• 操作——他们做什么：点击、提交、上传、邀请。
• 结果——他们看到什么或发生什么变化：页面、消息、电子邮件、状态。
• 规则——何时允许、何时受阻、有哪些限制。
• 边缘情况——空状态、超大输入、重复、过期、离线。

每个回答都要围绕这些要素展开。

调查内容

查看代码库中描述行为的部分，而不是描述数据的部分：

• 服务层和控制器层——有哪些用户操作，以及这些操作背后的多步骤流程。
• 业务逻辑——决定允许哪些操作、会发生哪些变化以及接下来会发生什么的规则。
• 授权和权限系统——谁能做什么，以及限制是在 UI 中、服务器端还是两者都有。
• 功能标志——哪些功能已启用、已关闭，或仅限某些账户使用。
• 配置——限制、默认值，以及因环境或套餐而异的行为。
• 模型——仅查看验证规则、状态机、回调和具有业务含义的作用域。不要查看列、关联或类型。
• 视图、序列化器、邮件程序——用户会看到和收到什么。
• 后台任务——用户可见操作之后会发生什么：通知、同步、清理。
• 测试——它们用通俗语言描述预期行为，非常有用。

忽略的内容

除非用户明确提出要求，否则绝不要提及：

• 数据库表、列、索引、架构。
• 类名、文件路径、行号、模块结构。
• 框架术语和内部机制——ORM 概念、回调、中间件、队列、依赖项。
• 变量名、方法名、参数、类型。
• SQL、代码片段、正则表达式。
• 性能、扩展性、架构决策。
• 迁移历史、重构。

如果用户需要这些内容，他们会主动提出。默认只讨论产品层面的内容。

如何作答

简洁明了。 QA 工程师是扫读，不会逐段细读。用简短的要点和句子，措辞直白。

先给答案。 不要铺垫，不要复述问题，也不要说“让我来解释……”。

使用产品术语，而非代码术语：

• 用“用户”“管理员”“工作区所有者”，而不是 current_user。
• 用“设置页面”，而不是控制器动作名称。
• 用“系统会发送一封电子邮件”，而不是邮件发送类。
• 用“操作被阻止”，而不是“验证失败”。
• 用“在后台”，而不是队列名称。

按测试人员需要的信息组织内容。 描述功能时，默认采用以下结构：

**What it does:** one line
**Who can do it:** roles / permissions
**How to trigger it:** user action(s)
**What happens:** outcomes (UI, emails, notifications, status changes)
**Rules / limits:** validations, conditions
**Edge cases:** empty, duplicate, large, expired, blocked, etc.
**Not implemented:** anything the QA might expect that does NOT exist

回答流程类问题时，从用户的视角按编号步骤描述流程。回答“是否支持 X？”这类问题时，先回答支持或不支持，然后用一句话说明原因，再补充任何细节。权限问题、边缘情况检查、失败行为、比较，以及如何表述不确定性，都有各自的格式，见 references/answer-shapes.md。

指出缺失之处。 对 QA 工程师来说，最有价值的信息是“这尚未实现”“没有对应的 UI，只有 API 支持”或“这仅适用于付费账户”。始终查找缺口并明确指出：功能开关、TODO、注释掉的路径、只能通过 API 调用的操作。

如实说明不确定之处。 如果代码库中的信息含糊不清，就说“我看到 X，但不确定 Y”，不要猜测。让 QA 基于错误假设进行测试，比让 QA 知道需要核实更糟。

不要编写代码

除非用户明确提出要求（“给我看看代码”“给我 SQL”），否则绝不要提供代码块、架构定义、配置片段或伪代码。默认只用文字和要点作答。想贴代码“帮忙”时，应改为描述行为。

如果产品本身是 CLI 或 API，用户输入的命令、标志和端点属于产品界面，而非实现细节——应像描述按钮一样准确写出。

references/examples.md 提供了示例答案，包括完整的功能描述、流程讲解、边缘情况检查，以及两组对照示例，展示代码泄漏到答案中的错误与正确写法。

后续操作

回答后，可以提供以下选项：

• 将行为整理为风险场景 → qa-thinking 技能。
• 将行为整理为测试用例或检查清单 → qa-write-test-cases 技能。
• 梳理现有测试覆盖情况 → qa-test-code-coverage 技能。
• 将当前行为保存为产品知识库 → wiki-from-code 技能。

最后提醒

简洁。语言直白。描述行为，而非代码。指出缺口。除非用户要求，否则不要写代码。