一、测试团队越作念越累，不是东谈主不够，是手段太散

上个月，我帮一个中型电商团队作念手艺评审。

他们有三个测试小组：Web、App、接口。

Web组用Playwright。

App组用Appium。

接口组用Requests + Pytest。

三个组，三套代码仓库，三种定位器写法，三种恭候战术。

新东谈主进来，要先学三套东西。

一个跨端场景（比如从Web下单，App阐明成绩），要三个组各写一遍，再用音讯部队串起来。

他们问我：是不是该裁掉一组东谈主，粗略挽救用某个买卖平台？

我说：问题不在东谈主，在你们的手段莫得挽救概括。

每一端王人在作念类似的事：

点击、输入、赢得文本、恭候要求、发送央求、断言反应。

但每个框架王人用我方的阵势抒发这些“手段”。

Web的“点击”是page.click(locator)，

App的“点击”是element.click，

接口的“央求”是requests.post(url， data)。

实质上，它们王人是“实践一个行为并考据效果”。

但你们的代码里，每一层王人在类似达成转念、重试、日记、断言。

这不是手艺债，这是架构债。

我用了三周时刻，把曩昔几年在多个神气里积存的教学抽出来，作念了一个通用测试Skills框架。

中枢主义很陋劣：

一套手段描摹，同期驱动Web、App、接口。

挽救调用阵势，挽救手段注册，挽救效毅力言。

代码也曾开源。底下讲泄露它如何使命。

二、实质不是缺框架，是缺“挽救调用层”

许多东谈主一听到“挽救框架”，第一反应是再作念一套超等框架，把通盘底层王人包进去。

那是伪善的念念路。

正确的念念路是：不要在底层挽救，要在“手段调用层”挽救。

什么是手段？

手段是一个可定名的、有输入输出、有实践逻辑的最小测试单位。

比如：

click(selector) 是一个手段

input_text(selector， text) 是一个手段

http_get(url) 是一个手段

wait_for_element(selector， timeout) 是一个手段

assert_text_contains(text) 是一个手段

Web端需要这些手段，App端也需要，接口端需要的仅仅其中一部分。

要道在于：

手段的调用方概略和手段背后是Playwright、Appium如故Requests。

它只祥和手段的名字和参数。

这就好比你在写业务代码时调用一个函数，你岂论这个函数是用Go写的如故Python写的。

是以咱们需要的不是挽救的实践引擎，而是挽救的手段注册表 + 动态转念器。

我的框架干的便是这件事。

三、中枢计制拆解：Skill概括 + 注册中心 + 动态转念

先看架构图。

拆解三个中枢计制。

机制一：Skill界说圭表 - 让每个手段自描摹

一个Skill的最小界说：

@register_skill("click")

def skill_click(selector: str，真钱牛牛APP2026世界杯中国官方下载 timeout: int = 5， **context):

"""点击指定元素，复古Web/App挽救selector"""

driver = context["driver"] # 由转念器注入

# driver可能是Playwright的Page，也可能是Appium的WebElement

driver.click(selector， timeout=timeout)

但这么还不够。每个底层驱动的API不同。

是以信得过的Skill达成是一个适配器：

class ClickSkill(BaseSkill):

name = "click"

parameters = {"selector": str， "timeout": int}

def execute(self， params， context):

driver = context["driver"]

if driver.__class__.__name__.startswith("Playwright"):

driver.locator(params["selector"]).click(timeout=params["timeout"])

elif driver.__class__.__name__.startswith("Appium"):

driver.find_element(AppiumBy.XPATH， params["selector"]).click

# 接口层不复古click，调用会报错

要道点： 手段里面知谈面前driver是什么类型，我方作念适配。

调用方十足无须管。

机制二：注册中心 - 手段的市集

通盘手段启动时注册到中心。

注册表休养一个字典：skill_name -> SkillClass。

转念器收到调用央求后，去注册表找手段，KPL王者IOS/安卓通用版/APP下载实例化，调用execute。

平允：

新增手段不需要修改转念器代码。

团队不错分享手段库，比如login_with_retry、wait_for_toast。

机制三：动态转念 - 一套DSL跑通通盘端

转念器给与两种输入：

YAML/JSON序列：适宜要道字驱动

Python链式调用：适宜代码作风

一个YAML用例示例：

name: 跨端下单进程

skills:

-name:navigate

params:{url:"https://xxx.com"}

-name:click

params:{selector:"#add-to-cart"}

-name:wait_for_element

params:{selector:".cart-badge"，timeout:5}

-name:http_post

params:{url:"/api/checkout"，data:{"item_id":123}}

-name:assert_status_code

params:{expected:200}

这个用例不错在Web环境跑（navigate， click），也不错在纯接口环境跑（http_post， assert_status_code）。

转念器会证据面前注册的手段结合，跳过不行用的手段（如click在接口环境自动跳过并报警）。

中枢洽商玄学：

手段是原子智商，用例是手段的有序组合。

底层驱动不错换，手段不错增删，但用例结构不变。

四、典型案例对比：统一个场景，三种终局，一套写法

拿“登录并校验”这个场景例如。

传统阵势：三套代码

Web端：

page.goto("/login")

page.fill("#username"， "test")

page.fill("#password"， "pass")

page.click("button")

page.wait_for_selector(".welcome")

assert page.text_content(".welcome") == "接待"

App端（类似，但API不同）：

driver.find_element(By.ID， "username").send_keys("test")

driver.find_element(By.ID， "password").send_keys("pass")

driver.find_element(By.ID， "login_btn").click

wait = WebDriverWait(driver， 5)

wait.until(EC.visibility_of_element_located((By.CLASS_NAME， "welcome")))

assert driver.find_element(By.CLASS_NAME， "welcome").text == "接待"

接口端：

resp = requests.post("/login"， json={"user": "test"， "pwd": "pass"})

assert resp.status_code == 200

assert "接待" in resp.text

Skills框架阵势：一套用例

skills:

-name:navigate

params:{url:"/login"}

-name:input_text

params:{selector:"#username"，text:"test"}

-name:input_text

params:{selector:"#password"，text:"pass"}

-name:click

params:{selector:"button"}

-name:wait_for_element

params:{selector:".welcome"，timeout:5}

-name:assert_text

params:{selector:".welcome"，expected:"接待"}

把这个YAML丢给转念器，培育driver_type=web，跑Web。

培育driver_type=app，跑App（唯有selector能被Appium剖析）。

培育driver_type=api，框架会自动将input_text和click转念为HTTP央求（若是达成了对应映射）。

执行上，接口环境不需要填表单，是以咱们会为接口场景单独写一个更简约的手段序列。但要道在于：

测试东谈主员不需要记取三套API，只需要记取手段名字和参数。

不错被截图传播的不雅点句：

测试框架的复杂度，应该由框架自身承担，而不是让每个用例编写者类似学习。

手段挽救，才是信得过的钞票复用。不然你仅仅在不同的端里类似造轮子。

五、工程落地启示：你的测试钞票不该绑定在某种器具上

这个框架开源后，我也曾在三个团队落地。

回来三条最径直的教学。

启示一：把现存测试剧本拆成“手段库”和“用例层”

不要一次性重写通盘效例。

先从最常用的10个操作驱动，注册成手段。

然后让用例通过手段调用来重构。

三个月后，你的用例文献会减少70%的类似代码。

启示二：手段不错跨神气分享

咱们在框架里内置了一个汉典手段仓库。

团队A写的captcha_solver手段，团队B不错径直拉下来用。

不需要复制代码，不需要知谈里面达成。

这对中大型团队的价值极大：

你不再需要每个神气王人配一个“自动化大家”。

启示三：新东谈主培训周期从两周压缩到两天

新东谈主只需要学会手段列表和YAML写法。

不需要先学Playwright API，再学Appium，再学Requests。

他们不错在第一天就写出能跑的用例，第二天交融手段背后的旨趣。

对在校生来说：

你咫尺不需要纠结“学Web自动化如故App自动化”。

你应该学的是“如何概括测试手段”。这个智商在职何端王人通用。

对低级工程师来说：

试着把你浅薄写的Playwright剧本，重构为手段+用例的状貌。

你会发现我方驱动从“写代码的东谈主”酿成“洽商框架的东谈主”。

对中级工程师来说：

这个框架展示了如何用“注册中心+适配器”模式解耦测试器具。

你不错把它引申到你的团队，粗略我方达成一个更轻量的版块。

六、问你的团队一个问题

去你团队的自动化代码仓库里，落拓找一个跨端的场景（比如用户从注册到下单）。

然后问我方：

若是来日要换掉其中一个底层框架（比如从Playwright换成Cypress），你要改若干处代码？

若是谜底是“逾越10处”，

那么这个框架就值得你花一天时刻商议。

霍格沃兹测试开导学社KPL王者IOS/安卓通用版/APP下载，是一个专注软件测试、自动化测试、东谈主工智能测试与测试开导的手艺疏通社区