在 C++ 环境中优化回归测试答案

【问题标题】：Optimizing regression testing in a C++ environnement在 C++ 环境中优化回归测试
【发布时间】：2009-12-16 09:52:24
【问题描述】：

为了避免过多的测试，我想向质量保证 (QA) 团队提供有关在开发迭代后必须对哪些功能进行回归测试的提示。您知道可以在 C++ 和 Subversion（以及 Visual Studio）开发环境中执行此操作的工具吗？

用例详情：

功能将由开发团队在进入方面点，通常是类或类方法。说，特征“excel文件 import" 由方法定义 ImportExcelFile(...) 类文件导入器。
在开发迭代过程中，开发团队提交了一些一些方法的改变类。说，这些课程之一被方法间接使用导入ExcelFile()
在迭代结束时，所有提交由工具分析，并生成并交付报告到 QA 团队。在我们的示例中， QA 团队获悉该功能 “excel文件导入”必须经过测试，并且其他特征 X Y & Z 是不变。

这个工具很可能会使用静态代码分析并使用颠覆 API。但它存在吗？

【问题讨论】：

【解决方案1】：

生日，

您所描述的并不是真正的回归测试。您只是在测试新功能。

回归测试是您专门运行完整的测试套件以查看支持您的新功能的代码是否破坏了以前工作的代码。

我强烈推荐阅读 Martin Fowler 的优秀论文“Continuous Integration”，它涵盖了您所谈论的一些方面。

它还可以为您提供更好的工作方式，特别是 Martin 在他的论文中谈到的 CI 方面。

编辑：尤其是因为 CI 有一些隐藏的小陷阱，事后看来是显而易见的。诸如阻止测试人员尝试测试尚未提交所有实现新功能的文件的版本之类的事情。（您确认在过去五分钟内没有提交）。

另一个重要的问题是，如果您的构建损坏并且直到有人检查代码然后尝试构建它以便他们可以测试它时才知道它被损坏了，那么您会浪费时间。

如果它坏了，你现在有：

CI 的基本理念是在白天对完整产品进行多次构建，以便尽早捕获损坏的构建。您甚至可以选择一些测试来检查您的产品的基本功能是否仍然有效。再次尽快通知您当前的构建状态存在问题。

编辑：至于您的问题，当您完成测试后如何标记存储库，例如测试_完成_2009_12_16。那么当你准备好计算下一组测试在最新测试完成标记和 HEAD 之间执行“svn diff -r”时？

HTH

顺便说一句，我会根据我的想法用一些进一步的建议来更新这个答案。

干杯，

【讨论】：

罗布，谢谢你的回答。实际上，我知道——也是 Martin Fowler 出版物的支持者——我们正在使用持续集成，包括自动化单元测试。这里的重点是我们还有一个单独的 QA 团队，专注于测试功能——XP 中的“故事”。我们希望能够指导他们在多次提交后应该重新测试哪些故事，尤其是为了防止对不可能回归的故事进行“过度测试”。
@Denis，干杯。您的开发人员可以标记单个用户故事的提交吗？在故事完成时进行一次提交可能既危险（例如由于本地副本丢失而导致工作丢失）又不灵活。我建议在美国完成并提交时标记存储库。顺便说一句，我希望每次有人对我说“不可能倒退”时，我都能得到一美元！ (-:

【解决方案2】：

将您的项目拆分为单独的可执行文件并构建它们。

如果依赖项发生变化，Make 将重建任何可执行文件。

将任何链接测试的输出文件添加到下一个测试的依赖项中 - 例如，保存文件测试的输出作为读取文件测试的依赖项。

在此之后构建的任何东西都需要进行单元测试。

如果任何库使用常见的可耗尽资源（堆内存、磁盘、全局互斥锁等），也将它们添加为依赖项，因为一个库中的泄漏导致的耗尽通常是另一个库中的回归失败。

在某个时间点之后构建的任何东西都需要回归测试。

除非您在保证人不会耗尽资源的环境中工作（例如 TinyC），否则您最终将对所有内容进行回归测试。回归测试不是单元测试。

【讨论】：