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

Question

为了避免过多的测试,我想向质量保证(QA)团队提供关于在开发迭代之后必须对哪些特征进行回归测试的提示.你知道在C++和Subversion(和visual studio)开发环境中可以做到的工具吗？

有关用例的详细信息:

1. 特征将由开发团队根据入口点(通常是类或类方法)来定义.比如,"excel文件导入"功能由类FileImporter的方法ImportExcelFile(...)定义.
2. 在开发迭代期间,开发团队对某些类的某些方法进行了一些更改.比如说,其中一个类是由方法ImportExcelFile()间接使用的
3. 在迭代结束时,工具会分析所有提交,并生成报告并将其交付给QA团队.在我们的示例中,QA团队被告知必须测试"excel文件导入"功能,并且其他功能XY和Z不变.

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

Answer 1

你好，

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

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

我强烈推荐阅读 Martin Fowler 的优秀论文“持续集成”，其中涵盖了您正在讨论的一些方面。

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

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

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

如果它坏了，你现在有：

• 测试人员坐在那里无法完成预定的测试，
• 开发人员中断当前的工作，返回之前的工作，以找出导致构建损坏的原因。更可能的是开发人员，因为问题是两个独立部分之间的交互，每个部分都独立工作。
• 由于开发人员必须重新回到之前工作的心态而造成的时间损失，以及
• 开发人员在中断调查之前回到他们正在从事的新工作的心态上会损失时间。

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

编辑：至于您的问题，完成测试后标记存储库怎么样，例如 TESTS_COMPLETE_2009_12_16。然后，当您准备好弄清楚下一组测试时，会在最新测试完成的标记和 HEAD 之间执行“svn diff -r”吗？

华泰

顺便说一句，我将用我想到的一些进一步的建议来更新这个答案。

干杯，