三月底的北京，杨絮刚开始飘。我坐在工位上，看着屏幕上刚刚跑完的测试报告，愣了几秒。
不是报告有问题，而是这报告来得太轻松了。
搁往年这个时候，版本迭代高峰期，我应该在干什么？打开Excel，对着需求文档一行行写用例；打开测试环境，一个页面一个页面点点点；打开Jira，一条一条提单。每天下班前看一眼当天的“战绩”：写了多少条用例，点了多少个页面，提了多少个bug。
但这个春天不太一样。我发现自己坐在工位上的时候，手没怎么动，脑子也没怎么累，但该干的活都干完了。
变化是从两周前开始的。那天产品扔过来一个需求文档，二十多页，一个新模块上线，按正常节奏，光测试设计就得两天。我看着文档发呆，突然冒出一个念头：能不能让AI帮我把用例先过一遍？
试了。然后，这个春天就变了。
一、第一周：让AI当我的“测试助理”
最开始的想法很简单——让AI帮我读文档。
我们做功能测试，最烦的就是看需求文档。不是不想看，是文档太长了。二十多页，密密麻麻的文字，有时候翻到后面已经忘了前面。更要命的是，文档里藏着一堆测试点，一不小心就漏了。
那天我试了个笨办法：把需求文档复制出来，分段扔给AI，然后问它：
“根据这段需求，能列出多少测试点？”
第一次试的是一个订单查询功能。文档里写：“用户可根据订单号、商品名称、下单时间范围查询历史订单，支持分页展示，每页默认20条，最多展示100页。”
AI返回的测试点：
正常场景：输入正确订单号，能查到对应订单
订单号为空：点击查询，应提示“请输入订单号或商品名称”
订单号不存在：查询结果为空，页面显示“暂无数据”
商品名称模糊查询：输入商品名称的一部分，应返回相关订单
时间范围：选择开始>结束，应有提示
分页边界：每页20条，第100页有数据，第101页无数据
……
我数了数，二十多个测试点。比我手动列的全，有些边界值我自己都没想到。
那天下午，我干了一件事：把接下来要测的三个功能的需求文档都喂给AI，让每个生成一份“测试点清单”。一下午的时间，平时要花一周的测试设计工作，干完了。
但问题也来了——这些测试点靠谱吗？
二、第一周的翻车：AI有时候会“编”
刚开始用的时候，我太信任AI了。它列的测试点，我基本照单全收，直接转成Excel就开始测试。
结果翻车了。
有个充值功能，AI列了一个测试点：“充值金额为负数时，系统应提示‘金额不能为负数’。”我一看，有道理啊，边界值嘛。跑到测试环境一试，发现根本不存在这个场景——前端输入框限制了只能输入数字，输不了负号。
还有一次，AI给一个权限管理模块列的测试点里，有一条“普通用户尝试访问管理员页面，应跳转403错误页”。但我查了一下权限设计文档，发现普通用户根本看不到管理员页面的入口，不存在“访问”这个行为。
这两次翻车让我明白一个道理：AI不知道你的系统长什么样。它能根据需求文档推测“理论上”的测试点，但不知道你的前端有没有做输入限制，不知道你的菜单权限是怎么配置的，不知道哪些异常场景在真实系统里根本不可能出现。
从那之后我学聪明了：AI列的测试点，我把它当成“初稿”和“提醒”，但最后过一遍脑子，结合自己对系统的了解，删掉那些不存在的，补充那些漏掉的。
这个配合方式，效率最高。
三、第二周：让AI帮我“生成用例”
测试点列完了，下一步是写具体的测试用例。就是那种“步骤1、步骤2、预期结果”的格式。
这活儿我以前最烦。一条条写，翻来覆去就那么几个套路，写多了手都酸。
第二周我开始试：能不能让AI直接把测试点转成测试用例？
比如第一个充值功能的测试点：“输入金额小于1元，应提示‘最低充值1元’”。
我给AI的提示是：
“把这个测试点写成标准测试用例，包括前置条件、测试步骤、预期结果，要写清楚具体怎么操作。”
AI生成的：
用例编号：TC_RECHARGE_002
用例标题：充值金额小于最低限额
前置条件：用户已登录，账户余额100元，充值页面已打开
测试步骤：
- 在充值金额输入框中输入“0.5”
- 点击“确认充值”按钮
预期结果：页面提示“最低充值1元”，充值失败，账户余额不变
比我手写的还规范。
后来我发现一个更好用的功能：批量生成。比如我有十几个测试点，全扔给AI，让它“按同样的格式，把这些都转成用例”。十几秒，十几条用例就出来了。
虽然每条都要看一眼确认，但比自己一条条敲快多了。
四、进阶玩法：让AI处理“复杂业务”
真正让我觉得这春天不一样的，是处理复杂业务的时候。
上周有个业务场景：优惠券叠加规则。规则文档写得跟天书似的，什么“同一订单可使用多张优惠券，但不可与满减活动共享，特殊商品除外，会员等级不同优惠不同……”
我看了两遍，脑子还是糊的。
后来我换了个思路，把规则文档拆成几段，喂给AI，然后问：
“假设你是测试人员，帮我设计这个优惠券叠加规则的测试用例，要覆盖正常场景、边界场景和异常场景。”
AI沉默了十几秒（可能是在思考），然后输出了一组用例，分类很清楚：
正常场景：
用户使用两张互斥券，下单时只能选择一张
用户使用两张可叠加券，下单时两张同时生效，优惠金额相加
边界场景：
订单金额刚好等于优惠券门槛，下单成功
订单金额比优惠券门槛少1分，无法使用该券
异常场景：
优惠券已过期，下单时不可选
优惠券适用范围与订单商品不符，下单时不可选
会员等级不满足优惠券使用条件，不可选
最后还加了一行总结：建议重点测试“互斥规则”和“门槛计算”，这两块最容易出bug。
我拿着这组用例去测，果然，互斥规则那块还真有个bug——两张本该互斥的券，居然能同时用。
那一刻我突然想：AI现在能干到这一步了？连测试策略都能给了？
五、关于“替代”的一点想法
这半个月的尝试，组里有人看在眼里。昨天午饭，一个刚入职的小姑娘问我：“哥，你说以后AI都能自己生成用例了，我们手工测试是不是就没活干了？”
我想了想，说：“你觉得我这半个月轻松了，是因为AI替我干了？”
她点头。
我说：“其实不是。AI替我干了写写画画的活儿，但真正让我轻松的是——我终于有时间去想那些以前没时间想的事了。”
以前我大部分时间耗在“怎么测”上：怎么把需求转成用例，怎么把用例写成文档，怎么把文档填进Excel。现在这部分AI帮我干了，我才有时间去想“测什么”：这个版本最核心的风险点在哪？哪些场景最容易出bug？用户真正在意的功能是哪些？
AI不会替代测试，但会用AI的测试会替代不会用AI的测试——这句话我这半个月才真正理解。
手工点点点不会消失，但它会变成测试工作中的一小部分。更多的精力，会放在测试设计、风险分析、用户体验这些更需要判断力的事情上。
六、给还在手工点点点的同学几个建议
如果你也想试试这条路，我踩过的坑可以帮你少走几步：
- 从最简单的开始
别一上来就让AI帮你设计全流程。先从单个功能点开始，让它帮你列几个测试点，看看效果，找找感觉。
- AI的产出要当“初稿”，别当“终稿”
它不知道你的系统长什么样，不知道你历史版本的坑在哪，不知道这次开发的代码质量如何。它列出来的，是你思考的起点，不是终点。
- 学会问问题
跟AI对话，不是下命令，是沟通。我试过几种问法：
“根据这段需求，列出测试点”（太宽泛，效果一般）
“从功能、界面、异常、边界几个角度，分析这个需求的测试点”（有框架，效果好）
“这个规则可能有哪些容易出bug的地方？”（让AI帮你思考风险点）
你问得越具体，它给得越有用。
- 保持判断力
AI说“这个字段必须测”，你可以听听。但如果你知道这个字段开发根本没改过，历史版本一直稳定，那优先级就可以往后放。最后拍板的，还得是你自己。
写在最后：这个春天，不太一样
今天下班的时候，我特意绕了个远路，从公司旁边的公园穿过去。
杨絮还在飘，桃花开了几棵。往年的这个时候，我应该是下班后累得不想动，窝在工位上刷手机回血。但这个春天，我居然有心情看看花。
不是活少了，是活变轻了。不是人懒了，是工具变聪明了。
前几天看到一篇文章，标题记不清了，但有句话记住了：测试的未来，不是点点点，是设计测试的人。
这个春天，AI替我干了点点的活儿，我终于可以开始想“设计”的事了。
也许这才是这个春天，最不一样的地方。
