企业官网建设流程全解析

最近面试了一个做自动化测试的候选人，聊到测试模型时，对方把框架和脚本混在一起讲，越说越绕。我意识到一个现象：很多做了两三年自动化的测试工程师，能熟练操作Selenium、pytest、JMeter，但如果你问他“当前项目用的是哪种自动化测试模型”，大多数人答不上来。

自动化测试模型这个概念虽然古早，却直接决定了自动化项目的维护成本、扩展空间和团队门槛。它和框架不是一回事，模型更像一种组织脚本、数据和页面对象的结构思想，框架只是承载思想的容器。这篇文章我准备把四种最常见的自动化测试模型——线性模型、模块化驱动模型、数据驱动模型、关键字驱动模型——用实际可运行的例子拆开讲一遍，把每种模型的优缺点说透，顺便讲讲我在实际项目里怎么选型。

如果你正在搭自动化体系，或者手里已有的自动化脚本越来越难维护，那这篇文章应该对你有点用。我不准备讲太学院派的理论，尽量用真实的脚本片段和你平时会遇到的问题来说明。

1. 先厘清一个概念：模型、框架和脚本到底在说什么

1.1 自动化的三个层次

很多团队选自动化工具时上来就比 Selenium 还是 Cypress、pytest 还是 Robot Framework，比了半天选错方向，是因为把三个层次混在一起了。

第一个层次是测试脚本，就是具体的一段代码，完成某个页面操作、接口调用或断言动作。第二个层次是测试框架，提供执行入口、结果收集、报告生成这些基础设施，它解决的是“怎么跑”的问题。第三个层次才是测试模型，描述的是脚本与脚本之间、脚本与数据之间、脚本与页面对象之间如何组织，解决的是“脚本怎么写才不容易烂”的问题。

用一个不太精确但好记的说法：框架是房子，模型是房子的户型。同样是 100 平米的房子，户型设计得好不好，直接决定了住进去之后舒不舒服。很多自动化项目框架选得很主流，但脚本写出来还是一团乱麻，本质上就是户型设计出了问题。

1.2 四种模型分类的依据：谁掌握变化

四种模型划分的底层逻辑其实只有一个问题：变化发生的时候，改哪里？

线性模型里，变化直接改脚本，脚本即用例，改需求等于重写脚本。模块化驱动模型里，变化被拆到公共模块和用例脚本两边，改动尽量收敛在一个模块内。数据驱动模型把变化赶进数据文件，脚本逻辑保持稳定，改数据就行。关键字驱动模型把变化更彻底地赶进了一张表格，非技术人员也能通过改表格来新增用例。

可以这样理解：模型本质上是在回答“测试数据、业务流程、对象定位、执行逻辑这四样东西，分别放在哪个位置”。选模型不是选工具，而是选一套应对变更的策略。

1.3 为什么选错模型会让自动化成本失控

我见过不少自动化项目死在 3 到 6 个月这个阶段，原因往往不是工具不行，而是脚本之间的复用关系从一开始就没设计对。

举个例子，一个电商下单流程的 UI 自动化，如果全部按线性脚本写，十条用例里可能六条都要走“登录-搜索-加购-结算”，这段流程就要被复制六遍。等到前端按钮改了定位，那不是改一处，是改六处。改完发现漏了一个，回归报告里就会出现莫名其妙的失败。这就是线性模型在变更频发场景下的真实成本。

反过来，如果一开始就把登录、加购这些动作抽成模块，改动就收敛在一个地方，用例脚本本身基本不动。这个差异在项目前期不明显，但到了脚本量两三百条的时候，差距就是几天的维护工时和几个小时的维护工时的区别。

2. 线性模型实例：从一段“最笨但能跑”的脚本说它的生存空间

2.1 一个最原始的线性脚本长什么样

线性模型也叫脚本录制模型，指一条用例就是一段从头到尾顺序执行的脚本，不做任何抽象和封装。它的典型形态是录制回放，或者手工一步步写出的 WebDriver 脚本。

我用 Python 加 Selenium 写一个最典型的登录脚本示例：

from selenium import webdriver from selenium.webdriver.common.by import By driver = webdriver.Chrome() driver.get("https://demo.example.com/login") username = driver.find_element(By.ID, "username") password = driver.find_element(By.ID, "password") login_btn = driver.find_element(By.ID, "loginBtn") username.send_keys("admin") password.send_keys("123456") login_btn.click() # 断言登录成功 assert driver.find_element(By.CLASS_NAME, "user-info").text == "admin" driver.quit()

这段脚本从打开浏览器到断言成功，一条路走到黑，没有函数、没有类、没有数据分离。很多测试工程师入行的第一条脚本都是这个形态。你把它跑起来，登录流程没问题，断言也正确，好像一切都很顺利。

这恰恰是线性模型最迷惑人的地方：单条脚本写起来太爽了，爽到让人忽略了它未来会带来的维护问题。

2.2 优点：三步见效，调试直接

线性模型最大的优点是门槛低、见效快。只要会基础编程，按着操作顺序把步骤翻译成代码，脚本就完成了。对完全没接触过自动化的团队来说，用线性模型做第一个 POC（概念验证），可以在一两天内跑通一个真实场景，让团队成员亲眼看到自动化的价值，这个心理层面的作用比技术本身重要得多。

它的调试体验也很直接。哪一步失败就定位哪一行，不需要翻模块调用链，不需要理解封装层级，报错信息就是当前行。因为这种做法，临时任务的脚本通常都会用线性模型来写。

还有一个容易被忽视的优点：线性脚本在执行顺序上完全可控，不需要考虑测试执行框架带来的随机顺序、用例并发、数据污染等问题。当你只需要验证一个孤立功能时，线性脚本是最快的方式。

2.3 缺点：改了需求，就得重写脚本

线性模型的致命伤是复用率为零和变更成本极高。

先说复用。六条用例都要登录，脚本就复制六遍登录代码。一旦登录按钮的 id 变了，六个地方都要改。下一个工程师接手，看到一段几百行的线性脚本描述一个复杂业务流程，他得从第一行读到最后一行才能知道脚本在做什么，这个理解成本是非常沉重的。

再往下还有个问题：线性脚本没有把“业务动作”和“底层定位”分开。断言的是一段 xpath 表达式，点击的也是一段 xpath 表达式，整个脚本被定位器占满了。业务人员看脚本根本看不懂，纯靠代码维护，一旦接口字段、页面结构、交互方式发生变化，脚本就是一次大面积重写。这种脚本数量一旦到上百条，维护自动化用例的时间可能超过手工执行用例的时间，项目也就走到了“自动化负收益”的境地。

2.4 什么情况下我反而会主动用线性模型

虽然前面把线性模型说得不堪，但实践中我其实会主动用，而且用得不少。

第一类场景是临时冒烟验证。比如产品经理说新版本改了一个按钮样式，我需要快速确认页面还能不能正常打开提交，写一个二三十行的线性脚本跑一遍，用完就删，不心疼。第二类场景是环境数据准备，比如测试环境需要批量造出十个不同等级的商品，这本质上是一次性任务，不值得为它设计模块。第三类是自动化起步团队做 POC，我通常建议先用线性脚本快速让团队看到可行性，等大家接受自动化这条路了，再立刻转入模块化改造。

关键判断标准就一条：这段脚本会不会被复用、会不会在业务变更后还要继续活很久。不会就不封装，会就必须做结构化设计。

3. 模块化驱动模型：把重复动作变成可复用的零件

3.1 模块化模型的核心思想：封装与分层

模块化驱动模型，也叫模块化测试框架，核心思想是分治和复用。把测试过程拆成一个个独立的公共模块，每个模块完成一个单独的业务动作或技术动作，用例脚本再把这些模块组装起来。

拿最熟悉的场景类比：一个手工测试工程师做回归测试，不会每次测试都从打开浏览器、输入用户名密码开始，他一定有个“登录测试账号”的习惯性操作。模块化模型就是把类似的动作固化成标准化零件，用的时候直接取零件组装。

分层设计通常有工具层、操作层、用例层三层：工具层封装浏览器驱动、等待机制、通用日志等基础能力；操作层封装具体业务动作，比如登录、搜索、创建订单，一个动作对应一个类或函数；用例层只负责编排业务步骤和断言结果，不在里面写具体的定位器，也不写脏逻辑。

3.2 一个登录场景的分层实例

我用一个简单但真实的分层例子讲清楚。以页面对象模式（Page Object Model）为例，先把登录页面抽象成类：

# 操作层：登录页面对象 from selenium.webdriver.common.by import By class LoginPage: def __init__(self, driver): self.driver = driver def open(self, url): self.driver.get(url) def login(self, username, password): self.driver.find_element(By.ID, "username").send_keys(username) self.driver.find_element(By.ID, "password").send_keys(password) self.driver.find_element(By.ID, "loginBtn").click() def get_login_user(self): return self.driver.find_element(By.CLASS_NAME, "user-info").text

然后写用例层，直接调用操作层的方法：

# 用例层 def test_login_success(): driver = webdriver.Chrome() login_page = LoginPage(driver) login_page.open("https://demo.example.com/login") login_page.login("admin", "123456") assert login_page.get_login_user() == "admin" driver.quit()

对比一下线性模型里的登录脚本，最直观的差异是：现在用例层只表达了三件事——打开登录页、执行登录、断言结果，每一件事的复杂度都被“藏”到了操作层里。另一个用例也需要登录时，不必复制这段流程，直接创建一个 LoginPage 对象调用 login 方法就行。

定位器如果变化，只改 LoginPage 类里的 locator，所有调用它的用例全部受益。这就是模块化模型把“变化点”收敛到一处的核心价值。

3.3 优点与缺点

模块化模型在四种模型里属于性价比最高的中庸之选，对多数测试团队的收益最稳定。

优点方面，第一是复用性高，只写一次登录逻辑，就能在成百上千条用例中被反复调用。第二是变更局部化，页面结构变了，定位器修改范围被限制在对应的页面对象里，不会牵一发动全身。第三是用例可读性好，用例层读起来像一份用例步骤清单，新同学接手也容易看懂。第四是支持并行开发，不同人员负责不同页面的对象封装，只要接口约定清楚，模块之间互不干扰。

缺点方面，它比线性模型有更高的设计门槛，要求团队具备基本的代码结构能力。如果封装得不好，容易出现“过度抽象”问题：为了复用而建很深的继承关系、为了参数灵活搞了七八个可选参数，最后用例层一行调用背后是三四十行调用链，出了问题要层层追查。模块间的依赖关系如果设计得不清楚，还会出现循环依赖，A 模块调 B 模块、B 模块又调回 A 模块。

3.4 模块化模型最容易掉进去的坑

模块化模型最大的坑不是封装得不够多，而是封装得过于拼命。

我见过一个项目，页面对象封装到第五层，基类套基类，一个按钮的定位器要经过四个类的继承才能找到。后来产品做了一个页面改版，改一个定位器，足足动了四个文件，因为基类里存了通用定位规则，子类又重写覆盖。他团队的人查看定位器要沿着继承链一层层找，这种抽象已经变成了负资产。

我的实操经验是：页面对象保留“这个页面上有什么”和“这个页面能做什么”就足够了，不要追求把所有相关页面都塞进一个超大类，更不要在工具层里塞业务判断。跨页面的业务流，比如下单流程，应该写在用例层或者专门的服务层里，不要让页面对象之间互相调用去拼凑业务。抽象是有代价的，每多一层封装，调一次试一次的成本就会增加，适度为止。

4. 数据驱动模型：让测试数据和脚本彻底分离

4.1 数据驱动模型的应用场景与思想

数据驱动模型的核心思想是：测试流程固定，变化集中在数据。脚本只负责执行逻辑，测试数据从代码里抽离出来，放到外部文件或数据库里，一条脚本配合多组数据运行。

典型应用场景是接口自动化测试。同样一个登录接口，要覆盖正常登录、密码错误、用户不存在、参数为空、并发登录等场景，接口的调用步骤完全一样，变的只是请求参数和期望结果。这种情况下把数据写在脚本里会让代码极度膨胀，数据驱动模型就是为此而生。

UI 测试里也很常见，比如一个表单提交页面，输入框的组合非常多，数据驱动可以让你只维护一段表单填写逻辑和一份测试数据，每条数据跑一遍流程，覆盖率比人工手写脚本高出不少。

4.2 一个带数据源的参数化实例

我用接口测试举例，这是数据驱动模型最纯粹的形态。测试数据放在 JSON 文件里：

[ {"username": "admin", "password": "123456", "expect": 200, "desc": "正常登录"}, {"username": "admin", "password": "wrong", "expect": 401, "desc": "密码错误"}, {"username": "", "password": "123456", "expect": 422, "desc": "用户名为空"} ]

测试脚本从数据文件读取数据，使用 pytest 参数化逐条执行：

import pytest import requests def load_json(file): with open(file, "r", encoding="utf-8") as f: return json.load(f) @pytest.mark.parametrize("case", load_json("test_data/login_data.json")) def test_login_api(case): resp = requests.post( "https://demo.example.com/api/login", json={"username": case["username"], "password": case["password"]} ) assert resp.status_code == case["expect"], f"{case['desc']} 失败，实际状态码 {resp.status_code}"

新增一条用例，只需要往 JSON 文件里加一个对象，脚本一行都不用改。执行失败时，描述信息会被带进 pytest 输出，定位是哪一条数据出的问题也很方便。

这里有个值得注意的设计细节：每条数据都带一个 desc 字段，这是我最常提醒团队的。很多团队的数据驱动用例失败后，报告只显示参数值和期望值，完全不告诉你这条数据是干什么的，排查问题要对着原始数据顺藤摸瓜。加一个描述字段，报告可读性会明显改善。

4.3 优点与代价

数据驱动模型的优点非常清晰。第一，脚本和数据解耦，业务测试人员经过简单培训后可以直接维护数据文件，不需要碰代码。第二，一条脚本覆盖大量数据组合，用极少的代码量获取极高的覆盖率。第三，回归执行效率高，同一逻辑跑十几条数据，对接口兼容性、边界值覆盖的帮助是直接的。

但它的代价也常被忽略。数据文件本身会成为新的维护对象，一旦数据文件里的用例积累到几百条，不加管理的用例会变成垃圾堆。数据自身的问题也可能掺进来，比如测试数据里的脏值导致接口返回 500，这在自动化报告里会表现为产品缺陷，实际却是数据责任人，这个误报会让开发团队对自动化报告失去信任。

还有一类场景不适合数据驱动：测试步骤本身随数据发生剧烈变化的场景。比如有的用例需要先登录后下单，有的用例只需要验证未登录拦截，它们流程差异太大，硬塞进同一个数据驱动模板，脚本里全是 if-else 分支，代码难看，执行也乱。

4.4 数据文件失控的前兆

数据驱动模型做一段时间后会暴露一些失控征兆，我列几个常见信号：数据文件里出现大量重复用例，同一个参数组合被不同的人各加了一遍；所有业务场景塞进同一个 Excel 文件，里面十几个工作表单各自为政；数据增长很快，但没有人清理无效历史数据；自动化失败的比例里，数据本身原因占到三成以上。

我的建议是：数据按业务模块拆分成多个文件，比如登录数据、订单数据、支付数据分开维护；每条数据必须带描述字段和归属标识；数据文件纳入版本管理，任何修改走代码评审流程；定期执行数据治理，把重复、无效、过期数据清掉。做到这几点，数据驱动模型才能长期保持健康。

5. 关键字驱动模型：把人人能写的表格变成可执行用例

5.1 关键字驱动的本质：业务动作词表

关键字驱动模型在自动化平台里最常见，Robot Framework、Katalon Studio，以及很多低代码自动化平台，本质都是在做关键字驱动。它的核心思想是把测试步骤抽象成一组“关键字”，每个关键字对应一个底层操作函数，用例则写成一张按顺序填充关键字的表格，由执行引擎逐行解释执行。

再形象一点：线性模型像一份事无巨细的菜谱，每一步都写“拿起锅”“打开火”“倒油”；关键字驱动模型则像一份标准菜谱，只写“热锅”“下油”“爆香”，厨师（执行引擎）知道这些动作怎么完成，写菜谱的人不需要懂厨具操作。

这意味着，编写用例的人不需要了解底层代码，只要知道关键字表怎么填，就能组织测试流程。这是关键字驱动模型与前面三种模型最本质的区别：前三种模型要求写用例的人具备编程能力，关键字驱动模型对业务测试同事很友好。

5.2 表格用例与执行器骨架

假设我们要用关键字驱动实现一个登录场景，用例表格长这样：

执行引擎读取表格的每一行，根据关键字分发到具体的函数：

def execute_step(step, driver): keyword = step["关键字"] if keyword == "open_url": driver.get(step["参数"]) elif keyword == "input_text": driver.find_element(*parse_locator(step["定位信息"])).send_keys(step["参数"]) elif keyword == "click": driver.find_element(*parse_locator(step["定位信息"])).click() elif keyword == "assert_text": actual = driver.find_element(*parse_locator(step["定位信息"])).text assert actual == step["参数"], f"断言失败，期望 {step['参数']}，实际 {actual}" def execute_test_case(steps): driver = webdriver.Chrome() for row_number, step in enumerate(steps, start=1): try: execute_step(step, driver) except Exception as exc: raise AssertionError(f"第 {row_number} 行执行失败，关键字 {step['关键字']}: {exc}")

表格里的每一行都被翻译成一次真实操作，哪天产品加了一个“记住登录状态”的选项，只需要新增一个勾选关键字，所有会用这张表的人都能在用例里增加这一行，无需改代码。这种扩展方式在测试团队和非技术业务人员混杂的场景里，体验是革命性的。

5.3 优点和缺点

关键字驱动模型的优点：第一，用例可读性非常高，表格本身就像自然语言写成的测试步骤，评审的时候业务人员也能看得懂。第二，业务人员可以参与用例编写，把测试设计能力从代码中解放出来。第三，关键字是跨页面、跨场景复用的，同一个输入关键字可以在所有表单场景里使用。第四，它是实现测试平台化和低代码自动化的基础。

但代价同样大：执行引擎和关键字库的设计在前期投入很大，相当于做一个小型开发框架。关键字的粒度非常难把握：关键字如果定义得太细，比如“输入文本”“点击按钮”，本质上只是把一句代码换成一个单元格，表格会变得冗长，写用例的人依然要理解控件定位；如果定义得太粗，比如一个“下单流程”关键字，它又回到了模块化模型的老路，失去灵活性。

调试也是个问题。关键字模型执行出错后，报错信息往往在引擎里，用例编写者很难直接从表格看出问题根因是什么。如果引擎没有做完善的日志和步骤追踪，一次失败定位可能需要同时看三层内容。

5.4 做关键字驱动时最需要小心的地方

我在实际项目里部署关键字驱动模型，通常要求团队满足三个条件才算合格。

第一，关键字定义必须按“业务动作”而不是“控件操作”来设计。“输入文本”“点击按钮”不是业务关键字，“填写登录信息”“提交订单”才是。只有业务关键字才能让不懂代码的测试人员直接使用。

第二，执行引擎必须对每一行用例做差分日志，记录执行到了哪一行、每个关键字的入参出参、耗时、失败原因。没有这个日志，关键字驱动就是黑盒，出问题只能对着表格发呆。

第三，关键字的文档必须同步维护。每个关键字的名称、参数列表、适用前提、返回值都写清楚，不然同一个操作有人叫 input_text，有人叫 enter_text，关键字库很快就会变成一团混乱。

还有一个提醒：关键字驱动模型不等于完全不需要代码。参与设计关键字库和引擎的人，需要比普通测试开发更高的工程能力。如果你团队里没有这样的人，不要轻易走这条路，硬上的话关键字库会变成一座新的维护山。

6. 四种模型横评：优缺点对照表与我的选型经验

6.1 一张表看完四者的差异

把四种模型放到一张表里，对比维度选五个：编写门槛、复用性、变更成本、对人员要求、典型适用场景。

这张表只能当参考，不能当教条。比如数据驱动模型在接口测试中写起来很容易，但在复杂 UI 流程中同样会碰到前置条件和执行顺序管理的问题，实战难度完全不同。

6.2 选型要看团队构成而不是功能列表

我见过许多团队在选择自动化测试模型时，把四种模型的优点列出来，试图做一个“集所有优点于一身”的方案，最后做出来的东西四不像。选型第一原则，是看这个团队到底有什么人。

如果团队全是功能测试工程师，没有专职测试开发，我通常会推荐关键字驱动模型。因为只有它能做到让功能测试人员不写代码就维护用例，其他模型写出来之后大概率没人维护。

如果团队有一两个测试开发加若干会基础代码的测试工程师，模块化模型加数据驱动是最稳的组合：测试开发负责封装底层组件，测试工程师负责写用例和补数据，分工清晰，成本可控。

如果项目是被开发团队主导的，比较适合数据驱动模型和关键字驱动模型，让测试人员专注生产数据和业务场景，把自动化执行能力收拢到一个平台里。团队构成决定了模型能活多久，功能清单决定不了。

6.3 混合模型才是多数项目的常态

实际项目里，很少会有一个项目从头到尾只使用一种模型。我在项目里最常见到的组合是“模块化 + 数据驱动”：页面对象做模块化封装，测试数据和参数化按数据驱动的方式外置，UI 和接口测试都用这套逻辑。

还有一些项目在单个自动化平台上引入了关键字驱动，给业务人员提供低代码编写入口，底层仍然是模块化封装，这种“外壳关键字、内里模块化”的架构，在大规模测试团队里效果很好。

我自己的默认组合是：接口自动化优先数据驱动，因为接口测试流程最稳定；UI 回归测试优先模块化模型加页面对象，因为页面变更天然适合局部收敛；临时验证用线性脚本，用完就丢；如果团队有平台化诉求，再在现有关键字驱动和模块化之间搭一层轻量桥，给业务人员开一个可用的用例编辑入口。不要追求纯正模型，要按模块的稳定性和团队能力混合使用。

6.4 从一种模型迁移到另一种时怎么过渡

如果项目里已经有大量线性脚本，想往模块化或数据驱动迁移，不要一次推翻重写。彻底重写会导致两个后果：迁移周期太长，业务等不起；新旧脚本并行期间，回归能力断档，没人敢发版本。

正确做法是先搭骨架。把最常用的操作，比如登录、搜索、创建订单，先抽成模块；再把经常变化的数据，比如账号、关键字、期望结果，外置到数据文件；最后把线性脚本一条条移植到新用例结构上，跑通一条删一条旧的。

迁移期间新旧脚本并存，我给团队的建议是设置一个“迁移窗口期”，以新用例通过量和旧用例衰减量为两个指标，每周看进展。等新用例覆盖率达到对应模块手工用例的八成以上，再下线旧脚本。这个过程会比较慢，但它不会打断正常的测试交付节奏。

我个人在实际项目中的一个深刻体会是：模型选择的真正关键点，不在于选得高级，而在于选得合适。很多团队在自动化初期过于迷信某些酷炫的框架和模型，做出来的东西看起来很完整，实际用起来却没人维护。与其这样，不如从小处着手，先把线性脚本跑起来，再逐步演进到模块化、数据驱动，甚至在合适的时机尝试关键字驱动。真正决定自动化项目命运的，从来不只是一个模型的名字，而是你把变化点放在了正确的位置，并且有人持续用心维护它。最后再分享一个细节：无论你最终选了哪种模型，确保新加入团队的同事能根据报告、日志和数据文件，在三十分钟内定位到一条失败用例的原因，这个标准达标了，模型才算落地成功。