何時應進行自動化測試？

測試會延續它的價值嗎？
這里的爭論比較復雜，所以我先給出一個大綱。
1. The code under test has structure。如一個有用的近似值，我們能把code under test分為功能代碼和支持代碼。
2.測試人員編寫那些有業務特色的腳本代碼，其它support code對測試人員來說是不可見的。
3. 對業務代碼的變動會對測試的行為產生影響。因此，因為它導致測試的死亡的可能性要比導致測試顯示出一個Bug的可能性要大得多。
4.測試的價值主要體現在當support code發生變化后發現Bug的能力。
5. 我們不知道support code的任何事情！我們怎樣去知道將來測試會不會把它當作是Bug被捕獲？當找到一些Bug的時候我們怎樣推測整個的測試過程是正確的？
----一般情況下如果某個地方做了變動那么那里就會出現Bug。如果那里在過去做了變化那么將來這里會有更多的變更。
----我們很難知道測試是否正常的工作，但是可以說明有一個功能沒有正常的進行工作。這樣的測試不會自動的執行。
6.測試下的代碼同其它的產品互相的影響，這些對support code的影響比較多。我們希望由于support code導致的Bug我們可以及時發現。
----我們再來認識一個低價值測試的特征。高價值的測試不可能是一個feature-driven的測試；而通常會是一個task-driven。
次要的考慮
當我在思考做自動化測試的時候我需要在頭腦中留意這樣一些事情：
l 人們（用戶）可以會發現自動化測試沒有發現的bug。我們用來過濾掉界面上不相關的變化的工具和測試庫可能同樣的也會過濾掉一些古怪的bug。我曾親眼看到一個測試員和偶然的發現當他移動鼠標的時候鼠標會不停的閃動而且這個現象不會經常的出現，對這個現象進行了深入的研究后我們發現了一個嚴重的bug。我聽說過這樣的一組測試，測試在屏幕上以X，Y為坐標顯示一個圖形，而這個圖形測試人員在界面上無法看到，可是測試工具卻可以發現它，并給出了正常的報告。
l 但是，如果測試人員非常的注意那些古怪的bug，那么會非常的辛苦而且還不會得到準確的檢測結果。如果潛藏一個精確度為0.0000001的bug，人是難以發現它的，而工具就不會。注意Nyman指出工具可能分析出來人們無法見到的東西。測試工具不會緊緊局限到屏幕上可見的那一部分內容，他可以發現表明下數據結構上的問題。
l 事實上，人們不可能保證反復的以手工的方式重復輸入相同數據來完成同樣測試的過程絲毫不差，相反的都會有些細小的差別。例如，人們的操作犯了錯誤、后退、重新輸入，這樣有時偶然會發現在錯誤操作處理和support code交互之間的bug。
l 需要在不同外部配置下進行的測試盡可能多的使用自動化測試。如果需要在其它的操作系統、驅動或者第三方的函數庫等情況下運行程序，理論上等同于使用不同的support code來運行程序。如果你知道將來會有這些變化，自動化測試將有很高的價值。但是，編寫一個對外部配置敏感的測試其實是一個騙局。因為這樣很可能使這組測試沒有多少對bug的判斷力而只是可以在不同的環境下運行。
l 如果在第一次運行測試的時候找到了一個bug，你清楚你應該在對bug進行修改后需要重新的對它進行測試。但是可能僅僅對這一個bug做自動化測試是不充足的?？梢詫@部分代碼做一個標記，說明將來會對這部分做更改，這樣還可以提醒你對這部分進行更多的自動化測試，如果bug出現在support code里，尤其應該這樣。

原文轉自：http://www.kjueaiud.com