1. 从“会用AI”到“用AI干活”：测试Skill到底解决了什么问题

很多人对AI测试的理解还停留在“让大模型帮我写一段pytest脚本”这个层面。写完之后复制粘贴，跑一遍，报错了再贴回去让它改。这个流程本身没问题，但它有个致命缺陷：每次都要重新描述上下文。你上周刚跟它讲清楚项目的目录结构、接口签名、鉴权方式，这周开个新对话，它全忘了。

Skill这个东西，本质上就是把“你反复跟AI说的那套话”固化下来，变成一个可复用、可组合、可版本管理的能力单元。你可以把它理解成给AI写的“岗位操作手册”——不是提示词模板那种一次性消耗品，而是带触发条件、带执行逻辑、带输出规范的完整工作流。

我日常在用的这25个Skill，覆盖了从接口测试、UI自动化、性能压测、数据构造到缺陷分析的全链路。它们不是那种“看起来很酷但跑一次就吃灰”的玩具，而是真正嵌入了我每天工作流的工具。有些Skill只有十几行配置，有些则包含完整的脚本编排和断言逻辑。接下来我会按使用频率和场景价值，把最核心的那些拆开讲清楚。

注意：Skill的质量不取决于它有多复杂，而取决于它是否精准命中了你工作流中某个高频、重复、容易出错的环节。一个只做“把JSON响应转成表格”的Skill，可能比一个“全自动生成测试报告”的Skill更有价值，因为前者你每天用二十次，后者你一周用一次。

2. 接口测试类Skill：让AI真正理解你的API契约

2.1 接口用例生成Skill：从Swagger文档到可执行脚本

这个Skill是我用得最频繁的一个。输入是一份OpenAPI/Swagger的JSON或YAML文件，输出是一套完整的pytest测试用例，包含正常场景、边界值、异常参数组合。

核心逻辑不是让AI“随便写几个用例”，而是让它按照一套固定的分析框架来拆解接口。我的Skill配置里嵌入了这样一段指令：

对于每个接口，按以下维度生成用例： 1. 必填参数缺失（逐个缺失，不是一次性全删） 2. 参数类型错误（字符串传数字、数组传对象） 3. 边界值（数值型取min-1、min、max、max+1） 4. 业务约束（如状态字段只接受特定枚举值） 5. 鉴权异常（无token、过期token、越权token）

为什么要这样设计？因为大多数人在让AI写用例时，得到的往往是“正常请求+一个错误请求”这种敷衍的结果。而实际项目中，参数缺失的组合爆炸才是最容易漏测的地方。通过Skill固化分析维度，每次生成的用例覆盖率能稳定在85%以上，剩下的15%靠人工补充业务特有的逻辑分支。

实测下来，一个中等复杂度的REST接口（约8个参数），这个Skill能在40秒内生成约35条用例，其中约30条可以直接运行。剩下5条需要微调，通常是因为接口有自定义的加密签名逻辑，AI无法从文档中推断出签名算法。

2.2 响应断言Skill：不只是status_code == 200

很多人写接口测试，断言就写一个assert response.status_code == 200。这等于没测。我的断言Skill会做三层校验：

• 结构校验：用JSON Schema验证响应体的字段类型、必填项、嵌套结构
• 业务校验：关键字段的值域范围、枚举合法性、关联字段的一致性
• 性能校验：响应时间是否超过阈值（比如P95 < 500ms）

这个Skill的配置里有一个关键设计：它会把接口文档中的example response作为基准，自动生成JSON Schema。你不需要手写Schema，AI会根据示例推断出合理的类型约束。当然，推断结果需要人工review一遍，特别是那些值为null的字段——AI有时会错误地把它标记为“必填但可为null”，而实际上业务上它可能是“非必填”。

实操心得：断言Skill一定要配置“软断言”模式。也就是说，当某个非核心字段校验失败时，记录警告但不要中断测试。否则一个无关紧要的字段类型变化会导致整个测试套件红掉，久而久之你就懒得看报告了。

2.3 接口依赖链Skill：处理登录态和上下文传递

这是接口测试中最烦人的部分。你要测一个“创建订单”接口，但必须先登录拿token，再查商品列表拿商品ID，最后才能调创建订单。传统做法是在conftest.py里写一堆fixture，但每次新增接口都要改fixture，维护成本很高。

我的依赖链Skill采用了一种“声明式”的思路。你只需要在测试用例的注释里写明依赖关系：

# @depends: login -> get_product_list -> create_order def test_create_order(): ...

Skill会自动解析这个依赖链，按顺序执行前置接口，并把需要的上下文变量（token、product_id等）注入到当前测试的上下文中。它的核心是一套变量提取规则：从登录接口的响应中提取data.token，从商品列表接口中提取data.items[0].id，然后以{{token}}和{{product_id}}的形式在后续请求中引用。

这套机制的好处是，当接口签名变化时，你只需要改依赖声明和提取规则，不需要动测试逻辑本身。我统计过，使用这个Skill后，接口测试的维护时间减少了约60%。

3. UI自动化类Skill：让AI帮你写“不会崩”的脚本

3.1 元素定位Skill：从“绝对路径”到“语义定位”

UI自动化最大的痛点不是写脚本，而是脚本今天能跑明天就崩。崩的原因90%是元素定位失效——开发改了个class名、调了个DOM结构，你的XPath就废了。

我的元素定位Skill强制使用“语义定位”策略。它不会生成那种//div[@class='el-form-item__content']/input[2]这种脆弱的选择器，而是优先使用：

• >user: name: "测试用户_{random_string(6)}" phone: "138{random_digits(8)}" email: "{random_string(8)}@test.com"

  Skill会根据模板生成数据，并自动处理唯一性约束。比如手机号不能重复，它会维护一个已生成号码的集合，确保每次生成的号码都是新的。

  更关键的是，这个Skill支持“数据清理”配置。每个测试用例执行完毕后，它会根据你定义的清理规则（比如调用删除接口、执行SQL删除）把数据清理掉。这样测试环境不会越跑越脏。

  4.2 Mock服务Skill：当依赖接口还没开发完

  前后端并行开发时，前端经常要等后端接口。这时候Mock服务就派上用场了。我的Mock Skill可以根据接口文档自动生成Mock服务，支持：

  • 根据Schema生成随机响应数据
  • 配置特定场景的响应（如返回错误码、返回空数据、返回超时）
  • 记录请求日志，方便调试

  这个Skill的一个亮点是场景切换。你可以通过一个特殊的请求头（如X-Mock-Scenario: error_500）来触发不同的Mock响应，而不需要重启服务。这在测试前端的错误处理逻辑时特别方便。

  4.3 数据库断言Skill：绕过接口直接验证数据

  有些测试场景，通过接口断言不够直接。比如“创建订单后，库存应该扣减”，你调接口查库存当然可以，但更可靠的方式是直接查数据库。

  我的数据库断言Skill支持在测试用例中嵌入SQL查询，并把查询结果与预期值进行比对。它会自动处理数据库连接池、事务回滚（对于写操作）、结果集转换等细节。

  # @db_assert: SELECT stock FROM products WHERE id = {{product_id}} == 99 def test_stock_deduction(): ...

  这个Skill的配置里有一个安全开关：默认只允许SELECT查询。如果需要执行UPDATE/DELETE，必须显式开启，并且会自动包裹在事务中，测试结束后回滚。这是为了防止误操作污染测试数据。

  5. 性能与稳定性类Skill：从“能跑”到“跑得稳”

  5.1 压测脚本生成Skill：从接口用例到Locust脚本

  性能测试的门槛在于脚本编写。JMeter的GUI虽然直观，但维护复杂场景时很痛苦；Locust用Python写脚本灵活，但很多人不熟悉它的API。

  我的压测脚本Skill可以直接把接口测试用例转换成Locust脚本。你只需要在接口用例上标注@load_test(users=100, spawn_rate=10, duration='5m')，Skill就会生成对应的Locust任务。

  它还会自动处理一些性能测试特有的逻辑：

  • 登录只执行一次，token在虚拟用户间共享
  • 参数化数据从CSV文件读取，避免所有用户用同一份数据
  • 添加思考时间（think time），模拟真实用户行为

  5.2 稳定性巡检Skill：7x24小时的“测试哨兵”

  这个Skill严格来说不是一个测试执行工具，而是一个定时巡检机器人。它会按照你配置的周期（比如每30分钟），自动运行核心接口的冒烟测试，并把结果推送到你的工作群。

  它的核心价值在于“早发现”。很多问题是在开发提交代码后几分钟内引入的，如果等到第二天上班才发现，修复成本会高很多。巡检Skill能在问题引入后30分钟内发出告警，并附上失败详情和最近一次成功的对比。

  配置上，我建议巡检用例只覆盖最核心的10-20个接口，执行时间控制在2分钟以内。太重的巡检会影响测试环境稳定性，太轻的又覆盖不到关键路径。

  5.3 日志分析Skill：从海量日志中捞出“真问题”

  测试失败时，日志往往有几千行。人工翻找效率极低。我的日志分析Skill会做三件事：

  1. 错误聚类：把相似的错误信息归为一类，避免同一个问题重复出现几十次
  2. 根因提取：从堆栈信息中定位到最底层的异常原因，而不是被上层的包装异常迷惑
  3. 关联分析：把日志中的请求ID与接口测试的请求记录关联起来，还原完整的调用链路

  这个Skill我通常配合CI使用。每次流水线失败时，它会自动生成一份“失败摘要”，包含错误分类、影响范围、建议排查方向。这份摘要直接贴到群里，开发同学一看就知道是不是自己的问题。

  6. 那些“用了就回不去”的辅助Skill

  6.1 测试报告生成Skill：从数据到洞察

  pytest-html生成的报告只是把结果罗列出来，缺乏洞察。我的报告Skill会做额外的分析：

  • 通过率趋势（对比最近5次执行）
  • 失败用例的分布（按模块、按错误类型）
  • 执行耗时TOP10的用例（找出性能瓶颈）
  • 不稳定用例识别（最近10次执行中，有时通过有时失败的用例）

  这些分析结果会以表格和简单图表的形式嵌入报告。特别是“不稳定用例”这个指标，能帮你快速定位那些“看起来通过了但随时可能崩”的测试，优先修复它们。

  6.2 用例评审Skill：AI帮你做Code Review

  写完测试用例后，我会用这个Skill做一次自动评审。它会检查：

  • 断言是否充分（有没有只断言status_code的）
  • 用例是否独立（有没有依赖其他用例执行顺序的）
  • 数据清理是否完整（有没有造了数据不删的）
  • 命名是否规范（有没有test_1、test_2这种）

  评审结果会以注释的形式标注在代码旁，方便修改。这个Skill帮我发现了不少“自己写的时候觉得没问题，但实际上是坏味道”的用例。

  6.3 环境检查Skill：测试执行前的“体检”

  测试跑失败，有时候不是代码问题，而是环境问题——数据库连不上、依赖服务挂了、磁盘满了。环境检查Skill会在测试套件执行前，快速检查关键依赖的可用性：

  • 数据库连接是否正常
  • 核心接口是否返回200
  • 测试账号是否有效
  • 必要的测试数据是否存在

  如果检查不通过，直接终止执行并给出明确的错误提示，而不是让测试跑一半才报一堆莫名其妙的错。这个Skill至少帮我节省了30%的“无效排查时间”。

  7. 关于Skill组合与编排的一些经验

  单个Skill再强，也只是解决一个点的问题。真正的效率提升来自于Skill的组合。我通常会把几个Skill串成一条流水线：

  比如“新接口测试”这个场景，我会这样编排：

  1. 接口用例生成Skill：从Swagger生成基础用例
  2. 数据工厂Skill：为用例准备测试数据
  3. 接口依赖链Skill：处理登录和上下文传递
  4. 响应断言Skill：执行三层校验
  5. 日志分析Skill：失败时自动分析原因
  6. 报告生成Skill：输出带洞察的报告

  这条流水线跑下来，一个新接口从文档到可执行测试，大约需要5-8分钟。其中人工介入的时间不超过2分钟（主要是review生成的用例和调整数据模板）。

  实操心得：Skill编排不要追求“全自动”。有些环节人工介入反而更快，比如用例的业务逻辑校验、测试数据的合理性判断。把AI擅长的事（生成、转换、分析）交给Skill，把需要业务判断的事留给自己。

  另外，Skill的版本管理很重要。我会把每个Skill的配置文件放在Git仓库里，每次调整都提交commit。这样当某个Skill的表现突然变差时，可以快速回滚到上一个版本。我吃过亏——有一次改了一个断言Skill的配置，导致一批用例的断言被弱化了，跑了一周才发现。从那以后，所有Skill的变更都必须经过一次完整的回归测试才能合并。

  8. 踩过的坑与避坑指南

  8.1 不要过度依赖AI生成的断言

  AI生成的断言有时候会“过于宽松”。比如你期望返回一个列表，AI可能只断言“返回的是列表类型”，而不检查列表长度和元素内容。我早期的做法是直接使用AI生成的断言，结果漏掉了好几个“返回空列表”的bug。

  现在的做法是：AI生成断言后，我会手动补充关键字段的精确断言。特别是那些业务上重要的字段（金额、状态、数量），必须用==而不是in或is not None。

  8.2 Skill的“上下文窗口”陷阱

  有些Skill需要把大量上下文（比如整个项目的接口文档）塞给AI。但大模型的上下文窗口是有限的，塞太多会导致“中间遗忘”——它记住了开头和结尾，中间的内容被忽略了。

  我的应对策略是分而治之。不要一次性让Skill处理整个项目的文档，而是按模块拆分。每个Skill调用只处理一个模块的接口，处理完再处理下一个。虽然调用次数多了，但每次的质量更稳定。

  8.3 测试环境的“脏数据”问题

  数据工厂Skill虽然好用，但如果清理逻辑没配好，测试环境会迅速被脏数据淹没。我曾经遇到过一个情况：数据工厂每天生成几千条测试订单，但清理逻辑只删除了主表记录，关联的明细表没删。一个月后，明细表膨胀到几百万行，查询慢到无法忍受。

  现在的做法是：每个数据工厂Skill都必须配置级联清理规则，并且每周做一次全量数据审计，确保没有孤儿数据。

  8.4 不要忽视Skill的“冷启动”成本

  一个新Skill从配置到稳定使用，通常需要1-2周的调优期。这期间你会遇到各种边界情况，需要不断调整配置。很多人在这期间就放弃了，觉得“还不如手动写”。

  我的建议是：从最简单的Skill开始。先做一个“把JSON转成表格”的Skill，用顺了再做“生成测试用例”这种复杂的。循序渐进，让肌肉记忆和信任感慢慢建立起来。

  9. 关于AI测试Skill的一些个人体会

  用了大半年这些Skill，最大的感受不是“AI替我写了多少代码”，而是它帮我建立了一套标准化的测试工作流。以前写测试用例，每个人的风格不一样，断言粒度不一样，数据清理方式不一样。现在通过Skill把这些规范固化下来，整个团队的测试代码质量都上了一个台阶。

  另一个体会是：Skill的价值会随着使用时间增长而增长。刚开始你可能只有三五个Skill，觉得提升有限。但当你有二十几个Skill，并且它们之间可以互相调用、组合时，效率提升是指数级的。就像搭积木一样，单个积木很简单，但组合起来能搭出很复杂的东西。

  最后分享一个小技巧：我会定期（大概每个月）回顾一次所有Skill的使用情况，把那些“一个月都没用过一次”的Skill归档掉。Skill不是越多越好，保持精简、高频、高质量，才能真正融入工作流。那些偶尔才用一次的Skill，需要的时候临时配一个就行，没必要长期维护。