過去的做法：
將大部分功能完成後，再進行除錯測試。
這樣做的缺陷：
很多Bug同時出現，無法判斷是哪裡出了問題。
解決方法：
將程式碼細塊化，一一除錯，分開進行bug的除錯和修改。
重點記錄：
團隊統一思想要從基本名詞解釋開始。
Bug：軟體的缺陷
TestCase：測試用例。測試用例描述了一個完整的測試過程，包括測試環境、輸入、期望的結果等。
TestSuite：測試用例集。即一組相關的測試用例。
Bug可以分解為：症狀、程式錯誤、根本原因。
1）症狀：即從使用者的角度看，軟體出了什麼問題。
2）程式錯誤：即從程式碼的角度看，程式碼的什麼錯誤導致了軟體的問題。
3）根本原因：錯誤根源，即導致程式碼錯誤的根本原因。
各種測試方法：
單元測試
程式碼覆蓋率測試
構建驗證測試：
顧名思義，構建驗證測試是指在一個構建完成之後，構建系統會自動執行一套測試，驗證系統的基本功能。在大多數情況下，這些驗證的步驟都是在自動構建成功後自動執行的，有些情況下也會手工執行，但是由於構建是自動生成的，我們也要努力讓BVT自動執行。
驗收測試：
在MSF敏捷建模中，建議還是採用場景來規劃測試工作。
“探索式”的測試：
就是指為了某一個特定目的而進行的測試，且就這一次，以後一般也不會重複測試。在軟體工程的實踐中，“Ad hoc”大多是指隨機進行的、探索性的測試。
迴歸測試：
迴歸測試不僅僅包括單元測試，也包括其他型別的測試。
場景/整合/系統測試：
在軟體開發的一定階段，我們要對一個軟體進行全面和系統的測試，以保證軟體的各個模組都能共同工作，各方面均能滿足使用者的要求。這類測試叫系統/整合測試。
夥伴測試：
夥伴測試是指開發人員可以找一個測試人員作為夥伴，在簽入新程式碼之前，開發人員做一個包含新模組的私人構建，測試人員在本地做必要的迴歸/功能/整合/探索測試，發現問題直接與開發人員溝通。通過夥伴測試把重大問題都解決了之後，開發人員再正式簽入程式碼。
效能測試：
1. 設計負載
2. 令使用者滿意的服務質量
壓力測試：
壓力測試要驗證的問題是：軟體在超過設計負載的情況下是否仍能返回正常結果，沒有產生嚴重的副作用或崩潰。
內部/外部公開測試
易用性測試
小強”大掃蕩