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

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

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

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

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

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

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

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

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

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

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

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

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

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