上周五的站会，我汇报完工作进度，旁边的老张凑过来压低声音问：“老实交代，是不是偷偷请了外包？或者……挖了个字节的测开大神在家远程帮你写脚本？”
我愣了一下，然后笑了。
这一周，我所在的团队正好遇上版本迭代高峰期，按往常节奏，光是把核心业务的回归测试脚本写完，至少得磨蹭三四天。但这周我不仅搞定了脚本，还有时间准点下班接孩子。老张的怀疑，我懂——毕竟就在一周前，我还跟他一起吐槽过自动化测试的种种破事。
这变化的秘密，其实不是什么外包大神，而是我自己用AI搭的一套测试脚本生成“流水线”。准确说，是AI辅助测试开发。今天把这周折腾的一点心得写出来，也许能帮到同样被脚本折磨的你。
一、一切始于那个写脚本写到吐的深夜
先交代下背景。我所在的团队，测试覆盖要求高，每次版本更新，接口自动化脚本必须同步更新。我们用的是Python + pytest框架，按说挺主流的，但痛点一直没解决：
- 用例设计全靠人肉：对着接口文档，一个个字段想边界值，脑袋想秃
- 数据准备烦得要死：注册接口要测用户名重复，我得先去数据库插一条；测手机号格式，得现造各种奇葩号段
- 代码重复劳动：参数化用例写起来跟复制粘贴似的，改个字段名得全局替换
上周二晚上，我在工位上对着一个要测12种组合的接口发呆，心想：这种重复劳动，凭什么不能交给AI干？
于是，我开始了为期一周的“AI辅助测试开发”实验。
二、第一阶段：让AI帮我写测试代码（从0到1）
最开始的想法很简单——把自然语言变成测试代码。
我的工具是DeepSeek（也有用ChatGPT的同事，看个人习惯）。第一次尝试，我给了它这样一段提示：
“用pytest写一个用户注册接口的测试脚本，接口地址/api/register，POST方法，要测正常注册、用户名重复、邮箱格式错误、密码太短、必填字段缺失这几种情况，用参数化实现。”
十来秒，它就吐出了一段代码。我复制到PyCharm里，微调一下字段名，跑起来居然全过。
import pytest
import requests
class TestUserRegister:
base_url = "http://test.env.com"
@pytest.mark.parametrize("username,email,password,expected_code,expected_msg", [
("testuser01", "test01@xx.com", "Pass1234", 200, "注册成功"),
("existing_user", "new@xx.com", "Pass1234", 400, "用户名已存在"),
("testuser02", "invalid-email", "Pass1234", 400, "邮箱格式错误"),
("testuser03", "test03@xx.com", "123", 400, "密码长度不足6位"),
("", "test04@xx.com", "Pass1234", 400, "用户名不能为空"),
])
def test_user_register(self, username, email, password, expected_code, expected_msg):
url = f"{self.base_url}/api/register"
payload = {"username": username, "email": email, "password": password}
res = requests.post(url, json=payload)
assert res.status_code == expected_code
assert expected_msg in res.json().get("message", "")
那一刻的感受挺微妙：不是AI写得多完美，而是它把我最不想干的“模板代码”给干了。边界值不用自己凑，参数化的架子自动搭好，我只需要核对业务逻辑。
第一天，我用这种方式搞定了5个接口的脚本，效率大概是我手敲的3倍。
三、第二阶段：让AI当测试设计助手（从1到10）
尝到甜头后，我开始加码。
传统的自动化测试，脚本只是最后一步，前面还有测试设计。以前我要先画脑图、列用例、写excel，再转成代码。现在，我把测试设计也扔给AI。
那天测一个订单查询接口，接口文档是Swagger格式的。我把OpenAPI的json文件喂给AI，然后问：
“基于这个接口定义，帮我设计订单查询功能的测试用例，要考虑分页参数、时间范围、状态过滤、异常订单号等情况。”
AI返回了一组测试点，还按优先级排了序：
- P0：正常查询全部订单
- P1：分页测试（page=1, size=10；page=2；size=0）
- P1：状态过滤（待支付、已支付、已取消）
- P2：时间范围（跨月、跨年、开始>结束）
- P2：异常订单号（不存在、含特殊字符、超长）
我挑了几个边界值让AI生成具体脚本，剩下的录进Excel，转给手工测试的同事用。那一周，手工测试的同事反馈，他们发现的几个漏测场景，AI设计的用例里其实都覆盖了——只不过开发还没实现，所以脚本跑通了，手工跑就挂了。这说明AI不是神，但它帮你兜住了不少底。
四、第三阶段：引入工作流，让AI更“懂”业务（真正的转折点）
前两个阶段虽然快，但有个问题：AI没有上下文。每次生成脚本，它都不记得刚才生成过什么，也不懂我们的业务规则。
比如我们有个业务规则：“用户当天取消订单超过3次，账号临时冻结24小时”。这种规则，光看接口文档是看不出来的。所以早期生成的脚本，最多测到状态码，测不到这么细的“状态流转”。
周三晚上，我研究了下Dify这个开源平台，试着把测试过程搭成可视化工作流。
我的设计思路是这样的：
- 输入层：把业务需求、接口文档、测试点用自然语言写进去
- 知识库层：把我们项目的OpenAPI规范、历史缺陷记录、业务规则文档传上去，让AI能检索
- 处理层：AI先理解需求，再查知识库，最后生成测试策略和脚本
- 输出层：生成pytest脚本+测试数据
举个例子。测“用户取消订单”功能时，我在输入框里写：
“测试用户取消订单，要覆盖正常取消、重复取消、超过3次后取消被限制、订单状态已发货后取消失败。”
AI先去知识库里翻业务规则，找到了“当日取消超3次冻结”那条。于是它生成的测试数据里，自动构造了这样一个用例：
{
"用例ID": "TC_Cancel_004",
"场景": "当日取消次数超限后尝试取消",
"前置": "同一用户当日已取消3次订单",
"输入": "订单号ORD004，取消操作",
"预期": "返回错误码400，提示‘取消次数已达上限，请24小时后重试’"
}
对应生成的脚本里，还加了一段前置数据准备：先调用三次取消接口，再测第四次。
那天老张看我跑这个用例，愣了：“这场景你怎么想到的？我都差点忘了这个规则。”我说：“我想不到，但AI记得。”
五、第四阶段：智能体的尝试（高阶玩法）
这周最后两天，我开始尝试更进阶的——让AI不再只是代码生成器，而是一个测试智能体。
参考了一些LangChain的案例，我试着搭了一个简单的Agent，它能做三件事：
- 理解任务：比如“测一下登录功能”
- 调用工具：比如先调GET /state接口看当前页面状态，再决定点哪个按钮、输什么数据
- 分析结果：如果登录失败，自动判断是密码错还是账号锁定，然后决定下一步是重试还是报bug
虽然只搭了个原型，但跑起来那个感觉挺奇妙的。我让它测一个带验证码的登录页，它第一次用“admin/123456”登录失败后，自己推理说“可能密码错误”，然后换了一套“admin/Pass1234”继续试。试了三次都失败，它居然在日志里写：“建议检查验证码识别服务是否正常。”
那一刻，我真有点理解网上那篇文章说的了：AI不是在执行脚本，而是在“思考”怎么测。
六、一周下来的几个数据
我不是那种特别喜欢讲故事的风格，还是摆几个数字吧：
- 脚本编写效率：按代码行数算，大概提升了3-4倍
- 用例覆盖率：对比我自己手写的版本，AI生成的用例在边界条件和异常场景上多覆盖了约30%
- 维护成本：目前还看不出来，但感觉只要及时更新知识库（接口文档、业务规则），AI生成的脚本适应能力应该比我手写强
- 心情变化：从周二晚上的“写吐了”变成周五下午的“这就周五了？”
当然，也不是没坑。有几次AI生成的脚本里有不存在的字段，可能是它“记混了”别的项目；还有一次它生成的SQL注入用例，直接把我本地测试环境搞挂了——所以现在我在跑之前，都会先review一遍，尤其是带写操作的那种。
七、给想入坑的同学几点建议
如果你也想试试这条路，我的几点体会供参考：
1. 从最简单的场景开始别一上来就想搭智能体。先让AI帮你写几个参数化用例，感受一下它能干什么、不能干什么。
2. 提示词要具体“帮我写个登录测试”和“帮我用pytest写登录接口的测试，要测密码错误、账号锁定、验证码错误，用参数化实现，断言状态码和错误信息”——后者效果明显好。AI不读心，你需要告诉它你要什么。
3. 建立知识库很重要如果只是单次对话，AI记不住你的业务。把接口文档、业务规则、历史缺陷整理一下，让AI能检索，生成的脚本会准得多。
4. 保持判断力AI生成的脚本，我从来不直接跑。先看一遍逻辑，确认没写删库操作（别笑，真有案例）再执行。工具再强，方向盘还得在自己手里。
写在最后
周五下午，老张还在追问我外援的事。
我把他拽到工位前，打开Dify的工作流画板，给他看那几个节点：需求解析、测试生成、脚本输出。又把聊天记录翻出来，让他看AI是怎么一步步写出那些测试用例的。
他看完沉默了几秒，然后说：“也就是说，你没请外援，你请了个AI？”
我说：“准确讲，是学会用AI给自己当外援。”
他拍拍我肩膀，走了。走几步又回头：“下周教教我？”
这大概就是我这周最大的收获——不是代码写得多快，而是发现了一种新的工作方式。以前是我写代码，机器执行；现在是我指挥AI写代码，AI执行，我review。我还是那个测试工程师，只是身后多了个不知疲倦的帮手。
也许就像那篇文章里说的：2025年，最好的测试工程师不是最快敲键盘的人，而是最会指挥AI的人。
至于老张的请求，我已经想好了——下周手把手教他。毕竟，团队整体变强了，我才有更多时间研究怎么把AI用得更好。
以上，就是一个测试工程师用AI写脚本一周的真实经历。希望对你有用。
关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。
学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。
我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。
在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。
同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。
