Software Testing - UI自动化测试常用设计模式之策略（Java）

分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击人工智能教程

策略模式也是非常常用的，甚至很多时候它是其他模式的基础。它的思想也特别简单，当初它诞生的原因是为了摆脱大量的if...else...，把每个条件分支做成一个策略类。讲一下在UI自动化中我们怎么做，举一个最简单的例子，比如在某种APP的测试中，大量的Case都需要经过如下的操作步骤：

1. 打开浏览器

2. 登录

3. 创建一个项目

4. 创建一个组件

5. 在组件页面上Build一个Feature

6. 运行Feature并等待运行结束

既然大量的Case都需要执行上面的操作，那我们当然就希望能做到代码复用，所以就写了一个方法来做这个事情。但是我们发现这些步骤中有一个操作是无法预测的，也就是如何Build一个Feature，我们索性把build DAG的操作定义为一个接口，它只有一个方法，就是build()，意思是这个方法要实现Build一个Feature的操作。但具体Build一个什么样的Feature，由子类自己去实现。 

于是我们就有了很多Feature的子类，他们分别实现不同Feature的Build操作。

于是我们就可以创建出这个可以用来复用的方法，这个方法需要传入一个FeatureBuilder的参数。

我们的产品的 DAG 如下

每个 DAG 中都有不同的算子组合在一起，形成一个图形。并且每个算子有它不同的配置。 要在 UI 上 build 一个 DAG 还是需要很多的操作的。 并且 case 之间要 build 的 DAG 的图形也是不一样的。 有的 case 需要 5 个算子组成一个图形， 有的 case 可能需要 10 个算子组成一个图形。 这些是完全不一样的操作， 也就是说虽然我们想写一个方法来封装上面所有的操作。但是其中构建 DAG 这一步是我们预先控制不了也复用不了的。这怎么办？ 所以我们索性把 build DAG 的操作定义为一个接口。 如下： 

它只有一个方法，就是 build()， 意思是这个方法要实现 build 一个 DAG 的操作。 但具体 build 一个什么图形什么配置的 DAG， 由子类自己实现。
于是我们有了很多固定图形的 dag 的子类， 他们分别实现不同的固定图形的 build 操作。 如下： 

于是我们创建这个可以用来复用的方法：

可以看到这个方法里我们执行了上面说的所有的步骤，比如打开浏览器，登录，跳转页面，创建工程等。 但是在 build 一个 dag 的时候，我们依赖一个 DagBuilder 类型的参数，也就是我们之前的定义的那个接口，当然这个 dagbuilder 使用了建造者模式，这个我们之后会讲。 现在我们在 case 中就可以很愉快的使用很少量的代码完成测试了。 如下：

当然熟悉函数式编程的同学会觉得这玩意非常眼熟， 实际上在 java8 中也完全可以使用 lamda 表达式来完成 DagBuilder 的构造。