关于自动化测试的一些思考（三）

以前在一个项目组，写了两次粗浅的自动化方面的思考

关于自动化测试的一些思考（一）http://www.cnblogs.com/tobecrazy/archive/2012/12/18/2824248.html

关于自动化测试的一些思考（二）http://www.cnblogs.com/tobecrazy/archive/2013/06/10/3131338.html

这两份都是刚作自动化测试的时候可以想到的，回顾一下，使人唏嘘。以前作的主要是基于server端的自动化，而且是Linux平台，

因此作自动化相对来讲比较容易。由于不须要考虑gui变化，关键字驱动就能够实现测试框架。

现现在作的web端测试，主要基于selenium测试框架的二次开发的框架。如今将项目中遇到的实际问题和一些思考分享一下。

接下来会详细介绍项目背景，团队以及本身的一些思考总结。

项目背景：B/S架构的web网站，属于长期产品，不断迭代（可参考淘宝），较复杂的业务逻辑测试框架比较完善，基于selenium二次开发深度定制。

团队：Global Team,作自动化的和作手工测试的严格分开，相对独立（专职的automation QA和manual QA）。

作手工测试的熟悉业务逻辑，主要参与设计case；作自动化的主要把manual QA的case

翻译成自动化的case，每一个release不停的run

遇到的实际问题:分为团队方面和测试框架的一些问题

首先说一下团队方面：

　　之前的团队里manual QA 和automation QA没有严格区分，case是咱们本身写的，因为业务逻辑没有那么复杂能够说是驾轻就熟，手到擒来。

如今的团队，因为automation QA focus在写自动化和跑Case，出现的最大的问题以下：

　　a.不懂业务逻辑，测出问题不能判定是否是bug，反而要通过manual QA去二次确认。

　　思考：automation QA要不断学习，充分熟悉业务逻辑，而且能站在customer角度考虑问题，留心一些不合理的设计。

      b.若是case 比较久远，而case缺少维护，这要已经被自动化的case维护起来比较难，逻辑已经不清楚。

　　思考：须要常常花时间和manual QA沟通，按期更新case

      c.绩效考核不够科学，考核的一个重要的指标，code coverage， 因为case是manual QA设计的，code coverage 不是说提升就能提升。

　　　考核的另一个指标，翻译成自动化的case的数目，若是某个component被新增或者废弃，都不能作相应的调整，由于这个指标是年初制定。

     这点仍是管理团队思考吧

     固然，以上都须要花费太多的时间，固然咱们的时间主要花费在翻译case、跑case并分析。

 下面是框架的问题：

　　首先自动化框架已经很完善，有专职的architect维护，我说的问题并非真正架构上的，而是维护起来的实际问题。

      a. 页面变化

      页面变化几乎是每一个作web自动化头疼的问题，由于原来的页面元素和业务逻辑都会有相应的变化，之前全部的验证点都失效。而web 产品版本迭代免不了

页面变化。框架是一个好框架，关键是用的人，因为水平的缘由，致使后期维护苦不堪言。上个图描述一下框架，之前的case，没有把 page action组装起来

直接在每一个case里写，这要代码重用性和可维护性比较差。若是页面元素变化了，要修改到每一个case里边。

若是使用actions，直接修改page和page action这要case不须要变化啦

思考： 要增长case的可维护性和代码的可重用性，就要进一步吧相应的共性的东西抽象出一个个方法，让容易变更的部分放在最底层

　　b. 由于整个框架是基于selenium（testng）的，开源的框架，好处多多（省钱，知道源代码能够二次开发深度定制），可是缺点也很多。

case 不够稳定，经常出现找不到Web element的现象。可能网速太差，或者自己某些方法不够科学，wait时间过短。也多是xpath写的不够科学。

 

     思考：加强case的稳定性，须要在case里边设置科学的wait time和重复刷新，另外一方面xpath写的时候要考虑到页面万一有微调的时候不受影响。

以上就是我对项目的一个初步总结。

接下来是我本身的一些想法：

　　1.自动化测试和手工测试

 　　　自动化和手工测试各司其职，因为咱们框架比较成熟，在java代码技巧上没有特殊的要求，由于方法都是封装好的，这要对成长不利。

固然手工测试也很厉害，须要懂业务也要设计case，私觉得测试能力主要体如今设计case的能力上。因此，在作自动化测试的同时，要思考为何

case这么设计，要试着设计case去cover那些manual QA考虑不到的地方。

     2.测试开发和移动自动化测试

       这也是我极为纠结的，之后的趋势是往移动方面走，将来是往移动方面走仍是作测试开发？