1. 项目概述当AI开始“写”测试最近在团队内部搞了个小实验把需求评审、测试设计到UI自动化脚本生成这一整条链路试着用AI给串了起来。项目代号叫“Sakura AI”不是什么高深莫测的框架本质上是一个基于大语言模型LLM的自动化工作流编排工具。它的核心目标很直接把产品经理一段模糊的需求描述变成一份结构化的需求文档再自动推导出测试场景、测试点生成可执行的测试用例最后一步直接吐出可运行的UI自动化测试脚本。听起来是不是有点“一步到位”的科幻感其实底层逻辑并不复杂。我们团队长期受困于需求变更频繁、测试设计耗时、自动化脚本维护成本高这“三座大山”。每次新需求下来测试同学要先反复沟通理解需求再花大量时间设计测试用例最后开发自动化脚本又是另一番功夫。我就想既然现在的大模型在理解自然语言和生成结构化内容上已经这么强了能不能让它来当这个“超级助理”把其中大量重复、模式化的工作给承接过去“Sakura AI”就是这个想法的落地。它不是一个要取代测试工程师的“AI员工”而是一个效率倍增器。它的价值不在于创造而在于“翻译”和“转换”把人类用自然语言描述的、充满歧义和省略的业务意图翻译成机器和人都能无歧义理解的结构化指令需求文档、测试用例再进一步转换成机器可执行的代码自动化脚本。这个过程中测试工程师的角色从“重复劳动的执行者”转变为“业务规则的定义者”和“AI产出的审核与优化者”把精力真正聚焦在那些需要人类经验和创造性思维的复杂场景、边界条件设计和业务逻辑验证上。2. 核心思路与架构设计2.1 为什么是“端到端”的自动化很多团队都在用AI辅助写单点用例或者生成代码片段但“Sakura AI”选择做一条龙服务背后有几点核心考量第一数据一致性与追溯性。传统的流程中需求文档、测试用例、自动化脚本是三个独立的产物由不同角色在不同时间点创建。一旦需求发生变更维护这三者之间的一致性就是一场噩梦常常出现脚本跑过了但用例没更新或者用例更新了但脚本还是老逻辑的情况。“端到端”意味着我们有一个统一的、结构化的数据源头。AI从需求描述生成的一切都基于同一个理解。当需求变更时理论上只需要更新原始描述就能触发后续所有产物的联动更新当然实际中需要人工审核确认这极大地降低了维护成本和出错概率。第二最大化利用AI的上下文理解能力。大模型的能力强弱严重依赖提供给它的上下文Context。如果只让它生成测试用例它可能对业务背景的理解是片面的。但如果让它从需求文档开始一步步推导它就能建立起一个完整的“业务认知模型”。这个模型会帮助它在设计测试场景时更准确地识别业务流、数据状态和用户角色在生成自动化脚本时能更合理地安排操作步骤、断言点和等待条件。简单说就是给AI的“信息食粮”越完整它“干活”的质量就越高。第三打破工具链壁垒形成闭环。很多团队的工具链是割裂的需求管理用Confluence或语雀用例管理用TestLink或Jira自动化用Selenium或Playwright。数据在不同系统间导入导出效率低下。“Sakura AI”在设计之初就希望成为一个集成中心。它生成的标准化结构如Markdown格式的需求文档、YAML/JSON格式的测试用例可以很容易地被其他工具解析和导入。未来甚至可以做成插件直接与现有项目管理、持续集成CI系统对接实现“需求描述提交 - 自动化测试就绪”的分钟级响应。2.2 Sakura AI 的核心工作流拆解整个系统的运行遵循一个清晰的、分阶段的“思维链”Chain-of-Thought输入与解析阶段用户输入一段自然语言需求描述。例如“作为一个用户我希望在购物车页面能修改商品数量修改后金额和总价能实时更新并且数量不能小于1。” 系统首先会对这段描述进行清洗和结构化提取关键实体如“购物车页面”、“商品数量”、“总价”和操作“修改”、“更新”。需求文档生成阶段AI基于解析后的信息按照预设的模板如用户故事格式As a [角色], I want to [目标], so that [价值]填充并扩展生成一份包含背景、范围、用户故事、验收标准AC、非功能性要求等的初步需求文档。这里的关键是让AI补充隐含信息比如“实时更新”可能意味着前端需要监听输入事件并发起API调用。测试场景与测试点推导阶段这是最体现AI“思考”能力的一环。系统会基于生成的需求文档特别是验收标准运用常见的测试设计方法如等价类划分、边界值分析、场景法来推导。例如针对“修改商品数量”场景正常修改、修改为边界值1库存上限、修改为非法值0负数非数字超过库存。测试点前端输入框交互、后端接口校验、金额计算逻辑、库存同步机制。测试用例生成阶段将测试点转化为具体的、可执行的测试用例。AI会为每个测试点生成测试步骤、测试数据、预期结果。例如用例标题验证将商品数量修改为0时系统给出错误提示且数量恢复为1。步骤1. 进入购物车页面2. 将某商品数量输入框内容清空输入03. 移开焦点或点击其他区域。预期结果页面弹出提示“商品数量至少为1”输入框中的值自动恢复为修改前的值。UI自动化脚本生成阶段这是最终的输出环节。AI将测试用例“翻译”成特定自动化框架如Playwright、Selenium的脚本。这一步需要AI理解页面元素定位通过CSS选择器、XPath等、操作命令click, fill, assert等和等待逻辑。我们通常会预先给AI提供项目的页面对象模型Page Object Model, POM概览或部分示例让它生成的脚本能符合项目现有的代码结构和定位策略。2.3 技术选型与架构组件“Sakura AI”本身不重造轮子而是现有优秀技术的“粘合剂”。核心大脑LLM我们选择了性能与成本平衡较好的开源模型例如DeepSeek-V3或Qwen2.5的某个版本通过API调用。选择它们的理由是对中文需求理解好在代码生成任务上表现稳定并且允许一定程度的定制化微调Fine-tuning。对于企业内部使用数据隐私也是重要考量。编排框架使用LangChain或Semantic Kernel这类AI应用框架。它们提供了便捷的工具来构建“链”Chain将上述多个阶段解析、生成、推导连接起来并管理复杂的提示词Prompt工程和上下文传递。提示词工程这是项目的灵魂。每个阶段都有精心设计的系统提示词System Prompt用于定义AI的角色和任务边界。例如在生成测试用例时提示词会明确要求“你是一名资深测试工程师请根据以下需求描述和测试点编写详细的手工测试用例。用例格式需包含用例ID、标题、前置条件、测试步骤、测试数据、预期结果。测试步骤必须清晰、可操作一个步骤只做一个动作。”知识库与上下文管理为了让AI生成的内容更贴合项目实际我们建立了一个轻量级知识库。里面可能包含项目专用的术语表、已有的页面对象定义示例、公司的测试用例设计规范文档、历史需求文档样例。在生成过程中通过向量检索Vector Search技术将与当前需求相关的知识片段作为上下文提供给AI使其输出风格和内容更“像”我们团队自己写的。输出与集成层生成的结果文档、用例、脚本会以标准格式Markdown, YAML, Python输出并保存到指定目录或通过Webhook推送到指定的系统如Git仓库、Jira。注意这个架构的关键不是追求全无人干预的“黑盒”而是建立一个“人机协作”的高效界面。AI负责产出草案人类负责审核、修正和决策。系统的设计要让人能轻松地介入每一个环节。3. 实操从一段需求描述到自动化脚本让我们用一个完整的、简化的例子走一遍“Sakura AI”的实际操作流程。假设我们有一个简单的电商网站现在要新增一个“商品快捷收藏”功能。3.1 第一步输入原始需求我们给系统输入以下描述 “在商品详情页商品图片旁边增加一个‘心形’收藏按钮。用户点击后按钮变为实心表示已收藏同时该商品被添加到用户的收藏夹列表中。未登录用户点击时弹出登录提示框。”3.2 第二步AI生成结构化需求文档系统调用LLM结合“电商需求文档”模板生成如下内容节选需求文档商品详情页快捷收藏功能用户故事作为一名浏览商品的访客/用户我希望能在商品详情页快速收藏我感兴趣的商品以便于日后查找或购买。验收标准ACAC1: 在商品详情页的主图区域附近清晰显示一个空心心形图标按钮。AC2: 当登录用户点击空心按钮时按钮视觉状态变为实心并有简单的动画反馈如填充效果。AC3: 点击收藏后调用后端“添加收藏”接口成功后将此商品ID关联到当前用户账户。AC4: 已收藏的商品再次进入该详情页时按钮初始状态显示为实心。AC5: 当未登录用户点击收藏按钮时前端阻止默认收藏动作并弹出模态框Modal提示“请先登录”。AC6: 用户可以从“我的收藏”页面查看所有已收藏的商品列表。3.3 第三步推导测试场景与测试点AI基于AC开始进行测试分析功能测试场景场景1登录用户首次点击收藏。场景2登录用户点击已收藏的商品取消收藏。场景3未登录用户点击收藏按钮。场景4登录用户收藏后刷新页面或重新进入。场景5从“我的收藏”列表进入商品详情页验证按钮状态。UI/UX测试点按钮位置、大小、颜色是否符合设计稿。空心/实心状态图标是否清晰。点击动画是否流畅。未登录弹窗的文案、按钮、关闭功能是否正常。接口与数据测试点点击收藏时是否发送了正确的API请求URL Method: POST Body: {product_id}。接口响应成功/失败时前端状态如何更新。重复收藏是否做了幂等处理。收藏数据是否正确关联用户ID和商品ID。兼容性测试点在不同浏览器、不同移动设备屏幕尺寸下按钮布局和功能是否正常。3.4 第四步生成详细测试用例AI选取“场景1登录用户首次点击收藏”为例生成一个测试用例TC-FAV-001: 验证登录用户可成功收藏商品前置条件1. 用户已登录2. 进入一个未收藏过的商品详情页。测试步骤观察商品主图附近确认存在一个“空心”心形按钮。点击该“空心”心形按钮。观察按钮视觉变化应变为“实心”状态并伴有填充动画。通过浏览器开发者工具Network标签检查是否发起了一个指向/api/favorite/add的POST请求请求体包含当前商品ID。检查该请求的响应状态码是否为200或201且响应体包含成功信息。导航至“我的收藏”页面确认该商品出现在收藏列表中。预期结果按钮状态正确变更接口调用成功且数据正确收藏列表更新。3.5 第五步生成Playwright UI自动化脚本这是最后一步也是技术集成度最高的一步。AI需要知道我们项目的页面元素定位方式。我们提前在知识库中提供了示例我们使用>import pytest from playwright.sync_api import Page, expect def test_logged_in_user_can_favorite_product(page: Page, login_user): 对应测试用例 TC-FAV-001 验证登录用户可成功收藏商品 # 前置条件login_user fixture 确保用户已登录 # 1. 进入一个未收藏过的商品详情页 (假设商品ID为 123) page.goto(/product/123) # 2. 确认初始为空心收藏按钮 favorite_button page.locator([data-testidproduct-favorite-button]) expect(favorite_button).to_be_visible() # 假设空心按钮有特定类名或SVG路径这里用类名示例 expect(favorite_button).to_have_class(icon-heart-outline) # 3. 点击收藏按钮并监听API请求 with page.expect_request(**/api/favorite/add) as request_info: favorite_button.click() # 4. 验证请求 request request_info.value assert request.method POST # 验证请求体包含正确的商品ID import json request_body json.loads(request.post_data) assert request_body[product_id] 123 # 5. 验证按钮状态变为实心 expect(favorite_button).to_have_class(icon-heart-filled) # 可以添加对简单动画的等待例如等待某个过渡类名被移除 # page.wait_for_timeout(300) # 简单等待实际可根据动画完成标志优化 # 6. 验证收藏列表可选如果当前页面不跳转 # 导航到收藏页验证 page.goto(/my/favorites) product_in_list page.locator(f[data-testidfavorite-item-123]) expect(product_in_list).to_be_visible()实操心得在脚本生成阶段最大的挑战是让AI生成的元素定位器稳定且符合项目规范。我们的经验是在知识库中提供一份《UI元素定位规范》和《常用页面对象示例》给AI学习。例如明确规定“所有可交互按钮优先使用>
