完善的校驗(yàn)，是自動(dòng)化測(cè)試的核心之一。完全覆蓋功能測(cè)試用例的自動(dòng)化腳本，才能代替手工測(cè)試，真正解放手工勞動(dòng)。

　　下面探討一下自動(dòng)化測(cè)試中的校驗(yàn)，包括：需要做什么樣的校驗(yàn)、自動(dòng)化實(shí)施、存在的問題及解決方案。

　　1. 需要做什么樣的校驗(yàn)

　　從我目前的經(jīng)驗(yàn)來看，web功能測(cè)試的校驗(yàn)點(diǎn)可以分為2種：數(shù)據(jù)持久層校驗(yàn)和UI校驗(yàn)。

　　數(shù)據(jù)持久層可能是DataBase(oracle、mysql)，也可能是文件系統(tǒng)(tfs、tair等)。

　　UI可能是頁面提示，可能是alert彈出框，也可能是頁面跳轉(zhuǎn)。

　　這2方面的校驗(yàn)是自動(dòng)化框架需要解決的基本問題，目前淘寶主站的頁面自動(dòng)化測(cè)試框架automan與接口測(cè)試自動(dòng)化框架iTest均能較好的滿足這2方面的需求。

　　2. 自動(dòng)化實(shí)施

　　在我們目前的自動(dòng)化實(shí)施中，是以功能測(cè)試的用例為藍(lán)本，實(shí)現(xiàn)一個(gè)腳本，模擬手工執(zhí)行的過程。

　　功能測(cè)試的用例通常會(huì)是一系列的操作與一組預(yù)期結(jié)果。正常流?操作成功，頁面提示操作成功，數(shù)據(jù)持久層生成記錄或更新記錄；異常流?操作失敗，頁面提示操作失敗，數(shù)據(jù)持久層不更新。

　　自動(dòng)化腳本的寫法亦是如此，一系列的操作，再作校驗(yàn)，符合預(yù)期?pass，不符合預(yù)期?fail。

　　3. 可能存在的問題

　　理想的狀況是，任何操作的正常流與異常流都有UI與持久層的2層校驗(yàn)，這種狀況下自動(dòng)化腳本理論上講能夠完全覆蓋功能測(cè)試的用例。

　　現(xiàn)實(shí)與理想有一定的差距，某些模塊在交互設(shè)計(jì)的時(shí)候省去了用戶提示。這種情況下，無法做UI校驗(yàn)，2層校驗(yàn)無奈的退化成了1層校驗(yàn)：正常流?數(shù)據(jù)持久層生成記錄或更新記錄；異常流?數(shù)據(jù)持久層不更新。

　　注意看到了，異常流不會(huì)更新持久層，也沒有頁面提示，與沒有操作的結(jié)果是一樣的。它帶來的問題是異常流的用例對(duì)應(yīng)的腳本無法保證完全覆蓋用例，因?yàn)楹芸赡懿]有執(zhí)行預(yù)期的操作。

　　下面看一個(gè)例子。

　　被測(cè)試的方法，都可以經(jīng)過一定的抽象，成為下面的樣子。

public void service(SomeRequest request， SomeReponse response) {
  // 我們的關(guān)注點(diǎn)而言，這是什么request和response并不重要
  // 1. request中存儲(chǔ)了大量的參數(shù)，首先校驗(yàn)參數(shù)的合理性，如果參數(shù)不符合預(yù)期，不執(zhí)行后面的實(shí)際操作
  if (!validateParams(request)) {
    …. // 某些操作
    return;
  }
  // 2. 執(zhí)行真正的操作
  doRealAction();
}


　　從測(cè)試用例的角度，我們期待的是，極少量驗(yàn)證參數(shù)正確性的用例在代碼邏輯1處停住，多數(shù)的用例都要能走到代碼邏輯2中，這樣才是真正的在做功能測(cè)試，在做業(yè)務(wù)邏輯的測(cè)試。

　　結(jié)合抽象過后的代碼及我們的窘境，可以發(fā)現(xiàn)問題的所在，期待的是在代碼邏輯2中走到異常流，但可能事實(shí)是直接在代碼邏輯1中已經(jīng)停止了執(zhí)行。

　　簡(jiǎn)單的分析一下原因。首先是設(shè)計(jì)上的不合理，即便交互設(shè)計(jì)是不給用戶提示，但在實(shí)現(xiàn)中，也可以做到在response中標(biāo)識(shí)明確的錯(cuò)誤原因，接口自動(dòng)化測(cè)試這種不care界面只關(guān)注流程的測(cè)試方法能很好的做到2層校驗(yàn)從而規(guī)避風(fēng)險(xiǎn)。其次是request中的參數(shù)格式問題，通常測(cè)試腳本在實(shí)現(xiàn)的時(shí)候肯定會(huì)保證參數(shù)的正確性，這個(gè)時(shí)候是可以確保在代碼邏輯2中走到異常流的，但是參數(shù)格式嚴(yán)格依賴于開發(fā)人員的設(shè)計(jì)，如果開發(fā)人員修改了參數(shù)的格式并與原來的格式不兼容，發(fā)生了我們不愿意看到的情形了。

　　4. 解決方案

　　第1種解決方案，也是好的解決方案，推動(dòng)開發(fā)人員修改設(shè)計(jì)與實(shí)現(xiàn)，總是在response中帶入錯(cuò)誤提示，這個(gè)方案需要開發(fā)人員參與，響應(yīng)會(huì)很慢，通常需要幾周時(shí)間。

　　從上面的分析來看，期待的是在代碼邏輯2中因業(yè)務(wù)邏輯的原因操作失敗，實(shí)際是在代碼邏輯1中因參數(shù)不符合預(yù)期停止執(zhí)行。我們需要一個(gè)保證?代碼正確的、確定的走到代碼邏輯2中；叵胍幌，正常流是操作成功，持久層更新記錄或生成記錄，那么一個(gè)主流程的正常流的腳本pass了，可以保證代碼能夠正確、確定的走過了代碼邏輯2。因此，第2種解決方案便出來了：只有1層校驗(yàn)的異常流腳本，必須要同時(shí)有一個(gè)配套的主流程的正常流的腳本，才能完整的、完全的覆蓋對(duì)應(yīng)的功能測(cè)試用例。

　　總結(jié)，自動(dòng)化測(cè)試的目的是以機(jī)器代替人工，其中一個(gè)核心的問題是如何使用自動(dòng)化腳本完全的覆蓋功能測(cè)試用例。從功能測(cè)試用例的角度出發(fā)，基本上都是操作再校驗(yàn)，因此這個(gè)問題轉(zhuǎn)化為如何完善的校驗(yàn)。接下來分析了如何完善的校驗(yàn)，可能存在的問題及解決方案。

　　ps：這個(gè)議題后舉出的一個(gè)例子是真實(shí)的案例。在實(shí)踐中遇到的問題是“出售中的寶貝”列表修改寶貝庫存，修改失敗也不提示錯(cuò)誤信息，只能做數(shù)據(jù)庫的校驗(yàn)。有8個(gè)用例，其中2個(gè)正常流能夠更新成功，6個(gè)異常流更新失敗，某一次項(xiàng)目合并主干后，8個(gè)用例里面的2個(gè)正常流總是失敗，而6個(gè)異常流卻總是pass，后分析是由于開發(fā)人員修改了參數(shù)格式而導(dǎo)致代碼執(zhí)行停在了代碼邏輯1。