Boost 测试策略与协议
Boost 库旨在既可靠又可移植。每位经验丰富的程序员都知道，这意味着每个库都必须针对适当数量的测试用例、在各种平台上进行测试，然后在每次更改以及每次发布之前再次测试（回归测试）。
“基于广泛的目标测试的质量保证”是 C.A.R Hoare 的问题“在没有证明的情况下，软件是如何变得如此可靠的”的关键答案之一。
回归测试
Boost 使用自动回归测试套件，该套件生成 HTML 编译器状态表。
测试策略
必需
- 每个 Boost 库都应提供一个或多个合适的测试程序，供 Boost 回归测试套件执行。除了通常期望成功完成的编译-链接-运行测试之外，还可以执行仅编译或仅编译和链接的测试，并且测试的成功可以定义为步骤的失败。
- 测试程序执行必须通过返回非零值来报告错误。它们也可以写入 stdout 或 stderr，但该输出应相对简洁。无论其他输出如何，非零返回值是回归测试框架识别到错误发生的唯一方式。请注意，要包含在状态表中的测试程序必须快速编译、链接和运行，因为测试会执行非常非常多次。
- 具有耗时测试的库应分为用于状态表的快速执行基本测试程序，以及用于详尽测试用例的单独的全面覆盖测试程序。基本测试应侧重于编译问题，以便状态表准确反映库在平台上正确编译的可能性。
- 如果由于任何原因，通常的测试策略不适用于特定库，则必须实施替代测试策略。
- 用于驱动库的回归测试的 Jamfile。
可选（但强烈推荐）
Boost Test Library 提供了许多有用的组件，可以简化测试程序的构建。
建议的修复错误或添加功能的协议。
- 首先，添加检测错误或测试功能的回归测试用例。有时添加一个用例会建议类似的未测试用例，并且也会添加它们。
- 其次，对于错误，运行回归测试并验证现在是否检测到该错误。
- 第三，然后，并且只有在那时，修复错误或添加功能。
- 最后，重新运行完整的回归测试 - 有时更改会破坏其他内容。
历史
致谢
由 Beman Dawes 编写。Jens Maurer、Paul Moore、Gary Powell 和 Jeremy Siek 提供了有益的建议。
