踩雷無數的狐狸先生

我們都希望透過測試自動化, 來讓測試夠方便一點, 或是把人力投入在更有效率的地方 手動的做每一次的回歸測試 (Regression), 對人力的消耗是非常大的 事實上 regression test 不太適合由人去執行...  regression test 理想上是可以完全重複, 我們希望在每一個的測試,執行一樣的步驟, 得到一樣的結果 這件事由人做會比機器做得更精準嗎？ 這是我們選擇做test automation  的原因, 那我們對automation 的期待是什麼？ 在沒有任何變動的情況下, 我們希望相同的版本和相同的環境能得到相同的結果  更重要的是我們希望系統或功能真正出現問題的時候失敗,  但是要做到這一點非常的難... 我們常常會遇到測試的不穩定 (Test Flaky) 帶給我們不可預期的結果 不穩定帶我們的結果是什麼？  在沒有任何變動的情況下,  綠燈, 紅燈交互出現  你選擇相信哪一個？紅燈？綠燈？ 這種flaky 的情況下,  選擇哪一個都是在欺騙自己... 在沒有查看之前,你不會知道是真的有功能壞掉, 還是只是假警報 如果你不相信automation 帶給你的測試結果,  這樣寫automation 還有意義嗎？ Treat Tests as Falsification, Not a Proof Test Automation 執行過後沒有噴出任何錯誤, 不代表系統沒有錯 有可能是你的測試寫錯了, 或是沒有涵蓋到這一塊 但是我們可以換一個角度想, 會讓我們更有信心 當automation fail 的時候, 代表是真的遇到了問題 五個會導致Automation Flaky 的原因 環境 (Environment) 測試資料 (Test Data) 版本控制 (versioning) 資源限制 (Resource Use) 系統行為 (System Behavior) 環境 (Environment) 如果我們的Automation 所使用的環境以任何方式的不穩定, 這些可能是配置上的改變或是依賴第三放的服務, 這些變化都是我們不可預測及掌控的 最常遇到的說法是 在我的環境或是local 跑起來是好的啊～～ 如果程式碼都一樣,  最大的差別就是測試環境了 當automation 太依賴環境的配置時, 任何微小非關程式碼的變化都有可能影響結