前言¶

在 DeepSeek Harness（DSH）里做需求测试，常见卡点往往不是「会不会点页面」，而是流程纪律：空目录要手工搭骨架、子目录开会话时框架根 AGENTS.md 不加载、长需求文档被模型自行拆分或干脆不拆、跨文档关联和版本没人确认、环境与账密每次重问、报告格式失控。社区插件 dsh-test-framework（维护者 liujianqiao701）面向测试工程师，用 cordis 插件把「初始化骨架 + 会话内闸门 + 引导式 onboard」串成一条绕不过去的链。DSH 生态是「一切皆插件」；目录页在 SkillHub，与 DeepSeek / 幻方无官方从属关系。

这是什么¶

dsh-test-framework 是发布在 npm 上的 DSH 工作流类插件：把一个空文件夹一键生成「测试工作框架」目录与规范文件，并在每次 AI 会话里注入框架状态与约束，配合工具与 runtime skill，强制走完「需求文档 → 子模块拆分确认 → 版本与跨文档关联 → 测试环境与账密登记」再开测。

实现上它是 cordis 插件，零第三方依赖（仅 Node 内置模块），无前端构建；适配 DSH（dsh.engines.dsh = "*"），运行环境要求 Node ≥ 20。源码与说明见 GitHub 仓库，许可证 MIT。

核心能力¶

痛点与对应机制¶

七个工具¶

开工前先调 test_framework_status：ready: false 时不应直接开测。

四个 runtime skill 与斜杠命令¶

自动加载的 skill 包括 test-framework（总契约）、test-framework-init、test-framework-onboard（测需求、拆模块、环境与账密引导）、test-framework-module。runtime skill 的 rank 为 250；框架内 <框架根>\skills\<同名>\SKILL.md（rank 100）会覆盖插件同名 skill。

插件还会在组装提示词时注入「测试框架状态」与契约边界（isolation.js）；并提供 /tf-status、/tf-gate（查状态，不消耗模型回轮）。

前置条件：Playwright MCP¶

playwright MCP（mcp__playwright__browser_*）为必需，无替代路径：框架铁律要求真实浏览器与真实点击/输入，缺它相关验证无法执行。插件会在会话开头状态段与 test_framework_status 中提示「未检测到 playwright MCP（必需）」。

配置写在 DSH profile 的 cordis.patch.yml：增加 mcp-playwright（serverName: playwright，命令 @playwright/mcp），且须有头（窗口可见）。改完须重启 DSH（profile 层不支持热加载）。

建议项：keyword_mcp（取证互补）、可选 cr69_mcp（老内核/小视口兼容）。

自查：

npx dsh-test-framework doctor

或在框架工作区内：

node _plugin\dsh-test-framework\lib\cli.js doctor

安装与启用¶

插件以当前 dsh 进程权限运行；安装前请自行查看源码与 MIT 许可证。以下命令来自仓库 README。

从 npm 安装（常用）¶

dsh plugin --profile desktop add dsh-test-framework

安装后重启 DSH（profile 的 bundles 与 cordis.patch.yml 不支持热加载）。验证：会话中是否出现 test_framework_status，或执行：

npx dsh-test-framework doctor --profile desktop

从源码链接安装（改插件时用）¶

cd <插件目录>
node lib\cli.js install --profile desktop
node lib\cli.js install --profile desktop --apply

完成后重启 DSH，并用 node lib\cli.js doctor --profile desktop 自检（依赖与 bundles 两处都须有条目，否则为半装）。

默认安装走目录联接（link:），避免在 profile 上触发整棵 node_modules 的 pnpm install；若要用官方命令并跑 pnpm：

node lib\cli.js install --profile desktop --apply --official

卸载（不动框架工作区文件）：

node lib\cli.js uninstall --profile desktop

可选配置¶

在 profile 的 cordis.patch.yml 中固定需求文档总根：

- id: test-framework
  config:
    reqDocRoot: '<你的需求文档总根目录>'

未配置时按「插件配置 → 环境变量 DSH_REQ_DOC_ROOT → <用户主目录>\需求业务文档」解析。

典型用法：onboard 引导链¶

test-framework-onboard 对应「测这份需求文档 / 新版需求 / 要不要拆 / 环境账密」等意图。README 给出的顺序如下。

1. test_framework_status：先认账，看缺什么；定位需求文档路径（不许猜）。
2. test_framework_doc_probe：页数、章节、菜单、删除线段落等 → 拆分判定；命中判据（如页数 > 100、多个顶级菜单名等）则停下，用 ask_user_question 让用户确认拆分方案。
3. 跨文档关联：问本地还有哪些关联需求文档（无关联须落 relatedDocs: []）。
4. 版本确认：明确本次测哪一版（禁止用文件时间判版本）。
5. 环境与账密：经 test_framework_record 等产品级登记流程落盘。

空目录起步时，可先 test_framework_init，再用 test_framework_module_add 按叶子菜单建模块；跨端关联变更前可用 test_framework_link 做只读体检。

适用场景与注意¶

适合谁：在 DSH 里做业务需求测试、希望 AI 按固定目录与闸门执行、又需要 docx 探针与报告归档纪律的测试工程师或小团队。

务必注意：

• 缺 playwright MCP 不是降级，而是铁律 10 类验证无法做；先 doctor 再开工。
• 插件判断 MCP 依赖读 profile 的 cordis.patch.yml，「未检测到」不等于一定不存在；无法判定时会标明。
• 卸载插件不会删除你已生成的框架工作区；敏感信息仍应只放在框架约定的账密文件中，并遵守本机安全策略。

结尾¶

dsh-test-framework 把「测试工作框架」从手工搭目录，变成可安装、可自检、可在会话里持续施加约束的 DSH 工作流插件：初始化、模块与版本 skill、docx 探针、登记与报告归档工具，以及 onboard skill，共同把需求测试的前置核对做成闸门。

• 目录页：https://www.skillhub.cn/plugins/liujianqiao701/dsh-test-framework
• GitHub：https://github.com/liujianqiao701/dsh-test-framework