上个月和几个大厂的测试负责人聊，发现一个共性焦虑：团队里每个人都在写差不多的脚本。登录写一遍，鉴权写一遍，数据初始化写一遍。换个项目，再来一遍。
半年后，脚本库膨胀到几百个，但真正能复用的没几个。
这不是某个人的问题，是整个行业在经历了自动化普及之后，集体撞上的墙——技能无法跨场景复用。
更麻烦的是，最近AI生成用例的能力越来越强。有人开始焦虑：写脚本这件事，是不是很快就不值钱了？
我的判断恰恰相反。不值钱的，是那些重复的低层脚本。真正有价值的，是把测试能力抽象成可组合、可复用的技能资产。
这篇文章不讲大道理，直接说我过去一年在一线落地的一套方案：测试技能仓库（Skills Repository）。
目录
一、现象的真相：不是脚本不够多，是技能没有仓库
二、本质变化：从“脚本驱动”到“技能驱动”
三、核心机制拆解：技能的定义、注册、组合与执行
四、典型案例对比：同样一个下单流程，两个团队的区别
五、工程落地启示：你现在就可以开始的四步走
六、一个实际的问题留给你
一、现象的真相：不是脚本不够多，是技能没有仓库
先看一个真实场景。
某业务线需要回归核心交易流程。A工程师花两天写了一套脚本，能跑通。两周后，B工程师要做类似的冒烟测试，他没找到A的脚本，或者找到了但看不懂，或者看懂了但依赖环境不一样，总之他重新写了一套。
C工程师来了，需要做压力测试的前置数据准备。他又写了一套数据构造脚本。
三个人的工作，本质上都在做三件事：登录、鉴权、造数据。
但没有人能直接复用。
这不是懒，也不是不共享。根本原因是：我们的自动化体系里没有“技能”这个抽象层。
什么是技能？一个独立的、可描述的、可执行的测试能力单元。比如“用手机号+验证码登录”、“生成一个已支付状态的订单”、“构造一个超过库存的商品快照”。
现在的脚本库，要么是一个完整的端到端用例，太臃肿没法拆；要么是一堆工具函数，太零散没法组合。
本质是：我们一直在囤积“用例”，而不是沉淀“能力”。
二、本质变化：从“脚本驱动”到“技能驱动”
这个差异不是词面上的，是工程架构层面的一次重构。
脚本驱动的思维是：我要测什么，就写什么。今天测登录，写登录脚本。明天测下单，写下单脚本。看起来直接，但每一个新需求都是在重复造轮子。
技能驱动的思维是：我先问自己，这个测试场景由哪些基础技能组成。登录是一个技能，选择商品是一个技能，提交订单是一个技能，支付是一个技能。然后我去技能仓库里找，有的直接用，没有的才去开发。
开发完一个新技能，不是用一次就扔，而是回收到仓库里，供后续所有场景复用。
这就变成了一个正向积累的过程。
核心在于：测试开发的工作对象，从“用例”变成了“技能”。
用例永远在变，但技能相对稳定。任何一个业务系统的登录逻辑，再复杂也就是那几种方式。订单状态的流转，再复杂也有边界。
当你把精力花在打磨这些稳定技能上，你会发现两个变化：
第一，新用例的编写时间从小时级降到分钟级。因为你在做组合，而不是从头写。
第二，跨项目复用的可能性大幅提升。技能和具体业务解耦之后，换个系统，只要接口协议相似，技能可以直接迁移。
三、核心机制拆解：技能的定义、注册、组合与执行
先给一张整体架构图，后面逐层拆。
3.1 技能的定义：到底什么算一个技能
不是所有函数都能叫技能。我们的技能定义包含四个要素：
输入契约：调用这个技能需要什么参数。比如“手机号登录”技能，需要手机号和验证码（或密码）。
输出契约：执行完返回什么。登录成功返回token和用户信息，失败返回错误码。
执行逻辑：具体的操作步骤。调用哪个接口，参数如何组装，重试策略是什么。
环境声明：这个技能依赖什么环境。需要数据库吗？需要Redis吗？需要mock某个外部服务吗？
有了这四个要素，一个技能才是可独立使用的。
3.2 注册机制：让技能能被找到
我们设计了一个轻量级的注册表，不是中心化的服务，而是一个基于文件加约定的方式。
每个技能对应一个YAML文件加一个Python（或Java）类。
YAML描述元数据：技能名称、版本、作者、输入输出格式、依赖标签。
Python类实现具体逻辑。
仓库启动时，扫描所有技能目录，构建一个内存中的索引。提供按标签、按输入输出类型、按关键词的检索能力。
为什么不用中心化服务？ 因为测试环境太复杂了。不同项目可能跑在不同的CI集群、不同的隔离环境。中心化注册表会变成一个单点和维护负担。文件加约定的方式，配合git仓库分发，足够简单，且天然支持分支隔离。
3.3 组合机制：技能如何拼成用例
这是最核心的工程点。我们不要求一个技能解决所有问题，而是让技能可以任意组合。
实现方式是技能编排器，本质是一个有向无环图执行器。
声明一个用例：登录技能 -> 加入购物车技能 -> 提交订单技能 -> 支付技能。
编排器负责：参数传递（前一个技能的输出作为后一个技能的输入）、失败处理（重试、跳过、终止）、并发控制、超时管理。
关键设计是：技能之间的耦合只通过输入输出契约，不共享任何全局状态。
这意味着登录技能返回的token，不是存在某个全局变量里，而是显式地作为参数传递给下单技能。
这种做法一开始会有点啰嗦，但长期来看，它让每个技能都可以独立测试、独立升级、独立替换。
3.4 执行闭环：跑完不是终点
技能仓库的价值不在存储，在执行后的反馈。
每个技能执行后，我们记录：执行时间、成功率、输入输出的具体值、失败时的完整上下文。
这些数据汇聚后，能做两件事：
第一，自动发现退化技能。某个技能成功率突然下降，说明被测系统对应功能可能出了问题，或者技能本身需要维护。
第二，生成技能的“健康分”。分数低的技能在执行时会收到警告，提醒使用者“这个技能最近不太稳定”。
没有反馈闭环的技能仓库，最终都会变成垃圾堆。
四、典型案例对比：同样一个下单流程，两个团队的区别
说理论可能不够直观，看一个真实对比。
两个团队同时接到一个任务：为新的优惠券系统做回归测试，需要覆盖领券、用券、退券后重新用券的场景。
团队A（脚本驱动）：
第三天，第一个用例写完了，能跑通领券+用券。
第五天，第二个用例写完了，覆盖退券。
第七天，发现退券后重新用券的逻辑和之前的用例有冲突，因为脚本里硬编码了订单状态。
第八天，花半天重构了第一个脚本。
第十天，交付了三个松散的脚本，互相之间没有复用。
团队B（技能驱动）：
第一天，去技能仓库检索。发现已经有“领券”、“查询优惠券”、“创建订单”三个技能。没有“退券”技能。
第二天，开发“退券”技能，耗时半天，测试并入库。
第三天，开始写用例。每个用例就是一份技能编排的YAML配置。
第四天，交付了六个用例，覆盖了所有边界场景。
第五天，需求变更，优惠券逻辑调整。只需要修改“领券”和“退券”两个技能的实现，六个用例一个不动，全部通过。
观点句：一次调试，到处运行——这才是工程化的起点。
差距在哪里？不是谁更勤奋，是谁的架构允许积累。
团队A的脚本里，技能和用例是绑死的。团队B的技能和用例是分离的，用例只是技能的排列组合。
五、工程落地启示：你现在就可以开始的四步走
不要一上来就想着做一个完美的仓库。会烂尾。
真实落地的路径是这样的：
第一步：先识别高频技能
拿最近一个月写的所有自动化脚本，统计一下前三频繁出现的操作是什么。大概率是登录、数据清理、环境初始化。
把这几个抽出来，先做成独立技能。不用管什么输入输出契约，先让它能被单独调用。
第二步：约定技能输入输出
这一步最难，但不是技术上的，是习惯上的。
强制要求：任何一个技能，不能读取全局变量，不能依赖外部文件路径，不能假设某个前置脚本已经跑过。
所有输入必须从参数来，所有输出必须显式返回。
这个约定比任何框架都重要。
第三步：建立最小编排能力
哪怕只是一个函数，能按顺序执行技能列表，并自动传递前一个的输出到后一个的输入。
不需要DAG，不需要并发，先让串行编排跑起来。
观点句：测试的核心竞争力不是写脚本，而是沉淀可复用的技能。
第四步：加一层反馈
最简单的方式：每个技能执行后，把结果写到一个日志文件里。每周跑一次统计，看看哪些技能失败率高，哪些技能从来没人用。
前者需要修复，后者可以考虑删除。
六、一个实际的问题留给你
技能仓库听起来不复杂，但我在落地过程中观察到，大多数团队不是因为技术做不到而失败，而是因为一个更根本的问题：
他们从来没有定义过，到底什么是“一个技能”。
有人把登录拆成了三个技能，有人把整个下单流程打包成一个技能。太细了没法用，太粗了没法组合。
这个问题没有标准答案，取决于你的业务稳定性和团队规模。
但我想问你的是：
你现在的测试资产里，那些反复被使用的能力，是显式地以“技能”的形式存在，还是散落在几十个脚本里，每次都要重新“考古”才知道怎么用？
如果你需要花超过十分钟才能回答这个问题，那可能你已经知道下一步该做什么了。
