QA如何用Obsidian和Claude管测试

交付速度一快，测试人员最先感到的不是忙，而是不确定：我是不是漏了什么，覆盖的场景是不是真的够。这种焦虑靠加班解决不了，得靠一套能查、能复用、能自动补全上下文的记录方式。有人把笔记工具换成 Obsidian，再把 Claude 接进来，日常测试工作就不再完全依赖记忆。

Obsidian 本身是一个本地笔记和知识管理工具，文件以 Markdown 格式存在电脑上。想要云端同步可以用付费版本，或者装社区插件。它吸引人的地方不是功能多，而是干扰少。之前用 Notion 时，页面外观能调的东西太多，容易把时间花在改模板样式上，真正写进去的内容反而少了。换成 Obsidian 之后，界面干净，注意力更容易留在笔记本身。

另一个现实考虑是数据安全。测试工作常接触内部系统、接口说明和业务规则，笔记存在本地会让人更放心。Obsidian 也支持装外部插件来补功能，但不会把主界面塞满。更重要的是，Markdown 文本和 AI 工具配合起来很顺，AI 生成的内容直接就是笔记格式，不用来回转换。

把 Obsidian 当第二大脑来用，第一步不是装插件，而是先固定几类经常写的文档。测试人员至少有三类模板值得提前建好。

一类是技术任务模板。数据库迁移、消费者创建、接口开发这类工作，测试计划的结构往往相似，每次新建笔记时直接套用，能省掉重复搭框架的时间。另一类是业务任务模板，用在更早的阶段，比如和产品负责人一起做产品发现时，用来梳理新功能可以加哪些测试层、有哪些风险、怎么缓解、上线后怎么衡量是否成功。还有一类是会议笔记模板，记录会议关键信息和待办，也可以用来准备自己要主持的会议。

模板解决的是格式统一，技能解决的是重复动作。Claude 的技能可以理解成一段预设好的指令，调用时按固定流程执行，减少每次重新描述需求的时间。

第一个技能用来生成测试计划。给它一个 Jira 任务编号，它会先去取这个任务的上下文，再到 Confluence 里找相关参考内容，然后按事先建好的模板输出一份 Markdown 测试计划。整个过程不用手动复制粘贴。第二个技能用来找漏掉计划的任务。它通过 Atlassian 的 MCP 连接，筛选出带特定标记、需要写测试计划但还没写的任务，把结果写进一个 Markdown 文件，再用看板插件展示，方便安排优先级。第三个技能负责发布测试用例，把已经规划好的用例推到 Zephyr 里，这是日常管理测试的工具。

插件方面，看板插件一直在用，用来跟踪任务状态。后来发现两个需求在社区商店里找不到现成的，就自己写了。一个插件的作用是在 Obsidian 里打开当前库所在目录的终端，这样不用切窗口就能运行 Claude Code。另一个插件用来列出所有可用的技能，并且直接在 Obsidian 里执行。两个插件都还不算最终版本，也没上架社区商店，但仓库里写了本地使用的步骤。

把模板、技能和插件串起来之后，一个典型流程是这样的。假设拿到一个任务编号，它来自产品侧的产品发现或史诗。先调用技能，技能根据编号去 Jira 拉取任务背景，再到 Confluence 找参考资料，结合业务任务模板生成一份初步的测试计划草稿。草稿进入 Obsidian 后，用看板插件标记状态，提醒自己下一步要做什么。如果任务属于技术类型，流程类似，只是换成技术任务模板，关注的测试层和风险点不同。最后，确认好的用例通过发布技能推到 Zephyr。

这套做法并没有让测试工作变成全自动。AI 生成的内容仍然需要人工检查，尤其是测试场景是否覆盖完整、数据准备是否合理。比较有效的做法是收集团队对生成测试的反馈，看看哪里描述不清、哪里漏了场景，再回头改模板。模板本身也不是一次定型的，用得多了会发现某些上下文需要补充，某些段落其实没必要保留，就随时调整。

对测试人员来说，值得先做的不是研究所有插件，而是选一个自己最常写的文档类型，建一个模板，把重复的结构固定下来。等模板用顺了，再考虑用技能把取上下文、找任务、发用例这些动作串进去。工具只是载体，真正减少遗漏的是把上下文留在可查的地方，让每次测试都有迹可循。