首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >自动化单元测试、集成测试或验收测试

自动化单元测试、集成测试或验收测试
EN

Software Engineering用户
提问于 2011-01-24 12:25:11
回答 7查看 12.8K关注 0票数 31

TDD和单元测试似乎是目前的热门话题。但与其他形式的自动化测试相比,它真的那么有用吗?

直觉地说,我猜想自动化集成测试比单元测试更有用。在我的经验中,大多数bug似乎是模块之间的交互,而不是每个单元的实际(通常有限的)逻辑。此外,回归通常是由于模块之间的接口变化(以及前后条件的变化)而发生的。

我是不是误解了什么,或者为什么与集成测试相比,单元测试得到了如此多的关注?这仅仅是因为我们假设集成测试是您拥有的东西,而单元测试是我们需要学习作为开发人员应用的下一个东西?

或者,与自动化测试的复杂性相比,单元测试只会产生最高的增益?

:您在自动化单元测试、自动化集成测试和自动验收测试方面有哪些经验?在您的经验中,什么已经产生了最高的ROI?为什么?

如果您必须选择一种形式的测试才能在您的下一个项目自动化,它会是哪一种?

提前谢谢。

EN

回答 7

Software Engineering用户

回答已采纳

发布于 2011-01-24 12:44:19

使单元测试非常有用的一个重要因素是快速反馈。

考虑一下当您的应用程序被集成/系统/功能测试完全覆盖时会发生什么(这已经是一种理想的情况,在大多数开发公司中都是不现实的)。这些测试通常由一个专门的测试团队来运行。

  • 如果你向SCM回购提交了一个更改,
  • 有时(可能几天)之后,测试人员获得一个新的内部版本并开始测试,
  • 他们发现了一个窃听器并提交了一个bug报告,
  • (在理想情况下)有人将错误报告重新分配给您。

这一切可能需要几天甚至几个星期。到目前为止,您已经在处理其他任务,因此您还没有前面编写的代码的详细信息。此外,通常您甚至没有任何直接的证据来证明bug的实际位置,因此查找和修复该bug需要相当长的时间。

而在单元测试(TDD)中

  • 你写个测试,
  • 你写了一些代码来满足测试,
  • 测试还是失败的,
  • 看一看代码,通常几秒钟内就会有"oops“体验(比如"oops,我忘记检查那个条件了!”)
  • 马上修好窃听器。

这一切在几分钟内就会发生。

这并不是说集成/系统测试没有用;它们只是服务于不同的目的。有了编写良好的单元测试,您可以在代码中捕获大量的bug,然后再进入集成阶段,在那里查找和修复它们已经花费了很多钱。您是正确的,需要集成测试来捕获那些很难或不可能通过单元测试捕获的bug类型。然而,在我的经验中,这是比较罕见的类型;我看到的大多数bug都是由于方法中某个简单甚至微不足道的遗漏引起的。

更不用说单元测试也测试您的接口的可用性/安全性等,从而为您提供至关重要的反馈,以改进您的设计和API。而IMHO可以大大减少模块/susbsystem集成错误的可能性: API越容易、越干净,误解或遗漏的可能性就越小。

您在自动化单元测试、自动化集成测试和自动验收测试方面有哪些经验?在您的经验中,什么产生了最高的ROI?为什么?

ROI取决于许多因素,其中最重要的可能是您的项目是绿地还是遗产。对于绿地开发,我的建议(和迄今为止的经验)是从一开始就对TDD风格进行单元测试。我相信这是最具成本效益的方法。

然而,在一个遗留的项目中,建立足够的单元测试覆盖范围是一项巨大的任务,将非常缓慢地产生效益。如果可能的话,尝试通过UI通过系统/功能测试来覆盖最重要的功能是更有效的。(桌面GUI应用程序可能很难通过GUI自动测试,尽管自动化测试支持工具正在逐步改进.)。这给了你一个粗糙而有效的安全网。然后,您可以开始逐步建立单元测试围绕最关键的部分应用程序。

如果您只需要选择一种形式的测试来自动化您的下一个项目,它会是哪一种?

这是一个理论问题,我认为这是毫无意义的。各种各样的测试都在一个优秀的SW工程师的工具箱中使用,所有这些都有不可替代的场景。

票数 37
EN

Software Engineering用户

发布于 2011-01-24 13:34:44

所有类型的测试都是非常重要的,并确保系统的各个方面都符合规范。所以向后看,“如果我必须选择一种测试.”我不会。单元测试给我的反馈不同于集成测试或一个人的交互测试。

下面是我们所做的测试的类型/好处:

  • 单元测试--确保单元执行我们期望的工作。我们测试每个接口的提供者和消费者合同-这是相当容易的自动化。我们也检查我们的边界条件,等等。
  • 集成测试--确保各单元协同工作。这主要是为了测试我们的设计。如果这里有什么故障,我们必须调整单元测试以确保它不会再次发生。
  • 系统测试-确保系统符合要求/规范。通常,人们都会做这种测试。
  • 验收测试--客户端这样做是为了验证最终产品是否做了广告。

可选但建议测试:

  • 用户体验测试:虽然我们从系统测试中得到了不错的反馈,但是让客户端预览某些预发布可以真正帮助我们确定是否需要在为时已晚之前进行更改。

为了理解为什么单元测试比集成测试更有优势,您必须了解需要全面的其他测试的数量级。对于单元A的每一个可能的结果,都需要一个测试。单元B也是如此。现在,如果这两种测试一起为一个更完整的解决方案而工作,那么测试的数量是组合的。简而言之,要测试单元A和单元B之间的相互作用的每一个排列,就需要进行A*B测试。加上单元C,三组测试的次数将为A*B*C。

这就是接口和对象边界的概念变得非常重要的地方。接口表示特定的契约。接口的实现者同意它将以某种方式运行。同样,接口的使用者同意它将以某种方式使用该实现。通过编写收集实现接口的每个类的测试,您可以轻松地测试每个实现是否遵守接口契约。这是等式的一半。另一半是测试消费者方面--这是模拟对象进入游戏的地方。模拟被配置为确保交互始终在规范中。此时,所需要的只是进行一些集成测试,以确保实现者/使用者契约的正确性。

票数 9
EN

Software Engineering用户

发布于 2011-01-24 12:33:32

这些是具有不同目标的不同工具:

  • 单元测试是一种设计工具(TDD),几乎是重构的先决条件。
  • 集成测试可以很好地可视化项目的进度,也可以很好地避免回归错误。

需要记住的一点是,您不能真正使用集成测试进行设计,也不会发现单元测试的回归。

票数 3
EN
页面原文内容由Software Engineering提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://softwareengineering.stackexchange.com/questions/39368

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档