对应代码：配套代码/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 个测试------沟通成本低于工具成本
- 项目处于高效迭代期------用例频繁变更，路由配置维护成本高于收益