為了不被找出軟體缺陷我還能做什麼？

昨天我們提到了那些我們沒有把握的程式碼都是會有缺陷的，發送這些有缺陷的程式給 QA 是不專業的表現。

那我們該怎麼做呢？其實很簡單，就是把 QA 做的事情在我們這個開發階段先做一次，也就是測試，一遍一遍的測試，想盡辦法來測試

程式都寫不完了還做測試

你一定會想，如果要做那麼多的測試，那會花掉太多的時間，你還要趕進度，趕在 deadline 前把工作做完。如果還要花時間作測試，那就沒有時間寫程式了。

好吧，我們還是選擇不要測試吧，沒辦法，現實總是逼的我們低頭。

的確，如果用原本的方法做事那一定做不完。但為了確保我們的程式碼是對的，測試又一定要做，但我們又不想花太多時間測試。那有沒有什麼方法是可以做測試又不用花太多時間的？

導入自動化測試

有的，那就是導入自動化測試，寫一些能夠隨時都能跑的單元測試，當你對程式碼有修改就去執行測試，通常這應該都會在幾分鐘內結束。

那我們應該用這些自動化測試去測試多少程式碼呢？ 80% 你覺得如何？

自動化測試 80% 的程式碼

如果我們真的做到了有 80% 的程式碼被自動化測試所涵蓋，那的確很了不起。有 80% 的程式碼是我們有把握的，因為它有測試保護著。

但你想想，還有 20% 的程式碼是我們沒有把握的，我們還是把沒把握的程式碼交了出去，雖然比例變少了，但這就是不專業的表現不是嗎？

那問題不就又回來了嗎？所以我們的目標應該是百分之百的程式碼都有測試。讓所有的程式碼都是我們有把握的，再交付給 QA 做測試。

百分之百的測試覆蓋率，這實際嗎？

你想一想，你所寫的程式碼都是因為某種情況下你希望它被執行，如果你希望程式碼可以被執行，那你就要知道它是否正確被執行，而要知道它是否正確的被執行，就一定要對它寫測試。所以每一行都應該要被測試。

你也許會說有些程式碼很難測試。沒錯，但之所以難測試因為一開始設計時就沒有考慮到怎麼去測試它。所以如果把他反過來想呢？先寫測試再寫被測試的程式碼，這樣你寫出來的程式碼就都有測試保護了。

這種方法叫做測試驅動開發(TDD，Test Driven Development)，有興趣可以上網查一下，這裡不多解釋。

有了自動化測試，就沒有缺陷了嗎？

所以有了百分百自動化測試覆蓋率的程式碼就沒有缺陷了嗎？

當然不是，因為還是會有一些我們沒考慮到的情況，但至少我們對我們所交付的程式碼更有信心。跟那些不寫測試的軟體開發人員比起來，我們顯的專業多了。

當然自動化測試沒那麼簡單，尤其是遇到 legacy code。 但不能因為困難我們就放棄不是嗎？