思考自動化測試--框架（二）

自動化測試工具其實是千萬種的，一般青年，上手就用工具，弄點小工具執(zhí)行執(zhí)行腳本，出出報告。文藝青年，寫個自動化測試框架把腳本，數(shù)據，GUI，結果等組織起來，便于執(zhí)行管理。好吧2X青年，就是回放錄制，回放錄制。
自動化測試工具，商業(yè)的，開源的，有好多。很多工具主要完成的是執(zhí)行本身，而自動化測試框架是一種組織方式，更多的是使用自動化測試的人怎么使用自動化測試的方式。自動化測試框架是由不同部分綜合而成，在于你在每個點怎么看待怎么用自動化測試測試自己的系統(tǒng)，工具與被測系統(tǒng)不同，可能答案不同。下面我就簡單說說自動化測試的框架各個部分：（PS：其實，有的人已經發(fā)現(xiàn)了，我上面說的自動化測試，已經專指根據界面進行end-to-end的測試了。）

測試腳本（GUI+操作+數(shù)據）

很多自動化測試框架，都在沿用傳統(tǒng)的關鍵字驅動方式，通過維護一張（GUI+操作+數(shù)據）為記錄的表，來根據這張表執(zhí)行自動化測試。為什么要這么做呢？乍一看，維護簡單，心一想，這么簡單手工測試也可以搞。多好啊。來看個例子：

其實我并不推薦這種方式，被測系統(tǒng)千遍萬化，測試流程，校驗方式不盡相同，簡單的一張表很難涵蓋所有內容，反而束縛了自動化測試腳本的靈活性。測試腳本就是測試腳本，可能就是一個代碼文件，沒有必要把他整理出來，弄得只是好看而不實用。(PS:不過如果你的自動化測試本來就不復雜，那么這個方式也是可以考慮的，還是要記住原則只是多數(shù)情況，遇到問題要具體問題具體分析)

準備測試數(shù)據

自動化測試的優(yōu)點就是程序可以不知疲憊的進行測試，那么一個測試腳本，給他不斷輸送數(shù)據，不就能做更多的測試嘛。思路簡單，難點在測試數(shù)據怎么來，有幾種方法，我也簡單分析一下：

• 靜態(tài)數(shù)據：

  • 寫在腳本里，這樣數(shù)據不太靈活，也不好維護，一般不推薦這樣。
  • 寫到文件或者數(shù)據庫里，有的時候自動化測試會使用一批數(shù)據，或者批量的設計數(shù)據，可以將這些數(shù)據寫到文件或者數(shù)據庫里，腳本讀取文件或者數(shù)據，這樣便于維護。
  • 初始化數(shù)據狀態(tài)，不論使用上述哪種靜態(tài)數(shù)據的方式都可以在加上對靜態(tài)數(shù)據狀態(tài)的初始化，而達到數(shù)據準備的目的。

• 動態(tài)數(shù)據：

  • 隨機生成數(shù)據，有些數(shù)據可以是使用隨機發(fā)生器生成隨機數(shù)據，這樣測試有一定的隨機性有利于測試，并且可以降低一些數(shù)據準備的成功
  • 隨機抽取數(shù)據：可以從數(shù)據庫中隨機抽取可用的數(shù)據。這種方式需要保證數(shù)據庫里有足量可用數(shù)據
  • 枚舉生成數(shù)據，一般這種數(shù)據生成，主要是為了測試全面，保證各種情況下的數(shù)據都可通過，窮舉所有參數(shù)的不同枚舉值，然后排列組合所有情況形成大量的數(shù)據，進行自動化測試。

這么多方法，在實際使用中，可能不能單一使用一種方法，而是上述方法組合使用，在不同的場景下使用不同的方式，框架需要盡量多的支持這些數(shù)據準備方式。

執(zhí)行方式

上面說了，測試執(zhí)行使用的腳本，說了測試數(shù)據的準備，下面就直接說說怎么執(zhí)行腳本。是不是就是直接運行就好了？自動化測試的特點是可以低成本的執(zhí)行，所以要充分利用這個特點，執(zhí)行方式越靈活越好，可以輕便地組織測試用例集，手工執(zhí)行，手工定時執(zhí)行，周期執(zhí)行，最好還能和CI工具融合起來在日常構建項目后執(zhí)行測試。當然，大量的執(zhí)行腳本也可以通過分布式的方式，分布執(zhí)行，從而通過增加設備來提高執(zhí)行效率。

測試結果整理

測試執(zhí)行完，會受到大量的結果報告，自動化測試結果是一定要需要分析的，有些可能是測試環(huán)境的問題，而不是程序本身的問題，甚至有可能是自動化測試腳本本身的問題，這些需要分析記錄（包括：提交缺陷）。這里建議在進行測試結果收集的時候，獲取程序的一些性能數(shù)據，比方說響應時間了，打開速度了，把這些性能數(shù)據也保存下來。雖然測試環(huán)境的性能數(shù)據不能保證指標的完全真實可靠，但是也是一種參考，在項目不斷迭代，可以從這些細小的性能數(shù)據發(fā)現(xiàn)迭代導致程序的性能下降的問題。

Mock測試環(huán)境

Mock是什么？Mock，我這里只是借用了單元測試里的概念。這里所說的Mock測試環(huán)境，包括被測系統(tǒng)內部模塊的Mock，也包括外圍系統(tǒng)的Mock。Mock簡單的說，就是個模塊（程序）或者系統(tǒng)，我用測試代碼去代替，測試執(zhí)行中，并沒有去執(zhí)行實際的代碼，而是執(zhí)行的測試代碼。而這些測試代碼一般都是比較簡單的返回，并沒有具體的邏輯處理。這里舉兩個例子，比方說我們寫了一個電商網站，然后支付使用的是支付寶，那么做支付測試的時候，那么我們就用一個模擬的支付寶接口（可以接受付款請求并返回付款完成消息）來代替真實的接口，測試的時候，使用“假”接口，來主要測試我們自身系統(tǒng)中是否有問題，而減少了聯(lián)調測試的消耗；還有，就是比較常見的在Web項目里，我們測試前臺的時候（可能后臺都沒有開發(fā)完），我們在測試里，可以寫Mock方法讓后臺返回我們指定的結果，而并不做邏輯操作更不會讀取數(shù)據庫。從上面的例子我們看出來了，其實Mock測試就很有利于分層測試，而且本身在單元測試中也使用的的非常的多。但是，要明確這種方式不是end-to-end的測試，測試不夠全面，與真實環(huán)境有差異，那么要用，可不要亂用（Mock雖好，可不要貪用哦）。

總的來說，自動化測試框架其實更多的是基于在自動化測試認識的基礎上的一種管理維護方法，只是可能這種框架需要寫代碼支持而已。根據不同的被測系統(tǒng)，不同的測試方法，不同的測試工具，根據實際情況選擇不同的方法，是做自動化測試框架最好的思路。因地制宜，切記不要老是想做臃腫的自動化測試產品最后發(fā)現(xiàn)根本用不起來。