browse-qa

此技能负责 QA 计划和报告，不负责低级别的浏览器命令百科全书。

不可妥协的规则：

1. 测试前，将收到的规格转化为明确的场景。
2. 执行前，确认含糊不清的目标或平台。
3. 使用 browse 技能进行实际的浏览器或模拟器交互。
4. 为每个失败或重要场景收集证据。
5. 仅在流程范围明确且对回归测试有价值时，才保存可重新运行的流程。

browse-qa

输入

• $request：工单、URL、应用目标、验收标准或自然语言 QA 请求

目标

生成可信的 QA 测试结果，以便：

• 将模糊的请求转化为明确的场景
• 针对真实目标执行这些场景
• 收集通过和失败的证据
• 在适当时保存可重新运行的 browse 流程
• 返回用户可据此采取行动的清晰 QA 报告

第 0 步：确定目标和规格

弄清楚：

• 要测试的功能
• 平台：Web、iOS 模拟器、Android 模拟器或 macOS 应用
• 目标 URL、构建产物或应用标识符
• 验收标准或预期结果

如果目标或平台含糊不清，请在测试前询问。

成功标准：明确 QA 目标和验收标准。

第 1 步：列出场景

将请求拆分为：

• 正常流程
• 验证或错误流程
• 边缘情况
• 值得在满足既定验收标准后尝试的探索性探测

除非用户要求进行广泛的 QA 检查，否则计划应精简到能在一次会话中执行完毕。

成功标准：有明确的场景列表和预期结果。

第 2 步：使用 browse 技能执行

使用 Skill 调用 browse 来进行：

• 导航
• 页面稳定性检查
• 交互元素发现
• 点击、填写和提交
• 截图、控制台日志和网络检查

规则：

• 对于一次逻辑连贯的用户旅程，保持使用同一个 browse 会话，除非有意进行隔离
• 只有遇到 CAPTCHA、MFA 或 OAuth 限制等实际阻碍时，才使用有头模式或交接模式
• 将截图和流程产物保存在 browse 会话目录下

成功标准：针对真实目标执行每个场景，并收集足够的证据来判断通过或失败。

第 3 步：记录可复用的回归流程

当场景稳定且值得重新运行时：

• 录制流程
• 将无关的用户旅程拆分为不同的流程文件
• 为每个已保存的流程起一个描述性名称

不要将嘈杂或半手动的录制保存为回归测试产物。

成功标准：保存的流程可独立重新运行，并与明确的场景相对应。

第 4 步：报告结果

对每个场景，记录：

• 预期结果
• 实际结果
• 通过或失败
• 截图路径、控制台错误或网络异常等证据

同时报告：

• 探索性发现
• 创建的回归流程文件
• 阻碍完整验证的问题

成功标准：其他工程师无需先重放整个会话，也能理解 QA 结果。

注意事项

• 不要在此处重复完整的 browse 命令手册；请使用 browse 技能。
• 请求含糊不清时，不要猜测平台。
• 不要仅仅为了声称创建了回归测试资源而保存低价值流程。
• 不要添加 disable-model-invocation；用户提出请求时，QA 应始终可用。
• 不要添加 context: fork；结果通常需要在当前执行流程中使用。

输出约定

报告以下内容：

1. 测试目标
2. 已执行的场景
3. 每个场景的通过／失败结果
4. 收集的证据
5. 创建的回归流程文件
6. 阻碍或未覆盖的部分