ln-521-test-researcher

路径： 文件路径（references/、../ln-*）相对于此技能目录。

输入

输入	必填	来源	描述
storyId	是	args、git branch、kanban、user	要处理的 Story

解析： Story Resolution Chain。 状态筛选： To Review

测试研究员

类型： L3 Worker

在制定测试计划前，研究真实世界中的问题和边缘情况，确保测试覆盖用户实际遇到的痛点，而不只是 AC。

目的与范围

• 使用 Web Search、MCP Ref、Context7 研究该功能领域的常见问题。
• 分析竞争对手如何解决同一问题。
• 从论坛、StackOverflow、Reddit 中查找客户投诉和痛点。
• 将结构化发现作为跟踪器评论（addComment）发布，供后续测试规划步骤使用。
• 不创建测试，也不更改状态。

何时使用

在以下情况下应使用此技能：

• 在测试规划工作流开始时，如果需要该功能领域的证据
• Story 包含非简单功能（外部 API、文件格式、身份验证）
• 需要发现 AC 之外的边缘情况

跳过研究的情况：

• Story 很简单（简单的 CRUD，没有外部依赖）
• Story 上已有研究评论
• 用户明确要求跳过

工作流

阶段 1：发现

必须阅读： 加载 references/input_resolution_pattern.md

1. 解析 storyId： 按指南运行 Story Resolution Chain（状态筛选：[To Review]）。

2. 从 docs/tasks/kanban_board.md 自动发现 Team ID

阶段 2：提取功能领域

1. 通过配置的跟踪器提供方获取 Story（getStory）
2. 解析 Story 目标和 AC，以确定：
   • 涉及什么技术/API/格式？
   • 用户的目标是什么？（例如，“翻译 XLIFF 文件”、“通过 OAuth 进行身份验证”）
3. 提取用于研究查询的关键词

阶段 3：研究常见问题

使用可用工具查找真实世界中的问题：

1. Web Search：

   • “[feature] 常见问题”
   • “[format] 边缘情况”
   • “[API] 注意事项”
   • “[technology] 已知问题”

2. MCP Ref：

   • ref_search_documentation("[feature] error handling best practices")
   • ref_search_documentation("[format] validation rules")

3. Context7：

   • 查询相关库文档，查找已知问题
   • 查看 API 文档中的限制

阶段 4：研究竞争对手的解决方案

1. Web Search：

   • “[competitor] [feature] 工作原理”
   • “[feature] 对比”
   • “[product type] 最佳实践”

2. 分析：

   • 市场领先者如何处理此功能？
   • 他们采用了哪些 UX 模式？
   • 常见的错误处理方式有哪些？

阶段 5：研究客户投诉

1. Web Search：

   • “[feature] 投诉”
   • “[product type] 用户问题”
   • “[format] issues reddit”
   • “[format] issues stackoverflow”

2. 分析：

   • 用户实际遇到了哪些困难？
   • 常见的挫折有哪些？
   • 用户预期与典型实现之间存在哪些差距？

阶段 6：整理并发布发现

1. 将发现整理为以下类别：

   • 输入验证问题（格式错误的数据、编码、大小限制）
   • 边缘情况（空输入、特殊字符、Unicode）
   • 错误处理（超时、速率限制、部分失败）
   • 安全问题（注入、身份验证绕过）
   • 竞争对手优势（我们应匹配或超越的功能）
   • 客户痛点（用户实际投诉的问题）

2. 在 Story 上发布跟踪器评论（addComment），附上研究摘要：

## Test Research: {Feature}

### Sources Consulted
- [Source 1](url)
- [Source 2](url)

### Common Problems Found
1. **Problem 1:** Description + test case suggestion
2. **Problem 2:** Description + test case suggestion

### Competitor Analysis
- **Competitor A:** How they handle this + what we can learn
- **Competitor B:** Their approach + gaps we can exploit

### Customer Pain Points
- **Complaint 1:** What users struggle with + test to prevent
- **Complaint 2:** Common frustration + how to verify we solve it

### Recommended Test Coverage
- [ ] Test case for problem 1
- [ ] Test case for competitor parity
- [ ] Test case for customer pain point

---
_This research informs both manual tests (ln-522) and automated tests (ln-523)._

关键规则

• 不创建测试： 仅进行研究和文档记录。
• 不更改状态： 仅发布跟踪器评论。
• 注明来源： 始终包含所查阅来源的 URL。
• 提供可执行的发现： 每个问题都应建议一个测试用例。
• 跳过简单的 Story： 不要研究“向页面添加按钮”。

运行时摘要产物

必须阅读： 加载 references/test_planning_summary_contract.md、references/test_planning_worker_runtime_contract.md

运行时配置：

• 系列：test-planning-worker
• 工作器：ln-521
• 摘要类型：test-planning-worker
• 协调器使用的负载字段：worker、status、warnings、research_comment_path

调用规则：

• 独立运行：省略 runId 和 summaryArtifactPath
• 托管运行：同时传入 runId 和准确的 summaryArtifactPath
• 始终在终止结果前写入经过验证的摘要

完成定义

• 从 Story 中提取功能领域（确定技术/API/格式）
• 调研常见问题（使用 Web Search + MCP Ref + Context7）
• 分析竞品解决方案（至少 1-2 个竞品）
• 找到客户投诉（论坛、StackOverflow、Reddit）
• 将发现整理成类别
• 发布带有“## Test Research: {Feature}”标题的跟踪器评论
• 至少提出 3 个推荐测试用例

输出： 包含调研发现的跟踪器评论，供 ln-522 和 ln-523 使用。

参考文件

• 调研方法：Web Search、MCP Ref、Context7 工具
• 评论格式：包含来源的结构化 Markdown
• 下游使用方：ln-522-manual-tester、ln-523-auto-test-planner
• 必须阅读： 加载 references/research_tool_fallback.md

---

版本： 1.0.0 最后更新： 2026-01-15