之前在一个项目组，写了两次粗浅的自动化方面的思考
关于自动化测试的一些思考（一）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.测试开发和移动自动化测试
这也是我极为纠结的，以后的趋势是往移动方面走，未来是往移动方面走还是做测试开发？