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

Question

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

有关用例的详细信息：

1. 功能将由 开发团队在入职方面 点，通常是类或类 方法。说，功能“excel文件 “导入”由方法定义 类的ImportExcelFile（...） FileImporter。
2. 在开发迭代期间， 开发团队承诺一些 一些方法的变化 类。比如，其中一个类 由方法间接使用 ImportExcelFile（）
3. 在迭代结束时，全部 通过工具分析提交 生成并交付报告 到QA团队。在我们的例子中， QA团队获悉该功能 必须测试“excel文件导入”， 和其他功能X Y＆amp; Z是 不变。

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

Answer 1

天儿真好，

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

回归测试是指专门运行完整的测试套件，以查看支持新功能的代码是否已破坏以前正在运行的代码。

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

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

编辑：特别是因为CI有一些隐藏的小陷阱，后见之明很明显。停止测试人员试图测试尚未实现新功能的所有文件的版本。 （您确认在过去五分钟内没有提交。）

另一个重要的一点是，如果你有一个破坏的构建，并且在有人检查代码然后尝试构建它以便他们可以测试它之前不知道它已经被破坏，那么就会浪费时间。

如果它坏了，你现在有：

• 坐着的测试人员无法进行预定的测试，
• 开发人员打断他们当前的工作，回到以前的工作来理清造成破坏构建的原因。更可能是开发人员，因为问题是两个独立部分之间的交互，每个部分都是独立工作。
• 由于开发人员必须重新回到上一段工作的思维模式而造成的时间损失，
• 开发人员的时间损失，让他们回到他们在调查中断之前正在进行的新工作的思维模式。

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

编辑：至于您的问题，在您完成测试后标记存储库的情况如何，例如TESTS_COMPLETE_2009_12_16。那么当你准备好研究下一组测试时，最新测试完成标签和HEAD之间的“svn diff -r”是什么？

HTH

顺便说一下，在我想到这些答案时，我会用一些进一步的建议来更新这个答案。

欢呼声，

Answer 2

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

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

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

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

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

在某一点之后建立的任何东西都需要回归测试。

除非你在一个保证人缺乏资源耗尽的环境中工作（例如TinyC），否则你最终会对所有事情进行回归测试。回归测试不是单元测试。