測試什么

　　因為沒有一個實際的測試集可以證明一個程式是正確的，因此關鍵問題變成了哪個測試子集最有可能檢測到最多的錯誤。選擇合適的測試例程的問題被稱為測試例程設計。雖然存在數十種測試案例的設計方法，但它們通常可歸為兩種截然不同的方法：功能測試和覆蓋測試。

　　功能測試（也稱為黑盒子測試）選擇可評估實現與需求規格符合程度的測試。覆蓋測試（也稱為白盒子測試）選擇可執行程式碼某些部份的測試例程。（過后，將詳細討論這兩種方法。）

　　這兩種測試都是對嵌入式設計進行嚴格測試所必須的。其中，覆蓋測試表示程式碼的穩定性，所以這種測試是用于已經完成或將近完成的產品的。另一方面，可在編寫要求文件時，同時編寫功能測試。

　　事實上，從功能測試開始入手，可以大幅地降低重復勞動和重寫測試案例的工作。因此，在我看來，要先考慮功能測試。

　　每個人都同意先編寫功能測試這個觀點，有人認為，功能測試在系統整合階段（而不是在單元測試時）最有用。以下是整合功能測試和覆蓋測試方法的一個簡單處理流程：

　　1．找出哪些功能未被功能測試完全覆蓋。

　　2．找出每個功能的哪些部份沒被執行。

　　3．找出需要哪些額外的覆蓋測試。

　　4．執行新增的額外測試。

　　5．重復以上步驟。

　　何時停止測試？

　　最通用的停止標準（按可靠性排序）如下：

　　1．老板命令停止測試

　　2．新的測試週期找到的新缺陷少于X個

　　3．在沒有發現任何新缺陷的情況下已經滿足了某個覆蓋閥限

　　無論你多么徹底地測試了程式，都無法保證找出所有缺陷。這引發了另一個有趣的問題：你可容忍多少缺陷？假設在極端軟體壓力測試過程中，你發現系統每進行大約20小時的測試就會鎖定。你仔細地檢查程式，但是仍無法找出這個錯誤的根源。這個時候你應該提供產品嗎？

　　多少測試才‘足夠好’？這個我說不好。但遵循一些久經時間考驗的規則總是好的：“如果方法Z預估Y行程式碼中的缺陷少于X個，那么就可放心地發佈程式了。”也許有一天會出現這種標準。編程產業仍然相對年輕，還達不到類似建筑業那樣的成熟度。

　　許多厚厚的建筑手冊和大本規格是多年經驗的結晶，它們可為建筑師、土木工程師和結構工程師提供按工期在預算內、建造一棟安全建筑所需的全部資訊。偶爾雖仍會有建筑倒塌，但畢竟很少見。在編程產業制訂出類似標準前，“多少測試才足夠？”就是個主觀判斷問題。