开源通用测试Skills框架，支持Web/App/接口统一调用

下面拆解三个核心机制。

机制一：Skill定义规范——让每个技能具备自描述能力

一个Skill的最小定义，简单来说就是注册一个函数，例如@register_skill("click")。但这还不够，因为每个底层驱动的API各不相同。因此，真正的Skill实现是一个适配器：技能内部知道当前driver的具体类型，自行完成适配，调用方完全无需关心底层差异。

机制二：注册中心——技能的统一市场

所有技能在启动时注册到中心，注册表维护一个字典：skill_name -> SkillClass。调度器收到调用请求后，前往注册表查找对应技能，实例化后调用execute方法。这样做的好处显而易见：新增技能无需修改调度器代码，团队可以共享技能库，例如通用的login_with_retry、wait_for_toast等。

机制三：动态调度——一套DSL驱动所有终端

调度器支持两种输入方式：YAML/JSON序列（适用于关键字驱动）和Python链式调用（适用于代码风格）。一个YAML用例可以描述完整流程，例如导航、点击、等待、发送请求、断言。这个用例既可以在Web环境中运行，也可以在纯接口环境中运行。调度器会根据当前注册的技能集合，自动跳过不可用的技能（例如click在接口环境中会自动跳过并发出警告）。

核心设计哲学非常清晰：技能是原子能力，用例是技能的有序组合。底层驱动可以更换，技能可以增删，但用例结构始终保持不变。

四、典型案例对比：同一场景，三种终端，一套写法

以“登录并校验”这个场景为例。传统方式下，Web端、App端、接口端需要三套完全不同的代码，API各不相同，维护成本极高。而在Skills框架下，只需要一套用例：定义一个YAML序列，描述导航、输入、点击、等待、断言等技能。将这个YAML传递给调度器，设置driver_type=web即可运行Web端，设置driver_type=app即可运行App端，设置driver_type=api则框架会自动将不适合接口环境的技能转换为HTTP请求（前提是实现了对应的映射）。

当然，接口环境通常不需要填写表单，我们一般会为接口场景单独编写一个更简洁的技能序列。但关键在于：测试人员无需记住三套API，只需要记住技能名称和参数。这才是实现降本增效的正确路径。

五、工程落地启示：你的测试资产不应绑定在特定工具上

这款框架在三个团队落地后，我总结出三条最直接的经验。

启示一：将现有测试脚本拆分为“技能库”和“用例层”

不要一次性重写所有用例。先从最常用的10个操作入手，将其注册为技能，然后通过技能调用来重构用例。三个月后，你的用例文件将减少70%的重复代码。

启示二：技能可以跨项目共享

框架内置了一个远程技能仓库。团队A开发的captcha_solver技能，团队B可以直接拉取使用，无需复制代码，也无需了解内部实现。这对于中大型团队的价值尤为突出：你不再需要为每个项目配备一名“自动化专家”。

启示三：新人培训周期从两周压缩到两天

新人只需要掌握技能列表和YAML写法，无需先学习Playwright API、再学习Appium、再学习Requests。他们可以在入职第一天就写出可运行的用例，第二天就能理解技能背后的工作原理。

对于在校学生而言，现在不需要纠结“学Web自动化还是App自动化”，而应该学习“如何抽象测试技能”，这个能力在任何终端都通用。对于初级工程师来说，尝试将平时编写的Playwright脚本重构为技能加用例的形式，你会发现自己正在从“写代码的人”转变为“设计框架的人”。对于中级工程师而言，这个框架展示了如何利用“注册中心+适配器”模式解耦测试工具，你可以将其推广到团队，或者自己实现一个更轻量的版本。

六、问你的团队一个问题

去你们团队的自动化代码仓库里，随便找一个跨端场景——比如用户从注册到下单。统计一下：为了支持Web、App、接口三种环境，你们的代码中重复实现了多少遍“等待元素出现”“输入文本”“点击按钮”？然后问自己：如果明天要替换其中一个底层框架，比如从Playwright切换到Cypress，你需要修改多少处代码？

如果答案是“超过10处”，那么这个框架就值得你花一天时间深入研究。