【问题标题】:Performance testing with external dependencies使用外部依赖项进行性能测试
【发布时间】:2020-04-08 00:26:44
【问题描述】:

在微服务领域进行性能测试(主要是负载测试)时,您的应用程序依赖但不由您的团队拥有/控制的外部依赖项 (API) 的方法是什么。在我的情况下,外部依赖项由同一公司内的团队拥有。那么您会指向相应的“真实”集成非产品端点,还是创建存根并模仿它们的响应时间以尽可能匹配生产?

  • 第一种方法示例:您的团队拥有的后端 api 并调用外部 api 来验证客户。您的团队无法控制客户 API,但您在运行负载测试时仍指向他们的集成测试端点。
  • 第二种方法示例:您的团队拥有的后端 api 调用发送静态响应并模拟外部客户 api 响应时间的存根。

我意识到这两种方法各有利弊,根据测试的目标,一种方法会优于另一种方法。但是你最喜欢的是什么?不一定是上述两者之间的选择。可以是完全不同的。

【问题讨论】:

  • 在这种情况下我会害怕使用存根。主要是因为这就是一家价值 10 亿美元、每天有数百万订单的计算机制造商如何与 100 多名开发人员一起工作 18 个月,将他们的结构转换为微服务,发现当他们投入生产时,什么都没有发生。在他们的开发环境中,他们对每个外部调用都进行了存根处理,这样做他们从未意识到 200 个微服务的 150 毫秒响应时间意味着 0.00% 的可用性。 the story 的道德 - 不要存根,因为你可以。存根,因为你必须这样做。
  • 谢谢!关于您对测试的信心及其提供的信息的好点。在我的情况下,具有其依赖关系的系统已经建立并具有其已知的弱点。但是,总有一些等待被发现...

标签: performance-testing stub external-dependencies


【解决方案1】:

识别被测系统(或应用程序)很重要。如果您衡量您自己的微服务的性能,那么您可以考虑将存根作为一种选择。

但是,性能测试通常用于评估整个系统的性能。目的通常是模拟实际使用中的延迟。稍微准确地对此进行建模的唯一方法是存根并使用“真正的”集成端点。这种方法具有额外的优势,因为它可以帮助您识别潜在的系统性能瓶颈,例如微服务之间的链式同步调用(服务 A 调用 B,B 调用 C,C 调用 D 等)。这些测试也可以重复用于负载测试。

简而言之,您需要同时做这两件事来确保:

  1. 微服务在 SLA 内执行
  2. 各种微服务作为一个整体在 SLA 内执行。

【讨论】:

  • 感谢您输入赛斯,我的声誉仍然不足以公开支持您的评论,但应该记录下来。很像在双方都启用覆盖的想法。就我而言,唯一的问题是外部团队拥有的集成端点有时甚至不接近生产端点。所以他们给你的信息可能会误导你。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-11-30
  • 2011-09-18
  • 1970-01-01
  • 2021-04-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多