測試驅動開發

預期成果：用 測試驅動開發 (Test-driven Development) 收集可重複驗證這項行為或品質風險的證據。 使用者情境：開發人員先為新的金額四捨五入規則，寫一個會失敗的範例測試。接著用最少的程式讓測試通過，再在所有測試都成功時整理重複程式；功能寫完後才補測試仍有幫助，但不算 TDD 的先測試流程。 驗證方式：測試驅動開發 (Test-driven Development)。 適用理由：每個小設計步驟都由失敗測試帶動，通過後再安全整理程式時，可以使用這個詞。 不應使用的情況：不要只因為專案有很多測試，就稱它採用 TDD；實作必須遵循先寫測試的循環。 測試要求：說明要測的系統與環境。定義預先準備的測試資料（Fixture）、其他輸入，以及看得到的預期結果。加入預期失敗、邊界案例、容許值、隔離方式與清理流程。 測試維護：讓失敗原因容易查找，並控制隨機或會改變的輸入。指定負責人。測試速度與維護成本要符合發布前檢查的需要。 驗收條件：已知缺陷存在時測試會失敗，修正後通過。測試能在目標環境重複執行，提供可採取行動的證據，且不洩漏或改動無關資料。 證據與限制（證據邊界）：沒有一份官方標準能管到全部內容。不同團隊、平台或框架的用法可能不同。 待確認：發布前必過的檢查、環境、測試資料、容許值、執行時間預算、負責人，以及不穩定測試的處理規則。