6

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

有关用例的详细信息：

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

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

4

2 回答 2

2

天，

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

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

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

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

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

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

如果它坏了，你现在有：

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

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

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

高温高压

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

干杯，

于 2009-12-16T10:12:08.143 回答
0

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

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

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

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

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

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

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

于 2009-12-16T11:43:58.180 回答