去年我被借调到一个数据中台项目救火，旁边工位坐了个测试妹子，每天从早到晚就是对着浏览器重复点同一套流程——登录、建单、审批、查报表，一天跑三轮回归，下班手都是抖的。
有一天她实在绷不住了，问我：“你们天天说自动化自动化，我连 Python 都装不上，能不能搞？”
我当时愣了一下。说实话，过去我骨子里也觉得自动化测试是开发的事，至少你得会写脚本。但那次我决定试试：给她建了个文件夹，里面放了一个 Markdown 文件和几份接口文档，让她用 AI 加载。十分钟后，她拿到了人生第一套完全可运行的自动化测试脚本，纯 Python，她一行没写。
那个文件夹，现在在我所有项目里都有一个备份，名字叫 auto-test-skill。今天我就把这个东西完整拆给你看。不管你是手工测试、产品经理还是运营，只要你稍微会用浏览器，这事儿就能办。
一、别把自动化测试想成非得写代码
先破个心魔。自动化测试的本质不是写代码，而是把重复的验证动作交给机器。过去没得选，必须写脚本；现在有了 AI + Skill，你只需要做你最擅长的事——告诉它你要测什么、怎么判断对错。
你手头一定有这些东西：
接口地址和请求参数（从浏览器 F12 就能扒）
某个功能的操作步骤（你每天点的那些菜单）
判断结果对不对的标准（返回码 200、页面出现“成功”、数据库某个字段更新）
这些就够了。剩下的活，让 AI 替你干。
二、搭骨架：你的测试助理入职文件夹
跟前面几篇讲的一样，Skill 就是一个文件夹里面放 SKILL.md。这次我们专为自动化测试定制。
在你电脑上建个文件夹叫 auto-test-assistant，里面新建 SKILL.md，抄下面这个模板（直接粘贴）：
name: auto-test-assistant
description: 为不懂代码的测试人员生成可执行的自动化测试脚本，基于提供的接口文档和场景描述
角色
你是一名资深测试开发工程师，精通 Python + pytest + requests 接口自动化测试。
你的服务对象是不懂编程的手工测试人员，你需要根据他们提供的接口文档或操作描述，生成可直接运行的自动化测试脚本。
工作守则
- 所有生成的脚本必须完整可运行，包含必要的 import 和 if name == "main" 入口。
- 每个测试用例必须包含清晰的断言，断言条件由用户指定或从预期结果推导。
- 脚本中必须包含详细的注释，解释每一步在做什么，让不懂代码的人也能大概看懂。
- 如果涉及接口依赖（如先登录获取 token），必须自动处理该依赖，并处理 token 过期等异常情况。
- 输出格式：一个完整的 .py 文件代码块 + 运行说明（安装依赖、执行命令）。
- 严禁使用未在项目中明确声明的第三方库，默认仅使用 requests 和 pytest。
保存。现在你的“自动化测试助理”已经入职了，虽然还只是个空架子。
三、喂资料：你给他什么，他就测成什么样
这个助理现在还瞎着，你得给他对接项目。在 auto-test-assistant 文件夹里建个子目录叫 references，把你能收集到的任何资料扔进去：
接口文档：有 Swagger JSON 最好，没有就把你平时用到的接口一个个从浏览器 Network 里复制请求 URL、方法、参数示例，整理成 Markdown 表格。哪怕手写几行都行，比没有强一万倍。
数据库表结构：如果验证要查库，导出一份表字段说明。
测试数据：比如测试账号、密码、常用参数值，注意脱敏。
你的测试步骤脑图：哪怕就是“1.登录 2.创建订单 3.查询订单 4.取消”这种流水账，也扔进去。
测试妹子当年给我的就三样：一张写了四个接口地址和参数的纸、一个测试账号、一句“登录后返回的 token 要放到后面接口的 Header 里”。就这些，没了。
我把它们扫成三个 Markdown 文件扔进 references/，然后修改 SKILL.md，在最下面加了一段：
项目背景
请务必先阅读 references/ 目录下的所有文件，这是当前被测系统的全部资料。
所有测试脚本必须基于这些真实接口和数据生成，严禁编造接口路径或参数。
加这一句的目的是锁死边界。不然 AI 会自己脑补接口，你拿到的脚本跑不起来。
四、开干：一句话，生成你的第一套自动化脚本
把整个文件夹拖进 Claude（或者你的 AI 工具的 Skill 加载入口），加载成功后，在对话框里输入：
根据 references 里的接口文档，帮我生成一套完整的回归测试脚本，覆盖这四个接口的正常场景和常见异常场景（参数缺失、token 过期）。测试步骤是先调用登录接口获取 token，然后依次测试创建、查询、取消订单接口。生成的脚本我能在本地用 python 直接跑。
30 秒后，它吐出一个 .py 文件，里面大概长这样：
import requests
import pytest
BASE_URL = "http://xxx.com/api"
TEST_USER = {"username": "test1", "password": "123456"}
def get_token():
"""登录获取 token"""
resp = requests.post(f"{BASE_URL}/login", json=TEST_USER)
assert resp.status_code == 200
return resp.json()["data"]["token"]
def test_create_order():
"""正向创建订单"""
token = get_token()
headers = {"Authorization": f"Bearer {token}"}
payload = {"productId": 1001, "quantity": 1}
resp = requests.post(f"{BASE_URL}/orders", json=payload, headers=headers)
assert resp.status_code == 200
assert resp.json()["code"] == 0
def test_create_order_missing_param():
"""缺少必填参数"""
token = get_token()
headers = {"Authorization": f"Bearer {token}"}
payload = {} # 空参数
resp = requests.post(f"{BASE_URL}/orders", json=payload, headers=headers)
assert resp.status_code == 400
assert"参数错误"in resp.json()["msg"]
旁边还贴心地附上了运行命令：pip install requests pytest && pytest test_api.py -v。
测试妹子把文件存成 test.py，装上 Python（我帮她装好的），在命令行里敲下那行命令，屏幕上绿油油的一片 pass，她差点在工位上蹦起来。
你一句代码没写。你只是把你脑子里知道的测试场景，用人话告诉了它。
五、不想装 Python 环境？连这步都可以省
后来我觉得让她装环境还是麻烦，就改了 Skill 的输出规则，让它直接生成可导入的 Postman Collection JSON 文件。
在 SKILL.md 里增加一条输出规则：
- 如果用户要求生成 Postman 格式，输出完整的 collection v2.1 JSON 代码，用户可直接导入 Postman 运行。
然后提问：
把刚才那套测试用例，输出成 Postman Collection，要求包含环境变量 BASE_URL 和 token 自动提取脚本。
AI 立刻甩出一个 JSON，她复制粘贴到 Postman 里，点一下 Run，连命令行都省了。那会儿我才彻底意识到：工具链从来不是障碍，障碍是你觉得非得懂工具链才能做自动化。
六、这玩意儿到底能替代多少工作量？
数据中台项目结束后我复盘过一次：我们那套“登录-建单-审批-推送”回归用例，总共 42 个场景。她手工跑一轮要 2.5 小时，每天至少一轮。用 AI 生成的脚本跑完，48 秒。
她后来把节省出来的时间，拿去做了探索性测试，在报表导出功能里挖出三个隐藏很深的边界 Bug，搁以前根本没人有空去点那些犄角旮旯的按钮。
所以别听信什么“无代码自动化是伪命题”这种话。对大部分业务系统来说，你缺的不是会写 Selenium 的人，缺的是一个能把你测试经验转化成可执行脚本的翻译官。 现在这个翻译官就是 AI + Skill，而且翻译得还越来越靠谱。
七、让你助理聪明起来的三个调教心法
当然，这助理不是一开始就听话。我们磨合期踩过的坑，值得你现在就避开：
① 输入必须带预期结果，否则断言全瞎。
很多人就扔一句“帮我测创建订单接口”，AI 就会只校验状态码 200，其他啥也不管。你必须把判断条件说清楚：“创建成功后返回的 code 字段为 0，data 里必须包含 orderId 且不为空，同时数据库 order 表对应记录状态为 NEW。” 提示词越细，脚本的断言越狠。
② 把环境信息写死进 references，别让 AI 猜。
域名、账号、token 获取方式、超时时间、重试次数，这些环境级的信息一律写在一个 env.md 里，在 SKILL.md 中强制引用。否则生成的脚本里基础 URL 是 localhost，你又要改半天。
③ 第一版脚本跑不通是正常的，把报错扔回去。
脚本生成后第一次运行大概率会碰到一两个小问题，比如字段名大小写不对、返回结构跟文档不一致。别怕，把控制台的报错信息直接复制粘贴给 AI，加一句“根据这个错误修改脚本”。它自己会定位修复。那个测试妹子后来学会这招，来来回回改了三轮，脚本就稳定了。她甚至总结了一句：“AI 写的代码我改不了，但我能让 AI 自己改。”
写在最后
那个数据中台项目交付后，测试妹子请我喝了杯奶茶，说了一句特别扎心的话：“原来你们开发每天在玩的那些东西，也没那么神嘛。”
我说对，其实技术这行，大部分壁垒不是知识，是包装。今天我把这层包装拆了，告诉你怎么用。你不需要学写代码，你只需要学会把你的测试脑子，装进一个文件夹里。
现在就动手。打开你的电脑，新建文件夹，把这篇教程里的模板贴进去，然后找一张你最近跑回归时用的接口列表，扔进 references/。加载 Skill，对你最讨厌的那个重复性测试用例说一句人话。
让你助理跑断腿，你把时间留给自己。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
