从需求分析到发布归档：一个测试项目如何用 dsh-qa 走完全流程
从需求分析到发布归档：一个测试项目如何用 dsh-qa 走完全流程
上一篇介绍了 dsh-qa 如何作为 DeepSeek Harness 里的测试工作台。这篇继续往下走，跟着工作台产生的记录，从第一条需求一直走到发布和归档。
如果想先看产品概览，可以先阅读《质量工作台 dsh-qa：把 AI 测试工作台装进 DeepSeek Harness》。
在开始生命周期 walkthrough 之前，先说清楚底层平台：DeepSeek Harness，简称 dsh，是 DeepSeek AI 开源的插件优先 agent harness。官方项目的核心描述很直接——一切都是插件——所以 dsh-qa 可以增加测试工作台，而不必再造一套独立的智能体系统。
这个平台也在快速变化。截至 2026 年 8 月 20 日，官方 GitHub 仓库页面显示约 16.73 万 stars、1.79 万 forks，说明开发者正在密集试用和扩展它。与此同时，官方仓库把项目标记为 developer preview（开发者预览），并提醒会出现不兼容变更。因此，本文的流程可以实际体验，但集成应当被视为一个持续变化的目标。
最后要看的不是聊天内容本身，而是一条从 DSH 项目会话开始、却不会停在聊天里的工作流：每一步做什么、AI 在哪里帮忙、人在哪里把关，都留在项目记录中。
下面是一个工作流 walkthrough，不代表 dsh-qa 可以自己批准发布。重点是跟着记录走：需求变成可测试范围，用例获得可追踪关系，执行产生证据，缺陷回到回归，报告保留实际完成的事情。
第一步：建项目，本地目录自动生成
在 dsh-qa 里新建一个测试项目，选择「测试项目」或「迭代」形态。
创建时可以自动生成八级本地工作目录：
01_需求与范围 / 02_测试计划 / 03_测试用例 / 04_测试数据与脚本 /
05_测试执行 / 06_缺陷 / 07_测试报告 / 08_发布与归档目录即规范，项目文件从一开始就按阶段归位。
删除项目记录不会删除文件夹——归档还在。
这个分离很实用：项目记录需要清理时，本地文件仍然可以保留。项目记录负责工作台视图，本地目录负责长期文件工作区。插件模式的数据在 ~/.dsh/dsh-qa/，独立运行模式的数据在仓库内的 data/ 目录。
需求分析：AI 先把需求登记上板
把需求文档丢给项目的 DSH 会话，让 AI 拆解。
AI 会把需求登记到工作台，并关联测试用例与验证目的，标记可测范围与潜在风险。
这时候你在看板上就能看到需求卡片，而不是聊完就散在对话记录里。
第一轮评审要问的不是“AI 有没有把文档总结出来”，而是“另一个测试人员能不能看懂范围、缺口，以及每条需求要怎么验证”。所以需求可以关联测试用例和验证目的，这个关系比标题相似更有意义。
用例设计：可执行、可判定、可追踪
让 AI 基于需求生成测试用例，质量原则内置在工作台的「测试模式」（preset id: qa）里：
- 用例必须可执行、可判定
- 覆盖正向、异常、边界场景
- 按需求追踪
trace与风险标签组织
每条用例带优先级与三态，登记后实时上板。
配合 awesome-qa-skills 的 /test-case-writing、/test-case-reviewer 技能，用例产出更稳定。
举个具体例子：需求是用户登录后可以修改邮箱。测试设计不能停在成功路径，还要考虑当前密码校验、格式错误、邮箱已被占用、会话过期、长度边界、确认提示，以及回溯到原始需求的 trace。dsh-qa 保存用例和元数据，QA Skill 帮你组织思路，是否覆盖充分仍然由负责人判断。
用例评审：门禁在这里把关
用例写完不是直接执行。
AI 提交用例评审申请，测试负责人人工审批。评审通过，卡片进入「执行中」；不通过，打回修改。
需求评审、策略评审、报告评审、发布、结项同理——AI 只负责申请与整理，审批权在人。
执行与缺陷回归：实时看板 + 自动化结果
执行中阶段，测试结果可以直接导入：
- Playwright / Pytest 等自动化结果通过
testrun_import工具登记 - 手动测试的结论拖拽卡片换列即可
发现缺陷，AI 按业务影响定严重级别，并记录复现频率与影响范围，区分「观察到的事实」与「原因猜测」——不编造数据，不把猜测写成结论。
缺陷修复后进入「缺陷回归」列，回归通过再进入「已发布」。
缺陷记录会刻意限制 AI 的“诊断冲动”。它记录观察到的行为、业务影响、复现频率、影响范围和状态。原因猜测可以在项目会话中讨论，但不能因为模型写得很肯定，就把猜测升级成事实。
里程碑：自动算截止日，临期有提醒
里程碑登记后自动计算截止日，逾期红标、7 日内临期黄标。
测试首页与日历同步展示，临期/逾期一目了然，不用再翻邮件找排期。
测试报告：版本链沉淀
AI 可以起草测试报告并保存为版本，报告区分：
- 已执行事实
- 未执行范围
- 证据缺口
发布后的报告进入项目档案，和需求、用例、缺陷、里程碑、知识、纪要一起，沉淀成项目自己的知识库。
报告流程还给不确定性留了位置。一份可信的报告应该分开记录已执行事实、未执行范围和证据缺口。如果浏览器矩阵没有跑完，就写进报告；如果缺陷修复了但没有回归证据，发布决策就应该看到这个缺口，而不是从草稿里继承一个绿色状态。
项目档案：九个分区，一个工作区
宽屏项目详情集中了九个分区：
概览 / 需求 / 用例 / 缺陷 / 里程碑 / 报告 / 知识 / 纪要 / 门禁外加进度、AI 策略、成员、文件目录与阶段时间线。
项目进行到哪一步、卡在哪里、谁负责什么，一个工作区看全。
九个分区的价值在于保留测试材料之间的上下文。没有关联需求的报告很难评审，没有里程碑和发布背景的缺陷也很难排优先级。档案视图把这些关系放在阶段时间线旁边，不需要下一个人重新翻聊天记录。
谁在把关，谁在干活
dsh-qa 的分工很明确：
- AI 干活：拆需求、写用例、登记缺陷、算里程碑、起草报告、提交门禁
- 人把关：审批门禁、确认缺陷严重级别、决定发布
这正是“AI 辅助测试”比较务实的落地方式：AI 提升速度，人守住质量。
还有一个边界需要保留。Playwright 或 Pytest 结果可以导入，但导入结果不等于自动获得产品质量结论。结果仍然需要项目上下文、测试范围、执行环境和人工解释。dsh-qa 让证据更容易放回工作流里，但没有替你完成判断。
从今天开始
最快的体验路径：
- 安装插件：
dsh plugin --profile web add github:naodeng/dsh-qa - 安装测试模式：
scripts/install-qa-preset.sh - 重启
dsh web，从侧边栏打开「质量工作台」 - 新建项目，或者直接看启动时自动创建的两个示例
项目地址：https://github.com/naodeng/dsh-qa
如果暂时不想配置 DSH，可以先用独立运行模式打开示例项目和迭代，体验项目、看板和日历。如果要验证完整 AI 闭环，再安装 qa preset 和配套技能，从 DSH 侧边栏进入项目，先跑一条小范围的“需求到用例”流程，再导入更大的自动化结果。先从小切片开始，审批点会更清楚。
项目现状与参与方式
dsh-qa 仍然是一个早期项目。完整流程已经可以跑通，但它还不是一款打磨完毕的软件——有些工作流目前保持简单，后续哪些地方需要做深、做快、做得更容易配置，要靠真实项目的反馈来决定。
欢迎先用小项目试试看。遇到缺陷、让人困惑的行为或想要的功能，可以在仓库的 Issues 里提交，尽量附上复现步骤和证据。也欢迎提交 PR，文档、修复、测试、无障碍和工作流改进都可以从小处开始。小而聚焦的 PR 更容易审阅和合并。