GitHub 2k星：基于大模型+Skills的自动化测试生成器，自然语言一键执行

凌晨两点的版本还在跑，某互联网大厂测试组的负责人看着屏幕上刚跑完的5000条自动化脚本报错清单发呆。

这不是虚构场景。当大模型可以生成代码、调试日志甚至重构全栈应用时，测试领域正在经历一个前所未有的阶段——不是AI能不能写测试代码，而是我们是否找到了正确的范式来教它 "一个系统到底该怎么测" 。

目录

• 一、组合爆炸与维护债务：自动化测试的隐性天花板
• 二、本质变化：从"执行指令"到"理解意图"
• 三、核心机制拆解：当Skills成为大模型的"操作手册"
• 四、一个真实的落地案例
• 五、对你意味着什么
• 六、留给你的一个问题

一、组合爆炸与维护债务：自动化测试的隐性天花板

先看一组数据。

一个中等复杂的电商业务：3种登录方式 × 4种商品类型 × 3种支付渠道 = 36种路径组合。传统做法是每个组合写一个脚本。36个脚本，每个脚本里80%是重复代码。这是典型的组合爆炸问题。

更致命的是变更蔓延。登录接口status字段从数字改成了字符串枚举，36个脚本全部失效。你一个一个改完，下个月支付接口改了，再来一轮。新人接手老模块时，需要两周才能摸清几十个文件里的前置依赖关系。

这种模式的本质问题是：业务流程的"骨架"和"血肉"混在一起写了。骨架是步骤之间的顺序与数据依赖，血肉是每个步骤的入参格式和校验规则。在传统脚本里，这两者是紧耦合的。这就是为什么写得越多，维护越累，缺陷发现率却没有提升。

二、本质变化：从"执行指令"到"理解意图"

Skills模式带来的转变，是测试范式的本质变化。

传统模式下，测试工程师的角色是"翻译官"——把业务需求翻译成机器可执行的步骤序列。入参写死、断言硬编码、调用链硬编码。

Skills模式下，工程师的角色变成了**"定义规则和边界"**。告诉AI：这个接口的契约是什么、哪些字段有约束、业务规则有哪些例外，然后让AI自己组合出合适的测试行为。

核心是四个字的转变：从"怎么做"到"做什么" 。

你不再写 page.fill('#username', 'admin')，而是说"测试一个已注册用户的登录流程"。Skills负责理解这句话的意图，自动完成：识别测试目标、分析被测系统、选择工具链、生成测试代码并执行。

很多人都以为Skills只是高级的提示词模板。但如果把普通Prompt比作一本"种菜说明书"，Skills就是"说明书+农具+机械臂"的组合包——它封装了具体的执行能力。

三、核心机制拆解：当Skills成为大模型的"操作手册"

技术上，Skills是一组由说明文档、脚本与资源组成的"技能包"，AI在需要时动态加载并执行。

以开源框架OpenClaw为例，其仓库中沉淀了数十个生产级测试Skills，覆盖了用例生成、缺陷发现、智能修复三大环节。比如：

• playwright_test_generator：输入自然语言"测试用户登录流程"，自动生成完整Playwright脚本，且会读取项目中的 pages/ 目录保证符合已有Page Object规范。
• requirements_to_tests：从需求文档中抽取出业务规则和分支条件，输出JSON格式的测试大纲，将需求评审到用例设计的时间从一天缩短到十分钟。
• api_test_generator：基于OpenAPI/Swagger文档，为每个接口自动生成happy path + error path的Pytest测试，确保接口合同变更时测试同步更新。

核心机制：三层渐进式架构

Skills的设计不是简单的指令堆积，背后有一个关键机制——分层加载。以Claude Skill为例，它采用"三层渐进式披露"架构：

第一层：元数据 —— 仅仅暴露Skill的name和description，总计几十个token。AI在启动时扫描所有Skill的元数据，但不加载完整内容。这保证了即使在具有大量Skills的环境中，大模型也不会因为上下文窗口而"思考"过载或遗忘关键上下文。

第二层：核心指令 —— 当AI判断某个Skill与当前任务相关时，加载完整的指令内容——如何拆解任务、有哪些约束边界。

第三层：完整执行资源 —— 在需要时调用脚本、工具和模板，执行具体操作。

这个设计的工程价值在于：低上下文开销 + 高复用性。你可以在Skill里塞几百行的指引和多个脚本文件，完全不用担心撑爆上下文限制。

四、一个真实的落地案例

用一个真实的例子来说明这个过程。

某大厂测试团队上线了一套基于Skills的测试智能体系统，处理Web自动化测试的完整生命周期。架构是这样的：

Agent 1：用例生成器。测试人员用自然语言描述测试意图，例如"测试用户登录后访问个人资料页"，系统结合RAG和Playwright代码模板生成初始测试脚本。

Agent 2：执行与自愈引擎。自动运行测试，当遇到元素定位失败时，触发AI重新分析页面并修复选择器。实测中元素定位失败修复耗时在2秒左右，成功率超过90%。

Agent 3：智能断言与报告分析。捕获执行结果和网络日志，通过LLM比对预期行为，输出结构化报告和代码修改建议。

团队把三个Agent串联到CI流水线，从"需求输入"到"测试通过"完全自动化。最终结果是：200个复杂场景验证，**编写与维护成本降低约60%**。

关键不是降低了多少，而是降低的方式。传统的效率提升往往通过增加脚本量来对冲维护成本，这套方案直接从源头解决了"脚本怎么写、怎么维护、怎么改"的闭环问题。

五、对你意味着什么

对于在校生

别再只看语法入门和基础教程。行业已经进入测试智能体阶段，懂理论会让你入门，但只有理解新的范式才能跟上节奏。测试自动化的门槛正在被Skills大幅拉低，但这是好消息——它意味着你不再需要成为Python或Java专家才能写出有价值的自动化测试。你需要关注的是如何定义测试意图和边界条件。

对于初级测试工程师

你现在的核心差距不是会写多少行脚本，而是是否具备"设计可复用校验能力"的意识。Skills本质上剥离了"意图定义"与"脚本执行"——你的价值点正在从写代码转向设计业务规则和边界条件。

对于中级测试工程师

这套模式解决的是一个根本问题：传统脚本模式下，测试代码本身就是债务。Skills + Agent模式的核心启示是，让测试行为可组合、可复用，而不是用脚本去覆盖无限组合。当接口变更时，你只需要调整契约定义，而不是逐个修改36个脚本。这才是真正的自动化，而不是自动化地制造债务。

六、留给你的一个问题

回到开头的场景。当那条红了的流水线再次出现时，你面临的选择不是修不修脚本——而是：

你现在的测试系统，是否具备一个真正的反馈闭环？

具体来说：当你的自动化测试失败了，系统能不能做到——

• 自动区分失败是业务逻辑错了，还是测试代码过时了？
• 自动分析导致失败的根因并给出修复建议？
• 完成修复后不重新投入人力去验证——而是把这个修复经验回馈到测试生成规则中，形成持续进化的能力？

如果这些都没有，你写的每一行测试代码都将在这个AI驱动的时代变为技术债务而不是安全网。

你是怎么定义系统中的故障信号、让它具备自我进化能力的？欢迎留言聊聊你的做法。