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

为了避免太多测试，我希望为质量保证（QA）团队提供一些提示，指出在开发迭代后哪些功能必须进行回归测试。你知道哪些工具可以在C++和Subversion（和Visual Studio）开发环境中实现吗？有关使用情况在C++环境中优化回归测试

详情：

功能将由开发团队进入点，通常是类或类方法来定义。说，功能“excel文件导入”由方法定义ImportXcelFile（...）类 FileImporter。
在开发迭代中，开发团队对某些类的某些方法提交了一些更改。说，这些类的一个间接使用方法 ImportExcelFile（）
在迭代结束时，所有提交由报告生成工具和分析并发表给QA团队。在我们的示例中， QA团队被告知功能必须测试“excel文件导入”，，并且其他功能X Y & Z不会更改为。

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

来源

2009-12-16 Denis Dollfus

G'day，

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

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

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

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

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

再大点是时间上的损失，如果你有一个破碎的构建和不知道它是坏了，直到有人签出代码，然后尝试构建它，以便他们可以测试它。

如果它坏了，你现在有：

测试人员围坐无法做到计划的检测，
开发打断他们目前的工作回到以前的工作理清什么引起的打破构建。更可能是开发人员，因为问题是两个独立部分之间的交互，每个部分都独立工作。
由于开发人员不得不重新回到前一部分工作的思维而导致的时间损失，以及开发人员重新陷入他们所从事的新工作的思维的时间损失在中断前进行调查。

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

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

HTH

顺便说一句，因为我认为他们我会更新这个答案与一些进一步的建议。

欢呼声，

来源

2009-12-16 10:12:08

Rob，谢谢你的回答。其实我知道并支持Martin Fowler的出版物，我们正在使用持续集成，包括自动化单元测试。这里的关键是我们还有一个单独的QA团队，专注于测试功能 - 就XP而言的“故事”。我们希望能够引导他们在多次提交之后重新测试哪些故事，特别是为了防止“过度测试”那些不可能倒退的故事。 – 2009-12-16 13:01:39

@Denis，欢呼声。你的开发人员可以标记单个用户故事的提交吗？当故事完成时进行一次提交可能是危险的（如由于本地副本丢失而导致潜在的工作损失）并且不灵活。我建议可能在美国完成并提交时标记存储库。顺便说一句，我希望我有一美元，每次有人说“不可能倒退”，当我明白了！（ - ： – 2009-12-16 13:07:44

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

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

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

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

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

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

除非你在保证缺乏资源耗尽的环境下工作（例如TinyC），否则你将最终回归测试一切。回归测试不是单元测试。

来源

2009-12-16 11:43:58

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

回答

相关问题