当微服务有独立的发布时间表时,端到端测试的有效性?

人气:947 发布:2022-10-16 标签: continuous-integration testing devops microservices continuous-delivery

问题描述

我是20多名开发人员中的一员,他们为我们公司的一个域(例如交付跟踪域)维护大约7个组件(网站和微服务)。

为了确保质量,我们在&Quot;域范围内进行了端到端测试。然而,我们的E2E测试有一个问题:我们的E2E环境可能具有与生产版本不同的组件。出现这种差异的原因是组件(例如微服务)有自己的发布计划。

如何处理此问题?My question is almost similar to this

您是否强制要求必须在正确的微服务版本上运行E2E?如果是,如何?

还是您接受CI和生产永远不会有相同的微服务版本,而只是依赖于监控生产这一事实?

最后,E2E在您的CI/CD渠道中有多重要?

请注意,我只对我们微服务的E2E测试感兴趣,因为我无法控制第三方服务何时发布。

谢谢

推荐答案

一般将测试视为捕获错误的网络,将e2e视为该网络的另一部分。一个人不能指望建立一个无限密集的网来捕捉所有的虫子,随着我们投入更多的努力来改进这个网,边际价值就会下降。

使用这些术语,我们试图用网络的e2e部分捕捉哪些错误,特别是在测试不同版本的多个微服务时?我们可能关注的是两个服务在更改后无法正确集成时出现的一类错误,或者更糟糕的是,一些特殊的边缘情况,到目前为止一直是隐藏的,但将通过新的行为揭示出来。

在任何情况下,由于e2e测试的工作量很大,特别是在正确启动环境方面,因此最好用不同的方式来覆盖这些错误-API测试,两个服务之间的集成测试。

那么实际上,e2e测试在哪里有用呢?在我看来,有力量的不是细微的,而是可能影响整个系统质量的重大故障。我倾向于将我的e2e努力集中在覆盖体系结构的尽可能多的内容上,以便覆盖每个微服务、数据库、通信路径等。通常在这方面与功能组有很好的相关性,所以就产品而言也有很好的覆盖率。

总而言之--我应该关心我合并的代码没有确切地测试产品将如何部署吗?我不这么认为--如果出现重大故障,一组不同的版本会注意到这一点。如果有一个细微的错误,它会被集成或API测试捕获。如果真的有一个很难捕捉到的错误,那么我会付出代价看到它在生产中-有时就是这样。

941