测试脚本和数据的解耦（数据驱动）

把测试数据和测试脚本分离，也就是说测试脚本只有一份。其中需要输入数据的地方用变量代替，然后把测试输入的数据单独放到一个文件中。这样存放数据输入的文件通常是表格的形式，也就是我们常见的 csv 文件

在测试脚本中通过 dataprovider 去 csv 文件中读取一行数据，赋值给相应的变量，执行测试用例，接着再用 csv 文件读取下一行的数据，读取完所有的数据，测试就结束了。csv 文件中有几行数据，测试用例就会被执行几次

数据驱动很好地解决了大量重复脚本的问题，实现了 “测试脚本和数据的解耦。目前几乎所有成熟的自动化测试工具和框架，都支持数据驱动的测试，而且除了支持 csv 这种常见的数据源之外，还支持 xls 文件，json 文件，yaml 文件，还有直接以数据库中的表作为数据源的，比如 QTP 就支持以数据库中的表作为数据驱动的数据源

页面对象（Page Object）模型

pageobject 模式：页面对象模式，将测试代码和被测试页面的页面元素及其操作方法进行分离。以此降低页面元素变化对测试代码的影响，每一个被测试页面都会被单独定义为一个类，类中会定位所有需要测试操作页面元素对象，并且定义操作每一个页面元素对象的方法。“页面对象模型” 的核心理念是，以页面为单位来封装页面上的控件的部分操作。而测试用例使用页面对象来完成具体的界面操作。

这是在我还没有运用 page object 的时候写的两条测试用例,一个登录成功，一个登录失败。 这里可以看到页面元素的操作和测试代码是混合在一起的。这里很明显的三个问题，第一两条测试用例大量代码重复；第二大量与测试逻辑无关的代码造成用例易读性的降低；第三一旦 UI 发生变化需要修改每一条测试用例，维护成本高昂。
Page Object 的设计模式很好地解决了以上问题，它遵循一个原则既页面操作和测试场景分开。每一个页面看做一个类，里面的公共方法既是这个网页提供的与用户交互的功能。当然如果有比较复杂的 UI 元素，则这些元素可以是单独的类。但是最后暴露给测试代码的交互方法仍然是 page 类来提供。Page 类中没有任何测试代码，没有任何的断言（assertion）。对于测试代码而言无需关心内部的实现，只需调用对应的公共方法提供的交互功能,无须自己实现任何网页元素的操作，还是举个例子。
第一部分是一个 login page 类，里面所有的定位操作都是私有的，只对外开放了 login page 支持的几种交互方式用户登录，成功登录信息，登录失败信息。第二部分则是我们的测试代码，测试了三种不同的场景。由此可见无论我 UI 如何变化，都会对所有的测试代码都是不影响的，反之亦然。当然这个例子还是有改进空间的，例如将测试数据与测试代码再分离，进一步提高测试代码的可读性和复用性，降低维护成本。

## 自动化测试过程中的测试数据
从创建的技术手段上来讲，创建测试数据的方法主要分三种：

1. API 调用
2. 数据库操作
3. 综合运用 API 调用和数据库操作 从测试的时机来讲，创建测试数据的方法主要分为两种：
4. 测试用例执行过程中，实时创建测试数据，通常称为 on-the-fly
5. 测试用例执行前，事先创建好开箱即用的测试数据，通常称为 out-of-box

基于 API 调用创建测试数据

直接通过 api 调用，由于 api 通常都有 token 机制来保护，所以实际项目中，通常会把对这些 API 的调用以代码的形式封装为测试数据工具
优点：测试产品的准确性直接由产品 API 保证
缺点：并不是所以测试数据都有相关 API 来支持
基于数据库操作创建测试数据
前提是产品功能正确，思路：

1. 手工方式。通过查阅产品设计需求文档和代码，找到相关的 sql 语句集合，或者直接找开发索要 SQL 语句集合
2. 自动方式。在测试环境中，先在只有一个用户的情况下，通过 GUI 页面操作数据的增删改，利用数据库监控工具获取所有业务表来修改记录，以此为依据开发 SQL 语句集

实时创建数据 on-the-fly

1. 在用例执行过程中实时创建数据，会导致测试的执行时间比较长。30% 都花在数据准备方面
2. 业务数据的连带关系，导致测试数据的创建效率特别低。举个栗子：创建订单数据，需要准备买家卖家的数据和订单商品的数据，最后才到创建这个订单的数据，执行效率很低
3. 实时创建数据对测试环境依耐性比较强。一点 api 接口出现问题，导致创建用户失败，无法进行登录用户操作

on-the-fly 和 out of box 进行互补

1． 对于相对稳定的，很少修改的数据，才用 out of box。比如买家账号，商品类目品牌
2． 对于一次性使用经常需要修改，状态经常变化的数据。建议使用 on the fly 方式
3． 用 on the fly 创建数据时，上游的数据可以才有 out of box 的方式提高测试效率。比如订单创建用 on the fly 方式，买家卖家商品数据采用 out of box 方式创建

以上内容摘取于极客时间

个人总结

测试脚本和数据的解耦（数据驱动），换做自己的话来说，就是要做到测试逻辑和测试数据的分离，有时候测试数据量比较大，测试逻辑比较复杂，代码混在一起，很难区分出哪些是测试逻辑和测试数据，会导致代码的可读性和后期的维护成本很高。既然想要做自动化测试就要做到可维护，可协作，可拓展，也要做到模块隔离，职责隔离，不然冲突会很严重。
页面对象（Page Object）模型，我个人理解是以页面为对象来封装页面的元素，这个时候就会涉及到分层思想，分层分为三个部分：元素层 + 操作层 + 业务层。
a) 元素层：获取定位元素
b) 操作层：对元素进行操作
c) 业务层：传入参数 进行业务操作
如果后期页面布局发生改变，要快速适配变更。可以直接操作元素层。