DeepSeek Harness火了，但你知道怎么用它生成测试用例吗？

一行命令装好，它10分钟帮我生成了50多条用例——然后我花了半小时改其中8条

大家好，我是某互联网公司的测试架构师。

上周，团队里一个做了3年功能测试的同事找我聊天，说了一句让我印象很深的话：“我在GitHub上看到DeepSeek Harness 12小时拿了5万星，但点进去看了半天，还是不知道这玩意儿到底能不能帮我写用例。”

我说：“你不是有库存管理API的接口文档吗？打开终端，我给你演示一下。”

20分钟后，他面前跑着一份覆盖等价类、边界值、异常场景的完整用例集。

他盯着屏幕看了一会儿，说：“就这？”

对，就这。

一、先搞清楚：Harness和模型到底是什么关系？

很多人第一次看DeepSeek Harness的文档，会被“Agent运行框架”“一切皆插件”这些词绕晕。

DeepSeek官方给了一个非常干脆的等式：Agent = Model + Harness。模型是“大脑”，负责推理和生成。Harness是“手脚和神经系统”——工具调用、任务规划、执行调度、沙箱、存储、循环，所有让模型“能干活”的工程活儿，全包了。

用一句话说清楚Harness在测试场景里的角色：它让AI不再只是“回答你的问题”，而是“自己读文档、自己提取规则、自己生成用例”。

这里要先破一个误解。很多人以为Harness是“又一个AI编程工具”。不完全是。官方定位是开发者底层工具——给你一套能自己搭Agent技术栈的底座，而不是一个开箱即用的终端助手。

但也正因如此，它在测试用例生成这个场景里，比很多成品工具都灵活。

二、安装：一行命令，2分钟

前置条件只有一个：Node.js 22或更新版本。

检查一下：

node --version

看到v22.x.x或更高就行。没有的话去官网装一下。

然后一行命令启动：

npx @deepseek-ai/dsh web

这条命令会自动下载并启动Harness的Web UI，默认在http://127.0.0.1:3080打开。

打开后，在Settings → Models里填入DeepSeek API Key。Harness本身免费开源，模型调用按Token收费。如果你想省钱，新用户通常有赠送额度，跑一轮用例生成的成本不到一块钱。

Windows用户注意：如果终端提示找不到命令，关掉终端重新打开一次。很多时候只是环境变量没刷新。

三、实战：用Harness生成库存管理API的测试用例

下面用一套真实的库存管理API来走完整流程。接口有三个：录入库存、查询库存、出库。

第一步：把文档和代码放进工作区

Harness需要一个工作区才能读到你的项目文件。在Web UI里选择一个目录，然后把接口文档（Word/PDF/Markdown都行）和代码放进这个目录。

我们当时的目录结构是这样的：

inventory-api/
├── docs/
│   └── api-spec.md        # 接口文档
└── app/
    └── inventory.py        # 库存管理代码

关键点：Harness的用例设计能力，很大程度上取决于你喂给它的“素材”质量。 文档写得越清楚，生成结果越准确。

第二步：给Harness下任务

在对话框里输入下面这段话：

阅读 ./docs 下的接口文档和 ./app 下的代码，提取测试需求。输出用例设计要点：包含等价类划分、边界值和异常场景，逐条列出，每条写清楚前置条件、操作步骤和预期结果。

这条提示词不是随便写的。它做了三件事：

限定范围——明确告诉Harness读哪些文件，不读哪些。
定义输出结构——等价类、边界值、异常场景，三类都要覆盖。
约束格式——每条用例必须有前置条件、操作步骤、预期结果。

用实测数据来说，这个环节的提示词效果是这样的：用例设计是Harness全链路里最出彩的一环，评级“强” 。它给的不是“测试正常流程”这种正确的废话，而是具体可执行的用例描述。边界值会主动凑成对——刚好等于阈值、刚过阈值各一条。异常场景也知道往负数、超长字符串、缺字段上想。

第三步：看看它生成了什么

等了一分钟左右，Harness输出了下面这份用例集。我挑几个有代表性的：

正常流程：

边界值（它主动凑成了对）：

异常场景：

一共生成了50多条用例。 从生成到输出，用了不到10分钟。

四、但等等——它生成的东西，真的能用吗？

这正是我那位同事后来花了半小时做的事情。

50多条用例里，有8条需要修正。

三种典型问题：

第一种：它“编”了不存在的接口。 有一条用例调用了一个叫/api/v1/inventory/adjust的接口——我们的文档里根本没有这个接口。AI在缺乏明确信息的时候，会用“合理的猜测”填补空白。

第二种：隐性业务规则它不知道。 我们的库存系统有一条规则——“VIP用户的库存预占不受上限限制”——这条规则只存在于产品经理的脑子里，没写进文档。Harness不知道，生成的用例就缺了这一块。

第三种：返回结构假设错了。 有一条异常用例的预期结果写的是“返回400，error字段为‘库存不足’”，但实际接口返回的是message字段，不是error。

这三种问题的本质是一样的：Harness不会凭空知道“没写进文档的东西” 。它做的是“翻译”——把文档和代码里的规则翻译成用例。翻译的完整性，取决于原文的完整性。

所以正确的用法不是“生成完直接用”，而是 “生成完人工过一遍” 。实测数据也印证了这一点：脚本编写环节，Harness偶尔会臆造接口，“每一条都要人看”。我们的做法是——生成完先跑一遍，红的先人工分类——是代码错还是用例错——再决定改哪边。

五、进阶：用现成的Skill一键生成用例

上面的流程需要你手写提示词。如果你想要更“傻瓜式”的体验，可以直接装一个社区已经封装好的Skill。

GitHub上有个开发者发布了function-testing插件，专门做功能测试用例生成。它的能力是：根据PRD、Git提交记录或用户故事生成功能测试用例，输出Excel风格的测试报告。

安装只有一条命令：

dsh plugin --profile web add "github:addxing/function-testing#main"

装好之后，你不需要再手写那段提示词了。直接在对话框里输入：

用 function-testing 为库存管理API生成功能测试用例，输出Excel风格报告。

Harness会自动加载这个Skill的规则，按标准流程生成用例。

Skill的本质是把“方法论”封装起来。 你今天花10分钟装一个Skill，以后每个项目都能用同一套标准流程生成用例——格式一致、覆盖标准一致、输出结构一致。不会因为今天心情好就多写几条、明天赶时间就少写几条。

六、避坑指南

坑一：文档质量决定用例质量

Harness的用例设计能力很强，但它强在“翻译”，不强在“补充”。文档里没写的规则，它不会凭空知道。

解法： 把隐性规则写进文档。哪怕只是一句“VIP用户不受库存上限限制”，写进去，Harness就能覆盖到。

坑二：把它当“全自动”用

Harness能替你完成80%的基础工作，但剩下20%需要你的业务判断。它偶尔会“编”接口，偶尔会假设错返回结构。

解法： 生成完必须人工过一遍。审核50条用例，比从零写50条用例，省下来的时间不是一星半点。

坑三：一次跑太多任务

实测发现，Harness在执行调度这个环节是短板——“任务一长就容易卡壳打转，响应慢还费钱”。

解法： 把大任务拆成小段下发。先让它生成用例，再让它写脚本，最后让它跑测试。不要一口气全丢给它。

坑四：忽略它的“开发者预览版”身份

官方明确说当前是developer preview，会有破坏性变更。不要把它直接用在生产环境的测试流程里。

解法： 先在本地或测试环境跑通流程，验证效果后再考虑接入正式流程。

七、实测数据：Harness到底能替测试开发干多少活？

最后说一组实测数据。

有团队把测试开发日常工作拆成五个环节，逐项交给Harness做，然后打分：

用例设计是Harness表现最强的环节。 这也是为什么我建议测试人从“用Harness生成用例”这个场景切入——它在这个环节的性价比最高，上手门槛最低。

扣掉评审时间，AI大概能替代一半到三分之二的重复劳动。它替的是重复劳动，不是判断力。

最后

传统写用例的路径是这样的： 啃PRD（半天）→ 画脑图（半天）→ 写用例（1-2天）→ 人工评审（半天）→ 修改（半天）——总计3-4天。

Harness的路径是这样的： 装环境（2分钟）→ 放文档（2分钟）→ 输入提示词（1分钟）→ 生成用例（10分钟）→ 人工审核补充（30分钟）——总计45分钟。

这中间差的不只是时间，差的是“敢不敢开始”的门槛。

Harness从来不是让测试工程师失业的工具。它是让测试工程师从“手写用例”的重复劳动中解放出来的加速器。

下次你拿到一份接口文档的时候，别打开Excel了。打开终端，输入那条命令：

npx @deepseek-ai/dsh web

10分钟后，你会看到结果。