題記：今晚一個人跑到杭州窩在賓館無所事事，也睡不著，就把這幾天來關于自動化測試的探討記錄下來，也給自己一個機會，逼著自己好好反思這一年多來關于自動化測試的點滴。其實，我也只是接觸過兩套自動化框架，一是項目組開發、設計出來的，在這個從無到有的過程中，我學到了很多。其二便是學習的Robot Framework，它告訴我一個優秀的自動化框架應該具備些什么。
都講自動化測試開發，當然要把開發自動化測試框架也當做一個項目來做。這時候，就需要考慮應該選擇何種類型的自動化測試框架：數據驅動、關鍵字驅動、還是Junit，TestNG ？ 抑或直接利用現有的開源自動化測試框架，如Robot Framework 。無法講這幾種類型的框架，孰優孰劣，關鍵是認清項目實際，選擇最適合的。講一些題外話，就Java學習者而言，Junit3.x的源碼是再好不過的教材了，JUnit框架運用到了大量的設計模式，反射機制。
在決定了選用何種自動化框架類型后，下面你需要抉擇的就是：應該選擇何種編程語言呢？編程語言的選擇和開發者的技術背景有很大關系，一般都會選擇自己熟悉的編程語言，但這也往往是個局限。另一方面，也受到SUT的影響。一般而言，很少見有選擇C，C++作為自動化框架開發語言的，雖然這兩種語言的執行效率要高，但開發效率要低一些。我們項目的自動化框架是Java語言編寫的，關鍵字也是由Java實現的。關鍵字的實現選擇Java，是由于SUT - 即Domino服務器提供的API是有Java ，C++。所以自然選擇了Java。而自動化框架開發語言的選擇，其實可以有別的選擇，如腳本語言Python ，Perl。腳本語言Python，或Perl，作為超高級開發語言，解釋執行的特性，在開發效率上可能會高一點。
下面就是關鍵字實現方式的選擇了。關鍵字就相當于手動執行測試用例當中的一個步驟，比如現在的項目，即一個關鍵字就是修改產品的一個配置選項，也可以是發一封帶有特定附件的郵件。就我們的產品而言，Domino提供的操作數據庫的方式有三種，即DIIOP、Web Services和本地調用。剛開始選擇的是DIIOP，這種方式實現起來比較簡單，后來發現通過這種方式實現的自動化腳本，即包含十幾個關鍵字腳本，其執行時間大概要35s – 40s。而Web Services的執行時間就要效率就要高得多，差不多一個自動化腳本的執行時間可以縮短10s， 但其實現需要分為服務器端Web Service的發布，和客戶端的調用，通過這種方式實現，測試環境的部署也要復雜些。講這些，主要是告訴我們，一開始就需要對這些做出評估，選擇合適的方案，不然中途改變，影響是很大的。
自動化框架，說白了就是流程的封裝啦。那么一個自動化框架應該包括哪些流程呢？來看看下面這兩幅框架圖吧。
第一幅圖講解了一套自動化測試是由自動化框架，自動化腳本，關鍵字組成的。第二幅圖描述了自動化框架的流程：根據配置挑選要執行的測試用例，解析自動化執行腳本，將自動化執行腳本送給自動化執行引擎，生成Log文件，最后生成Report。
對比Robot Framework框架，這套簡單的自動化框架有哪些地方可以提高呢？第一個，基于Test Suit的setup和teardown。一個自動化腳本的組成是這樣的：清理、初始化測試環境（如，建立一些測試腳本需要用到的數據庫）， 執行自動化腳本，生成執行結果，最后清空環境。這些步驟我們的自動化腳本中也實現的，但如果想在執行一批測試用例之前，做一些動作，執行完以后，在清空，我們用得方式就是把這些自動化腳本的名字在要執行的一批測試腳本之前，我們的腳本是按字母排序的，這樣確保的。其實應該有更好的方式。第二個，自動化腳本中有關鍵字Fail了，是否還需要接著執行下面的關鍵字呢。我們框架式會繼續執行，但Robot Framework做到了可配置，它是通過listern來實現的。可以好好學習下。
自動化框架、關鍵字的開發周期怎么安排，怎么預估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 設計、框架開發、自動化腳本實現、各種規則制定、多方面協作等，所以需要把自動化測試開發當做項目來做哦！