某企业 APP 自动化测试 POC:AI 智能体能否真正完成测试执行闭环?

某企业 APP 自动化测试 POC:AI 智能体能否真正完成测试执行闭环?
关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集为保护客户业务信息本文对企业名称、被测产品及部分测试数据进行了匿名化处理。文中内容基于真实 POC 验证过程整理。导读很多企业已经开始使用 AI 生成测试用例但真正进入测试执行阶段后依然绕不开一个问题AI 能不能不依赖提前编写好的自动化脚本直接理解手工测试用例自主操作 APP并完成结果断言在本次企业 POC 中我们选择了一个生活服务类 APP 的典型业务场景对爱测智能测试平台的 APP 自动化测试智能体进行了验证。测试任务并不复杂却非常具有代表性启动 APP → 添加目标城市 → 判断添加结果 → 删除目标城市 → 判断删除结果 → 退出应用。这次验证重点不在于“跑通一个脚本”而是判断 AI 智能体能否完成从用例理解、页面分析、路径规划、操作执行、结果断言到报告生成的完整闭环。目录企业为什么要验证 AI 自动化测试本次 POC 选择了什么业务场景AI 测试智能体如何执行测试本次重点验证了哪些 AI 能力POC 最终取得了什么结果AI 测试平台能为企业带来什么价值从 POC 走向企业落地还需要关注什么一、企业为什么要验证 AI 自动化测试传统 APP 自动化测试通常依赖 Appium、UIAutomator 等框架由测试人员提前完成元素定位脚本编写页面等待异常处理断言设计报告集成这种方式在流程稳定、页面变化较少的场景中十分成熟但随着业务快速迭代企业也会面临一些现实问题。1. 自动化脚本建设周期较长一条手工测试用例通常不能直接转化为可执行任务。测试开发人员需要将自然语言步骤拆解为代码再为每个页面元素配置定位方式。对于业务流程较长、交互频繁的 APP用例自动化改造成本并不低。2. 页面变化会带来持续维护成本按钮位置调整、页面结构变化、控件属性修改都可能导致原有脚本失效。测试人员不仅要编写脚本还要持续维护脚本。3. 指令型测试步骤难以直接执行手工用例中经常出现这样的描述删除目标城市。这句话对人工测试人员来说很容易理解但传统自动化脚本无法直接执行。它需要进一步拆解为进入城市管理页面找到目标城市点击删除入口点击删除图标确认删除检查城市列表企业希望验证的正是 AI 智能体能否理解这种面向业务的测试指令并自主完成后续操作。二、本次 POC 选择了什么业务场景本次 POC 选择了某生活服务类 APP 中的“城市管理”功能。这是一个典型的移动端业务流程涉及页面跳转、信息搜索、列表选择、数据删除和结果断言等多种操作。测试用例主要步骤启动被测 APP进入城市管理页面点击添加城市搜索并添加目标城市检查目标城市是否添加成功删除刚刚添加的目标城市检查目标城市是否已被移除检查当前页面是否显示默认城市退出应用这个场景看似简单但其中包含了多个值得验证的能力验证维度具体内容用例理解能否理解自然语言测试步骤页面感知能否识别当前页面结构和可操作元素路径规划能否规划从当前页面到目标功能的操作路径搜索与输入能否完成输入、搜索和列表选择自主推理能否将“删除城市”拆解为多个具体动作结果断言能否判断添加、删除是否成功过程留痕能否生成截图、视频、日志和断言记录因此这次 POC 验证的并不是某一个点击动作而是 AI 对完整测试任务的理解和执行能力。三、AI 测试智能体如何执行测试爱测智能测试平台没有将手工用例简单翻译成一段固定脚本而是通过 APP 自动化测试智能体完成动态执行。整个执行过程可以概括为五个阶段。1. 用例配置测试人员在平台中选择需要执行的手工测试用例并配置本次执行所使用的大语言模型APP 用例执行智能体自动化执行节点任务名称及运行参数配置完成后即可启动测试任务。2. 启动并分析 APP智能体启动被测 APP 后不会立即按照固定坐标点击而是先分析当前页面结构识别页面中的按钮、输入框、列表和可交互区域。3. 按照测试意图执行操作智能体根据测试用例中的业务描述依次完成进入城市管理页面点击添加入口搜索目标城市选择并添加城市检查添加结果进入删除流程删除目标城市检查删除结果执行过程中智能体会结合当前页面状态动态决定下一步操作。4. 自主完成断言测试用例中不仅包含操作步骤还包含预期结果。智能体需要确认目标城市是否出现在城市列表中删除操作完成后目标城市是否已消失当前页面是否显示预期的默认城市这意味着 AI 不只是负责“点击”还需要理解测试步骤对应的业务结果。5. 生成完整测试报告执行完成后平台自动生成测试报告记录每一步操作截图实际执行动作断言过程和结果测试执行视频详细运行日志用例最终执行状态测试人员可以根据截图、视频和日志回看整个执行过程。四、本次重点验证了哪些 AI 能力本次 POC 重点验证了五项能力。1. 自然语言测试用例理解传统自动化测试需要测试人员将业务步骤转换为代码。AI 测试智能体则直接读取手工测试用例并识别其中的操作对象操作意图页面目标预期结果断言条件例如当用例中写明“添加目标城市”时智能体需要理解这不是一次简单点击而是一个包含进入页面、搜索、选择和确认的连续任务。2. 页面结构动态分析智能体启动 APP 后会根据当前页面内容识别可操作元素而不是完全依赖提前写死的操作坐标。当页面状态发生变化时智能体会重新分析当前页面并决定下一步操作。这种执行方式有助于降低传统 UI 自动化对固定页面路径和固定元素定位的依赖。3. 操作路径自主规划本次验证中测试用例描述的是业务目标并没有为智能体提供每一个点击动作。以“删除目标城市”为例智能体需要自主推理删除目标城市 ↓ 进入城市管理或编辑页面 ↓ 定位目标城市 ↓ 找到删除入口 ↓ 点击删除 ↓ 处理确认操作 ↓ 检查删除结果这也是本次 POC 中最有代表性的验证点。AI 智能体不是机械复现预设脚本而是根据测试目标和当前页面状态动态规划操作步骤。4. 业务结果智能断言测试执行是否成功不能只看操作有没有完成还要看业务结果是否符合预期。在本次场景中智能体完成了对以下结果的判断目标城市添加成功目标城市出现在城市列表中目标城市删除成功删除后列表中不再显示目标城市页面显示预期的默认城市这使得 APP 自动化测试从“执行动作”进一步延伸到了“验证业务结果”。5. 测试过程可观测与可追溯AI 自动化测试能否进入企业使用除了执行成功率还需要解决一个重要问题当执行失败时测试人员能否快速知道问题出在哪里爱测智能测试平台在本次执行中生成了完整的过程记录包括步骤截图操作日志断言结果执行视频异常信息测试人员可以通过视频回放还原操作过程通过日志分析智能体的执行步骤通过截图定位具体页面状态。这为后续的问题分析、执行复盘和缺陷定位提供了依据。五、POC 最终取得了什么结果本次单条测试用例成功完成了完整执行流程启动 APP → 添加目标城市 → 断言添加成功 → 删除目标城市 → 断言删除成功 → 检查默认城市 → 退出应用从本次 POC 结果来看平台完成了以下能力验证POC 验证项验证结果识别自然语言测试步骤已完成分析 APP 页面结构已完成自主规划操作路径已完成执行点击、搜索和选择已完成根据指令推理删除流程已完成完成添加与删除断言已完成生成截图、视频和日志已完成输出完整测试报告已完成尤其是在“删除目标城市”这一指令型步骤中智能体能够根据当前页面状态自主推理需要进入编辑页面、定位目标城市、点击删除入口并完成确认操作。最终执行结果与人工测试人员按照测试用例操作的结果一致。需要说明的是本次验证属于特定 APP、特定版本和特定测试用例下的 POC 结果。单条用例执行成功并不等同于已经完成大规模生产验证。但它至少证明了一点AI 测试智能体已经具备从手工测试用例出发完成 APP 操作执行、结果断言和报告生成的基础能力。六、AI 测试平台能为企业带来什么价值1. 降低手工用例自动化改造门槛企业现有测试资产中通常积累了大量手工测试用例。传统自动化建设需要将这些用例逐条转换为代码而 AI 测试智能体可以直接理解自然语言测试步骤为企业已有用例资产提供新的执行方式。这意味着测试自动化的起点可以从“编写脚本”逐步前移到“编写清晰的业务用例”。2. 减少简单重复脚本的开发成本对于登录、搜索、添加、删除、设置等常见业务流程测试团队通常要投入大量时间编写和维护自动化脚本。通过 AI 智能体承担部分指令型用例的执行工作测试开发人员可以将更多精力投入到复杂业务场景设计测试策略制定平台能力建设质量风险分析核心链路保障3. 提升测试用例的可执行性传统手工测试用例更多是给人看的。引入 AI 智能体后用例需要具备更加明确的操作对象、业务目标和预期结果。例如相比于检查一下城市功能。更适合 AI 执行的描述是搜索并添加目标城市确认该城市出现在城市列表中随后删除该城市确认城市列表中不再显示该城市。这种变化也会推动企业逐步提高测试用例的规范性和结构化程度。4. 缩短测试结果分析链路测试失败后平台不仅给出“成功”或“失败”还可以结合截图查看页面状态视频回放操作过程日志分析执行步骤断言记录确认预期差异相比只有最终结果的黑盒式执行可观测的执行过程更有利于企业定位问题。5. 为智能化测试体系提供统一入口爱测智能测试平台的能力不只局限于 APP 用例执行还可以围绕企业测试全流程扩展需求文档分析测试点提取测试用例生成手工用例 AI 自动化执行Web、APP 等多端测试智能遍历与探索性测试领域建模与知识图谱测试报告与质量数据沉淀企业可以从一个高频、可验证的业务场景开始通过 POC 逐步验证平台能力再根据实际效果扩展应用范围。七、从 POC 走向企业落地还需要关注什么一次 POC 跑通解决的是“能力是否可行”的问题。真正进入企业生产环境还需要进一步验证以下内容。1. 用例规模需要从单条用例逐步扩展到几十条、几百条甚至更多测试用例评估批量执行效果。2. 页面复杂度需要覆盖弹窗、动态列表、权限申请、网络异常、加载等待、复杂手势等更多移动端交互。3. 执行稳定性需要连续运行多轮统计执行成功率、平均耗时、失败原因和重试效果。4. 版本适应能力需要在 APP 页面改版、控件变化或流程调整后观察智能体是否仍能正确完成任务。5. 成本与效率除了关注模型能力还需要综合评估单条用例执行时间模型调用成本Token 消耗设备资源占用人工维护投入爱测智能测试平台在执行过程中集成了相应的算法和调度能力以减少不必要的模型调用和 Token 消耗但具体收益仍需要结合企业真实用例规模进行测算。结语这次企业 POC 验证的意义不只是完成了一次“添加并删除城市”的 APP 操作。它真正验证的是一条新的自动化测试路径自然语言测试用例 → AI 理解测试意图 → 分析当前页面 → 自主规划操作 → 模拟用户执行 → 判断业务结果 → 生成可追溯报告传统自动化测试的核心是“测试人员提前把每一步写成代码”。AI 测试智能体尝试解决的则是测试人员描述要验证什么由智能体根据页面和业务目标决定具体怎么执行。对于正在建设智能化测试体系的企业来说更适合的落地方式不是一开始就替换现有自动化体系而是选择具有代表性的业务场景开展 POC验证智能体能否理解现有手工用例验证复杂交互能否稳定执行验证断言结果是否可信验证报告是否便于追溯验证整体成本是否具备投入价值从一个场景跑通到一类场景复制再到多端测试规模化应用才是 AI 测试平台真正进入企业质量体系的现实路径。关于我们霍格沃兹测试开发学社隶属于测吧北京科技有限公司是一个面向软件测试爱好者的技术交流社区。学社围绕现代软件测试工程体系展开内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试以及人工智能测试与 AI 在测试工程中的应用实践。我们关注测试工程能力的系统化建设包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法沉淀可复用、可落地的测试开发工程经验。在技术社区与工程实践之外学社还参与测试工程人才培养体系建设面向高校提供测试实训平台与实践支持组织开展“火焰杯” 软件测试相关技术赛事并探索以能力为导向的人才培养模式包括高校学员先学习、就业后付款的实践路径。同时学社结合真实行业需求为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务用于个性化能力提升与工程实践指导。人工智能 · 目录上一篇华为测试专家忠告AI生成的用例缺少这种思维就只是废纸阅读 187爱测智能测试平台​