之前在一個項目組，寫了兩次粗淺的自動化方面的思考
關於自動化測試的一些思考（一）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.測試開發和移動自動化測試
這也是我極為糾結的，以后的趨勢是往移動方面走，未來是往移動方面走還是做測試開發？