1. 项目概述从传统UI自动化测试的“泥潭”中抽身如果你和我一样在软件测试领域摸爬滚打了几年那么“UI自动化测试”这个词大概率会勾起你一些复杂的情感。一方面它代表着测试效率的终极理想——让机器代替人工7x24小时无休地执行回归测试快速发现界面层的Bug。但另一方面提起Selenium、Appium这些开源框架很多测试工程师的第一反应可能是环境配置的噩梦、脆弱的元素定位、永无止境的脚本维护以及那令人望而生畏的学习曲线。我们投入大量时间搭建框架、编写脚本最后却发现脚本的维护成本甚至超过了它节省的人工测试时间。这感觉就像费尽心思造了一艘船结果大部分时间都花在了修补漏洞上而不是航行。最近我所在的项目组面临一个紧急需求需要对一个即将上线的大型Web应用和配套的移动端App进行全面的UI自动化回归测试覆盖。时间窗口只有两周。按照老路子拉起一个团队配置Selenium Grid、搭建Appium环境、编写几百个测试用例……这根本是不可能完成的任务。就在我们焦头烂额之际技术总监提到了“龙测AI-TestOps云平台”并丢下一句话“试试这个听说能告别脚本编程用AI搞定自动化。”起初我是怀疑的。毕竟“零代码”、“AI驱动”这类口号在测试工具领域并不新鲜但实际用起来往往差强人意。然而迫于时间压力我们决定一试。结果出乎意料我们真的在一周内完成了Web端和移动端核心业务流程的自动化测试用例搭建、执行和报告生成并且顺利完成了平台的私有化部署将数据和测试资产牢牢掌控在自己手中。这个过程让我对现代AI驱动的测试平台有了全新的认识。这篇文章我就来详细拆解我们是如何做到的分享从评估、上云试用到最终私有化落地的完整心得和踩过的坑。无论你是正在被传统自动化测试折磨的测试工程师还是寻求测试效能突破的技术负责人相信这些实战经验都能给你带来直接的参考。2. 核心思路解析为什么是AI-TestOps而不仅仅是“录制回放”在深入实操之前我们必须先理清一个核心概念龙测AI-TestOps平台解决的到底是什么问题它和传统的Selenium IDE录制回放、或者市面上一些低代码测试工具有何本质区别理解了这一点你才能明白其价值所在而不会简单地把它视为一个“高级录制工具”。2.1 传统UI自动化测试的三大核心痛点我们之所以寻求变革是因为旧有模式存在难以逾越的障碍脚本编写与维护成本高昂无论是使用Selenium WebDriver写Python/Java代码还是用Appium描述移动端操作都需要测试人员具备相当的编程能力。更痛苦的是当产品UI发生变更比如一个按钮的ID变了或者一个页面布局调整对应的测试脚本就会大面积失败需要人工逐一排查和修复。这个维护成本在敏捷开发、快速迭代的背景下被无限放大。元素定位的脆弱性这是UI自动化的“阿喀琉斯之踵”。我们依赖XPath、CSS Selector等定位元素但这些定位器非常脆弱。前端开发修改一个div的class甚至只是调整一下组件库版本就可能导致定位失效。虽然提倡使用更稳定的id或># 进入部署目录 cd /opt/aittestops-platform # 编辑环境变量配置文件 vim .env以下是我们修改的关键配置项# 平台访问URL填写服务器的内网IP或域名后续CI/CD调用和用户访问用 PUBLIC_URLhttp://192.168.1.100:8080 # 数据库配置使用内置的MySQL一般无需改动但建议修改强密码 MYSQL_ROOT_PASSWORDYourStrongPassword123! MYSQL_DATABASEaittestops MYSQL_USERaittestops_user MYSQL_PASSWORDYourUserPassword456! # 对象存储配置。平台产生的截图、报告、日志需要存储。 # 我们使用本地文件系统挂载到宿主机的一个大容量目录HDD STORAGE_TYPEfilesystem FILE_STORAGE_PATH/data/aittestops/storage # 宿主机目录需要提前创建并赋予权限 # AI服务配置关键 AI_SERVICE_ENABLEDtrue # AI服务对GPU有要求如果服务器无GPU或GPU驱动未装可先设为false但元素自愈功能会受限 AI_SERVICE_GPU_ENABLEDfalse # 我们服务器无GPU先关闭 # 邮件服务器配置用于发送测试报告 SMTP_ENABLEDtrue SMTP_HOSTsmtp.qiye.163.com SMTP_PORT465 SMTP_USERyour-emailcompany.com SMTP_PASSWORDyour-smtp-password SMTP_FROMyour-emailcompany.com第三步启动服务配置完成后使用docker-compose启动所有服务。这个过程会拉取多个镜像Web前端、后端API、AI服务、MySQL、Redis、执行节点控制器等耗时较长。# 在部署目录下执行 docker-compose up -d使用docker-compose logs -f可以跟踪启动日志观察是否有错误。首次启动所有服务就绪可能需要5-10分钟。第四步初始化访问当所有容器状态变为healthy或running后在浏览器访问http://192.168.1.100:8080。首次访问会进入管理员账号初始化页面设置超级管理员账号密码。第五步配置执行环境节点私有化部署后平台本身没有执行测试的能力需要添加“执行节点”。执行节点是真正运行浏览器和模拟器/真机的机器。在平台管理后台进入“执行环境”-“节点管理”。平台会提供一个“节点启动器”的下载链接和安装脚本。我们准备了一台单独的Linux虚拟机4核8GB作为执行节点。在该机器上下载启动器并运行。启动器会以Agent形式运行并自动向平台主服务器注册。在平台管理页面上就能看到这个新节点在线。在节点上你可以配置该节点具备的能力例如安装Chrome、Firefox浏览器安装Android模拟器镜像等。这些环境配置同样通过Docker容器管理非常清晰。4.3 私有化部署中的难点与解决方案难点一镜像拉取缓慢或失败由于部署包内的镜像可能从Docker Hub拉取国内网络可能较慢。解决方案方案A推荐联系龙测技术支持获取离线镜像包.tar文件通过docker load命令手动导入到服务器。方案B在服务器上配置Docker镜像加速器如阿里云、中科大镜像源修改/etc/docker/daemon.json文件。难点二AI服务启动失败如果服务器没有NVIDIA GPU或CUDA驱动未正确安装AI服务容器可能无法启动。日志中会出现CUDA相关的错误。临时方案如前所述在.env中设置AI_SERVICE_GPU_ENABLEDfalse使用CPU模式运行AI服务。性能会下降但基本功能可用。长期方案为服务器配备GPU如Tesla T4并正确安装NVIDIA驱动、CUDA Toolkit和nvidia-container-toolkit。然后修改docker-compose.yml中AI服务的配置添加GPU资源声明。难点三存储空间快速增长自动化测试会产生大量截图和日志很快占满磁盘。解决方案我们做了两件事定期清理策略在平台管理后台配置测试报告和原始数据的保留时长如只保留30天。挂载大容量存储将FILE_STORAGE_PATH指向我们准备好的4TB HDD并与运维同事设置监控告警当磁盘使用率超过80%时触发清理或扩容流程。难点四执行节点与内网应用的连通性我们的被测系统部署在内网另一个网段。执行节点Docker容器内需要能访问到这些内网地址。解决方案确保执行节点所在的宿主机网络与被测系统网络互通。更复杂的场景下可能需要配置Docker容器的网络模式为host或者自定义网络路由。5. 集成CI/CD与团队协作实践自动化测试只有融入开发流程才能发挥最大价值。我们将其集成到了现有的GitLab CI流水线中。5.1 与GitLab CI的流水线集成我们在项目根目录创建了.gitlab-ci.yml文件添加了一个测试阶段stages: - build - test - deploy # ... 其他阶段定义 ... ui_automation_test: stage: test only: - main # 仅在main分支合并时触发 - tags # 打标签发布时也触发 script: - | # 使用龙测平台提供的CLI工具或API触发测试计划 # 首先获取API Token在平台用户设置中生成 # 然后调用平台API执行指定的测试计划 curl -X POST ${AITESTOPS_URL}/api/v1/plans/${PLAN_ID}/run \ -H Authorization: Bearer ${AITESTOPS_TOKEN} \ -H Content-Type: application/json \ -d {env: staging, branch: ${CI_COMMIT_REF_NAME}} - echo “UI自动化测试任务已触发请前往龙测平台查看执行结果。” after_script: - | # 可选等待测试完成并获取结果决定流水线是否通过 # 这里可以写一个轮询脚本调用平台API检查计划执行状态 # 如果测试失败可以令CI任务失败 # 我们为了快速反馈先设置为不阻塞仅通知 artifacts: when: always reports: junit: reports/junit.xml # 如果平台能产出JUnit格式报告可以收集关键配置AITESTOPS_URL和AITESTOPS_TOKEN是我们在GitLab CI的Variables中设置的敏感变量分别对应私有化平台的地址和管理员API Token。${PLAN_ID}是我们在龙测平台上预先创建好的测试计划ID这个计划里包含了我们想要在每次集成时运行的冒烟测试用例集。这样每当有代码合并到主分支CI流水线就会自动触发龙测平台上的UI自动化测试计划。测试结果会实时更新在平台上。5.2 团队协作与测试资产管理平台提供了良好的团队协作功能角色与权限可以创建不同角色的用户管理员、测试组长、测试工程师、只读观众并精细控制其对项目、测试用例、测试数据、执行环境的操作权限。测试用例版本管理测试用例的每次修改都有历史记录可以对比差异必要时回滚到旧版本。这与代码的Git管理类似。公共测试数据池可以将常用的测试数据用户账号、商品ID、城市列表等维护在公共数据池中供所有测试用例引用方便统一管理和更新。测试计划与定时任务可以创建复杂的测试计划组合不同模块的用例并设置定时执行如每日凌晨执行全量回归。我们的实践我们将测试团队分为两个小组用例设计组和执行分析组。用例设计组主要由业务测试人员构成利用零代码可视化编辑器负责将手工测试用例转化为自动化用例并维护测试数据。他们几乎不需要编写代码。执行分析组技术较强的测试工程师负责维护平台的执行节点环境、集成CI/CD、编写一些复杂的自定义脚本通过平台提供的“脚本步骤”功能可以插入Python/JS代码块处理特殊逻辑、分析每日定时任务产生的失败报告并判断是Bug还是脚本需要维护。这种分工极大地提升了整体效率让合适的人做擅长的事。6. 一周实践总结收益、局限与未来展望回顾这一周的高强度实践从最初的怀疑到后来的惊喜龙测AI-TestOps平台确实给我们带来了显著的改变。核心收益效率的极致提升我们3个人的小团队在一周内构建了超过200个核心业务流程的自动化用例Web和App各半。如果用传统SeleniumAppium的方式仅环境搭建和框架设计可能就要一周编写200个用例至少需要一个月。维护成本的直观下降在后续两周的产品迭代中UI发生了数次小调整。大约70%的变更被平台的AI自愈能力自动处理了我们只需要对剩余30%的用例进行手动调整且调整过程是在可视化编辑器中进行非常直观耗时不到半天。团队能力的解放业务测试人员能够深度参与自动化测试左移得以真正实现。他们可以将更多精力花在探索性测试、用户体验测试等更有价值的事情上。质量反馈闭环加速与CI/CD的集成使得每次代码提交都能快速得到UI层的质量反馈问题发现时机从测试阶段提前到了开发集成阶段。当前局限与注意事项对复杂交互和动态内容的挑战对于高度依赖拖拽、画布绘制、游戏等富交互场景或者页面内容完全由JavaScript动态生成且无稳定标识的场景平台的录制和AI识别仍然会遇到困难可能需要借助自定义脚本步骤来辅助。私有化部署的资源消耗AI服务和并发执行节点对服务器CPU、内存和GPU有一定要求初期需要做好容量规划。对于中小团队使用SaaS版本可能是更经济的选择。“零代码”的边界虽然大部分操作可以零代码完成但处理一些极端复杂的逻辑、数据驱动测试的复杂参数组合、或者需要连接外部数据库验证时仍然需要写一些脚本。平台提供了自定义代码块的能力但这要求测试人员具备基础的编程知识。学习成本转移从学习Selenium/Appium API的编程成本转移到了学习新平台的操作逻辑、概念模型和最佳实践上。虽然曲线更平缓但仍需要投入时间。未来展望这次实践让我们看到了AI赋能测试的切实可能性。它不是一个遥不可及的概念而是能立即带来效率提升的工具。对于团队而言下一步我们计划将更多历史Selenium用例逐步迁移到新平台统一管理。探索平台更高级的功能如利用AI生成测试用例、智能分析测试失败的根本原因。将UI自动化测试与API自动化测试、性能测试的数据和结果在平台内进行关联分析构建更全面的质量看板。最后我的个人体会是工具永远在进化。作为测试工程师我们的核心价值不在于精通某一种框架的API而在于深刻的业务理解、缜密的测试思维和快速适应新工具、新方法的能力。龙测AI-TestOps这类平台的出现不是要取代测试工程师而是将我们从重复、繁琐、低价值的“脚本民工”劳动中解放出来让我们能更专注于高价值的测试设计与质量分析工作。如果你也正困于传统UI自动化的维护泥潭不妨花点时间评估一下这类现代测试平台它可能会为你打开一扇新的门。