这是我购买的"极客时间"上的一套课程的笔记，总共52讲，定期对其中的内容做一笔记，巩固学习内容。
14 更接近业务的抽象：让自动化测试脚本更好地描述业务
这一篇介绍了GUI自动化测试中“业务流程（business flow）”的概念、核心思想以及应用场景。
操作函数的粒度：一个操作函数到底应该包含多少操作步骤才是最合适的。
很大程度上取决于项目的实际情况，以及测试用例步骤的设计。
可以遵循的设计依据：以完成一个业务流程为主线，抽象出其中的“高内聚低耦合”的操作步骤集合，操作函数就由这些操作步骤集合构成。
衔接两个操作函数之间的页面
完成一个业务流程操作，往往会需要依次调用多个操作函数，但是操作函数之间会有页面衔接的问题。
业务流程抽象
基于操作函数的更接近于实际业务的更高层次的抽象方式。基于业务流程抽象实现的测试用例往往会灵活性非常好，可以很方便地组装出各种测试用例。
在这段伪代码中，调用了4个业务流程，每个都是作为独立的类封装的。类的内部实现通常是调用操作函数。而操作函数内部，则是基于页面对象模型完成具体的页面控件操作。
对于每一个业务流程类，都会有相应的业务流程输入参数类与之一一对应。具体的步骤通常有如下几步：
- 初始化一个业务流程输入参数类的实例；
- 给这个实例赋值；
- 用这个输入参数实例来初始化业务流程类的实例；
- 执行这个业务流程实例。
执行业务流程实例的过程，其实就是调用操作函数来完成具体的页面对象操作的过程。
分析伪代码发现，每个业务流程都可以接受不同的起始页面。通过这种方式可以很方便地完成两个业务流程之间的页面衔接。
这就需要在它的内部对不同的初始页面做出相应的处理，以保证这个业务流程真正开始的页面是在所传入的页面。
由于业务流程存在分支的可能性，每个业务流程执行完成的最终页面也不是唯一的，可以使用getEngPage方法拿到这个业务流程执行结束后的最后页面。
具体的，查看原文中作者对代码的详细解读，就可以很清楚的理解，业务流程之间的页面衔接是如何实现的。
业务流程的优点：
- 业务流程的封装更接近实际业务；
- 基于业务流程的测试用例非常标准化，遵循“参数准备”、“实例化Flow”和“执行Flow”这三个大步骤，非常适用于测试代码的自动生成；
- 由于更接近实际业务，所以可以很方便地和BDD结合。BDD就是行为驱动开发。
业务流程的核心思想是，从业务的维度来指导测试业务流程的封装。由于业务流程封装通常很贴近实际业务，所以特别适用于组装面向终端用户的端到端（E2E）的系统功能测试用例，尤其适用于业务功能非常多，并且存在各种组合的E2E测试场景。
【心得】
以前做GUI自动化测试的时候，没有用到这种方法，基本上是按照操作步骤一溜烟的走下来，对每个操作步骤及获取元素的方式进行了封装，使得用例编写人员无需编写真正的代码，而只要根据规则编写操作步骤即可。
坏处就是可读性没有这么高，当操作十分复杂的时候，操作步骤会特别多而且繁琐，并且整个系统的用例中，存在大量重复的操作步骤（虽然引入了子用例的方式，不必每个用例都从头开始写所有的操作步骤），可读性并不是很强，仅适合比较小型，且相关人员对系统功能都比较熟悉的情况。
当时自己也比较困惑，有没有更好的方式。由于种种原因，自己并未在这个方向上进行更深一步的探索，仅仅是完成了当时的项目，但是相关的疑问一直没有得到解答。
再来看作者的方法，适用性比我之前做过的那个要强很多，虽然用例编写人员仍然需要编写真正的代码，但是由于做到了标准化，稍加培训，也不是特别难的事情。
当然，重点还是在操作函数的编写以及业务流程的抽象上，这就需要在具体的项目中进行实践了。
