都講自動化測試開發，當然要把開發自動化測試架構也當做一個項目來做。這時候，就需要考慮應該選擇何種類型的自動化測試架構：資料驅動、關鍵字驅動、還是junit，testng ？ 抑或直接利用現有的開源自動化測試架構，如robot framework 。無法講這幾種類型的架構，孰優孰劣，關鍵是認清項目實際，選擇最适合的。講一些題外話，就java學習者而言，junit3.x的源碼是再好不過的教材了，junit架構運用到了大量的設計模式，反射機制。
自動化架構，說白了就是流程的封裝啦。那麼一個自動化架構應該包括哪些流程呢？來看看下面這兩幅架構圖吧。
第一幅圖講解了一套自動化測試是由自動化架構，自動化腳本，關鍵字組成的。第二幅圖描述了自動化架構的流程：根據配置挑選要執行的測試用例，解析自動化執行腳本，将自動化執行腳本送給自動化執行引擎，生成log檔案，最後生成report。
自動化架構、關鍵字的開發周期怎麼安排，怎麼預估effort ？項目自動化測試架構，自動化腳本開發也分成了兩iteration。 第一個疊代期間，完成自動化架構主要流程，完成主要關鍵字，建構smoke部分的自動化腳本。第二次疊代，進一步完善自動化架構，接着添加關鍵字，完成regression部分自動化腳本。剛開始，effort的估計沒有把握，因為有些關鍵字的實作可能比較困難，這時候需要及時sync風險。第二個階段，effort的估計就有底了。
如何協同開發？自然是加入版本控制。現在的自動化架構用的版本控制是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 設計、架構開發、自動化腳本實作、各種規則制定、多方面協作等，是以需要把自動化測試開發當做項目來做哦！
====================================分割線================================
最新内容請見作者的github頁：http://qaseven.github.io/