c++ - 在 C++ 环境中优化回归测试

Question

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

有关用例的详细信息:

1. 特征将由开发团队在入门方面点，通常是类(class)或类(class)方法。比如说，功能“excel文件import"由方法定义类的 ImportExcelFile(...)文件导入器。
2. 在开发迭代期间，开发团队 promise 了一些一些方法的改变类。比如说，这些类(class)之一被方法间接使用导入Excel文件()
3. 在迭代结束时，所有提交由该工具分析，并且生成并交付报告给质量检查小组。在我们的示例中，QA 团队被告知该功能“excel文件导入”必须要测试，并且 X Y & Z 的其他特征是不变。

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

Answer 1

你好，

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

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

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

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

编辑:特别是因为 CI 有一些隐藏的小陷阱，事后看来很明显。例如阻止测试人员尝试测试尚未提交所有实现新功能的文件的版本。 (您确认在过去五分钟内没有提交)。

另一个重要的问题是，如果您的构建损坏并且直到有人 checkout 代码然后尝试构建它以便他们可以测试它才意识到它已损坏，这会浪费时间。

如果它坏了，你现在有:

• 测试人员坐在那里无法进行预定的测试，
• 一名开发人员中断了他们当前的工作以返回到之前的工作，以找出导致构建失败的原因。更有可能是开发人员，因为问题是两个独立部分之间的交互，每个部分都独立工作。
• 由于开发人员不得不重新思考之前的工作而造成的时间损失，以及
• 开发人员在中断调查之前重新思考他们正在从事的新工作的时间损失。

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

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

HTH

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

干杯，