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