最近老有人问我，说现在 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， 正常返回 code=200、token 字段；密码错误时返回 code=4001。 请帮我生成完整测试用例，包含： 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. 同一用户同一批次活动只能领取一次，重复领取返回 code=5001； 3. 每个批次优惠券数量有限，库存不足返回 code=5002； 4. 信道只允许 app 和 h5，其他渠道返回 code=4000。 请生成 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, timeout=10, **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, tools=tools) 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 直接 POST：
import 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, json=payload, headers=headers, timeout=60) 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 要稳得多。
