思考自動(dòng)化測試--框架（二）

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

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

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

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

準(zhǔn)備測試數(shù)據(jù)

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

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

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

• 動(dòng)態(tài)數(shù)據(jù)：

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

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

執(zhí)行方式

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

測試結(jié)果整理

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

Mock測試環(huán)境

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

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