也談自動化測試開發(2)

　　如何協同開發?自然是加入版本控制?，F在的自動化框架用的版本控制是Git，這個比較火哦!多人協同開發，提交代碼，肯定會有conflict。我們的做法是這樣的，除了master分支，每個人在自己本地建個開發分支，每次提交代碼前，先從Git Server上checkout最新代碼到master分支，然后，在本地的開發分支和master分支merge，最后commit代碼。

　　自動化腳本如何命名?我們的自動化腳本都是從手動測試用例挑選出來的，我們希望做到自動化腳本和手動腳本之間有個關聯，但同時又要做到，只要看到這個自動化腳本的Title,就能知道這個自動化腳本的大概的測試意圖。我們是這樣做的，ModuleName_FilterName+ID， 這個ID便是手動測試用例的Define ID。

　　Keyword的粒度怎么把握?關鍵字相當于手動執行的一個執行步驟，我們是這樣做的，首先Review手動執行的測試用例，抽取出通用的步驟，實現關鍵字。但如果關鍵字的粒度做得太細，那么關鍵字的數量會比較龐大，但粗了的話，關鍵字參數的形式就會比較復雜，對于構造自動化腳本的同事來說，就需要學習。這個粒度需要把握好，同時，對于自動化關鍵字參數，需要有詳盡注釋，使用格式范例。

　　自動化腳本中的變量如何維護?一般會把自動化腳本中的一些跟執行環境相關的參數以變量的形式抽取出來，存放在配置文件里，這樣一來，在部署自動化測試環境的時候，就只需要修改這些跟環境相關的配置文件即可以。但這個配置文件會隨著自動化測試用例的增加，而變得臃腫。

　　自動化腳本中運行結果如何判斷?自動化測試腳本，如同手動執行測試用例一般，也有預期結果，實際結果的比對，如果兩則不一致，則認為這個自動化腳本Fail。剛開始我們是這樣做的，將預期結果一參數的形式傳給一個關鍵字，這個關鍵字在后臺會比較實際結果，如果不一致fail。剛開始也覺得沒問題，后來發現，因為環境因素，一些預期結果是會發生變化的，這時候，我們必須修改自動化腳本。后來的做法是這樣的，先dump出一份預期結果，存放在本地，執行自動化自動化腳本的時候，再Dump出一份實際結果，然后比對這二者。這樣就避免了頻繁改動自動化執行腳本了。

　　執行結果的容錯性?如何確保執行結果是可靠的，在自動化關鍵字的實現過程中，會加入一些容錯機制。舉個簡單的例子，發一封帶特性附件的郵件，命中了一個策略。這時候，會在log數據庫中產生一條記錄。在實現自動化關鍵字的時候，可能會遇到這樣的情況，當你去檢查log數據庫的時候，很有可能那條log記錄還沒生成好，這時候如果直接判斷，自然會fail。我們是怎么提高容錯性的呢?很簡單的方法，就是加入了一定時間的延時，比如循環檢查多少次，每次delay一秒等方法，這就帶來了另一問題，在執行時間會延長。

　　及時獲取RD幫助。在實現DLP功能時，發現程序重新載入配置會比較耗時，如果自動化腳本不能重新載入完成，就發郵件的話，是無法命中你的配置策略的。這時候，需要尋求RD幫助，他們在后臺提供了hidden key。當enable這個hidden key后，重新載入完成后，程序會在console上打印出提示信息，這時候，我們的自動化腳本只需要去檢查這些提示信息有沒有生成，就可以判斷是否重載完成，再發郵件。

　　在自動化測試開發，維護過程中，成本最大的是什么?覺得一方面是測試數據的維護。另一方是因為產品功能方面的變動引入的自動化腳本需要修改方面的成本。

　　自動化測試的應用場景?對于項目而言，最大的價值是什么?就我們項目而言，主要還是把手動測試用例變為自動化測試用例，也就是所謂的黑盒、功能性自動化實施。當初定位的時候，也是想做成自動化回歸測試的，縮短回歸測試時間，提高回歸測試效率，確保代碼優化、及新引進的代碼不會影響舊有功能。也沒指望自動化測試能發現手動測試發現不了的問題。理想的狀態時這樣的，自動化測試和CI系統集成，當出了一個新的build，自動化框架能夠自動安裝新build，執行自動化腳本，完了以后將執行結果通過郵件發布出來。

　　有沒有方法把關鍵字的實現提前?而不是等到功能穩定后，再開始做自動化?？催^Junit中的mock的概念，但具體怎么做，還不清楚，下階段學習下!

　　現在看來，一套自動化測試的開發也涉及到：項目本身需求分析、hight-level 設計、框架開發、自動化腳本實現、各種規則制定、多方面協作等，所以需要把自動化測試開發當做項目來做哦!

原文轉自：http://www.uml.org.cn/Test/201306283.asp