亚马逊AMET支付团队如何利用Strands智能体加速测试用例生成

📢 转载信息

原文链接：https://aws.amazon.com/blogs/machine-learning/how-the-amazon-amet-payments-team-accelerates-test-case-generation-with-strands-agents/

原文作者：Jayashree R, Fahim Surani, and Harsha Pradha

在亚马逊阿联酋站 (Amazon.ae)，我们为中东和北非地区的五个国家（阿联酋、沙特阿拉伯、埃及、土耳其和南非）的约 1000 万客户提供服务。我们的 AMET（非洲、中东和土耳其）支付团队负责管理这些多元化国家/地区的支付选择、交易、体验和分期付款功能，平均每月发布五项新功能。每项功能都需要进行全面的测试用例生成工作，这传统上会消耗每个项目 1 周的手动工作量。我们的质量保证 (QA) 工程师将这些时间用于分析业务需求文档 (BRD)、设计文档、UI 模拟和历史测试准备工作——这项工作每年仅测试用例创建就需要一名全职工程师。

为了改进这一手动流程，我们开发了 SAARAM（QA 生命周期应用），这是一个多智能体 AI 解决方案，可帮助将测试用例生成时间从 1 周缩短到几小时。通过使用 Anthropic 的 Claude Sonnet 结合 Amazon Bedrock 以及 Strands Agents SDK，我们将生成测试用例所需的时间从 1 周缩短到短短几小时，同时还提高了测试覆盖的质量。我们的解决方案展示了如何研究人类认知模式（而非仅仅优化 AI 算法）可以创建出增强而非取代人类专业知识的生产级系统。

在本文中，我们将解释如何通过以人为本的方法克服单智能体 AI 系统的局限性，实施结构化输出来显著减少幻觉，并构建了一个可扩展的解决方案，该方案现已定位扩展到整个 AMET QA 团队，并计划在未来扩展到国际新兴商店和支付 (IESP) 组织的其它 QA 团队。

解决方案概述

AMET 支付 QA 团队负责验证影响数百万客户支付功能的代码部署，这些客户遍布不同的监管环境和支付方式。我们手动创建测试用例的流程增加了产品周期的周转时间 (TAT)，占用了宝贵的工程资源用于重复的测试准备和文档任务，而不是用于战略性测试工作。我们需要一个自动化的解决方案，它既能保持我们的质量标准，又能减少所需的时间投入。

我们的目标包括：将测试用例创建时间从 1 周缩短到几小时以内；捕获经验丰富的测试人员的机构知识；跨团队标准化测试方法；并最大限度地减少 AI 系统中常见的幻觉问题。该解决方案需要处理跨越多种支付方式、地区法规和客户群的复杂业务需求，同时生成与我们现有测试管理系统保持一致的具体、可操作的测试用例。

该架构采用了复杂的多智能体工作流。为实现这一目标，我们经历了 3 次不同的迭代，并且随着新技术的开发和新模型的部署，我们仍在不断改进和增强。

传统 AI 方法的挑战

我们最初的尝试遵循传统的 AI 方法，将整个 BRD 输入给单个 AI 智能体以生成测试用例。这种方法经常产生通用的输出，例如“验证支付是否正确”，而不是我们的 QA 团队所需的具体、可操作的测试用例。例如，我们需要像以下这样具体的测试用例：“验证当阿联酋客户对超过 1000 迪拉姆的订单选择货到付款 (COD) 且已保存信用卡时，系统显示 11 迪拉姆的 COD 费用，并通过 COD 网关处理支付，订单状态转换为‘等待配送’。”

单智能体方法存在几个关键限制。上下文长度限制使得有效处理大型文档变得困难，而缺乏专业处理阶段意味着 AI 无法理解测试优先级或基于风险的方法。此外，幻觉问题产生了不相关的测试场景，可能会误导 QA 工作。根本原因很明确：AI 试图在没有经验丰富的测试人员在分析需求时所采用的迭代思考过程的情况下，压缩复杂的业务逻辑。

以下流程图说明了我们尝试使用具有全面提示的单个智能体时遇到的问题。

以人为本的突破

我们的突破来自于对方法的根本转变。我们没有问：“AI 应该如何思考测试？”，而是问：“有经验的人类是如何思考测试的？”目的是专注于遵循特定的分步过程，而不是仅仅依靠大型语言模型 (LLM) 独立实现这一点。这一理念上的转变促使我们对高级 QA 专业人员进行了研究访谈，详细研究了他们的认知工作流程。

我们发现，有经验的测试人员不会整体处理文档——他们会经历专业化的思维阶段。首先，他们通过提取验收标准、识别客户旅程、理解用户体验 (UX) 要求、映射产品需求、分析用户数据和评估工作流能力来分析文档。然后，他们通过一个系统的过程来开发测试：旅程分析、场景识别、数据流映射、测试用例开发，最后是组织和优先级排序。

然后，我们将原始智能体分解为充当各个步骤的连续思考动作。我们使用 Amazon Q Developer for CLI 构建和测试了每个步骤，以确保基本思想是合理的，并结合了主要和次要输入。

这一洞察促使我们设计了 SAARAM，其中包含模仿这些专家测试方法的专业智能体。每个智能体都专注于测试过程的特定方面，例如人类专家如何在精神上对不同分析阶段进行划分。

基于 Strands Agents 的多智能体架构

基于我们对人类 QA 工作流程的理解，我们最初尝试从头开始构建自己的智能体。我们不得不创建自己的循环、串行或并行执行逻辑。我们还创建了自己的编排和工作流图，这需要大量的手动工作。为应对这些挑战，我们迁移到了 Strands Agents SDK。它提供了多智能体编排所需的功能，用于协调复杂、相互依赖的任务，同时保持清晰的执行路径，从而帮助提高了我们的性能并缩短了开发时间。

工作流迭代 1：端到端测试生成

SAARAM 的第一个迭代由单个输入组成，并创建了我们的第一个专业智能体。它涉及通过五个专业智能体处理工作文档，以生成全面的测试覆盖。

智能体 1 被称为客户细分创建器 (Customer Segment Creator)，它专注于客户细分分析，并使用四个子智能体：

• 客户细分发现 (Customer Segment Discovery) 识别产品用户细分群体
• 决策矩阵生成器 (Decision Matrix Generator) 创建基于参数的矩阵
• 端到端场景创建 (E2E Scenario Creation) 为每个细分群体开发端到端 (E2E) 场景
• 测试步骤生成 (Test Steps Generation) 详细的测试用例开发

智能体 2 被称为用户旅程映射器 (User Journey Mapper)，它采用四个子智能体来全面映射产品旅程：

• 流程图和序列图是使用 Mermaid 语法的创建器。
• 端到端场景生成器以这些图表为基础。
• 测试步骤生成器用于详细的测试文档。

智能体 3 被称为客户细分 x 旅程覆盖率 (Customer Segment x Journey Coverage)，它结合了智能体 1 和 2 的输入，以创建细化的、特定于细分的分析。它使用四个子智能体：

• 基于 Mermaid 的流程图
• 用户旅程
• 每个客户细分的序列图
• 相应的测试步骤。

智能体 4 被称为状态转换智能体 (State Transition Agent)。它分析客户旅程流程中的各种产品状态点。其子智能体创建代表不同旅程状态的 Mermaid 状态图、特定于细分的状态场景图，并生成相关的测试场景和步骤。

如下一图所示的工作流，以基本的提取、转换和加载 (ETL) 过程结束，该过程将来自智能体的数合并并去重，并将最终输出保存为文本文件。

这种系统化的方法有助于全面覆盖客户旅程、细分群体和各种图表类型，从而通过智能体和子智能体的迭代处理，实现彻底的测试覆盖生成。

解决限制并增强能力

在利用 Strands Agents 开发更强大、更高效的工具的征程中，我们发现了初始方法中的五个关键限制：

• 上下文和幻觉挑战 – 我们的第一个工作流面临隔离的智能体操作带来的限制，这些操作中单个智能体独立收集数据并创建可视化表示。这种隔离导致了有限的上下文理解，从而降低了准确性并增加了输出中的幻觉。
• 数据生成效率低下 – 智能体可用的有限上下文导致了另一个关键问题：生成了过多的不相关数据。由于缺乏适当的上下文感知能力，智能体产生的输出不够集中，导致掩盖了有价值的见解的噪音。
• 受限的解析能力 – 初始系统的解析范围过于狭窄，仅限于客户细分、旅程映射和基本需求。这种限制阻止了智能体访问全面分析所需的全部信息范围。
• 单源输入约束 – 该工作流只能处理 Word 文档，造成了严重的瓶颈。现代开发环境需要来自多个源的数据，而这一限制阻碍了整体数据收集。
• 僵化的架构问题 – 重要的是，第一个工作流采用了紧密耦合的系统和僵化的编排。这种架构使得修改、扩展或重用组件变得困难，限制了系统对不断变化的需求的适应性。

在我们的第二次迭代中，我们需要实施战略性解决方案来解决这些问题。

工作流迭代 2：全面分析工作流

我们的第二次迭代是对智能体工作流架构的彻底重新构想。我们没有修补单个问题，而是从模块化、上下文感知和可扩展性作为核心原则的基础上从头开始重建：

智能体 1 是智能网关。文件类型决策智能体充当系统的入口点和路由器。它处理文档文件、Figma 设计和代码存储库，对数据进行分类并将其定向到适当的下游智能体。这种智能路由对于在整个工作流中保持效率和准确性至关重要。

智能体 2 用于专业数据提取。数据提取器智能体采用六个专业子智能体，每个子智能体都专注于特定的提取领域。这种并行处理方法有助于实现全面覆盖，同时保持实际速度。每个子智能体都运用特定领域的知识，提取通用方法可能会忽略的细微信息。

智能体 3 是可视化智能体 (Visualizer agent)，它将提取的数据转换为六种不同的 Mermaid 图表类型，每种图表都有特定的分析目的。实体关系图映射数据关系和结构，流程图可视化过程和工作流。需求图阐明产品规范，UX 需求可视化说明用户体验流程。过程流程图详细说明系统操作，思维导图揭示特征关系和层次结构。这些可视化为相同的信息提供了多种视角，有助于人类审阅者和下游智能体理解复杂数据集中模式和连接。

智能体 4 是数据冷凝器智能体 (Data Condenser agent)，它通过智能上下文蒸馏执行关键的综合工作，确保每个下游智能体接收到其专业任务所需的精确信息。该智能体由其浓缩信息生成器提供支持，合并来自数据提取器和可视化智能体的输出，同时执行复杂的分析。

该智能体从完整文本上下文中提取关键元素——验收标准、业务规则、客户细分和边缘情况——创建结构化摘要，同时保留基本细节并减少 Token 使用量。它将每个文本文件与其相应的 Mermaid 图表进行比较，捕获仅在视觉表示中可能遗漏的信息。这种仔细的处理在智能体交接过程中保持了信息完整性，确保重要数据在流经系统时不会丢失。结果是一系列浓缩的附录，用于丰富 Mermaid 图表，使其包含完整的上下文。这种综合处理确保了当信息传递到测试生成阶段时，它是完整、结构化且优化了处理的。

智能体 5 是测试生成器智能体 (Test Generator agent)，它将收集、可视化和浓缩的信息整合在一起，以生成全面的测试套件。该智能体处理六个 Mermaid 图表以及来自智能体 4 的浓缩信息，采用由五个子智能体组成的管道。旅程分析映射器、场景识别智能体和数据流映射子智能体根据来自智能体 4 的输入数据生成全面的测试用例。测试用例从三个关键角度生成后，测试用例生成器会对其进行评估，并根据内部指南重新格式化以确保一致性。最后，测试套件组织器执行去重和优化工作，交付一个在全面性和效率之间取得平衡的最终测试套件。

该系统现在处理的内容远超工作流 1 中的基本需求和旅程映射——它处理产品需求、UX 规范、验收标准和工作流提取，同时接受来自 Figma 设计、代码存储库和多种文档类型的输入。最重要的是，向模块化架构的转变从根本上改变了系统的运行和演变方式。与我们僵化的第一个工作流不同，这种设计允许重用早期智能体的输出，集成新的测试类型智能体，并根据用户需求智能地选择测试用例生成器，使系统具备持续适应的能力。

下图显示了 SAARAM 的第二次迭代，其中包含五个主要智能体和多个子智能体，并进行了上下文工程和压缩。

额外的 Strands Agents 特性

Strands Agents 为我们的多智能体系统提供了基础，提供了一种模型驱动的方法，简化了复杂的智能体开发。由于 SDK 可以通过高级推理能力将模型与工具连接起来，我们仅用几行代码就构建了复杂的_工作流_。除了其核心功能外，以下两项关键功能对我们的生产部署至关重要：使用结构化输出来减少幻觉和工作流编排。

使用结构化输出来减少幻觉

Strands Agents 的结构化输出功能使用 Pydantic 模型将传统上不可预测的 LLM 输出转换为可靠的、类型安全的响应。这种方法解决了生成式 AI 中的一个基本挑战：尽管 LLM 擅长生成类似人类的文本，但它们可能难以提供生产系统所需的持续格式化的输出。通过强制使用 Pydantic 模式进行验证，我们确保响应符合预定义的结构，从而能够与现有测试管理系统无缝集成。

下面的示例实现演示了结构化输出的实际工作方式：

from pydantic import BaseModel, Field from typing import List import json # 定义结构化输出Schema class TestCaseItem(BaseModel): name: str = Field(description="Test case name") priority: str = Field(description="Priority: P0, P1, or P2") category: str = Field(description="Test category") class TestOutput(BaseModel): test_cases: List[TestCaseItem] = Field(description="Generated test cases") # 带有验证的智能体工具 @tool def save_results(self, results: str) -> str: try: # 解析并验证 Claude 的 JSON 输出 data = json.loads(results) validated = TestOutput(**data) # 仅在验证通过时保存 with open("results.json", 'w') as f: json.dump(validated.dict(), f, indent=) return "Validated results saved" except ValidationError as e: return f"Invalid output format: {e}"

Pydantic 会自动针对定义的 Schema 验证 LLM 响应，以促进类型正确性和所需字段的存在。当响应不符合预期结构时，验证错误会提供有关需要更正内容的清晰反馈，有助于防止格式错误的数据在系统中传播。在我们的环境中，这种方法在不同智能体之间提供了始终如一、可预测的输出，而与提示变化或模型更新无关，最大限度地减少了一整类数据格式错误。因此，我们的开发团队能够更高效地工作，并获得完整的 IDE 支持。

工作流编排优势

Strands Agents 的工作流架构为我们的多智能体系统提供了所需的复杂协调功能。该框架支持具有明确任务定义的结构化协调、独立任务的自动并行执行以及依赖操作的顺序处理。这意味着我们可以构建复杂的智能体间通信模式，这些模式如果手动实现将会非常困难。

下面的示例片段显示了如何在 Strands Agents SDK 中创建工作流：

from strands import Agent from strands_tools import workflow # 创建具有工作流功能的智能体 main_agent_3 = create_main_agent_3() # 使用结构化输出任务创建工作流 workflow_result = main_agent_3.tool.workflow( action="create", workflow_id="comprehensive_e2e_test_generation", tasks=[ # 阶段 1：并行执行（无依赖项） { "task_id": "journey_analysis", "description": "Generate journey scenario names with brief descriptions using structured output", "dependencies": [], "model_provider": "bedrock", "model_settings": { "model_id": "us.anthropic.claude-sonnet-4-20250514-v1:0", "params": {"temperature": } }, "system_prompt": load_prompt("journey_analysis"), "structured_output_model": "JourneyAnalysisOutput", "priority": , "timeout": }, { "task_id": "scenario_identification", "description": "Generate scenario variations using structured output for different path types", "dependencies": [], "model_provider": "bedrock", "model_settings": { "model_id": "us.anthropic.claude-sonnet-4-20250514-v1:0", "params": {"temperature": } }, "system_prompt": load_prompt("scenario_identification"), "structured_output_model": "ScenarioIdentificationOutput", "priority": , "timeout": }, { "task_id": "data_flow_mapping", "description": "Generate data flow scenarios using structured output covering information journey", "dependencies": [], "model_provider": "bedrock", "model_settings": { "model_id": "us.anthropic.claude-sonnet-4-20250514-v1:0", "params": {"temperature": } }, "system_prompt": load_prompt("data_flow_mapping"), "structured_output_model": "DataFlowMappingOutput", "priority": , "timeout": }, # 阶段 2：等待前 3 个任务完成 { "task_id": "test_case_development", "description": "Generate test cases from all scenario outputs using structured output", "dependencies": ["journey_analysis", "scenario_identification", "data_flow_mapping"], "model_provider": "bedrock", "model_settings": { "model_id": "us.anthropic.claude-sonnet-4-20250514-v1:0", "params": {"temperature": } }, "system_prompt": load_prompt("test_case_development"), "structured_output_model": "TestCaseDevelopmentOutput", "priority": , "timeout": }, # 阶段 3：等待测试用例开发完成 { "task_id": "test_suite_organization", "description": "Organize all test cases into final comprehensive test suite using structured output", "dependencies": ["test_case_development"], "model_provider": "bedrock", "model_settings": { "model_id": "us.anthropic.claude-sonnet-4-20250514-v1:0", "params": {"temperature": } }, "system_prompt": load_prompt("test_suite_organization"), "structured_output_model": "TestSuiteOrganizationOutput", "priority": , "timeout": } ]

工作流系统为我们的用例提供了三个关键功能。首先，并行处理优化允许旅程分析、场景识别和覆盖率分析同时运行，独立智能体处理不同方面而不会相互阻塞。系统根据可用性自动分配资源，最大限度地提高了吞吐量。

其次，智能依赖管理确保了测试开发等待场景识别的完成，而组织任务则依赖于测试用例的生成。上下文在依赖阶段之间得到有效保留和传递，在整个工作流中保持了信息完整性。

最后，内置的可靠性功能为我们的系统提供了所需的弹性。自动重试机制能优雅地处理瞬态故障，状态持久性支持长运行工作流的暂停和恢复，而全面的审计日志记录则支持调试和性能优化工作。

下表显示了工作流输入的示例和潜在的输出。

🚀 想要体验更好更全面的AI调用？

欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。