让DeepSeek Harness自己写测试、跑测试、找Bug，它能做到哪一步？

光说不练假把式。我们给 DeepSeek Harness 设计了一场三关闯关实验：第一关写测试用例，第二关自己执行测试，第三关最狠——丢给它一段埋了雷的代码，让它找 Bug。一关比一关难，也正好能摸出这个 Agent 的能力边界在哪里。实验环境和此前实测一致：Node.js 环境，npx @deepseek-ai/dsh web 启动，标准模式，当前 developer preview 版本。三关围绕同一个背景展开：一个订单计价函数。

第一关：写用例

靶子函数如下：

def calc_order_price(items):
    """items: [{"name": str, "price": float, "count": int}, ...]
    返回 (总价, 均价)；总额超过 100 打 8 折"""
    total = 0
    for item in items:
        total += item["price"] * item["count"]
    if total > 100:
        total *= 0.8
    return round(total, 2), round(total / len(items), 2)

我们只给了这个函数和一句话："为它编写 pytest 用例，覆盖正常流、边界和异常。"几分钟后 dsh 交卷，挑三条：

def test_normal_order_no_discount():
    items = [{"name": "a", "price": 30.0, "count": 2}]
    total, avg = calc_order_price(items)
    assert total == 60.0        # 60 未超过 100，不打折

def test_over_100_gets_discount():
    items = [{"name": "a", "price": 60.0, "count": 2}]
    total, avg = calc_order_price(items)
    assert total == 96.0        # 120 超过 100，打 8 折

def test_empty_items_raises():
    # 边界：空列表，当前实现会除零
    with pytest.raises(ZeroDivisionError):
        calc_order_price([])

值得说的是后两条：折扣用例的期望值 96.0 算得对，说明它真的按规则推演过，不是抄模板；空列表那条，它不光想到了空输入，还在备注里写明"当前实现对空列表会除零"。边界意识在线。第一关，通过——生成快、方向对。

第二关：跑用例

第二关让 dsh 执行自己写的用例。它确实能执行命令、读回输出：

python -m pytest test_price.py -v

结果：跑起来了，失败摘要也给得像样，哪个用例挂在哪条断言上都能说清。但两个老毛病都犯了：一是响应速度偏慢，一轮分析要等一会儿；二是我追加"修正后重跑"的组合动作时，它打了一次转，重复读同一份日志，需要我人工提醒才继续推进。另外这种多轮任务越长，API 成本放大得越明显，短循环跑、跑完即结，更划算。第二关，勉强通过——会跑会看结果，但节奏得人来带。

第三关：找埋雷代码的 Bug

重头戏来了。我们把函数升级了一下，埋进三个雷（注释是标给读者看的，喂给 dsh 的是去掉注释的原码）：

def calc_order_price(items, discount=0.8):
    """订单总额满 100 打 8 折，返回 (总价, 均价)"""
    total = 0
    for i in range(1, len(items)):              # 雷 1：跳过了第一件商品
        total += items[i]["price"] * items[i]["count"]
    if total > 100:
        total = total * discount                # 雷 2：需求其实规定只对超出 100 的部分打折
    avg = total / len(items)                    # 雷 3：空列表时除零
    return round(total, 2), round(avg, 2)

提示词只有一句："审查这个函数，指出所有缺陷。"dsh 的体检报告：

• 雷 1，抓到了。它指出 range(1, len(items)) 会漏掉第一件商品，还给了修正建议。差一错误是它的强项，静态读码的功夫在线；
• 雷 3，抓到一半。它提到空列表的除零风险，但归在"建议加防御性判断"里，没当成正经缺陷处理；
• 雷 2，没抓到。它认为打折逻辑"写得没毛病"——单看代码，total * discount 确实语法正确、逻辑自洽。问题出在业务规则上：我们手里的需求写的是"只对超出 100 的部分打折"。这条规则不在代码里，dsh 看到的只有代码，自然判它无错。

为了验证，我们把需求原文补进提示词又跑了一次。这回雷 2 被抓到了：它明确指出"全额打折与'仅超出部分打折'的规则不符"，并给出了分段计价的修正思路。同一个函数，差别只在输入里有没有验收标准——这大概是本次实验最有价值的一个观察。

第三关，部分通过：语法和明显逻辑错误抓得住，业务语义错误只有在规则被明确给出时才抓得到。

边界到底在哪

三关跑完，dsh 找 Bug 的边界很清楚：能抓的是"大家都认的错"——语法问题、差一、除零、明显不合理的控制流；抓不到的是"业务规则分歧"——折扣范围算错、状态码语义不对、字段映射错位，这些的正确答案不在代码里，在需求里。

所以实践建议也很实际：想让它找 Bug，就把验收标准跟代码一起给它，规则写得越具体，命中率越高；只给代码，它只能对"代码写得对不对"负责，没法对"代码做得对不对"负责。

本文整理自霍格沃兹测试开发学社的原创分享，更多测试开发与 AI 测试实战内容，我们下一篇见。