当前位置：首页 > news >正文

【Appium 系列】第12节-智能路由 — API测试 vs UI 测试的自动选择

news 2026/5/16 20:46:55

对应代码：`配套代码/test/core/test_router.py`

说明：本节讲解如何根据测试用例的特征，自动选择使用接口测试还是UI测试。

这节讲什么

我手头有一个登录功能的测试用例。这个用例可以有两种测法：

接口测试：直接发 HTTP 请求到/api/login，验证返回的 JSON 数据
UI 测试：启动 Appium，打开登录页面，输入用户名密码，点击登录按钮

两种方法都能验证登录功能，但耗时差很多：

接口测试：1-2 秒
UI 测试：30-60 秒（含推动启动时间）

问题来了：什么时候该用接口测试？什么时候该用 UI 测试？

一开始我靠人工判断，写着写着发现：

有些用例明显该用接口（比如"验证 API 返回状态码"）
有些用例明显该用 UI（比如"验证按钮点击效果"）
但有些用例模棱两可（比如"验证登录成功"）

于是写了个路由器，让程序自动判断。

核心思路

路由器的逻辑很简单：根据用例描述中的关键词，统计 API 倾向和 UI 倾向，选倾向高的那个。

测试用例 → 提取文本 → 统计关键词 → 判断倾向 → 选择测试类型

关键词设计

API 关键词（看到这些词，优先用接口测试）：

接口、api、API、请求、响应、http、rest、restful
数据准备、数据清理、批量操作、后台、服务端

UI 关键词（看到这些词，优先用 UI 测试）：

界面、页面、UI、点击、输入、滑动、显示、展示
按钮、输入框、下拉、弹窗、跳转、导航

判断逻辑

api_count = 统计 API 关键词出现次数 ui_count = 统计 UI 关键词出现次数 if api_count > ui_count: 选择接口测试 elif ui_count > api_count: 选择 UI 测试 else: 默认选择 UI 测试（因为 UI 测试更能验证用户体验）

实战案例

案例 1：明显的 API 用例

name: "验证登录接口返回正确状态码" description: "发送 POST 请求到 /api/login，验证响应状态码为 200"

路由器分析：

API 关键词：接口、请求、响应 → 3 个
UI 关键词：无 → 0 个
判断：API 倾向强，选择接口测试

案例 2：明显的 UI 用例

name: "验证登录按钮点击后跳转到首页" description: "输入用户名密码，点击登录按钮，验证页面跳转到首页"

路由器分析：

API 关键词：无 → 0 个
UI 关键词：按钮、点击、页面、跳转 → 4 个
判断：UI 倾向强，选择 UI 测试

案例 3：模棱两可的用例

name: "验证登录功能" description: "用户能够成功登录系统"

路由器分析：

API 关键词：无 → 0 个
UI 关键词：无 → 0 个
判断：倾向相同，默认选择 UI 测试

为什么默认选 UI？因为 UI 测试覆盖的场景更广——它验证的是用户真实能看到、能操作的东西。接口测试只是验证数据层，UI 测试验证的是完整体验。

代码实现

核心代码在core/test_router.py：

class TestRouter: # API 关键词 API_KEYWORDS = [ "接口", "api", "API", "请求", "响应", "http", "rest", "restful", "数据准备", "数据清理", "批量操作", "后台", "服务端" ] # UI 关键词 UI_KEYWORDS = [ "界面", "页面", "UI", "点击", "输入", "滑动", "显示", "展示", "按钮", "输入框", "下拉", "弹窗", "跳转", "导航" ] @classmethod def determine_test_type(cls, test_case: dict) -> TestType: # 1. 如果用例明确指定了测试类型，直接用 if "test_type" in test_case: return 解析 test_case["test_type"] # 2. 提取用例文本 text = f"{name} {description} {steps}" # 3. 统计关键词 api_count = sum(1 for kw in API_KEYWORDS if kw in text) ui_count = sum(1 for kw in UI_KEYWORDS if kw in text) # 4. 判断 if api_count > ui_count: return TestType.API elif ui_count > api_count: return TestType.UI else: return TestType.UI # 默认 UI --- ## 注意事项 ### 1. 关键词不是万能的 关键词匹配只能覆盖大概 70% 的用例。剩下的 30% 需要人工判断，或者在用例中明确指定 `test_type` 字段。 **建议**：对于关键用例，不要依赖自动路由，直接写死 `test_type: api` 或 `test_type: ui`。 ### 2. 默认值的选择 我选择默认走 UI 测试，是因为： - UI 测试覆盖的场景更广 - 即使接口没问题，UI 也可能有问题（比如按钮没响应） - 宁可多花 30 秒，也不要漏掉 UI 层面的 bug 如果你的项目更关注接口稳定性，可以改成默认走 API 测试。 ### 3. 关键词需要持续维护 随着项目迭代，新的测试场景会出现，关键词列表也需要更新。 **建议**：每季度 review 一次关键词列表，把新出现的场景词加进去。 --- ## 实际使用建议 如果你准备在项目里上路由自动选择，建议按以下步骤来： **路由配置 Checklist：** - □ **关键词列表确认**：根据项目实际用例，review API 关键词和 UI 关键词列表，删掉不相关的词，加上项目特有的词 - □ **关键用例显式指定**：登录、支付、退款这类核心流程，不要依赖自动路由，在用例 YAML 里写死 `test_type: api` 或 `test_type: ui` - □ **默认值确认**：确认你的项目默认走 API 还是 UI（这篇默认 UI，如果你的项目更关注接口稳定性可以改成默认 API） - □ **HYBRID 支持**：如果项目有混合测试需求，保证路由也支持 `test_type: hybrid` - □ **日志可追溯**：路由判断结果要打到日志里，方便排查"为什么这个用例走了 API 而不是 UI" - □ **定期 review**：每季度检查一次路由准确率，关键词匹配不准确的用例考虑显式指定 **什么时候不该用自动路由？** - 用例数量少于 50 个——人工判断成本很低，自动路由的收益不大 - 团队只有 1-2 个测试——沟通成本低于工具成本 - 项目处于高效迭代期——用例频繁变更，路由配置维护成本高于收益

查看全文

http://www.jsqmd.com/news/830398/