三月底的北京，杨絮刚开始飘。

我坐在工位上，看着屏幕上刚刚跑完的测试报告，愣了几秒。

搁往年这个时候，版本迭代高峰期，我应该在干什么？

打开Excel，对着需求文档一行行写用例；打开测试环境，一个页面一个页面点点点；打开Jira，一条一条提单。

每天下班前看一眼当天的“战绩”：写了多少条用例，点了多少个页面，提了多少个bug。

但这个春天不太一样。

我发现自己坐在工位上的时候，手没怎么动，脑子也没怎么累，但该干的活都干完了。

变化是从两周前开始的。

那天产品扔过来一个需求文档，二十多页，一个新模块上线，按正常节奏，光测试设计就得两天。

我看着文档发呆，突然冒出一个念头：能不能让AI帮我把用例先过一遍？

我们做功能测试，最烦的就是看需求文档。

不是不想看，是文档太长了。

二十多页，密密麻麻的文字，有时候翻到后面已经忘了前面。

更要命的是，文档里藏着一堆测试点，一不小心就漏了。

那天我试了个笨办法：把需求文档复制出来，分段扔给AI，然后问它：

第一次试的是一个订单查询功能。

文档里写：“用户可根据订单号、商品名称、下单时间范围查询历史订单，支持分页展示，每页默认20条，最多展示100页。

”

订单号为空：点击查询，应提示“请输入订单号或商品名称”

商品名称模糊查询：输入商品名称的一部分，应返回相关订单

分页边界：每页20条，第100页有数据，第101页无数据

……

我数了数，二十多个测试点。

比我手动列的全，有些边界值我自己都没想到。

那天下午，我干了一件事：把接下来要测的三个功能的需求文档都喂给AI，让每个生成一份“测试点清单”。

一下午的时间，平时要花一周的测试设计工作，干完了。

刚开始用的时候，我太信任AI了。

它列的测试点，我基本照单全收，直接转成Excel就开始测试。

有个充值功能，AI列了一个测试点：“充值金额为负数时，系统应提示‘金额不能为负数’。

”我一看，有道理啊，边界值嘛。

跑到测试环境一试，发现根本不存在这个场景——前端输入框限制了只能输入数字，输不了负号。

还有一次，AI给一个权限管理模块列的测试点里，有一条“普通用户尝试访问管理员页面，应跳转403错误页”。

但我查了一下权限设计文档，发现普通用户根本看不到管理员页面的入口，不存在“访问”这个行为。

这两次翻车让我明白一个道理：AI不知道你的系统长什么样。

它能根据需求文档推测“理论上”的测试点，但不知道你的前端有没有做输入限制，不知道你的菜单权限是怎么配置的，不知道哪些异常场景在真实系统里根本不可能出现。

从那之后我学聪明了：AI列的测试点，我把它当成“初稿”和“提醒”，但最后过一遍脑子，结合自己对系统的了解，删掉那些不存在的，补充那些漏掉的。

测试点列完了，下一步是写具体的测试用例。

就是那种“步骤1、步骤2、预期结果”的格式。

这活儿我以前最烦。

一条条写，翻来覆去就那么几个套路，写多了手都酸。

第二周我开始试：能不能让AI直接把测试点转成测试用例？

比如第一个充值功能的测试点：“输入金额小于1元，应提示‘最低充值1元’”。

“把这个测试点写成标准测试用例，包括前置条件、测试步骤、预期结果，要写清楚具体怎么操作。

”

用例标题：充值金额小于最低限额

前置条件：用户已登录，账户余额100元，充值页面已打开

测试步骤：

预期结果：页面提示“最低充值1元”，充值失败，账户余额不变

后来我发现一个更好用的功能：批量生成。

比如我有十几个测试点，全扔给AI，让它“按同样的格式，把这些都转成用例”。

十几秒，十几条用例就出来了。

虽然每条都要看一眼确认，但比自己一条条敲快多了。

人工智能技术学习交流群

伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？

我们建了一个

「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。

无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！

期待与你交流！

👇

src="https://img2024.cnblogs.com/blog/1772657/202602/1772657-20260206005058718-2085311268.png"

alt="image"

上周有个业务场景：优惠券叠加规则。

规则文档写得跟天书似的，什么“同一订单可使用多张优惠券，但不可与满减活动共享，特殊商品除外，会员等级不同优惠不同……”

后来我换了个思路，把规则文档拆成几段，喂给AI，然后问：

“假设你是测试人员，帮我设计这个优惠券叠加规则的测试用例，要覆盖正常场景、边界场景和异常场景。

”

AI沉默了十几秒（可能是在思考），然后输出了一组用例，分类很清楚：

正常场景：

用户使用两张可叠加券，下单时两张同时生效，优惠金额相加

边界场景：

最后还加了一行总结：建议重点测试“互斥规则”和“门槛计算”，这两块最容易出bug。

我拿着这组用例去测，果然，互斥规则那块还真有个bug——两张本该互斥的券，居然能同时用。

那一刻我突然想：AI现在能干到这一步了？

连测试策略都能给了？

这半个月的尝试，组里有人看在眼里。

昨天午饭，一个刚入职的小姑娘问我：“哥，你说以后AI都能自己生成用例了，我们手工测试是不是就没活干了？

”

我想了想，说：“你觉得我这半个月轻松了，是因为AI替我干了？

”

我说：“其实不是。

AI替我干了写写画画的活儿，但真正让我轻松的是——我终于有时间去想那些以前没时间想的事了。

”

以前我大部分时间耗在“怎么测”上：怎么把需求转成用例，怎么把用例写成文档，怎么把文档填进Excel。

现在这部分AI帮我干了，我才有时间去想“测什么”：这个版本最核心的风险点在哪？

哪些场景最容易出bug？

用户真正在意的功能是哪些？

AI不会替代测试，但会用AI的测试会替代不会用AI的测试——这句话我这半个月才真正理解。

手工点点点不会消失，但它会变成测试工作中的一小部分。

更多的精力，会放在测试设计、风险分析、用户体验这些更需要判断力的事情上。

别一上来就让AI帮你设计全流程。

先从单个功能点开始，让它帮你列几个测试点，看看效果，找找感觉。

它不知道你的系统长什么样，不知道你历史版本的坑在哪，不知道这次开发的代码质量如何。

它列出来的，是你思考的起点，不是终点。

跟AI对话，不是下命令，是沟通。

我试过几种问法：

“根据这段需求，列出测试点”（太宽泛，效果一般）

“从功能、界面、异常、边界几个角度，分析这个需求的测试点”（有框架，效果好）

“这个规则可能有哪些容易出bug的地方？

”（让AI帮你思考风险点）

AI说“这个字段必须测”，你可以听听。

但如果你知道这个字段开发根本没改过，历史版本一直稳定，那优先级就可以往后放。

最后拍板的，还得是你自己。

今天下班的时候，我特意绕了个远路，从公司旁边的公园穿过去。

杨絮还在飘，桃花开了几棵。

往年的这个时候，我应该是下班后累得不想动，窝在工位上刷手机回血。

但这个春天，我居然有心情看看花。

不是活少了，是活变轻了。

不是人懒了，是工具变聪明了。

前几天看到一篇文章，标题记不清了，但有句话记住了：测试的未来，不是点点点，是设计测试的人。

这个春天，AI替我干了点点的活儿，我终于可以开始想“设计”的事了。

推荐学习

src="https://img2024.cnblogs.com/blog/1772657/202602/1772657-20260206005058718-2085311268.png"

alt="image"

测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与

Python

驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展

“火焰杯”

软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂

1v1

私教服务，用于个性化能力提升与工程实践指导。