Software Testing - UI自动化测试常用设计模式之装饰器（Java）

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

装饰器，适配器和代理我觉得可以不用分得那么清， 都是为了使现有的类的行为满足我们新的需求，而做的一层封装。 最经典的例子就是 java io 中的高级流，低级流了。 感兴趣的同学可以去看看。 那么在 UI 自动化中会有什么情况会用到呢？ 最常用的就是重试的功能。 UI 自动化是出了名的不稳定的， 有很多公司都会启用失败重跑的功能。 记得我再外包那些年的时候， 经历过的国外公司几乎都会在 UI 自动化中实现失败重跑的功能。逻辑很暴力，当 case 运行失败的时候就重跑整个 case。 这种暴力的做法优缺点很分明。
优点：

• 实现简单，一些测试框架比如 testng 已经支持这种功能 缺点：
• 失败的 case 也会进入 report 中，要对 report 单独处理
• 暴力的不管三七二十一，只要失败就重跑的策略会在很多时候大大的增加了测试的执行时间。 比如本来就是 bug 引起的失败还是会去重新运行的话，最终还是会失败的，白白的浪费了执行的时间和资源。尤其是在像我们这种有很多长时间的异步任务的产品，这种策略更加无法忍受。

鉴于上面说的缺点， 我们希望可以有重试的功能， 但是还比较希望能够控制重试的执行粒度。比如运行时间短的，成本较低的，容易出错的，UI 操作复杂的是可以重试的， 但是那些运行时间长的，不容易出错的非 UI 任务我们是不重跑的。 比如对于我们的产品来说，在 UI 上设置算子的配置，组件算子的 dag 图，这些都是 UI 操作，运行时间较短，但是大量的 UI 操作是比较容易出错的。 但是这些算子一旦运行起来，就都是后台的操作，UI 上没有任何变化，这时候 case 就是在那里自旋等待，轮询算子状态而已，一般来说，只要算子运行失败了，那基本就是真失败了，就算再跑一次也大概率还是会失败的，即便不是 bug，那不管是因为环境问题还是集群问题，都不是一个失败重试能解决的。 所以我们要重试的就是组装 Dag 的操作。 还记得上一次说建造者模式中的 DAGBuilder 么？ 是的，我们现在就是要对它进行失败重试，dagBuilder 只负责构建 UI 上的复杂操作，并不负责执行和等待后台的任务结束，正是把构建和执行拆分了开来，正合适进行失败重跑的场景 (这里也体现出设计原则中的一个类只负责一件事的好处)。 那么问题来了， 原本的 DagBuilder 就只是一个在 UI 上构建 DAG 图的操作，并没有失败重跑的操作。 而我们也并不希望把失败重跑的功能加到 DAGBuilder 里面， 一来是因为我们要遵循设计原则，只让一个类负责尽量少的事情。 二来是有些情况下，我们也希望没有失败重跑的功能，直接将异常抛出来。由调用方处理。 所以我们使用装饰器模式， 封装一个装饰器类。 如下：

• 装饰器类可以实现被装饰的 DagBuilder 的接口，保持接口兼容和使用方式一致
• 装饰器类在创建时传递被装饰的对象，然后在方法中调用被装饰的 DagBuilder 的方法。并添加自己的新功能， 也就是失败重跑。

上面截图中，就是在 dagBuilder 抛出异常后，捕获异常，然后重置页面初始状态 (刷新页面) 重新调用 DagBuilder 的方法。 使用的时候如下：

PS： 这里发现我们只对 dagBuilder 做了失败重试， 大家会发现上面的登录，页面切换，创建 project 等操作并没有重试的功能。 因为这些操作简单，并且足够稳定， 一旦失败，除开 bug 的原因就是环境发生了问题或者是 UI 发生了变化而脚本没有及时更新。不论哪种情况都不是重试能解决的， 当然也有一种情况是环境的服务出现了一些性能问题， 比如我们曾经遇见过集群 IO 负载过高，导致一个接口请求就数秒甚至 10 几秒。 所以有时这些稳定简单的操作会超时，这时候重试是有可能会让这些操作跑过去，但是我们是不会这么做的。 因为环境本身就出现了问题，这里我们是希望 case 就这么直接失败的，减少不必要的运行时间。所谓失败了也要快速的失败，快速的反馈。

PS2：使用 python 的同学实现失败重试就简单多了， python 自带装饰器的语法糖。