如何避免冗余测试

软件测试 自动化测试 单元测试 tdd 验收测试
2022-01-10 15:44:39

我们正在使用完全测试驱动的方法构建应用程序。作为开发人员,我们非常熟悉单元测试,但还没有接触过集成/功能/验收测试。因此这篇文章。

该应用程序公开了一个 Web UI(HTML 资源),它调用一个安全的 REST API(使用 JSON 序列化),然后委托给一个独立于任何交付机制的核心域模型(事务性应用程序服务和业务实体)。REST API 最终将公开。持久性是使用关系数据库和 ORM 实现的。使用标准的 Java / Spring / Hibernate 技术栈。

如果我们想做纯 TDD,我们将编写以下测试:

  • 用于 Web UI 的 Selenium / WebDriver 测试
  • REST API 的集成测试
  • 应用服务的集成测试
  • 存储库的集成测试(持久性)
  • Web 控制器的单元测试(REST API)
  • 应用程序服务的单元测试
  • 验证器的单元测试

我所说的集成测试是指针对部署在类似生产环境中的功能齐全的应用程序的测试。通过单元测试,我的意思是针对单个类的测试,其中协作者/依赖项已被测试替身(模拟、存根等)取代。

显然,每个测试都有不同的视角(Web 测试以用户为中心,API 测试以 API 消费者为中心,其他测试以开发人员为中心)并验证不同的断言(Web 测试的 HTML 元素内容、HTTP 响应和 API 测试的状态代码、应用程序测试的数据库内容和异常、单元测试的边缘案例等)。但是所有这些测试之间也有很多重叠,特别是在涉及到夹具时(例如,如果其他用户已经注册了相同的电子邮件,则用户无法注册)。因此,我们可以通过专注于较高层来避免编写其中一些测试(例如,只为重复电子邮件案例的用户注册编写 Web 测试),但如果较低层被重复使用,它们就会暴露出来。不同的客户端(例如批处理客户端使用的应用程序服务)。

所以我们最终想知道编写所有这些测试会有多大用处,以及我们如何才能更有效地使用我们的方法。你对此有什么看法?

我意识到这更像是一个讨论类型的问题,而不是一个有明确和可验证答案的问题,所以如果这不是合适的论坛,请您指导我到这些讨论的最佳论坛。

干杯!

2个回答

编写和维护自动化测试是一项巨大的投资,可以慢慢开始

编写和维护自动化测试的成本很高。如果测试以无效的方式编写,则投资可能不会得到回报。同样,如果测试需要大量维护,无论是因为测试的编写方式还是因为被测接口正在迅速变化,那么您的投资可能不会得到回报。与任何大笔投资一样,简化流程是值得的,这样您就有时间进行实验并从错误中恢复过来。

自动化 UI 测试特别脆弱,仍然需要手动测试

根据我的经验,UI 测试往往比 API 级别的测试更脆弱。浏览器不断发展,在我看来,每个新的浏览器版本都需要更改 Selenium,有时也需要更改我的测试。如果 HTML 没有在适当的地方使用元素 ID,那么您的测试必须通过不太永久的方式来识别元素。

最重要的是,UI 的某些方面仍需要人工审查:布局、措辞、颜色、字体和图形的使用以及可用性。

测试是达到目的的手段,而不是目的本身

我们的工作既困难又复杂,我们很想寻找能够无条件解决问题的绝对答案。但是,每个开发人员和每个项目都是不同的。一些开发人员喜欢快速编码并使用自动化测试来发现错误。其他开发人员可能会在编写一行代码之前考虑很长时间,从而减少错误。只要他们的素质高,他们如何开展工作都没有关系。

此外,即使对于同一个开发人员,他们的工作质量也可能会因他们正在从事的工作而有所不同。

我曾经认为每个人都应该为所有事情编写自动化测试,但是在与各种不同规模、技能和经验的团队合作之后,我相信正确的答案会更加复杂和混乱。

当任何其他类型的测试耗时、容易出错和/或重复时,考虑编写自动化测试

有些问题比其他问题更容易进行自动化测试。专注于显然难以通过任何其他方式测试的领域将帮助您在宝贵的时间中进行良好的投资。

搭腔

如果您对测试有雄心,一些重复工作是不可避免的,但您可以通过相互讨论您的测试内容来减少重复工作。

喷,

正如您所怀疑的那样,您的问题没有灵丹妙药的答案,但我可以提供一些建议供您考虑。

  • 在可能的情况下,将任何特定操作只编码一次并多次重复使用。
  • 尽可能结合面向对象和数据驱动的测试代码来驱动您的测试。
  • 如果您可以将一系列单元级测试和功能测试串在一起,请执行以下操作:如果您可以以函数的形式编写功能操作以单击链接,并传入页面、链接信息和预期结果一个文本文件,您只需要一个代码单元来处理单击链接,并且可以在多个位置使用它来进行流程测试。用于组合选择、按钮单击等的类似例程意味着您可以最大限度地减少重复工作。
  • 如果多个测试运行正在执行应用程序的同一部分,则将数据验证部分作为一次运行的一部分。
  • 随时记录您的测试。我正在使用一个脚本代码库,该代码库有超过 50 万行代码,几乎一样多的数据行,并且执行了这么多测试用例,如果有任何文档的话,其中大部分都没有记录。找出哪个位做了如此痛苦的事情,以至于那里有很多重复,遗留效应是噩梦般的。

希望这能给你一个很好的起点来考虑。