★ FEATURED ARTICLE 最近老有人问我说现在 AI 这么火DeepSeek 到处都在聊那它到底能不能用在自动化测试上是不是真的能帮人少加班我的答案是能而且用对了地方效果非常明显。但前提是你得搞清楚 AI 的边界把它放在合适的环节里而不是指望它一巴掌帮你把整个测试体系都重写了。这篇就把我过去一段时间用 DeepSeek 配合 pytest、Appium、Selenium 这些主流框架做自动化测试的完整思路、实操过程、踩过的坑和最终沉淀下来的方法一次性说清楚。1. 先搞清楚AI 到底在自动化测试里替你干了哪些活1.1 传统自动化测试的效率瓶颈在哪聊 AI 之前咱们得先坦诚面对一个问题自动化测试发展这么多年框架已经很成熟了selenium 也好、pytest 也好为什么实际落地时效率还是上不去说白了卡点从来不在执行这一环而在写用例、维护数据和排查失败这三个环节。我在好几家团队里都看到过同样的场景自动化用例写了一两千条但每次版本迭代光是修 locator、改接口字段、补测试数据就要花掉一大半时间。写用例本身倒不慢真正吃时间的是跟着需求变化反复改。而且很多测试同学写用例的姿势还是手敲遇到新的接口文档、新的页面原型得一点一点翻译成代码。这种活儿重复性极高正好是 AI 最擅长消化的部分。1.2 AI 能切入的四个核心环节我实操下来DeepSeek 这类大模型在自动化测试里真正能稳定提效的主要是四个环节第一是测试用例代码的生成。你给它一个接口文档、一个页面需求描述它能直接产出 pytest 函数、selenium click 操作、appium 滑动操作这类基础代码。第二是测试数据的构造。不管是接口的字段组合、边界值还是数据库里需要预置的数据AI 可以根据你给的规则批量生成。第三是脚本维护。页面改了、接口字段重命名了你把新代码和报错丢给它它能非常快地定位差异并给出修改建议。第四是问题定位。用例跑了失败把日志贴过去它能辅助判断是环境问题、数据问题还是代码本身的问题。这四个环节覆盖了我日常大概百分之七十的工作量。剩下的百分之三十比如复杂的业务逻辑编排、跨系统状态校验、架构层面的设计还是得靠人的脑子。1.3 什么样的团队和项目最适合引入 AI也不是所有项目都适合一上来就上 AI。我个人的判断标准很简单业务规则清晰、输入输出明确的场景优先。像接口测试、表单流程测试、数据校验这种AI 很容易理解和生成像涉及大量人工主观判断的视觉还原测试、音频视频测试AI 虽然能做但现阶段更适合做一些辅助性的图像比对和异常帧识别别指望它全自动。如果你所在的团队已经有比较成熟的自动化用例沉淀那引入 AI 是在现有资产上升级如果你们还在从零搭建框架AI 也能帮你省掉很多脚手架的时间但对团队核心人员的要求反而更高因为你需要有能力判断 AI 生成的东西到底对不对。2. 实战第一步用 DeepSeek 生成高质量的 pytest 测试代码2.1 写好提示词的四个关键要素很多人觉得 AI 生成代码不好用直接用 DeepSeek 官网聊天窗口也行很快。但我试过之后发现大部分说AI 写的代码没法用的同事问题不在 AI在提示词写得太模糊。你给一句写一个登录测试它当然只能给你一个过家家级别的脚本。要让 AI 输出能直接跑的代码提示词里至少得有四个要素测试目标的业务背景、被测对象的技术栈、明确的输入输出示例、以及你对代码风格或框架结构的要求。给你看个我常用的模板参考你是资深测试开发。我在用 pytest requests 做接口自动化测试。 被测接口是用户登录接口POST /api/v1/login入参为 username、password 正常返回 code200、token 字段密码错误时返回 code4001。 请帮我生成完整测试用例包含 1. 正确用户名密码登录成功 2. 密码错误时断言返回值 3. 缺少必填参数时的异常处理 要求使用 fixture 管理 base_url断言要精确到具体字段代码要符合 pytest 风格。在这个例子里我的四个要素分别是技术栈pytest requests、业务背景登录接口、输入输出路径、参数、返回字段、代码要求fixture、断言精度。信息越具体生成结果就越接近可用状态。这是一条我以为值得反复强调的经验AI 生成代码不是魔法它的输出质量上限大概率等于你的提问下限。2.2 从需求描述到可运行用例的一次完整示例我拿一个真实项目里的例子给你拆一遍。当时要测一个优惠券系统的发券接口需求描述就一句用户满足条件后领取优惠券同一用户只能领一次。这种描述给 AI它大概率只能生成一个只调接口看是否返回成功的用例。这不叫自动化测试这叫接口连通性检查。合格的用例应该覆盖参数边界、状态幂等、并发重复请求、优惠券库存扣减是否准确等等。我是这么给 DeepSeek 下需求的优惠券领取接口 POST /v1/coupon/receive入参userId、couponId、channel。 业务规则 1. 用户必须满足会员等级≥2 才能领取 2. 同一用户同一批次活动只能领取一次重复领取返回 code5001 3. 每个批次优惠券数量有限库存不足返回 code5002 4. 信道只允许 app 和 h5其他渠道返回 code4000。 请生成 pytest 用例覆盖以上规则并考虑并发场景下单测使用 pytest 的 parametrize 实现参数化。它生成出来的代码骨架基本是可用的有 parametrize 参数化表、有独立 test 函数还自动加了多线程并发测试的雏形。我拿到手大概只改了百分之十的代码主要是一些自定义断言函数的调用方式、项目里统一的响应封装类名。桐下省掉我大把从网上翻资料找格式化写法的时间。2.3 代码生成后的审查与打磨清单AI 生成的代码不代表可以无脑合并到主干尤其是测试代码它的目标不只是跑通还要能发现 bug。所以我在提交前会过一遍自己的审查清单一般固定看五点第一看断言的强度AI 很容易生成只断言状态码 200 的用例这种用例遇到业务逻辑错误时根本拦不住要在关键位置断言业务码、数据库落库状态或响应体里的具体字段。第二看测试独立性AI 生成的用例经常会假设前置数据存在但真实项目里你需要通过 fixture 去构造环境否则用例换个环境就挂。第三看参数化是否覆盖边界值AI 默认只覆盖它理解到的正常 一个异常你要自己补空值、超长值、特殊字符。第四看是否保留了日志与现场信息用例失败时如果什么上下文都没有排查成本会很高我一般要求 AI 生成的代码里带 run_id、请求参数快照、响应体快照。第五看有没有假通过陷阱也就是 try except 把异常吞掉、只在测试里打印日志而不加断言这类写法必须删掉。这份清单看起来麻烦但它本质上是把人工测试设计经验前置进 AI 协作流程坚持做下来你和 AI 的配合会越来越顺。3. 进阶玩法AI 辅助接口自动化测试与测试数据构造3.1 接口自动化框架怎么和 AI 结合接口自动化是在我看来 AI 落地效果最好的一个测试领域没有之一。因为它输入输出结构清晰断言规则明确大模型理解起来几乎零门槛。我在项目里用的是 pytest requests 的结构配合一套自研的断言封装大概像这样组织import requests import pytest def _request(method, url, **kwargs): resp requests.request(method, url, timeout10, **kwargs) return resp这个最基础的封装适合直接丢给 DeepSeek 作为上下文参考。然后你让它生成测试用例时它会基于你已有的请求封装来组织代码而不是另起炉灶生成一堆独立请求的脚本。这一点对后续维护非常重要一旦项目里改了统一鉴权逻辑你只需要改一个封装几百个用例跟着生效。如果让 AI 各自为战写散装代码改起来就等着哭吧。实际项目中我发现AI 最强的不是从零写一个框架而是基于你现有的代码风格去补全用例。所以正确的用法是先给它看两三个你手写的典型用例再让它生成同风格的新用例。它会模仿得又快又像几乎不用调整。3.2 测试数据构造的高效姿势做接口自动化最烦人的工作之一就是造数据。你要测用户领券就得先有一个等级满足条件、信用分正常、没有风控标记的用户你想测退货就得先有订单、支付流水、物流单号还得让订单状态走到指定节点。以前我的做法是写一堆 SQL 脚本和造数接口的调用脚本每次跑测试前手工触发。现在我用 DeepSeek 来干两件事效率提升特别明显。第一件事是让它根据数据库表结构生成测试数据的 SQL 脚本。你只需要把 create table 语句贴给它说清楚要造什么样的数据它会直接生成带外键关联的 insert 语句。需要注意的是AI 生成的 SQL 可能存在外键依赖顺序问题、字符集问题我一般会提醒它注意表之间的依赖顺序并用事务包裹这样造数失败时可以整体回滚。第二件事是让它生成通过接口链路造数的脚本比如先注册、再登录、再下单、再支付一连串串起来。这种链路脚本早期我手写得花半天现在 AI 一次性生成后我只要调一下业务差异部分。3.3 怎么让 AI 帮你跑通参数化与断言覆盖接口测试有一个很核心的思路叫参数化同一接口不同参数组合跑到各个分支里去。以前大家要么手写大量的 parametrize 列表要么去业务代码里找枚举值维护成本极高。DeepSeek 在这里能帮上大忙原因是它很擅长根据你对业务规则的文字描述推断出参数组合矩阵。我试过一个比较经典的场景订单查询接口有分页参数、状态参数、排序参数混合起来有几十种组合。我把接口文档和业务规则描述贴给它它在两分钟内生成了一份带 pytest.mark.parametrize 装饰器的完整用例文件还自己给每个组合起了有业务含义的 test id失败用例一眼就能看懂是哪种参数场景出了问题。你只需要在生成后抽查几组数据是否符合业务规则剩下的大胆交给 CI 去跑。不过这里要提醒一个坑AI 在推断参数组合时偶尔会遗漏一些不可能出现的组合比如它可能不知道某个渠道和某个支付方式根本不会同时出现。这种隐性业务知识它接触不到。所以我的习惯是拿到 AI 生成的参数化矩阵后先让最熟悉业务的产品或资深测试过一眼把不可能场景剔除再进版本库。4. UI 自动化场景AI 如何加速 Appium 与 Selenium 的落地4.1 定位器生成与维护的痛点转化UI 自动化里最让人崩溃的就是定位器维护。用 Selenium 写 web 端用 Appium 写移动端动不动就因为前端改了 class 名、加了层 dom 结构一整批用例瞬间变红。以前定位器基本靠手写和猜现在 AI 成了我处理这个问题的第一工具但没有那么神秘只是一个转译过程。我在 chrome 的 devtools 里复制一段元素对应的 HTML或者 Appium dump 出来的 xml 片段贴给 DeepSeek让它在原来的定位策略基础上给出更稳的方案。它能提出的思路包括换成相对定位、用 xpath 基于文本匹配、用>tools { call_api: call_api, assert_db: assert_db, read_case_data: read_case_data } def run_agent(task): messages [ {role: system, content: 你是测试执行助手以下是你可以调用的工具...}, {role: user, content: task} ] for step in range(10): response call_deepseek(messages, toolstools) action parse_action(response) if action[type] finish: return action[summary] result execute_tool(action) messages.append(...)跑起来之后效果还是挺有趣的你给它一句跑一遍登录全链路并校验优惠券数量变化它真的会自己编排调用、登录、领券、查库最后返回一份结果。这里面最值得警惕的是要让 AI 每一步行动都有日志输出方便出问题时回放追踪否则它自己玩岔了都很难通过最后的结论判断是哪一步出的问题。5.3 实施时的注意事项Agent 虽然能提升自动化程度但现阶段还是有不少限制。我的核心建议是循序渐进别一上来就让它全权负责所有回归测试。先在一个风险较低的冒烟场景里试用将它的执行范围限定在只读接口和查询类数据库操作上不要让它随意执行写操作或删除操作否则一旦推理出错影响的数据可能就是线上环境。AI 的推理不是百分百稳定你要给 Agent 加护栏比如限制请求域名、限制数据库用户只读权限、限定最大执行步数。这个思路跟给实习生交代任务是差不多的边界划清楚活儿才能放心交给它。另外一个容易被忽视的问题是提示词可靠性。真实环境里 AI 的每次输出都有细微差异你不能假设它每次生成的 JSON 格式完全一致所以解析层要写得足够健壮缺失字段要有默认值。我在早期原型里就因为 AI 一次少了个中括号导致整个解析崩溃排查了很久才发现是输出格式抖动问题。6. 常见问题与排查技巧实录6.1 五个高频问题及排查思路跟 AI 协作做测试时间长了总会遇到一些反复出现的问题。我从自己实践里挑五个典型的整理成了下面的速查表方便你直接对照AI 生成的用例在本地运行报错。大部分情况是因为缺少上下文依赖没安装、环境变量没设置、测试数据不存在。排查时先看报错栈的前三段基本能定位是 import 问题还是运行时数据问题。你把完整报错栈回贴给 AI让它修正通常一轮就能解决。如果二轮还是不对别再死磕自己看一眼代码大概率是 AI 对你们项目特有的封装理解有偏差。测试代码风格和项目现有代码不一致。这是最常见的问题不是 bug 但影响维护。解决方法是在提示词里加上请严格遵循项目代码风格使用 pytest fixture、禁止使用 unittest 类、断言必须使用自定义的 assert_custom 方法这类约束会比事后人工改快得多。AI 生成的定位器跑了几天就开始不稳定。前端改了样式或者 dom 层级变动建议在设计案例时主动让 AI 生成多套定位策略把稳定性最高的作为首选其余作为备选。如果已经出现不稳定直接把新旧 dom 结构都给 AI 重新生成即可。AI 在生成用例时漏掉了异常场景。我在提示词后追加一句请补充边界值与异常入参场景例如空值、超长字符串、特殊字符效果比让它自由发挥好得多。但依旧会漏所以一旦业务上有新增的异常路径你要主动在提示词里点名AI 才会持续关注。Agent 执行时中途跑偏。这个我碰到过好多次AI 在执行过程中突然开始猜测数据而不是调用工具查证。解决思路是加一条系统级约束你没有权限假设任何值所有数据必须通过工具获取并且在每轮循环后做中断检查发现它在编数据就立刻终止。6.2 关于 AI 幻觉的应对策略AI 幻觉在测试领域的影响被很多人低估了。它生成一段看起来非常合理的 pytest 代码里面的断言、mock、业务逻辑都对但有个致命问题某个接口路径是它编出来的。这种代码第一次能跑通还好跑不通的时候你又没看仔细就会浪费时间在无效排查上。我的应对策略是两条一是场景尽量收窄只给 AI 明确存在的信息不给它的想象空间。凡是涉及接口路径、数据库表名、字段名的地方都在提示词里给出准确值不允许它发挥。二是所有 AI 生成的代码都必须经过一次静态检查重点看硬编码的参数、URL、鉴权信息是否明显不合理。尤其是涉及生产环境的地址和账号必须由人工严格核对不能直接采用。6.3 团队协作与流程配套AI 提效不是一个人的事它需要流程上的配套。我在团队里推过一段时间的 AI 辅助测试发现最明显的效果是新人上手速度变快了。以前新人进组光写接口测试用例就要熟悉大半个月现在借助 AI 可以快速生成基础用例然后带着问题去问老同事比如为什么这个场景要额外断言库存这种提问质量远比一无所知地上手要高。但团队里也有个反面现象就是有些人过度依赖 AI生成代码不审就提交导致一堆能跑但测了个寂寞的用例进了仓库。所以我把 AI 生成用例的代码评审权重提高了凡是 AI 贡献的测试代码提交信息里必须标注AI generated 人工审查目的不是歧视 AI而是提醒每个用例还是要有人对它负责。7. 工具链选型DeepSeek 接入方式与组合建议7.1 调用 API 的几种方式与成本参考部署方式百花齐放从平台可视化界面、到官方的 API再到私有本地化部署选择空间一直不小。我个人的经验是前期还没有太多敏感信息时直接用官方的 API 就是最快的验证路径。它的接口格式是 OpenAI 兼容的所以你用 requests 就能轻松调用不需要引入复杂的 SDK。以 Python 为例最朴素的调用方式是用 requests 直接 POSTimport requests url https://api.deepseek.com/v1/chat/completions headers { Authorization: Bearer your_api_key, Content-Type: application/json } payload { model: deepseek-chat, messages: [ {role: system, content: 你是资深测试开发工程师。}, {role: user, content: 帮我生成登录接口的 pytest 用例。} ] } resp requests.post(url, jsonpayload, headersheaders, timeout60) print(resp.json()[choices][0][message][content])这种方式适合快速验证和轻量脚本。如果集成到 pytest 框架里做单元级 AI 辅助我会封装一个简单的 helper让所有用例生成请求统一走一条路径这样管理 key、超时、重试都方便一些。成本方面不用太担心日常生成测试代码的请求规模在我自己项目里的消耗很小远低于手工编写消耗的人力成本。但如果是大规模批量使用比如团队里每个用例都要实时调 AI那建议在中间层加缓存相同的业务描述不要反复请求。7.2 本地部署的取舍说到本地部署我周围不少同事第一反应是隐私和数据安全。确实测试代码里经常包含业务接口路径、数据库信息、用户数据这些信息要是全走公共 API有些团队会觉得不放心。我有一次自己也试过在本地机器上研究部署方案核心结论是本地部署完全可行但对机器配置有要求配置不够的话推理速度会明显掉队不少人试了几次就放弃回头用 API 了。我这里不展开具体的环境配置明细因为不同型号的机器、不同的部署方案差异很大但给你一个决策参考如果团队对数据外发零容忍那本地部署值得投入如果只是图省事公共 API 完全够用没必要折腾。另外要提醒一点不管选哪种方式都要在测试环境里跑通 POC让实际写代码的人亲手验证效果再定。部署方案是手段不是目的最终衡量标准只有一个能不能帮你稳定地产出有效的测试用例。7.3 与主流测试框架的组合矩阵最后按我的实践整理了一套 AI 与主流测试框架的组合建议方便你根据自己项目类型快速对应测试场景推荐框架AI 辅助切入点接口自动化pytest requests用例生成、参数化矩阵、断言补充、数据构造Web UI 自动化Selenium pytest元素定位、Page Object 生成、跨版本页面迁移移动端自动化Appium pytest跨端用例翻译、控件层级分析、手势与弹窗处理接口性能测试Locust / JMeter压测脚本生成、参数关联、结果初步分析数据校验pytest SQLAlchemy造数脚本生成、库存/状态流转断言补全你会发现AI 在这些组合里扮演的不是替代框架的角色而是框架和业务理解之间的翻译官。测试框架依然是你工程化的骨架AI 帮你在骨架上快速长出肌肉。这套组合我实践了几个月很明显的感受是重复性工作确实减少了但测试设计的能力、业务的理解深度、代码的审查能力反而变成了更稀缺的技能。想在这条路上走得远这些能力还是得趁早练起来。最后再分享一个小技巧。无论用哪种接入方式我建议你在团队里建一个AI 提示词库把自己验证过的高质量测试相关提示词沉淀下来比如生成接口测试用例的万能模板、生成 PageObject 的标准流程、批量转换用例的指令这类内容。新同事来了直接抄作业大家产出质量就容易对齐。我自己的提示词库已经积累了几十个常用模板每次写新用例之前先翻翻确实比每次从零开始问 AI 要稳得多。
阅读完成 · 觉得有帮助？
