你為什么要做自動化測試(2)

　　放在以前，如果“前進”按鈕沒有按下，用戶輸入不會生效，所以“后退”就是界面改為前一頁，沒什么大不了的?，F在就不一樣了，“后退”意味著某些狀態發生了變化，如果那些狀態要被CEIP記錄，那就是一個值得關注的問題。

　　別忘了添加CEIP的初衷是暴露潛在的Usability缺陷。用戶成功的走過各個頁面并完成設置，這是需要記錄的成功案例;用戶感到迷惑不得不中途退出，這也是需要記錄的失敗案例;用戶后退到之前的頁面來重試，更是需要記錄的失敗案例。每個案例都需要記錄些什么數據，視情況而定，但不外乎“當時狀態”。

　　請注意，沒有CEIP的時候，設置向導關注的是“最終狀態”;有CEIP的時候，還需要關注“當時狀態”。我要問一個問題，如果當初不考慮CEIP，一個設計設置向導的開發工程師，能一早想到要維護“當時狀態”的可能性有多大?

　　顯然，這是一個非常容易引入缺陷的地方、非常需要在把缺陷埋進去之前就采取行動的地方。那么，自動化測試在這里能幫到我們什么?

　　防范回歸缺陷嗎?前面說過，太晚了。況且在自動化測試程序寫出來第一次運行的時候，缺陷就已經被發現了;等到發現回歸缺陷的時候，像前面說的，情況更尷尬了。

　　進行人工無法執行的測試?跟前面說的一樣，在自動化測試程序寫出來第一次運行的時候，缺陷就已經被發現了。我們如何才能夠在把缺陷埋進去之前就采取行動呢?

　　其實，這里更需要的是在設計層面或者是代碼層面的審核和分析。你可以稱之為白箱測試，但我側重于設計測試用例的過程而不是執行它們的過程。

　　假設你是開發工程師，你會怎樣設計這個功能?也許會維護一個數據結構，或者沿用已有的結構，在向導頁面變化或者用戶輸入變化時更新它們，在恰當的時候調用CEIP的API把它們記錄進去。

　　假設我是測試工程師，我會列出引用這些數據結構的地方，觀察它們是怎樣被修改和讀取的，思考用怎樣的輸入，環境條件和執行順序/時序打破設計或者代碼中蘊含的假設，使得進行CEIP記錄時它們不能代表真實情況。例如，倘若設計中沒有維護“當時狀態”的話，一個包含“后退”的動作序列就可以打破原有的假設了。

　　我還會找出跟相關狀態變化有關的界面消息響應，觀察所有這些響應最終能不能正確作用在相關狀態上。這是容易被忽略的部分，前面基于引用的方法并不能覆蓋這種連引用都沒有的情況。

　　當你找到能打破假設的測試用例時，你并不需要執行它就已經可以知道有沒有缺陷了，因為它來自于你對設計或者代碼的攻擊性思考。在真正執行之前，你已經在腦子里執行過一次了。

　　甚至，你并不需要覆蓋所有的用戶動作和輸入，因為經過設計和代碼審核，你已經知道哪些因素跟CEIP相關，有些測試用例是無關和浪費時間的。

　　可見，為了在把缺陷埋進去之前就采取行動，自動化測試用處并不大，多從用戶的角度思考，多分析設計和代碼，取得的效果更好。這里我所采取的決策是：

　　- 分配較少時間在自動化測試代碼編寫上

　　- 利用代碼分析工具，結合設計說明，跟蹤CEIP所記錄的數據的來源，以及與用戶場景(User Scenario)的關系

　　- 根據狀態機設計的經驗，檢查當前設計能在多大程度上滿足反映“當前狀態”的需要

　　然而我們還是要堅定不移的把想到的測試用例在自動化測試中實現出來并定期執行，并不因為前面說的就把它丟在一旁。

　　第一，上述在設計層面或者是代碼層面的審核和分析不可能，也不必要每天、每次修改代碼的時候都做一次。如果有無需人力的驗證方法，它就比需要人力的方法優勝。只有設計變動對CEIP功能有足夠大的影響時，才會再次分析那些影響。

　　第二，修改代碼，并不一定都是改動CEIP的功能，也就是說，別人、別的團隊也可能去修改，同時你不一定還在測試這個功能。“鐵打的營盤流水的兵”，這些自動化測試用例，就是鐵打的營盤，保證軟件質量不會因為流水的兵而崩潰。

　　上面說的就是決策做不做自動化測試的一個例子，以及期間所需要考慮的各種問題。在微軟，自動化測試只是一個工具，做不做、什么情況/時間做，都是全盤分析的結果。就算絕大多數團隊都在做，也只是一個結果，而不是原因。獨立自主的思考，深入細致的調研，扎實的系統分析能力，代表用戶說話，才是微軟贊賞的卓越工程。

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