做自動化測試的原因
作者: papercrane 來源: papercrane的專欄
不少介紹微軟測試過程的文章都強調大量運用自動化測試，給人一個只要有了自動化測試，整個測試過程就得到保證的印象。不可否認自動化測試的作用，但是對于下面兩個問題：
“自動化測試總是任何時間內、任何條件下、任何項目階段中的最佳選擇嗎？”
“進行/不進行自動化測試的決策是怎樣做出來的？”
答案會是什么？
為了回答這兩個問題，我想分享一個真實的微軟測試項目的經驗。
在這個項目中需要關注兩件事情：設置向導和客戶體驗改進計劃。
設置向導，或者安裝向導，相信安裝過軟件的朋友都知道，就是引導用戶完成一系列操作的一種界面，具有連續出現的窗口，每個呈現不同的內容，使用戶每次只關注特定的項目從而容易完成復雜的全部操作。
客戶體驗改進計劃（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之后，如果用戶按“后退”按鈕呢？
放在以前，如果“前進”按鈕沒有按下，用戶輸入不會生效，所以“后退”就是界面改為前一頁，沒什么大不了的�，F在就不一樣了，“后退”意味著某些狀態發生了變化，如果那些狀態要被CEIP記錄，那就是一個值得關注的問題。
別忘了添加CEIP的初衷是暴露潛在的Usability缺陷。用戶成功的走過各個頁面并完成設置，這是需要記錄的成功案例；用戶感到迷惑不得不中途退出，這也是需要記錄的失敗案例；用戶后退到之前的頁面來重試，更是需要記錄的失敗案例。每個案例都需要記錄些什么數據，視情況而定，但不外乎“當時狀態”。
請注意，沒有CEIP的時候，設置向導關注的是“最終狀態”；有CEIP的時候，還需要關注“當時狀態”。我要問一個問題，如果當初不考慮CEIP，一個設計設置向導的開發工程師，能一早想到要維護“當時狀態”的可能性有多大？
顯然，這是一個非常容易引入缺陷的地方、非常需要在把缺陷埋進去之前就采取行動的地方。那么，自動化測試在這里能幫到我們什么？
文章來源于領測軟件測試網 http://www.kjueaiud.com/