探索式測試：測試自動化實例分析(2)

　　通過持續運行測試程序，Harry獲得了以下成果。

　　測試運行了7天，覆蓋了2200萬個用戶查詢。

　　發現了1萬個有問題的建議結果。

　　在建議詞條數據庫中，發現了1.9萬個從未被返回的建議詞條。它們應該被剔除。

　　當然，真實的測試過程比上述描述要復雜一些。但是，它們都擁有相同的核心：從簡單的測試Oracle開始，利用測試反饋持續完善Oracle。Harry將這種迭代式的測試開發過程稱作涌現式測試(Emergent Testing)。

　　案例3：測試行車路線(Driving Direction)

　　在線地圖可以給出從地點A到地點B的行車路線(Driving Direction)。那么如何測試該功能呢?

　　Harry的測試輸入集合是全美所有郵政編碼(Zip Code)的兩兩組合。這是一個非常龐大的集合，它提供了令人放心的測試覆蓋率。

　　Harry的測試策略仍舊是構建啟發式測試Oracle。開始時，他的規則集合包含這么一條規則：

　　行車路線的長度與A到B的直線距離沒有數量級的差距。

　　這里需要對在線地圖的實現稍作說明。在線地圖的實現可以大致分為兩層：繪制地圖的Web UI和提供地圖數據的Web Service API。API能夠返回指定郵政編碼的經緯度坐標。因此，利用其返回值，就可以算出兩點間的直線距離。對于行車路線，API返回的是一系列點的坐標值，Web UI將行車路線路線繪制為貫穿這些點的曲線。計算臨近兩點間的距離，將結果累加，就可以得到行車路線的長度。因此，上述規則的實現并不復雜。

　　然而，在實際測試過程中，這條規則卻產生了許多“誤報”。下圖就是一個例子。

　　于是Harry替換了檢查規則。新加入的規則是：

　　從A到B的行車路線的長度與B到A的行車路線的長度沒有明顯差別。

　　這條規則沒有產生太多的誤報，而且發現了一些有趣的錯誤。下圖就是一個例子。

　　對案例2與案例3的再分析

　　在案例2和案例3中，被測試對象有如下特點：

　　難以構造能夠給出標準結果的測試Oracle。自動建議的計算是基于海量數據的模式匹配，行車路線的搜索是典型的人工智能算法。在技術上，很難準確預測它們的輸出。從業務的角度，這兩個問題在現實世界也不存在“標準答案”。

　　在這兩個應用中，Web UI從Web Service API中獲得數據。這意味著，測試程序可以忽略UI，直接調用Web Service API，以測試核心邏輯。良好的設計分層提供了可測試性，而可測試性簡化了測試程序的構造。

　　測試輸入使用真實數據，且相對容易構造。自動建議的測試輸入來自必應的服務端日志，測試程序只需要遍歷文本日志就可以構造測試輸入。行車路線的測試輸入是全美郵政編碼的兩兩組合，測試程序只需要讀取一個記錄全美郵政編碼的文本文件，就可以組合出所有的測試輸入。

　　單個測試執行速度快，這有助于測試程序在較短的時間內完成大量的檢查。自動建議的Web Service API的響應時間應該在毫秒級，行車路線的API可以慢一些，但也必須在1~2秒內返回結果。于是，Harry的程序能夠檢查2200萬個輸入，能夠使用“全組合”策略提供充分的測試信心。

　　在案例2和案例3中，測試策略有如下特點：

　　充分利用計算機的運算能力，將(與人力成本相比非常廉價)機器資源使用到極致。

　　用簡單的啟發式規則構造測試Oracle。利用海量數據和啟發式Oracle做數據驅動測試。

　　迭代地構造Oracle。從簡單的規則開始，利用測試結果逐步增強、修改、完善Oracle。

　　Oracle的輸出不是二值的通過或失敗。它更像過濾器，其輸出是需要進一步人工調查的案例。

　　與一些測試方法追求精簡的測試用例集不同，測試程序運行盡可能多的測試用例。一方面，自動建議和行車路線的缺陷很難預測，需要大量的測試;另一方面，既然單個測試執行速度很快，為什么不多測試一些真實數據呢?

　　充分利用測試工程師的智力。當計算機完成了枯燥的計算，測試工程師可以專注于改進Oracle和調查問題案例，而這些任務是計算機所不能完成的。

　　性價比高。在微軟總部雷蒙德，一個測試工程師的年薪大約是8萬美元?；?萬美元，就可以為他配備10臺強勁的計算機，而這些計算機至少可以使用3年。因此，合理的測試策略應該是讓機器全負荷運轉，讓人專注于富有智力挑戰的任務。

　　Harry的幻燈片與視頻

　　以下是本文所引用的幻燈片和相關連接：

　　Harry Robinson的主頁：www.harryrobinson.net。

　　案例1和案例2的來源：Harry在PNSQC 2010的主題演講“using simple automation to test complex software”的視頻和幻燈片。內容非常有啟發性，強烈推薦。

　　案例3的來源：Harry在CAST 2010的報告“Exploratory Test Automation”的幻燈片。

原文轉自：http://www.anti-gravitydesign.com