测试脚本和数据的解耦（数据驱动）
把测试数据和测试脚本分离，也就是说测试脚本只有一份。其中需要输入数据的地方用变量代替，然后把测试输入的数据单独放到一个文件中。这样存放数据输入的文件通常是表格的形式，也就是我们常见的 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 如何变化，都会对所有的测试代码都是不影响的，反之亦然。当然这个例子还是有改进空间的，例如将测试数据与测试代码再分离，进一步提高测试代码的可读性和复用性，降低维护成本。
## 自动化测试过程中的测试数据
从创建的技术手段上来讲，创建测试数据的方法主要分三种：
- API 调用
- 数据库操作
- 综合运用 API 调用和数据库操作 从测试的时机来讲，创建测试数据的方法主要分为两种：
- 测试用例执行过程中，实时创建测试数据，通常称为 on-the-fly
- 测试用例执行前，事先创建好开箱即用的测试数据，通常称为 out-of-box
基于 API 调用创建测试数据
直接通过 api 调用，由于 api 通常都有 token 机制来保护，所以实际项目中，通常会把对这些 API 的调用以代码的形式封装为测试数据工具
优点：测试产品的准确性直接由产品 API 保证
缺点：并不是所以测试数据都有相关 API 来支持
基于数据库操作创建测试数据
前提是产品功能正确，思路：
- 手工方式。通过查阅产品设计需求文档和代码，找到相关的 sql 语句集合，或者直接找开发索要 SQL 语句集合
- 自动方式。在测试环境中，先在只有一个用户的情况下，通过 GUI 页面操作数据的增删改，利用数据库监控工具获取所有业务表来修改记录，以此为依据开发 SQL 语句集
实时创建数据 on-the-fly
- 在用例执行过程中实时创建数据，会导致测试的执行时间比较长。30% 都花在数据准备方面
- 业务数据的连带关系，导致测试数据的创建效率特别低。举个栗子：创建订单数据，需要准备买家卖家的数据和订单商品的数据，最后才到创建这个订单的数据，执行效率很低
- 实时创建数据对测试环境依耐性比较强。一点 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) 业务层：传入参数 进行业务操作
如果后期页面布局发生改变，要快速适配变更。可以直接操作元素层。