乐于分享
好东西不私藏

软件测试 – AI写代码后先查意图

软件测试 – AI写代码后先查意图

AI 写代码以后,很多团队的第一反应是让 CI 跑一遍。能编译,单测过,页面看起来也没坏,就准备合并。这个节奏很危险。因为 AI 最常见的问题不是不会写代码,而是把需求意图写偏了。

比如需求说“新用户首单免运费,不可与企业折扣叠加”。AI 很可能写出一个看似合理的判断:新用户就免运费。单测如果只覆盖新用户,当然绿。但真正的风险在叠加规则。

AI 生成代码后,测试人先查三件事:业务前提有没有漏、互斥规则有没有错、异常路径有没有被简化。

01别先看代码风格,先看业务前提

很多 AI PR 写得很整齐,变量名也漂亮。但业务前提可能被吃掉。测试人 review 时,不要只问“这段能不能跑”,要问“它默认了什么”。默认用户都已登录?默认库存不会变?默认工具调用一定成功?这些默认,正是线上事故的起点。

02互斥规则是 AI 最容易写漏的地方

AI 很擅长补正向流程,不擅长理解业务里的互斥和例外。优惠不可叠加、审批不能自审、退款后不能再发货、冻结账户不能提现,这些规则不一定出现在同一个段落里,却必须在测试里合到一起。

旧做法
风险侦探做法
只跑生成的单测
补一组互斥规则测试
只看 happy path
加测冲突、重复、撤销、过期
相信 AI 摘要
回到原始需求和历史缺陷核对

03把意图审查写成模板

意图审查伪代码

def review_ai_change(change):

    assert change.has_business_preconditions()

    assert change.covers_exclusion_rules()

    assert change.has_rollback_or_error_path()

    return ‘ready for regression’

我不反对 AI 写代码。相反,我觉得它会成为常态。但测试人要把精力从“有没有代码”转到“代码有没有守住业务意图”。这件事做不好,后面自动化越完整,越会把错误意图保护起来。

AI 写得快不是风险,写偏了还一路跑绿才是风险。

下一篇继续讲 Agent:当系统会自己规划动作,测试就不能只靠路径覆盖了。