一聊到自动化与脚本很多人第一反应是“敲几行代码让电脑自己干活”。这个理解没错但太窄了。我在一线做自动化测试、写运维脚本、帮同事搭测试平台前前后后折腾了快十年发现脚本这东西真正的价值不在于省掉几次鼠标点击而在于把重复劳动沉淀成可复用的资产。无论是Web自动化、接口自动化还是设备老化测试里的全自动执行脚本本质上都是同一件事把“人反复盯着屏幕操作”的过程变成“程序按照规则自己判断、自己执行、自己回报结果”的过程。这篇文章不打算写成一本工具书而是想从这些年我自己踩过的坑、换过的思路、推倒重来的方案出发聊清楚自动化与脚本落地的完整链路。内容会覆盖设备老化测试脚本的设计逻辑、Selenium和Playwright这类Web自动化工具的使用边界、接口自动化框架选型、Shell与Bat脚本的常见报错排查以及AI写脚本和AI自动化测试平台带来的变化。每块内容都会给出我实际用过的方案和判断依据适合正在做测试开发、运维或刚接触自动化脚本的工程师阅读。1. 从设备老化测试脚本说起自动化脚本的真实工作方式设备老化测试全自动执行脚本是这两年搜索热度很高的一个方向。很多人觉得它很神秘其实就是把“长时间反复操作某个设备或应用验证它会不会卡死、崩溃、内存泄漏”这个过程自动化。我最早接触这类任务是在做安卓系统的稳定性专项需求很简单让手机反复解锁、启动应用、滑动页面、截图、记录性能数据连续跑几十个小时不能断。看似简单真正落地时第一个难题就来了解锁。1.1 一个看起来“很傻”的需求重复一千次解锁、点击、截图测试机连上电脑后第一条命令往往是adb shell input keyevent 82模拟发送菜单键来唤醒屏幕。但很多设备还有锁屏密码或手势密码这就不能靠一行命令解决了。我当时用Python封装了一层设备操作库把解锁逻辑做成一个函数先检查屏幕状态如果灭屏就按电源键再判断当前是否处于锁屏页然后根据设备配置输入密码或执行滑动解锁。这类脚本的难处不在语法而在“不确定性”。设备响应有时快有时慢网络请求偶尔超时UI渲染偶尔卡顿脚本如果按固定顺序执行跑一个小时就会遇到意外状态。所以我后来给老化测试脚本定了一条铁律每步操作之后必须做“状态校验”校验不过就重试重试超过三次就记录失败并跳过本轮而不是让整个脚本崩溃退出。def unlock_device(device, password): for attempt in range(3): device.shell(input keyevent 224) # 唤醒 time.sleep(2) status device.shell(dumpsys window | grep mDreamingLockscreen) if false not in status: continue if password: device.shell(finput text {password}) device.shell(input keyevent 66) return True report_failure(unlock_failed) return False这段代码是关键逻辑的简化版。实际项目中还要考虑消息弹窗遮挡、输入法弹出等问题但核心思路就是这样不要相信设备处于“预期状态”每一步都要拿真实状态去核对。1.2 脚本框架怎么搭为什么我用Pythonadb而不是测试框架做老化测试脚本前我纠结过要不要直接上Appium或者UiAutomator。后来放弃了原因很实际老化测试的目标不是验证业务功能而是压测稳定性。Appium这类框架为了通用性和跨端支持引入了大量中间层跑几个小时后容易因为通信链路本身的问题中断反而不稳定。Python脚本直接调adb命令链路最短出问题最好排查。这是我最终采用的执行框架模块选型原因设备通信adb命令 Python subprocess链路短、稳定、易排查操作指令adb shell input/adb shell am覆盖点击、滑动、启动应用等大部分场景数据采集dumpsys meminfo/top获取内存、CPU、帧率等指标结果汇总CSV 定时上传方便后续统一分析执行调度Python线程池 脚本入口支持多台设备并行互不干扰用这个方案最舒服的一点是“出问题我能兜底”。比如某台设备死机了连接还在但操作无响应脚本可以通过adb wait-for-device等待重连然后再重启应用继续跑。顶层框架很难做到这样灵活的控制。提示如果你刚开始写老化测试脚本不要一上来就追求复杂的框架设计。先跑通单设备的“解锁-启动应用-滑动-截图”链路再逐步加入并行和设备异常处理这种方式最不容易失控。1.3 老化测试里最有价值的三个脚本细节这里分享三个我在多轮迭代后沉淀下来的细节单看都很小合在一起决定了脚本能不能真正“挂机跑”第一是日志的“可回溯性”。每条关键操作都要带时间戳和设备序列号写入独立日志文件。跑完24小时后如果第800轮失败了你要能准确知道第800轮从几点开始、中间执行了哪些步骤、哪一步出的异常。我见过很多脚本只输出“pass/fail”出了稳定性问题根本没法定位等于白跑。第二是资源的“自愈能力”。长时间运行中应用占用的内存会越涨越高截图文件会越积越多。脚本里要有定时清理截图缓冲区和重启应用释放内存的逻辑。有些测试团队把内存泄漏当结论其实只是脚本不会自动整理资源导致的假象。第三是“冒烟验证”。正式跑长稳之前先用同一套脚本跑20轮快速冒烟把明显的环境问题、脚本问题提前暴露掉。冒烟都过不了的长稳脚本跑再久也只是浪费时间。2. Web自动化最容易翻车的地方驱动、等待与验证码Web自动化是自动化与脚本世界里最热闹的一块。Selenium是老牌选手Playwright是后起之秀这几年搜索排行榜上“selenium自动化测试框架”“playwright自动化框架”“web自动化selenium浏览器驱动怎么判断下载哪个区别”常年霸榜。很多新人刚起步就被浏览器驱动搞懵了第一步就卡了一整天。2.1 浏览器驱动版本匹配到底怎么判断“selenium浏览器驱动怎么判断下载哪个”这个问题本质上是ChromeDriver和浏览器版本不匹配的问题。Selenium启动浏览器时WebDriver需要和浏览器内核版本兼容版本差太远就直接报错session not created。判断方式很简单打开浏览器地址栏输入chrome://version看到的版本号是一串长数字比如120.0.6099.109。驱动下载页面一般按主版本号分类你只需要拿前两位或前三位数字也就是120或120.0去对应目录下载即可。最好不要用“最新版”三个字解决问题因为Chrome浏览器经常自动升级昨天能跑的脚本今天可能突然全部报错这时第一反应就应该是检查浏览器版本有没有变。浏览器版本驱动版本结果120.0.6099.109ChromeDriver 120.0.6099.109正常启动120.0.6099.109ChromeDriver 114.0.5735.90启动报错120.0.6099.109ChromeDriver 119.0.6045.105大概率报错或行为异常我给团队定的规矩是统一锁定浏览器版本禁止自动升级浏览器更新必须走运维审批流程。否则脚本稳定性和浏览器版本强绑定今天好好的明天就挂排查成本极高。2.2 等待策略从sleep到expected_conditions我第一次写Selenium脚本时和大多人一样在每次点击后直接time.sleep(3)。简单粗暴但有两个致命问题一是页面加载快了白白浪费时间二是页面加载慢了3秒不够脚本照样失败。后来我才意识到Web自动化的核心难点根本不是定位元素而是“知道页面什么时候真正准备好了”。Selenium官方给的解决方案是显式等待。遇到需要等待的元素时用WebDriverWait配合expected_conditions去轮询元素状态超时再抛异常。Playwright这边做得更好一点它的选择器操作自带自动等待默认会等到元素可见、可操作后再执行点击。这也是我后来更愿意用Playwright的原因少写很多等待代码稳定性反而更高。// Playwright 自动等待示例 await page.click(#submit-button); await page.waitForSelector(.result-table); const text await page.textContent(.result-table); console.log(text);注意显式等待和隐式等待不要混用。Selenium里同时设置driver.implicitly_wait(10)和WebDriverWait时等待时间会叠加导致脚本莫名奇慢排查起来很头疼。2.3 拼图验证码自动化的破与不破“自动化selenium网页拼图验证怎么自动化”这个问题搜索量很高。拼图验证码自动化的基本思路是两步第一步用图像识别或目标检测定位缺口位置第二步模拟人类拖动滑块的轨迹把缺口坐标换算成拖拽距离再用ActionChains或Playwright的鼠标事件执行拖拽。第一步做起来相对容易用OpenCV的模板匹配就能在多数场景下找到缺口位置。第二步真正的难点是“模拟人手”。机器瞬间拖过去会被风控系统识别为异常需要加入缓启动、加速、减速、甚至小幅回退的轨迹算法。即便轨迹再像人验证码服务方还会有更多维度的风控指标比如鼠标进入页面的位置、拖拽前的停留时间、浏览器指纹等所以“全自动过验证码”在对抗环境下永远是被动方。从合规角度说拼图验证码本质是网站用来区分真人和自动程序的防线。做自动化测试时遇到验证码更合理的做法是找测试环境对应的“绕过开关”或者让开发同学在测试环境里把验证码流程临时屏蔽。真要去攻克生产环境的验证码不仅难度大还可能触及不想触碰的边界我个人不推荐把它作为自动化测试的常规路径。3. 接口自动化框架选型从“能跑”到“不重写三轮代码”接口自动化的热度一直居高不下因为它的ROI在自动化测试里算最高的没有UI那种脆弱的选择器依赖执行速度又快往往几百条用例几分钟就能跑完。但一个有意思的现象是团队里接口自动化脚本通常活不过三个月原因不是写不出来而是“写个能跑的脚本很容易写一个能长期维护的框架很难”。3.1 接口自动化最小闭环长什么样搭建接口自动化第—步不是选框架而是先把最小闭环跑通。我把这个闭环拆成五个步骤用Charles或浏览器开发者工具抓取一个真实请求拿到URL、请求方式、请求头和请求体。用Python Requests或Java HttpClient发出去确认返回结果跟手工调用一致。对返回结果做断言至少校验HTTP状态码和核心业务字段。把请求数据整理成可用文件维护的形式比如YAML或JSON。把所有用例串进一个测试入口统一执行并生成报告。很多人一上来就想做平台跳过了“手动跑通一条用例”这一步结果架子搭得很华丽一条真实用例都跑不稳。我自己带项目的经验是先用半个月把手里的业务接口全部脚本化跑稳定了再谈框架和平台。3.2 框架选型Python pytest与Java TestNG的真实取舍“java接口自动化测试框架”和“python自动化测试”的搜索量都很高选型之争几乎每个团队都会遇到。我给团队的判断依据很简单如果团队现有后端是Java且未来要做大规模企业级平台选JavaTestNGREST Assured如果团队里测试同学主要写Python且交付节奏要求快速迭代选PythonpytestRequests。对比维度Python pytestJava TestNG上手成本低代码量少高类型和样板代码较多数据驱动pytest的parametrize非常方便TestNG DataProvider灵活但写法冗余生态与报表allure-report插件成熟ReportNG / Allure 均可团队背景要求会Python即可需要熟悉Java构建和依赖管理适合场景快速交付、中小规模团队企业级平台、与Java服务端深度融合这里想多说一句语言之争很多时候是伪命题真正的分水岭在于“谁来维护”。框架再好如果写的人和维护的人不是同一拨或者维护的人换了一批脚本很快就废掉了。所以选型会议上我会问一句“半年后这个框架是哪位同学负责改”这个问题比“Java还是Python”重要得多。3.3 测试数据与环境的隔离平台化最容易忽略的问题搭建AI自动化测试平台或者接口自动化测试平台时大家首先关注用例管理、调度引擎和报告展示却经常忽略测试数据。一个真实场景测试环境里的订单号、用户账号是有生命周期的上周创建的数据这周可能被清理了接口用例明明代码没问题却跑挂了。平台再强大测试数据管理跟不上所有用例都会变成“时而绿时而红”。我的做法是把测试数据分为两类一类是“只读基础数据”比如字典表、配置项通过接口预置或SQL初始化跑用例前检查存在性另一类是“业务数据”必须在用例内部自行创建和清理比如先创建订单再查询订单最后删除订单或标记无效。平台层面还要支持环境维度隔离每个环境有独立的配置中心和数据库切换环境只需要改一个变量。这个思路看着平常但在团队里推行后接口用例的稳定性从70%左右直接升到了93%以上。自动化脚本的失败率不全是代码问题数据血缘不清晰往往占了很大比例。4. Shell和Bat脚本的入门与踩坑从命令行开始让电脑干活搜索热词里有一大批和“脚本报错”相关的问题比如“pnpm : 无法将‘pnpm’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”“windows脚本命令闪退”“powershell开机自启脚本”。这些问题看着零散其实都指向一个共同的知识点在Windows环境里跑脚本最常用的Shell和Bat脚本需要理解环境变量、执行策略、编码和路径引用这几个基础概念。4.1 在Windows终端里运行命令时报“无法识别”怎么查“无法将‘npm’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”这类报错大概率不是命令不存在而是系统在PATH环境变量里找不到对应的可执行文件。排查思路有三种先用where.exe npm查看系统是否能定位到npm的可执行文件路径如果能找到说明只是当前终端没刷新环境变量重启终端即可。换个思路检查安装包的bin目录是否已经被正确加入PATH。Windows下很多工具安装时不会自动写入用户环境变量需要手工添加。如果路径里包含中文或空格某些工具解析会出错这时最好把工具安装目录调整到纯英文路径。我记得有一次帮同事排查git命令无法识别用的是最简单的方法找到git安装目录下的cmd文件夹把路径复制到系统环境变量的Path里保存后重启终端问题直接解决。环境变量这种问题百分之八十都是“路径没配对”或者“改了没生效”这两类。4.2 Bat脚本双击闪退的排查链路Windows下写Bat脚本最常见的问题就是双击后黑窗口一闪而过什么信息都看不到。很多人第一反应觉得是脚本写错了其实连错在哪都不知道因为窗口已经关了。我的排查流程很固定先在命令行窗口里手动执行脚本而不是双击然后在脚本开头加echo on把每一条命令的执行过程显示出来最后在出错或希望暂停的位置加pause这样窗口会停住你就能看到具体的报错了。echo off echo Starting script... set targetC:\work\project cd /d %target% echo %target% changed successfully pause一个隐藏得很深的坑是“批处理文件的编码”。很多Bat脚本在Windows自带记事本里保存时默认是UTF-8 with BOM或ANSI如果脚本里有中文注释或中文路径执行时可能出现乱码甚至直接报错。后来我统一改成用VSCode保存为GB2312或UTF-8 with BOM这个坑才算彻底避开。C盘清理脚本bat下载这类需求我也经常看到本质上是自动清理临时目录、清空回收站和缓存。这种脚本本身不复杂但发布给别人用之前必须在多台环境验证过。曾经看到一个应急清理脚本把%SystemRoot%环境变量写错导致清理到了C盘根目录差点引发系统文件损坏。脚本里的危险命令比如del、rmdir一定要先做路径判断避免在错误的目录下执行。4.3 PowerShell开机自启脚本的两种落地方式PowerShell开机自启脚本运维里很常见。实现方式有两种一种是把脚本快捷方式放到启动文件夹另一种是用任务计划程序注册开机任务。我推荐后者原因有两个一是任务计划程序可以设置延迟启动避免开机时和其他服务抢资源二是可以指定以管理员权限运行避免UAC弹窗阻塞。# 创建开机自启动任务的PowerShell命令 $action New-ScheduledTaskAction -Execute powershell.exe -Argument -File C:\Scripts\cleanup.ps1 $trigger New-ScheduledTaskTrigger -AtStartup $trigger.Delay PT1M Register-ScheduledTask -TaskName MyStartupScript -Action $action -Trigger $trigger -RunLevel Highest这里需要注意的是PowerShell脚本默认执行策略是Restricted直接双击.ps1文件会提示“因为在此系统上禁止运行脚本”。需要先执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser放行本地脚本。很多新手在自启动脚本上折腾很久其实问题根本不是脚本本身而是执行策略没调对。4.4 Shell脚本for循环与计划任务的常见错误Linux和Windows双修的工程师都绕不开Shell脚本。搜索词“shell脚本for循环”“linux运行python脚本”“linuxshelloracle脚本”热度一直很高。Shell的for循环是这个生态的敲门砖但写的时候有几个特别容易出错的地方。第一是for循环语法里变量引用的空格问题。for i in 1 2 3循环变量会按空格拆分如果文件名里带空格就会出现意外拆分需要改用for file in *.txt这种通配符形式。第二是循环体里需要执行外部命令时变量加不加引号对结果影响巨大“变量没有加引号”是我见过最多的Shell脚本bug来源。#!/bin/bash # 遍历日志目录并输出大于100M的文件 for file in /var/log/*.log; do if [ -f $file ]; then size$(stat -c%s $file) if [ $size -gt 104857600 ]; then echo $file $size fi fi doneCrontab方面最常见的坑是环境变量继承问题。crontab里执行Python脚本时你会发现PATH被重置了python3命令经常找不到。解决方案是在脚本里显式指定绝对路径或在crontab开头设置PATH/usr/local/bin:/usr/bin:/bin。另外crontab最小粒度是分钟级如果自动化任务需要更频繁地执行就要在Shell脚本里自己实现循环或换用systemd服务。5. AI写脚本之后自动化这件事的结构性变化这一两年AI自动化测试平台搭建、自己搭建agent进行自动化测试、AI写UI自动化提效这些词频繁登上热搜。AI确实改变了自动化与脚本的生产方式。过去写一个端到端测试脚本可能要半小时现在把需求描述清楚AI几分钟就能生成初稿。但这不代表自动化测试工程师的岗位变得不重要了恰恰相反门槛从“会写代码”转移到了“会描述问题、会校验结果、会设计场景”。5.1 让AI写脚本提示词应该怎么组织用AI生成脚本最关键的不是会聊而是能把需求描述到让AI能直接产出可执行代码。我自己的实践是提示词至少包含五个要素目标环境、输入数据、操作步骤、期望结果、失败处理。比如我想让AI写一个“登录后创建订单”的接口测试用例不会只写“帮我写个登录测试”而是这样组织请使用Python3和pytest框架写一个接口测试用例。 被测环境http://test.internal.example.com 接口信息 1. POST /api/login参数 {username:admin,password:Pssw0rd}返回里面包含 token 字段 2. POST /api/order请求头需带上 Authorization: Bearer {token}参数 {product_id: 1001, quantity: 2} 断言需求第二步返回期望 HTTP 200且响应中的 hasPendingPayment 字段为 true。 额外要求用例之间要能独立运行token通过 fixture 获取。这样生成的代码基本可以直接放进工程里跑。如果只写一句话让AI自由发挥生成的东西往往是“看起来能用”的玩具代码遇到真实接口的鉴权、加签逻辑就抓瞎。5.2 从自动化测试脚本到AI Agent我理解的演进路径“自己搭建agent进行自动化测试”这个方向很前沿但也最容易让人迷惑。Agent和传统脚本的核心区别在于传统脚本是“固定流程”Agent是“目标驱动”。你给Agent一个目标比如“把首页主要功能全部回归一遍”它会自己拆解成登录、浏览商品、加入购物车、结算等多个步骤中间遇到弹窗还会自己尝试关闭。我自己搭过一个极简版的测试Agent底层逻辑是“LLM做决策 脚本做执行 环境反馈做校验”。Agent先用大模型把自然语言目标拆成可执行的函数调用然后调用Selenium或Playwright去操作浏览器操作完再让模型观察返回的页面文本或截图判断是否达到了子目标没达到就调整策略重试。这个方案跑通Demo不难工程化很难。最难的是“反馈回路”的质量。页面上一堆动态广告、闪烁标签模型看到的DOM信息噪声很大容易做出错误判断。后来我加了一层“语义压缩”先把DOM转成简化文本只保留关键按钮和输入框的描述Agent的判断准确率才明显提上去。这也印证了一件事AI再强底层的自动化能力、元素定位能力、环境稳定性依然是地基。5.3 搭建AI自动化测试平台的可行路径很多人问“AI自动化测试平台搭建”到底从哪里入手我的建议是从“传统测试平台 一个AI能力接口”开始而不是一上来就构建一套全新的AI原生平台。具体来说有三步第一步先把用例管理、执行调度、报告展示这些基础设施做起来没有这些底座AI生成再好的用例也没地方跑。第二步在平台的用例编写入口集成大模型API让测试人员可以用自然语言描述需求平台自动生成脚本草稿人工确认后入库。第三步引入“智能断言”让AI根据接口响应的Json结构自动识别哪些字段适合做关键断言降低用例编写成本。搭建过程中最容易被低估的是“质量门禁”。AI生成的用例不能直接进生产环境至少要经过语法检查、静态扫描、测试环境试跑三层过滤。我见过一个团队用AI批量生成了几千条用例结果大约15%的用例跑出来是“通过但不验证任何东西”这种假阳性比真失败更危险它会让你对质量产生错觉。6. 脚本的价值不在代码量而在“少找人”做了这么多年自动化和脚本我有一个很深的体会脚本写到最后拼的不是技术而是思维。同一件事有人写出来的脚本只能自己用、用一次有人写出来的脚本团队能共享、能长期跑差别在于设计脚本时有没有考虑“让别人省心”这件事。6.1 脚本自检让脚本能自己判断对错一个成熟脚本和玩具脚本的差别看它会不会“自检”。我见过太多脚本执行完最后一个命令就算结束没有校验结果、没有比对期望值、没有生成摘要。这样的脚本即便跑成功也不能验证业务是否真正正确。真正的脚本应该在关键节点都埋上断言或校验逻辑至少每步操作后有成功/失败的判断最后汇总成一份人类能快速看懂的报告。“控制信效度的脚本”这个热词我理解就是在讲这个脚本不仅要执行还要能控制执行的有效性和可靠性。给脚本加上“结果自检”机制是让脚本从“跑个流程”升级为“完成任务”的关键一步。6.2 幂等、日志与退出码三个容易被忽略的工程习惯幂等性这个概念很多时候在大规模部署脚本里才会被认真对待。一个清理临时文件的脚本如果执行到一半中断第二次再执行会不会产生错误如果“先删除旧文件再创建新目录”的流程设计成“先备份再删除”中断后能恢复这就是幂等。我写脚本时凡是涉及删除、创建、移动文件的都会在开头先判断前置条件而不是盲目执行。日志和退出码也是如此。一个没有日志的脚本出问题时你只能干瞪眼。一个不遵守退出码规范的脚本0代表成功、1代表通用错误、2代表参数错误这些约定如果乱了后续做CI/CD集成时根本没法判断脚本是否通过。我后来在团队里强制推广一个规范所有脚本必须支持--log-level参数必须有明确的退出码凡是不能给出清晰退出码的脚本不允许进流水线。6.3 哪些场景不适合自动化脚本的边界感最后想说一个容易被忽略的话题自动化不是万能的。有些任务不适合写脚本强写反而增加负担。我总结下来至少有三类第一类是“一次性且探索性”的任务。比如临时查一条数据、手工试一个接口人点几下几秒钟就能完成写脚本反而浪费时间。第二类是“结果需要强主观判断”的任务。比如视觉走查UI设计是否符合预期、体验某个交互流程是否顺畅这些场景机器只能辅助核心决策还是要人来做。第三类是“高风险且失败代价巨大”的操作。比如直接操作生产数据库、批量删除线上数据这类操作用半自动脚本也有风险我更倾向于手工执行四目确认。自动化与脚本的核心从来不是“消灭人工”而是“把人工从重复劳动中解放出来让人的精力花在更有创造力的判断上”。这也解释了为什么这两年AI自动化测试平台、Agent自动化测试这么火——它们本质上还是在解决“重复”的问题只是把提炼规则的过程也交给了机器。真正有用的自动化永远是在给人和机器划定清晰的边界让每个环节都做自己最擅长的事。最后再说一个实际体会很多人刚开始学自动化时喜欢收藏一堆工具和框架但真正难的是坚持把一个场景做到闭环。我自己的习惯是每个月至少写一个以前没写过、但能帮自己或同事省时间的脚本。从给手机自动打卡到给测试报告自动发邮件提醒都是很不起眼的小东西但因为真正解决了“少找一次人”的问题它们带来的满足感远比学了某个冷门框架大得多。
