UI自动化脚本编写思路

                                                 项目页面自动化分享（二）

                                                                                   ——脚本编写思路

       在项目的开发和第一轮测试阶段，我花了部分时间来编写脚本。当我开始执行产出的批量脚本时，很多脚本失败，这在平时进行产品维护编写页面自动化过程中是没遇到的。

      通过对项目页面自动化的不同之处进行了思考和分析，原因如下：1.前端产出的demo页面，某些控件名发生改变，脚本编写完成后，花时间修改控件名；2.单个脚本实现的功能校验点，是以最小的测试集为单位，包含了多条tc的校验，每条tc都包含页面的操作，因为项目前期，项目质量不高，单个tc的页面操作留下的数据，容易对下个tc的页面操作及数据校验造成影响，脚本失败率高，自动化发现的bug精准率低。3.脚本代码可读性不强，相同的修改点，涉及到批量脚本相同代码的修改。

      因此，在这次项目中，只需要1个小时完成的脚本，我却花了3倍的时间。更多的时间用在了脚本的优化。虽然用了更多的时间，但自己总结了一套编写项目页面自动化脚本的思路。

     图1 是项目的一个功能模块。和红框标识的平行的内容是最小的测试集。图2 是其中一个最小的测试集(红框标识的测试集)里的多条tc。






 

        1个脚本实现的校验点的粒度应该怎样划分呢？一种方式是，我们可以单个脚本只包含1条tc的校验，这样编写脚本的好处是，校验点单一，方便问题排查。但产生的问题是，一方面，项目中实现页面自动化的tc数几十上百，产生的脚本数很多，难于维护，另一方面，运行1个脚本就执行1次淘宝页面登陆和退出操作，如此的操作，过于频繁。另一种方式是，我们也可以单个脚本包含多条tc的校验，这样编写的好处是，脚本数相对较少，方便维护，淘宝页面登陆和退出操作大量减少。但问题是，1个脚本里单个tc的页面操作留下的 数据，容易对下个tc的校验点产生干扰，脚本发现bug精准率低。

       面对1个脚本实现的校验点的粒度划分，我在第二种方式上做了一些优化，避免了问题的产生。

我以最小测试集为单位，产出1个脚本。有多少这样的测试集，就有多少脚本数。1个脚本实现了单个最小测试集里所有tc的校验，对不能实现页面自动化的tc，在图中用特殊的icon作标识(图2)，进行手工测试。

       图3是1个脚本的编写思路：






       3个红框里的方法是Automan提供的脚本编写基本结构。在这次项目里，封装的NO.1方法，是对操作页面的抛出，NO.2方法是数据库的数据清理，NO.3方法，是执行NO.2前查询数据，若数据没问题，不做数据清理，NO.4方法是页面的数据清理，NO.5方法是单个tc的校验。用这样的思路，将代码封装成一个个方法。方便process()方法里的调用。代码简洁，可读性较强。

      图4是主方法process()对其它方法的调用，实现了整个脚本的运行：




    

        步骤1完成脚本运行前数据的校验和清理，步骤2完成操作页面的抛出和页面上的数据清理，步骤3是完成1条tc的检验后再次清理数据，再次进入要操作的页面，接着调用下1条tc的校验方法。如此的数据清理，很好的解决了上文所述的问题：单个tc的页面操作留下的 数据，容易对下个tc的校验点产生干扰。

       在这里，要说明一点，脚本运行失败后，为了更好的排查是哪条tc的方法校验出了问题，可以在每条tc方法的校验里，在结果

不正确的if分支写上明确的错误信息：





      建议调用verify开头的校验方法，即使单个tc校验出错，脚本仍能很好完成运行，不会因为校验错误就中断运行。这里的错误信息简明扼要的包含操作和错误的结果，方便自己快速定位bug。

        这里分享的脚本编写思路，适用于在页面上点击相应控件后，涉及到页面展示或数据库的校验，产品大部分的页面自动化都可以用这样的编写思路完成脚本。

        脚本经过这样的编写整理后，整批脚本可运行率大大提高，项目的页面自动化就这样顺畅的实现了。

        项目页面自动化的实现，最大的瓶颈是时间！时间的争取，一方面体现在批量脚本优化，用了上面的编写思路，优化时间可控了，另一方面，就是批量脚本的编写。

        如何提高编写效率？这次项目深有体会，请见下一段分享。