AI功能如何摧毁微服务测试以及修复方法
作者：微信文章文章讨论了GenAI和微服务结合带来的测试挑战，传统测试方法失效，提出左移测试并使用真实环境测试，强调基于沙盒的测试平台能提升AI功能交付速度和质量，最终在竞争中获得优势。
译自：Why AI Features Break Microservices Testing and How To Fix It
作者：Arjun Iyer
许多工程团队都在竞相推出 AI 功能。智能搜索、个性化推荐、自动内容生成——集成 生成式 AI (GenAI) 功能 的压力是巨大的。但我和数百个工程团队交流后发现了一个令人不安的事实：虽然他们可以比以往更快地构建这些功能，但可靠地测试这些功能变得异常困难。
这不仅仅是一个生产力问题，而是一场根本性的测试危机。构建 AI 驱动功能的团队发现，他们现有的测试方法根本不是为 GenAI 引入的 微服务架构 的复杂性而设计的。
让工程领导者夜不能寐的问题不是“我们如何构建 AI 功能？”，而是“我们如何知道它们在生产环境中真正可靠地工作？”
完美风暴：当 GenAI 遇到微服务
完美风暴：当 GenAI 遇到微服务
我最近与一家金融科技公司的工程副总裁进行了交谈，该公司正在争先恐后地推出 AI 驱动的功能以保持竞争力。“我们现在可以很快地构建智能欺诈检测功能，”她告诉我。“但是我们添加的每个 AI 功能都会带来新的依赖项——向量数据库、LLM [大型语言模型] API、嵌入服务、护栏系统。弄清楚所有这些组件是否真的能与我们现有的支付处理、用户身份验证和通知服务一起工作？这就是我们感到不知所措的地方。”
GenAI 功能引入了一类根本不同的复杂性，这种复杂性 打破了传统的测试 方法：
• 不可预测的行为模式。 与传统的 API 不同，GenAI API 可以为类似的输入返回截然不同的输出。你根本无法有效地模拟这种可变性。• 复杂的集成链。 单个 AI 功能通常需要协调多个服务：向量数据库、LLM API、内容审核 API 和现有的业务逻辑服务。• 外部依赖蔓延。 AI 功能严重依赖于外部 GenAI API 和专门的数据库，每个 API 和数据库都会增加新的故障模式和响应模式，这些模式无法在本地模拟。
为什么传统测试会失效
大多数团队尝试以与以往测试微服务相同的方式处理 AI 功能测试：使用模拟依赖项的单元测试，然后在共享的预发布环境中进行集成测试。由于几个关键原因，这种方法在 AI 功能方面彻底失败。
• 模拟无法捕获 AI 行为。 你如何模拟 LLM 的响应？你编写的任何模拟都将是对实际模型的行为模式、响应时间和边缘情况的拙劣近似。实际的 AI 服务可能会根据你的模拟无法预测的上下文，以完全不同的格式返回响应。• 本地开发环境变得不可能。 在本地运行向量数据库、多个 AI 服务和复杂的协调不仅速度慢，而且在技术上通常是不可能的。开发人员最终会针对简化的、不切实际的本地设置进行测试，这些设置与生产环境几乎没有相似之处。• 集成问题出现得太晚。 团队最终更加依赖预发布环境来验证所有内容是否真的可以一起工作。但是，随着越来越多的团队争夺相同的共享预发布资源，这会造成巨大的瓶颈。当预发布环境出现故障时（AI 功能经常出现这种情况），整个工程团队都会受阻。• 调试变成一场噩梦。 当多个 AI 功能同时部署到预发布环境并且出现故障时，找到根本原因就像解决一个谋杀之谜。是新的推荐算法吗？更新的内容审核？多个更改之间的交互？工程师们浪费了几天时间来回切换到他们几周前编写的代码。
AI 系统的左移势在必行
解决方案不是减慢 AI 功能的开发速度——那样会丧失竞争优势。解决方案是从根本上重新思考我们何时以及如何验证这些复杂的集成。
具有前瞻性思维的团队正在 将全面的测试左移，在代码合并之前，在真实的环境中验证 AI 功能的行为。但这里有一个重要的见解：“左移”并不意味着在本地使用模拟进行测试。它意味着将类似于生产环境的环境更贴近开发人员的工作流程。
这就是传统的左移建议在 AI 系统中失效的地方。你无法在你的笔记本电脑上运行所有内容，并且你无法在不损失保真度的情况下模拟所有内容。AI 集成的复杂性需要一种不同的方法：轻量级的、真实的环境，开发人员可以立即访问这些环境，而无需完全复制环境的开销。
真实的环境：缺失的一环
如果不是在昂贵的完整环境复制或不切实际的模拟之间进行选择，而是有第三种选择，那会怎么样？现代的 基于沙盒的测试平台 通过启动仅包含修改后的服务的轻量级环境来解决此问题，同时将请求路由到在共享基线中运行的真实 AI 服务、数据库和下游依赖项。
这种方法能够在实际的 LLM API 上使用真实的响应模式进行测试，验证真正的服务集成，并在代码新鲜时捕获特定于 AI 的问题，而无需 复制整个环境 的成本。
竞争优势
我最近合作的一个金融科技团队使用这种方法将他们的 AI 功能交付时间从几周缩短到几个小时。“我们过去花在调试预发布环境问题上的时间比构建功能的时间还多，”他们的工程主管告诉我。“现在我们可以立即发现 AI 集成问题，而开发人员仍然记得他们为什么做出特定的实现选择。”
这种计算方式引人注目。当多个团队部署更改后，AI 集成问题出现在预发布环境中时，调试可能会消耗几天的时间。当在 拉取请求过程中的隔离沙箱 中捕获到相同的问题时，解决问题只需几分钟。
更重要的是，能够快速验证 AI 功能的团队可以推出更多的 AI 功能。当竞争对手在预发布瓶颈和集成难题中挣扎时，具有前瞻性思维的组织正在快速迭代驱动业务价值的 AI 功能。
超越测试危机
GenAI 革命正在创造全新的软件复杂性，而我们现有的测试工具并非为处理这些复杂性而设计。能够蓬勃发展的组织是那些通过真实的环境测试来补充传统单元和集成测试的组织，这些测试可以实际验证 AI 系统的复杂、不可预测的行为。
在 Signadot，我们亲眼目睹了这种转变，因为越来越多的团队为其 AI 功能采用基于沙盒的测试。在一个构建 AI 功能变得越来越容易的世界中，竞争优势属于能够以最快速度验证它们的团队。问题不是你的团队是否会为 AI 功能采用真实的环境测试，而是你是否会在你的竞争对手之前这样做。
引用链接
Why AI Features Break Microservices Testing and How To Fix It:https://thenewstack.io/why-ai-features-break-microservices-testing-and-how-to-fix-it/
生成式 AI (GenAI) 功能:https://thenewstack.io/genai-is-quickly-reinventing-it-operations-leaving-many-behind/
微服务架构:https://thenewstack.io/microservices/
:https://cdn.thenewstack.io/media/2025/06/7dd2f155-storm_-genai-microservices-683x1024.jpg
打破了传统的测试:https://thenewstack.io/from-poc-to-production-why-genai-projects-often-stall/
将全面的测试左移:https://thenewstack.io/why-we-shift-testing-left-a-software-dev-cycle-that-doesnt-scale/
基于沙盒的测试平台:https://thenewstack.io/sandbox-testing-the-devex-game-changer-for-microservices/
复制整个环境:https://thenewstack.io/why-duplicating-environments-for-microservices-backfires/
拉取请求过程中的隔离沙箱:https://thenewstack.io/shifting-testing-left-the-request-isolation-solution/
Signadot:https://www.signadot.com/
页:
[1]