Boost 測試政策與協議
Boost 函式庫旨在兼具可靠性和可移植性。每個經驗豐富的程式設計師都知道，這意味著每個函式庫都必須針對大量的測試案例，在各種平台上進行測試，然後每次進行更改以及每次發布之前都必須再次測試（回歸測試）。
「基於廣泛目標測試的品質保證」是 C.A.R Hoare 提問「軟體如何在沒有證明的狀況下變得如此可靠」的關鍵答案之一。
回歸測試
Boost 使用自動化的 回歸測試套件，該套件會產生 HTML 格式的 編譯器狀態表格。
測試政策
必要
- 每個 Boost 函式庫都應提供一個或多個合適的測試程式，以供 Boost 回歸測試套件 執行。除了預期成功完成的常規編譯-連結-執行測試之外，還可以執行僅編譯或編譯和連結測試，並且測試的成功可以定義為步驟的失敗。
- 測試程式執行必須透過返回非零值來回報錯誤。它們也可以寫入 stdout 或 stderr，但輸出應該相對簡短。無論其他輸出如何，非零返回值是回歸測試框架識別錯誤發生的唯一方法。請注意，要包含在狀態表格中的測試程式必須編譯、連結和執行速度快，因為測試會執行很多很多次。
- 具有耗時測試的函式庫應分為用於狀態表格的快速執行基本測試程式和用於詳盡測試案例的單獨完整涵蓋測試程式。基本測試應側重於編譯問題，以便狀態表格準確反映函式庫在平台上正確編譯的可能性。
- 如果由於任何原因，通常的測試政策不適用於特定函式庫，則必須實施替代測試策略。
- 一個用於驅動函式庫回歸測試的 Jamfile。
選用（但強烈建議）
Boost 測試函式庫 提供許多有用的元件，可簡化測試程式的建構。
修正錯誤或新增功能的建議協議。
- 首先，新增偵測錯誤或測試功能的回歸測試案例。有時新增一個案例會提示類似的未測試案例，並將它們也新增進去。
- 其次，對於錯誤，執行回歸測試並確認現在已偵測到錯誤。
- 第三，然後，只有這樣，才能修正錯誤或新增功能。
- 最後，重新執行完整的回歸測試 - 有時更改會破壞其他東西。
歷史記錄
致謝
由 Beman Dawes 撰寫。Jens Maurer、Paul Moore、Gary Powell 和 Jeremy Siek 提供了有益的建議。
