關於自動化測試的一些思考（三）

以前在一個項目組，寫了兩次粗淺的自動化方面的思考

關於自動化測試的一些思考（一）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.測試開發和移動自動化測試

       這也是我極爲糾結的，之後的趨勢是往移動方面走，將來是往移動方面走仍是作測試開發？