集成测试与测试覆盖率

时间:2012-10-31 15:44:29

标签: testing integration-testing code-coverage

我的公司有一个规则,可以通过单位或集成测试达到75%的测试覆盖率。由于整个系统的复杂性,开发人员倾向于编写集成测试(例如,对正在运行的应用程序使用selenium webdriver),而不是嘲笑依赖服务/类的负担。

我不是那样的朋友,并想知道i-tests的测试覆盖率数据实际意味着什么:

在我看来,测试应该定义预期的行为并测试它。如果i-test深入到应用程序,通过许多服务,可能直到DB层再返回,它将覆盖很多行,但是绝对不清楚这种覆盖行的预期行为是什么。因此,覆盖数据的质量是有问题的恕我直言,更糟糕的是,增加了维护工作。

POV是否正确?在与管理层讨论时,我该如何备份呢?

2 个答案:

答案 0 :(得分:3)

关于测试覆盖率的盲百分比规则并不是很理想。集成测试就是一个很好的例子。如果有什么东西坏了,你能准确说出什么破了吗?如果您有多个集成点(例如,单个请求命中数据库,Web服务并发送电子邮件),该怎么办?那里有太多让测试真正有意义的东西。

如果不测试所有可能的结果,您可以获得100%的覆盖率吗?你能编写10,000个测试但是仍然无法覆盖一个软件中最重要的类吗?盲目指标很糟糕,质量没有真正的结果。

通常,进行更小,更离散的测试更有价值。我们通过剔除集成点并在测试中嘲笑它们来做到这一点。然后,您可以设置方案,“如果数据库执行此操作,那么我的代码会执行此操作。”这种类型的问题在内存中比在可重复的基础上设置数据库以更精确地解决问题更容易解决。您如何自动化服务器断开连接的集成测试?那很难。删除处理特定SQL异常的数据库更加容易和可重复。

答案 1 :(得分:1)

如果您在截止日期之前无法达到75%的测试覆盖率,或者即使您达到它,将会发生什么呢?剩下的25%,所以您的公司并不专注于获得缺陷较少的产品专注于测试覆盖率的百分比。尽管你使用硒或任何所谓的硒,但以可信的方式解释你的方法。