Boost 库旨在兼具可靠性和可移植性。每个经验丰富的程序员都知道这意味着每个库都必须针对足够数量的测试用例，在各种平台上进行测试，然后每次进行更改和每次发布之前都必须再次测试（回归测试）。

“基于广泛的目标测试的质量保证”是 C.A.R Hoare 的问题“软件如何在没有证明的情况下变得如此可靠”的关键答案之一。

回归测试

Boost 使用自动 回归测试套件，该套件生成 HTML 编译器状态表。

测试策略

必需

• 每个 Boost 库都应提供一个或多个合适的测试程序，以供 Boost 回归测试套件 执行。除了通常的编译-链接-运行测试期望成功完成之外，还可以执行仅编译或编译和链接测试，并且测试的成功可以定义为步骤的失败。
• 测试程序执行必须通过返回非零值来报告错误。它们也可能写入 stdout 或 stderr，但输出应该相对简短。无论其他输出如何，非零返回值是回归测试框架识别发生错误的唯一方法。请注意，要包含在状态表中的测试程序必须快速编译、链接和运行，因为测试会执行很多很多次。
• 具有耗时测试的库应分为用于状态表的快速执行基本测试程序和用于详尽测试用例的单独的全覆盖测试程序。基本测试应集中于编译问题，以便状态表准确反映库在平台上正确编译的可能性。
• 如果由于任何原因通常的测试策略不适用于特定库，则必须实施替代测试策略。
• 一个 Jamfile 来驱动库的回归测试。

可选（但强烈推荐）

Boost 测试库 提供了许多有用的组件，可以简化测试程序的构建。

• 使用库的 测试工具 来构建不需要太多结构的简单测试程序。
• 使用库的 单元测试框架 来构建需要构建成单个测试和测试套件的更复杂的测试程序。

修复错误或添加功能的建议协议。

• 首先，添加检测错误或测试功能的回归测试用例。有时添加一个案例会提示类似的未测试案例，并且它们也被添加。
• 其次，对于错误，运行回归测试并验证现在是否检测到该错误。
• 第三，然后，并且只有这样，才能修复错误或添加功能。
• 最后，重新运行完整的回归测试 - 有时更改会破坏其他内容。

历史

参见回归测试历史.

致谢

由 Beman Dawes 撰写。Jens Maurer、Paul Moore、Gary Powell 和 Jeremy Siek 提供了有用的建议。

---