完善的校驗，是自動化測試的核心之一。完全覆蓋功能測試用例的自動化腳本，才能代替手工測試，真正解放手工勞動。

　　下面探討一下自動化測試中的校驗，包括：需要做什么樣的校驗、自動化實施、存在的問題及解決方案。

　　1. 需要做什么樣的校驗

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

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

　　UI可能是頁面提示，可能是alert彈出框，也可能是頁面跳轉。

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

　　2. 自動化實施

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

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

　　自動化腳本的寫法亦是如此，一系列的操作，再作校驗，符合預期?pass，不符合預期?fail。

　　3. 可能存在的問題

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

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

　　注意看到了，異常流不會更新持久層，也沒有頁面提示，與沒有操作的結果是一樣的。它帶來的問題是異常流的用例對應的腳本無法保證完全覆蓋用例，因為很可能并沒有執(zhí)行預期的操作。

　　下面看一個例子。

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

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


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

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

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

　　4. 解決方案

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

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

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

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