写自动化脚本时，你可能遇到过这些情况：加一条新用例就要复制一份脚本，只改几个输入值；接口字段一变，几十个脚本全得跟着改；用例越堆越多，却没人说得清哪些数据跑过、哪些没跑。这篇不聊概念定义，而是把关键字驱动和数据驱动两种模型拆成可执行的动作：先看你的项目卡在哪一类问题上，再决定用哪种结构组织脚本，最后给一份落地清单和不适用的场景。
写自动化脚本的人常卡在同一个地方：加一条新用例就复制一份脚本，只改几个输入值；接口字段一变，几十个脚本全得跟着改；用例越堆越多，却没人说得清哪些数据跑过、哪些没跑。这时候问题往往不在脚本写得差，而在结构选错了。
关键字驱动和数据驱动不是两个时髦名词，而是两种把脚本拆开的方式。先看你痛的是脚本结构重复，还是测试数据重复，再决定用哪种组织方式。下面按「先判断、再落地、最后排查」的顺序讲，末尾给一份上手清单。
先搞清两种模型各自解决什么问题
关键字驱动的核心是把「操作」和「数据」分离：脚本里只写打开、输入、点击、断言这些动作名，具体对象和值放到外部表里查。它适合流程固定、步骤重复、但参数经常变的场景。数据驱动的核心是把「逻辑」和「输入输出」分离：一套执行逻辑配多组数据集，跑一遍数据表就等于跑多条用例。
- 关键字驱动
- 动作名和对象信息外置，脚本只负责按表执行；改页面先改表
- 数据驱动
- 执行逻辑只写一份，输入输出全从数据集读；加入参等于加用例
- 混合用法
- 关键字表里嵌数据集，先分动作再分数据，多数中大型项目最终都走这条路
两者不冲突，判断依据很直接：如果脚本里大量重复的是「怎么做」，优先关键字驱动；重复的是「拿什么值做」，优先数据驱动。一次性验证、流程每次都不一样、断言逻辑差异极大的探索性测试，不适合套这两种模型，强行抽象只会增加维护成本。
数据驱动怎么落地：从数据集到执行链
- 数据集优先用表格或结构化文件，字段名固定：用例编号、前置条件、输入、期望结果、是否跳过；字段命名混乱是后期最难查的坑
- 执行逻辑里不写死任何业务值，所有会变的东西都从数据集读；写完拿一条数据改个值，看是否只改数据就能跑通
- 异常数据单独放一组：缺字段、超长、类型不符这类边界值，和正常用例分开跑，方便定位是逻辑错还是数据错
- 断言不要只比对一个整体字符串，拆成可定位的字段逐项比，失败时能直接看出是哪一列不对
数据集规模上去之后，执行链要能回答「这条用例用的是哪行数据」。做法是每跑一条就把用例编号和数据集行号写进日志上下文，失败时能直接跳到那行去核对。这一步偷懒，后面复现问题就得靠猜。
关键字驱动怎么落地：动作库与表的组织方式
- 收敛关键字把常用动作收敛成一组稳定的关键字，比如打开页面、输入文本、点击元素、等待元素、校验文本；关键字数量宁可少而稳，不要为每个页面单独造一个
- 外置定位对象定位信息单独维护一张表，页面改版时只改这一处，脚本主体不动；定位方式优先选稳定属性，避免依赖会随版本变的文案
- 按模块分表关键字表按业务模块分文件，不要全部塞进一张大表；模块边界乱了，后面查一个失败用例要翻几百行
- 先试点再铺开挑一条最稳定的主流程做试点，跑顺了再铺开，别一上来就把全部回归用例重构成关键字表
跑起来之后：超时、并发、降级与日志
超时不要用固定长等待，按环境实测基线定。可以到 接口测速：先量出你的延迟基线（/tools/speed-test） 跑一遍，拿到你这边的响应水平再填数字，别照搬别人的值。等待上限设好之后，失败信息里要带上实际耗时，方便区分是慢还是错。
| 现象 | 先查哪里 | 常见原因 |
|---|---|---|
| 同一数据集只有几条失败 | 对应用例行与断言列 | 数据本身越界或格式不符 |
| 整批一起失败 | 关键字表与环境状态 | 依赖不可用或登录态过期 |
| 偶发失败、重跑就过 | 超时上限与并发批次 | 等待时间卡在临界值 |
| 改完页面全挂 | 定位信息表 | 定位属性随版本变了 |
并发跑数据集时分批推进，批次大小按被调服务的限流情况定，不要一次全放出去。失败重投前先判断是数据问题还是环境抖动，两者处理方式不同。外部依赖不可用时，标记跳过而不是全部失败，避免一次波动把整轮结果染红。
- 日志至少记清五项：用例编号、数据集行号、当前关键字、入参、耗时与失败原因，缺一样复盘就得靠猜
- 结果按「通过、失败、跳过」三态统计，跳过不算通过，别把两者混在一起看
- 每轮跑完保留一份结果快照，方便和上一轮对比是变好还是变差
- 失败用例聚合成一份清单，按模块分组发给对应负责人，不要只发一个总数
给团队的上手清单与不适用场景
第一步统计现状：现有脚本里有多少行是复制粘贴出来的，重复率高的先做数据驱动；有多少行在重复描述操作步骤，重复率高的先做关键字驱动。第二步定规范：数据集字段命名、关键字命名、失败标记方式，三条写进团队约定，不然每个人一套写法。第三步定评测口径：每次改脚本后跑同一批固定用例，对比通过率和耗时变化，别只看「这次跑绿了」。
| 场景 | 优先模型 | 判断依据 |
|---|---|---|
| 同一流程、入参多变 | 数据驱动 | 脚本主体一字不改，只加数据集行 |
| 多页面、步骤高度雷同 | 关键字驱动 | 操作名可复用，定位信息集中维护 |
| 两者都严重 | 先数据后关键字 | 先把输入输出外置，再收敛动作 |
| 需求频繁变、维护人少 | 暂不抽象 | 先保用例覆盖，过早抽象反而拖慢 |
什么情况下不适用：项目仍在频繁改需求、页面结构一周一变、团队只有一两个人维护脚本，此时先保证用例覆盖，不要过早抽象。想更系统地看自动化工具和中转方案的分工，可以去 工具目录（/tools） 按类型筛一遍；模型本身的调用差异，到 模型资料库（/models） 对照说明看当时的资料。
下一步把你现在脚本里重复最多的一段抽出来，按上面的表判断该走数据驱动还是关键字驱动，改完跑同一批固定用例对比结果；需要对照工具与接口基线时，回站内目录页查当时的数字。→常见问题
数据驱动和关键字驱动到底该先上哪个？
看你的重复点在哪。如果脚本之间大量复制，只是输入值和期望结果不同，先做数据驱动，改动最小。如果脚本里大段都在重复描述点击、输入这些步骤，页面一改要动很多地方，先做关键字驱动。两者可以叠加，不用二选一。
数据驱动是不是就是把用例写在 Excel 里？
不是。Excel 只是载体，核心是执行逻辑里不写死业务值。用 CSV、JSON、数据库表都一样。判断标准很简单：改一条测试数据，是不是只动数据文件、不动代码。如果还要改脚本，那只是把数据挪了个地方。
这套模型在什么情况下会拖后腿？
需求还在快速变、页面结构不稳定、维护人力只有一两个的时候，抽象层反而会成为负担，改一个字段要同时动表、关键字和脚本三处。这种阶段先用直白的线性脚本保证覆盖，等流程稳定了再重构。
