UI-自动化常用设计模式.docx

? ? UI 自动化常用设计模式 (二) ? ? 作者：孙高飞 ? 状态模式 状态模式之所以常用是因为在我们的很多业务逻辑中都会有不同状态的出现，比如订单的状态，任务的状态。而不同的状态下UI上会有不同的行为。 比如不同的控件的展示， 不同的报错信息等。 我们往往需要验证不同状态下的逻辑。 但是我们的状态往往比较多(一般怎么都会有个5，6种吧)。 所以我们需要一种合适的方法来组织和管理这些状态下的行为。举个例子， 在我们的产品中，每一个算子都有：未配置，配置成功，等待运行，运行中，运行成功，运行失败和终止这6种状态。算子在每种状态下显示的控件和能操作的逻辑是不一样的。我们一个最简单的需求就是，在case中验证每一种状态下，UI控件的展示是符合需求的。 比如处于未配置状态的算子是不能运行和停止的， 运行中的算子是可以看见停止按钮但是无法显示运行按钮，相反的配置完成的算子是可以显示运行按钮但是不能展示停止按钮的。? ? 上面是我们的状态抽象类的一部分代码截图。 里面看到有一个抽象方法是validateNodeUI， 用来执行验证操作。 不同状态的子类有着不同的逻辑。 比如下面这个处于Running状态的子类。 ? 这个running状态的子类覆盖实现了父类的validateNodeUI方法，running状态的算子只能看到停止按钮。 然后我们再看看终止状态的算子和运行成功状态的算子。 ? ? 终于状态的算子是可以重新运行的但是看不到停止按钮， 而运行成功的算子因为已经到了算子的最终状态， 所以它既不能运行，也不能停止。 这样我们就有了我们的状态类。 接下来我们看怎么使用这些状态类。 我们需要在所有算子的父类(Node)里写一个查询当前状态的方法。意思是通过UI来查看当前算子的运行状态是哪一种并返回。然后在自己验证控件的方法中，使用相应的状态类。如下： ? PS: 也许会有小伙伴问上面写了那么多if else来创建各种不同的状态类， 为什么不用工厂模式来做？ 那是因为整个项目中只有这一个地方使用了状态类， 也就没有必要专门封装一个工厂类了。 大家要小心过度设计哦~~ 这样我们的每一种状态下的UI控件的验证就都写好了。 case中使用的时候入下： ? 当然状态模式中不只有验证UI控件这一个功能。 由于不同的状态下拥有着不同的行为，假如由于case编写者的失误， 非要在终止状态下的算子上点击终止按钮， 那肯定会在查找控件超时后抛出一个element not found的error出来。 这样有两个不好的地方： element not found 的报错信息并不友好，尤其是有些控件的查找方式用xpath查找的，用非文案的方式查找的。 让会再看report的时候并不能很容易看出来错误出在了哪里。需要到代码里去看或者debug。 一般查找控件的API都是自旋等待并设定超时时间的，比如我再项目中设置的隐式等待时间是10s. 要等10s后才抛出这个异常也是满耗时的。我们希望立刻就抛出这个错误。 所以不同状态的子类中可以去实现不同的行为， 如下： ? 可以看到停止状态的子类的stop方法会直接抛出一个异常。 只要一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为，就可以使用状态模式 接下来分析一下状态模式的优点： 在产品复杂业务逻辑和状态流转下， 可以有效的以一种结构化的方式把我们的代码组织起来。 如果我们不使用状态模式，会导致在case或者page类中出现大量的if else。导致后期的维护成本和可读性都很差。 装饰器模式 装饰器，适配器和代理我觉得可以不用分得那么清， 都是为了使现有的类的行为满足我们新的需求，而做的一层封装。 最经典的例子就是java io中的高级流，低级流了。 感兴趣的同学可以去看看。 那么在UI自动化中会有什么情况会用到呢？ 最常用的就是重试的功能。 UI自动化是出了名的不稳定的， 有很多公司都会启用失败重跑的功能。 记得我再外包那些年的时候， 经历过的国外公司几乎都会在UI自动化中实现失败重跑的功能。逻辑很暴力，当case运行失败的时候就重跑整个case。 这种暴力的做法优缺点很分明。优点： 实现简单，一些测试框架比如testng已经支持这种功能 缺点： 失败的case也会进入report中，要对report单独处理 暴力的不管三七二十一，只要失败就重跑的策略会在很多时候大大的增加了测试的执行时间。 比如本来就是bug引起的失败还是会去重新运行的话，最终还是会失败的，白白的浪费了执行的时间和资源。尤其是在像我们这种有很多长时间的异步任务的产品，这种策略更加无法忍受。 鉴于上面说的缺点， 我们希望可以有重试的功能， 但是还比较希望能够控制重试的执行粒度。比如运行时间短的，成本较低的，容易出错