项目页面自动化分享（二）——脚本编写思路

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

　　通过对项目页面自动化的不同之处进行了思考和分析，原因如下：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精准率低。