测试脚本和数据的解耦

文章内容来源于《软件测试52讲》

如果在测试脚本中硬编码（hardcode）测试数据的话，测试脚本灵活性会非常低。而且，对于那些具有相同页面操作，而只是测试输入数据不同的用例来说，就会存在大量重复的代码。

依旧以百度搜索为例，上一篇文章中实现的百度搜索的测试用例，当时用例中搜索的关键词是“python”，假设我们还需要测试搜索关键词是“Java”和“go”的场景，如果不做任何处理，那我们就可能需要将之前的代码复制 3 份，每份代码的主体完全一致，只是其中的搜索关键词和断言（Assert）的预期结果不同。

更糟糕的是，界面有任何的变更需要修改自动化脚本时，之前复制出来的三个脚本都需要做相应的修改。一旦页面元素名字发生了变化，就需要修改所有脚本中 findElement 方法的 by.name 属性。如果有 100个或者更多的脚本呢，就会发现脚本的维护成本实在是太高了。

测试数据和测试脚本分离

也就是说测试脚本只有一份，其中需要输入数据的地方会用变量来代替，然后把测试输入数据单独放在一个文件中。这个存放测试输入数据的文件，通常是表格的形式，也就是最常见的 CSV 文件。
然后，在测试脚本中通过 data provider 去 CSV 文件中读取一行数据，赋值给相应的变量，执行测试用例。接着再去 CSV 文件中读取下一行数据，读取完所有的数据后，测试结束。CSV 文件中有几行数据，测试用例就会被执行几次。

优点
1、数据驱动很好地解决了大量重复脚本的问题，实现了“测试脚本和数据的解耦”。

2、数据驱动测试的数据文件中不仅可以包含测试输入数据，还可以包含测试验证结果数据，甚至可以包含测试逻辑分支的控制变量。

3、数据驱动测试的思想不仅适用于 GUI 测试，还可以用于 API 测试、接口测试、单元测试等。

页面对象（Page Object）模型

利用模块化思想，把一些通用的操作集合打包成一个个名字有意义的函数，然后 GUI 自动化脚本直接去调用这些操作函数来构成整个测试用例，这样 GUI 自动化测试脚本就从原本的“流水账”过渡到了“可重用脚本片段”。

优点
1、解决了脚本可读性差的问题，脚本的逻辑层次也更清晰了；
2、解决了通用步骤会在大量测试脚本中重复出现的问题
操作函数可以被多个测试用例共享，当某个步骤的操作或者界面控件发生变化时，只要一次性修改相关的操作函数就可以了，而不需要去每个测试用例中逐个修改。

页面对象模型的核心理念是，以页面为单位来封装页面上的控件以及控件的部分操作。而测试用例使用页面对象来完成具体的界面操作。

---

---

如何把控操作函数的粒度？

一个操作函数到底应该包含多少操作步骤才是最合适的，在很大程度上取决于项目的实际情况，以及测试用例步骤的设计，并没有一个放之四海而皆准的绝对标准。

1、如果粒度太大，就会降低操作函数的可重用性。
极端的例子：百度搜索的案例，把“登录”“搜索”“登出”的操作作为一个操作函数。
2、如果粒度太小，也就失去了操作函数封装的意义。
极端的例子：把每一个步骤都作为一个操作函数。
3、更糟糕的是，在企业实际自动化测试开发中，每个测试工程师对操作函数的粒度理解也不完全相同，很有可能出现同一个项目中脚本粒度差异过大，以及某些操作函数的可重用性低的问题。

但是，脚本粒度的控制还是有设计依据可以遵循的，即往往以完成一个业务流程（business flow）为主线，抽象出其中的“高内聚低耦合”的操作步骤集合，操作函数就由这些操作步骤集合构成。

比如，对于“用户注册”这个业务流程，其中的“信用卡绑定”操作就会涉及多个操作步骤，而这些操作在逻辑上又是相对独立的，所以就可以包装成一个操作函数。也就是说，业务流程会依次调用各个操作函数，来完成具体的业务操作。

如何衔接两个操作函数之间的页面？

完成一个业务流程操作，往往会需要依次调用多个操作函数，但是操作函数和操作函数之间会有页面衔接的问题，即前序操作函数完成后的最后一个页面，必须是后续操作函数的第一个页面。

如果连续的两个操作函数之间无法用页面衔接，那就需要在两个操作函数之间加入额外的页面跳转代码，或者是在操作函数内部加入特定的页面跳转代码。

业务流程（Business Flow）抽象

业务流程抽象是，基于操作函数的更接近于实际业务的更高层次的抽象方式。
基于业务流程抽象实现的测试用例往往灵活性会非常好，可以很方便地组装出各种测试用例。

案例：已注册的用户登录电商平台购买指定的书籍
业务流程： 依次是完成用户登录、完成书籍查询、完成书籍购买、完成用户登出

这 4 个业务流程都可以作为独立的类进行封装，可以被很方便的重用并灵活组合，类的内部实现通常是调用操作函数。而操作函数内部，则是基于页面对象模型完成具体的页面控件操作。

对于每一个业务流程类，都会有相应的业务流程输入参数类与之一一对应。
具体的步骤通常有这么几步：
1、初始化一个业务流程输入参数类的实例；
2、给这个实例赋值；
3、用这个输入参数实例来初始化业务流程类的实例；
4、执行这个业务流程实例。

执行业务流程实例的过程，其实就是调用操作函数来完成具体的页面对象操作的过程。

优点
1、业务流程的封装更接近实际业务；
2、基于业务流程的测试用例非常标准化，遵循“参数准备”、“实例化 Flow”和“执行 Flow”这三个大步骤，非常适用于测试代码的自动生成；
3、由于更接近实际业务，所以可以很方便地和 BDD 结合。
BDD 就是 Behavior Driven Development，即行为驱动开发