你為什么要做自動化測試

　　不少介紹微軟測試過程的文章都強調大量運用自動化測試，給人一個只要有了自動化測試，整個測試過程就得到保證的印象。不可否認自動化測試的作用，但是對于下面兩個問題：

　　“自動化測試總是任何時間內、任何條件下、任何項目階段中的最佳選擇嗎?”

　　“進行/不進行自動化測試的決策是怎樣做出來的?”

　　答案會是什么?

　　為了回答這兩個問題，我想分享一個真實的微軟測試項目的經驗。

　　在這個項目中需要關注兩件事情：設置向導和客戶體驗改進計劃。

　　設置向導，或者安裝向導，相信安裝過軟件的朋友都知道，就是引導用戶完成一系列操作的一種界面，具有連續出現的窗口，每個呈現不同的內容，使用戶每次只關注特定的項目從而容易完成復雜的全部操作。

　　客戶體驗改進計劃(Customer Experience Improvement Program，簡稱CEIP)就不是那么為大眾所了解。實際上Windows系統中有這么一個缺省關閉的選項，如果用戶打開了，關于用戶如何使用微軟軟件的信息，例如常點擊的菜單項有哪些、缺省選項被改動為哪些值等等，會被Windows系統自動記錄下來并定期發送到微軟的服務器。專業分析師會解讀這些數據，從中發現微軟軟件設計上的潛在缺陷：它們會導致用戶迷惑、誤解，以致無法正確使用某些功能。

　　這里要測試的功能，就是為某處設置向導添加CEIP的記錄動作。第一次接觸這個新事物，不少測試工程師的通常反應是，模擬用戶在設置向導中的操作，然后觀察CEIP的記錄數據對不對，完事。

　　自動化測試更是小菜一碟：驅動用戶界面操作本不是難事，何況測試設置向導本身功能的工程師已經做好了一切，借花獻佛就好了;CEIP的記錄數據也是拿已經做好的函數讀一下記錄，然后跟預期數據比較就好了。

　　表面看是如此，但如果這就是故事的全部，那就沒有說的必要了。實際上，這只是冰山浮在水面上的部分。

　　先考慮一下兩個問題：

　　這個功能沒測試好的后果是什么?

　　CEIP是用于指導下個版本的可用性(Usability)設計的。如果里面的缺陷導致不準確的信息，那么CEIP分析師會被誤導從而得出不反映真實情況的結論。例如，本來用戶很常用的一個菜單項“打印”，被誤記錄為“屬性”的話，結論會是“打印”沒什么人去用，“屬性”倒有不少用處。那么開發下個版本的軟件時，根據這個“據說從真實的用戶統計數據得來”的結論，很可能“屬性”被放到顯眼處，很常用的“打印”反而被藏起來了。不要爭辯哦，這是被大量用戶數據所證實的嘛。所以，CEIP是把雙刃劍，不準確的數據比沒有數據更糟糕。

　　這個功能沒在測試中發現的缺陷，會被誰、什么時候發現?

　　很多測試中沒發現的功能缺陷，發布出去之后用戶遲早會發現。唯獨這種CEIP的功能，用戶除了打開或者關閉之外永遠不會去接觸：用戶為什么要關心CEIP記錄得對不對呢?事實上這些功能缺陷用戶不知道，微軟也不一定知道，只會根據CEIP數據調整設計。除非之后的若干個版本改得實在太過分以致怨聲載道，或者跟用戶調查的結論相差實在太大，才會驚覺可能是CEIP的問題。所以CEIP數據的缺陷，是一個不定延時引信地雷，埋下去就難以挖出來，而且要挖出來還極為麻煩：怎樣回應用戶“上幾個版本都是這樣的，我都習慣了為什么又要改”的質疑?“根據CEIP數據決定這樣改，但后來我們發現CEIP數據錯了”?(用戶一臉茫然：什么是CEIP數據?跟我有什么關系?什么叫做記錄我做過的事?你想說這是我自作自受的結果嗎?)

　　綜上所述，這個功能不是對著界面點擊一通就能看出對不對的，測試人員還需要觀察記錄下的數據并與做過的操作相對照;測試用例需要持續的在多個版本中執行以防范回歸缺陷(Regression Bug);測試這個功能，防止缺陷被埋進去具有更高的價值，因為事后很難挖出來。

　　表面上看，似乎自動化測試是板上釘釘的事：人工測試很難;還需要反復執行。但請考慮一下最初提到的一個問題：“自動化測試總是任何時間內、任何條件下、任何項目階段中的最佳選擇嗎?”

　　回答這個問題之前，請先看看加入CEIP之后設置向導有什么變化：

　　設置向導在每一頁收集用戶的輸入，直到“完成”按鈕被按下，然后拿著設置的數據往指定的地方一一寫入。加入CEIP之后，如果用戶按“后退”按鈕呢?

原文轉自：http://www.uml.org.cn/Test/2008061310.asp