关键字驱动测试是什么
关键字驱动测试把测试逻辑与用例描述分离：用例写成关键字加参数的动作序列（如打开页面、输入账号、点击登录、断言结果），由测试引擎解释执行。业务人员可读、可维护用例表，自动化工程师维护关键字库。它适合流程稳定、场景量大且执行者与脚本作者分离的团队，代价是初期框架投入与关键字库治理。
基本信息
| 结构分层 | 用例表（关键字序列）、关键字库（动作实现）、对象库（元素定位） |
|---|---|
| 表示载体 | 表格、Excel、CSV 或 Gherkin 等可读文本 |
| 与数据驱动关系 | 关键字驱动常与数据驱动叠加：同一关键字序列配多组数据 |
| 适用对象 | 业务验收类、重复度高但变化可控的端到端流程 |
| 维护重点 | 关键字单一职责、命名统一、废弃关键字定期清理 |
| 常见工具 | Robot Framework 的关键字机制是典型实现 |
用例表示例
用例表示例
用例：登录并下单
打开页面 | /login # 关键字 | 参数
输入文本 | #username | ${user}
输入文本 | #password | ${pwd}
点击 | #submit
断言文本 | #welcome | 欢迎回来
点击 | #add-cart
断言存在 | #cart-count == 1
# 换一组数据即可复跑，无需改关键字实现典型使用场景
- 业务回归：大量相似流程由实习生或业务方按表格执行与维护。
- 验收自动化：验收实例直接用关键字表达，业务方审阅无障碍。
- 多端复用：同一关键字库适配不同前端技术栈，用例不动。
- 稳定业务系统：流程十年不变的场景，维护成本摊薄收益明显。
- 脚本能力不均的团队：少数人写框架，多数人写用例。
关键字要单一职责：一个关键字做一件事，命名清晰，否则用例表很快看不懂。
动态界面是软肋：定位频繁变化时维护对象库的工作量会吃掉收益。
先小步验证：选一条稳定流程试点，验证收益后再铺量。