如何把控操作函数的粒度？
操作函数的粒度：一个操作函数到底应该包含多少操作步骤才是最合适的。
很大程度上取决于项目的实际情况，以及测试用例步骤的设计。
可以遵循的设计依据：以完成一个业务流程为主线，抽象出其中的“高内聚低耦合”的操作步骤集合，操作函数就由这些操作步骤集合构成。
完成一个业务流程通常都需要依次调用多个操作函数，如果连续两个操作函数之间无法用页面衔接，我们就需要在函数间加入额外的页面跳转代码。
在解决如何把控操作函数的粒度以及页面衔接的问题上就此可以引出业务流程的概念
业务流程抽象
基于操作函数的更接近于实际业务的更高层次的抽象方式。基于业务流程抽象实现的测试用例往往灵活性会非常好，你可以很方便地组装出各种测试用例
从这个伪代码来看，拆分出来的4个业务流程都是作为独立的类封装的，可以被很方便的重用并灵活组合，类的内部实现通常是调用操作函数。而操作函数内部，则是基于页面对象模型完成具体的页面控件操作。对于每一个业务流程类，都会有相应的业务流程输入参数类与之一一对应，分为一下几步：
-
初始化一个业务流程输入参数类的实例
-
给这个实例赋值
-
用这个输入参数实例来初始化业务流程类的实例
-
执行这个业务流程实例
分析伪代码发现，每个业务流程都可以接受不同的起始页面。通过这种方式可以很方便地完成两个业务流程之间的页面衔接。这就需要在它的内部对不同的初始页面做出相应的处理，以保证这个业务流程真正开始的页面是在所传入的页面。由于业务流程存在分支的可能性，每个业务流程执行完成的最终页面也不是唯一的，可根据实际情况而定。
总的来说，执行业务流程实例的过程，其实就是调用操作函数来完成具体的页面对象操作的过程。
业务流程的核心思想
从业务的维度来指导测试业务流程的封装。由于业务流程封装通常很贴近实际业务，所以特别适用于组装面向终端用户的端到端（E2E）的系统功能测试用例，尤其适用于业务功能非常多，并且存在各种组合的E2E测试场景。
优点：
-
业务流程的封装更接近实际业务；
-
基于业务流程的测试用例非常标准化，遵循“参数准备”、“实例化Flow”和“执行Flow”这三个大步骤，非常适用于测试代码的自动生成
-
由于更接近实际业务，所以可以很方便地和BDD结合。BDD就是行为驱动开发