★ FEATURED ARTICLE 这个标题看着宽泛但懂行的人都知道自动化与脚本这六个字背后是测试、运维、办公、数据处理一整条技术栈的日常。我做了十年左右的自动化相关工作从最早用按键精灵模拟鼠标点按钮到后来搭接口自动化框架、维护设备老化测试脚本再到这几年把 Playwright 这类工具塞进业务流程里最大的感受是自动化从来不是会写脚本这么简单它是一套关于如何用代码替代重复劳动的决策体系。这篇文章我不会给你列一份工具清单就完事。我想聊的是更实在的东西到底哪些场景适合上脚本哪些场景硬上自动化会死得很惨测试框架怎么选才不踩坑日常的 Shell、PowerShell、Python 脚本怎么写才不容易烂在手里以及当脚本莫名其妙跑不起来的时候你该按什么顺序去排查。这些内容适合正在做测试、运维、开发或者想用自动化解放双手的职场人参考。1. 先别急着写脚本自动化需求的三类边界很多人一听到自动化就兴奋恨不得把每天的工作全交给脚本。我见过最夸张的例子是有人想把 PDF 文件重命名这种五分钟能手动搞定的事情花一整天写 Python 脚本去处理。这不是自动化这是给自己挖坑。1.1 真正适合脚本化的需求长什么样判断一个需求适不适合脚本化我一般看三个特征重复性高同一个操作流程每周、每天甚至每小时都在重复比如每次发版后要跑一遍冒烟测试、每天要汇总报表、每台新设备接入后要执行同样的初始化配置。规则明确整个流程在逻辑上是确定的没有模糊判断。比如读取 Excel 里每一行的订单号到系统里查询状态把结果写回新列——每一步都有明确输入和输出。出错成本可控脚本跑挂了最坏的结果也就是重跑一遍不会造成数据丢失或生产事故。像那种直接操作生产数据库的一键脚本除非你写了完善的事务回滚否则我劝你还是先人工核对。符合这三条的需求你才值得投入时间写脚本。符合得越多投资的回报率越高。1.2 哪些需求硬上自动化会翻车反过来有几类需求我强烈不建议自动化流程经常变动的系统。我做过一个项目业务方每两周改一次操作流程前端页面按钮位置变了我的 UI 自动化脚本就废了改脚本的时间比手动操作还长。需要专家判断的环节。比如审阅文档、评估代码质量、判断一张设计图是否符合品牌规范——这些领域目前连 AI 都只能辅助你指望用脚本硬编规则结果是脚本又长又脆弱。纯一次性任务。领导说帮我把这份通讯录整理成 Excel这种活儿打开 Excel 手动处理半小时就完了没必要写脚本。这些边界不是固定的。同一个任务在不同团队、不同频率下结论可能完全不同。关键是你得养成一种直觉在动手写第一行脚本前先问自己这个问题值得自动化吗维护成本未来六个月会不会超过手工成本2. 自动化测试框架选型pytest、Appium、Playwright 到底怎么选聊到自动化测试领域永远是话题中心。搜索热词里 pytest、Appium、Java接口自动化框架、Playwright 一个不少说明大家都在纠结选型问题。我的建议很简单选型不是追新而是看你和你的团队最擅长什么语言以及被测对象长什么样。2.1 pytest 为什么是接口自动化的默认答案如果你做的是接口自动化尤其是 HTTP API 的自动化测试pytest 基本是绕不开的选择。理由不是因为它功能最全——论封装程度它比不过很多商业工具——而是因为它足够轻且活。轻指的是你不需要重型 IDE也不用单独安装什么服务端。项目里有一个虚拟环境pip 装好 pytest 和 requests就能开写了。活指的是 pytest 的 fixture 机制。很多人在接口自动化里最头疼的是每个用例都要先登录拿 token用 fixture 可以把这套前置逻辑剥出来全局复用。举个例子你要给一个 RESTful API 写登录态管理最朴素的写法是每个测试函数里先调登录接口拿 token再拼到请求头里——写二十个用例你就想吐了。用 fixture 的话import pytest import requests pytest.fixture(scopesession) def auth_token(): resp requests.post(https://api.example.com/login, json{user: admin, pass: secret}) return resp.json()[token] pytest.fixture() def headers(auth_token): return {Authorization: fBearer {auth_token}} def test_get_user(headers): user requests.get(https://api.example.com/user, headersheaders) assert user.status_code 200这段代码里scopesession是关键它告诉 pytest 这个 token 在整个测试会话里只取一次后面的用例全部复用测试时间会快很多。很多人不知道 fixture 还能指定作用域导致每个用例都调一遍登录接口整个测试套件跑下来跟龟速一样。2.2 Appium 做移动端自动化之前你想清楚这几件事Appium 在移动端自动化里的地位不用多说但我的经验是很多人倒在开始用 Appium 之前这两件事上一是环境搭建远比写脚本麻烦。Appium 依赖 Node.js、Appium Server、对应平台的 SDK、真机或模拟器驱动。光是让 Appium 能正确识别一台 Android 设备的 UDID 和 Android 版本就可能卡掉新人一个下午。二是iOS 和 Android 的自动化逻辑差异巨大。iOS 上走的是 XCUITest需要 Mac 环境Android 上走 UIAutomator2 或 Espresso跨平台代码通常是底层框架帮你封装但一旦遇到页面元素定位差异还是得写平台分支。如果只是做简单的 UI 冒烟测试我建议你先评估一下要不要上 Appium。现在很多项目其实可以用更轻的方案——比如直接在真机上通过 adb 命令敲 input tap 模拟点击配合截图对比做断言。虽然不如 Appium 灵活但对于设备老化测试这种场景adb 层面的控制稳定性反而更高。2.3 Playwright 和 Maestro新一代 UI 自动化的取舍Playwright 这几年在 Web UI 自动化领域势如破竹微软出品API 优雅自动等待机制比 Selenium 省心很多。它的核心价值是wait for the element to be actionable不用你手动 sleep极大降低了脚本的不稳定性。不过要提醒一件事Playwright 的能力上限还是局限在浏览器里面。它的page.goto()、locator.click()都假设你在操作一个真实的浏览器。如果你的业务流程跨越了浏览器和本地应用——比如要在网页上触发某个本地软件的交互——那就不能只靠 Playwright 了你可以在脚本里用page.pause()进行调试或者配合系统级控制工具。Maestro 则是移动端 UI 自动化的一匹黑马主打低代码和声明式。它的 YAML 文件描述流程比如- tapOn: 登录、- assertVisible: 首页。对刚接触移动自动化的团队来说Maestro 的学习曲线比 Appium 平缓太多了。但它的问题也很明显自定义逻辑能力弱复杂断言、数据驱动不太方便。所以我给的建议是团队里有资深工程师坐镇用 Appium团队要快速铺开移动自动化用 Maestro 先跑通场景。2.4 Java 接口自动化框架的常见组合如果你是 Java 技术栈接口自动化通常绕不开 RestAssured 或 HttpURLConnection配合 TestNG 或 JUnit 5 管理用例。网上搜Java 接口自动化测试框架出来的组合大体都是这样请求层RestAssured 提供优雅的链式 API处理 JSON 响应很方便。用例层TestNG 的DataProvider做数据驱动Test管理分组和执行顺序。断言层Hamcrest 或 AssertJ断言语句可读性好。报告层Allure 或 TestNG 自带的 HTML 报告建议用 Allure可以生成更美观的测试报告。我个人对 Java 接口自动化的核心建议是不要花太多时间在框架的封装上。我看到很多团队写了一个巨大的接口基类里面集成了日志、重试、加解密、校验签名、数据库断言最后代码复杂度飙升维护起来苦不堪言。接口自动化的本质是验证服务端逻辑是否正确你的脚本应该保持薄薄一层核心是测业务、不是测框架。3. 日常脚本的三大高频场景Shell、PowerShell、Python测试框架终究是自动化大棋盘里的一个分支。日常工作中Shell、PowerShell、Python 这三把刀才是处理杂活的根本。把这三样用好你才能从这个也会那个也会模仿到遇到重复劳动马上能想到脚本。3.1 Linux 下的任务脚本for 循环、定时、日志轮转Linux 服务器上最常用的脚本场景无非是批量处理、定时任务和日志管理。批量处理shell 的 for 循环是基本功。比如你对一批 IP 要 ping 一遍for host in $(cat /tmp/hosts.txt); do ping -c 2 $host /tmp/ping.log 21 echo $host done /tmp/ping_status.log done注意$host要加引号防止 IP 列表里有空格导致命令被拆分。这种细节在写复杂循环的时候特别容易踩坑。定时任务自然是 crontab。但我想多提一句cron 脚本里环境变量和手动执行时不一致是超级常见的坑。你手动跑脚本没问题放进 cron 里就报命令找不到十有八九是 cron 环境里的 PATH 没有包含你命令所在的目录。解决方式是在脚本开头显式设置 PATH或者直接写命令的绝对路径#!/bin/bash export PATH/usr/local/bin:$PATH日志轮转我推荐用系统自带的 logrotate而不是自己写脚本去删。你只需要一个配置文件比如/path/to/app/*.log { daily rotate 7 compress missingok notifempty }这个配置的意思是日志每天轮转一次保留 7 份历史旧的压缩存放。你写脚本去定时清理日志还要考虑文件锁、并发、硬链接完全没有必要。3.2 Windows 下的批处理与 PowerShell 开机自启脚本Windows 环境下大批量自动化还停留在.bat和.ps1的时代。两者的选择很简单简单任务用 .bat 就够了涉及逻辑判断、对象操作、调用系统 API 用 PowerShell。比如你只想把当前目录下所有 test 开头的文件复制到一个备份文件夹bat 几行搞定for /f delims %i in (dir /b /s test*) do copy %i D:\backup\但如果要做开机自启脚本——比如启动后自动拉取代码、启动开发环境、把日志压缩上传——那用 PowerShell 更合适。Windows 的启动文件夹可以直接放.bat或.vbs而计划任务则能设置更多触发条件。我的经验是PowerShell 开机自启脚本最容易死在执行策略上。默认情况 Win 系统不允许运行未签名的本地脚本会抛 UnauthorizedAccess 错误。你当然可以用Set-ExecutionPolicy RemoteSigned修改策略但请注意在企业域环境里组策略可能覆盖你的设置。更稳妥的做法是给脚本签名或者把核心逻辑做成计划任务绑定用户登录时触发。3.3 Python 把碎片化操作串起来Shell 和 PowerShell 适合操作系统级别的任务而 Python 更适合做跨系统的胶水活儿读写 Excel、访问 API、解析 HTML、发邮件、操作数据库。我之前写过一篇关于AI自动化办公的内容核心思想就是让 Python 做那个连接器把各种服务串成一条生产链。比如你每天上班第一件事是从企业微信或邮箱里下载报表然后整理成固定格式发给领导。这种活儿手动做很枯燥用 Python 配合openpyxl操作 Excel加上smtplib发邮件基本一小时就能写个雏形。之后每天双击一下脚本一切自动完成。Python 脚本在不同场景下参数传递也有讲究。你不可能每次改文件路径都要改代码而是应该支持命令行传参import sys path sys.argv[1] if len(sys.argv) 1 else D:\\default.xlsx或者用argparse写更优雅的解析。所有频繁调整的配置账号、路径、阈值都应该抽出来放在脚本头部或者独立的配置模块里。否则三个月后你自己回来看这段脚本都不知道那个常量为什么是 90。4. 脚本跑不起来先排查这几类经典根因写脚本不难难的是调试。我自己统计下来日常工作中遇到的脚本跑不起来问题根因高度集中在环境、权限、路径、依赖四大类。我把最常见的几个拿出来讲透大家可以对照排查。4.1 pip 无法识别环境变量与 Python 安装路径很多人第一次接触 Python 自动化就被这条报错劝退了pip : 无法将“pip”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。这个报错的意思是 Windows PowerShell 在当前路径和系统 PATH 环境变量里都找不到pip命令。本质上不是 pip 没装而是 pip 所在目录没有加入 PATH。排查顺序确认 Python 是否装好了命令行里输入python --version如果有输出说明 Python 本体在 PATH 里如果没有问题就大了你要先去 Python 官网重新安装并且安装界面里务必勾选Add Python to PATH。如果 Python 正常、pip 不识别找到 Python 安装目录下的Scripts文件夹通常是C:\Users\你的用户名\AppData\Local\Programs\Python\Python312\Scripts。把它加入系统 PATH 环境变量。不想改全局 PATH 的话可以后续用python -m pip install xxx来调用 pip这个写法不依赖 pip 命令本身在不在 PATH 里。我很推荐大家养成python -m pip的习惯它能避免很多环境问题。同理跑 Python 脚本也尽量用python xxx.py而不是直接双击.py文件——双击时如果出现闪退你会完全看不到错误信息。4.2 命令行脚本闪退与执行策略脚本闪退这个问题Windows 上非常常见。报了闪退很多人第一反应是脚本是不是写错了但逻辑上更可能是因为脚本还没执行到你的代码就在启动阶段崩了或者执行完了之后窗口立刻关闭你根本没机会看到输出。我的习惯是任何需要排错的脚本先不要双击运行而是打开 PowerShell/CMD 在命令行里手动执行。这样即使报错错误信息也会留在终端里。如果脚本在命令行里能正常跑只是双击会闪退那大概率是脚本输出完信息后窗口被关闭了你可以在脚本末尾加一句kbd input()等用户按键再退出或者用pause命令。PowerShell 脚本还有一个特定坑默认执行策略是 Restricted。你在命令行里运行.ps1它会提示因为在此系统上禁止运行脚本。第一反应别慌用Get-ExecutionPolicy查看策略再决定要不要修改。如果你只是需要一个临时绕过可以用powershell -ExecutionPolicy Bypass -File 脚本路径.ps1。4.3 许可证管理器报错这类环境依赖问题有时候你脚本本身没问题但是它所依赖的外部组件坏了。比如搜索词里的自动化许可证管理器(0086:000301)未正确安装——这是很多商业测试工具或者工业软件会碰到的现象。它们的安装分为两个部分主程序和一个授权许可服务License Service。如果授权服务没装好或者被安全软件拦截了启动主程序一上来就报许可证管理器未正确安装。这类问题的通用排查思路我觉得大家值得收藏检查系统的 Windows 服务里是否有对应的 License Server 服务状态是否在运行。一般你在服务窗口按名字搜就能找到。如果服务启动失败打开事件查看器eventvwr.msc看Windows 日志 - 应用程序里最近的错误记录往往会有具体错误码。很多许可证管理器的根因是端口被占用或者防火墙拦截。软件安装时会默认监听某个端口比如 27000、5099 之类如果被别的程序抢占了服务起不来。用netstat -ano | findstr 端口检查。如果确认是安装损坏最干净的办法是卸载主程序 卸载许可证管理器 删除残留安装目录 重启 重新安装。顺序别反了先重启再重装避免残留进程。这类问题的共性教训是商业软件/工具链的授权组件对环境的敏感程度远比开源工具高。别一上来就怀疑是脚本代码的问题。遇到授权报错先用最短路径确认服务在不在、端口通不通、防火墙放没放行。4.4 脚本在异常环境下的日志采集不管什么语言、什么操作系统我强烈建议你在任何稍复杂一点的脚本里都加上日志输出。不是简单 print而是要带时间戳、带级别、输出到文件。Python 里用 logging 模块import logging logging.basicConfig( filename/tmp/automation.log, levellogging.INFO, format%(asctime)s [%(levelname)s] %(message)s ) logging.info(脚本开始执行)日志的价值我举一个真实场景。有一次我维护的设备老化测试脚本在运行到第 800 台设备时突然报错。如果没有日志你得从头调试有了日志直接查最后几百行记录一眼就看到某一台设备的 adb 连接超时了。节省的时间是小时级的。5. 从脚本到自动化体系pipeline、设备老化测试、AI 办公单一脚本解决单点问题自动化体系解决持续问题。这两者之间的差距是很多初级工程师和高级工程师的分水岭。5.1 从手动敲命令到 CI/CD pipeline 脚本搜索热词里出现pipeline脚本语法我认为这代表了很多人已经有意识想把自动化脚本接入到 CI/CD 里面去。常见的比如 Jenkins Pipeline或者 GitLab CI。它们本质上是在用脚本描述一套流程让代码提交、构建、测试、部署自动串起来。我的建议是如果你刚开始接触 CI/CD别一上来就写花哨的 Groovy 语法。先从 Jenkins 的自由风格项目开始在里面添加几个构建步骤拉取代码、运行 pytest、归档测试报告。跑通了之后再迁移到声明式 Pipeline。声明式 Pipeline 的核心结构其实很清晰pipeline { agent any stages { stage(Checkout) { steps { git https://github.com/example/repo.git } } stage(Test) { steps { sh pytest tests/ -v } } stage(Report) { steps { archiveArtifacts artifacts: reports/**/*.html } } } }写这种 pipeline 脚本唯一要反复确认的是每一步的输入和输出是什么。第一步拉下来的代码在哪里第二步运行时的工作目录是什么如果对工作目录不确定你在 pipeline 里加的sh命令很可能跑在 .jenkins 的默认工作区和其他步骤预期位置不一致就会出现明明文件在那里脚本却找不到的情况。5.2 设备老化测试全自动执行脚本的实战思路设备老化测试全自动执行脚本是搜索热词里很硬核的一个方向我在智能硬件和车载项目里做过类似的事。这个场景的核心难点在于你的测试对象不是软件而是硬件。硬件测试需要考虑物理连接、电流、温度、设备识别等太多软件层面没有的因素。以 Android 设备老化测试为例我搭建过一套流程设备发现与分配通过adb devices获取所有连接的设备给每台设备打标记。循环执行压力动作用脚本控制设备反复做开机、关机、安装应用、卸载应用、切换网络等操作。状态记录每轮操作后采集设备电量、温度、内存、CPU 占用写入时序数据库。异常告警如果某台设备响应超时或温度异常脚本自动标记并触发钉钉/邮件通知。核心代码用 Python 很容易组织import subprocess, time def run_adb(command, serial, timeout10): try: output subprocess.check_output(fadb -s {serial} {command}, timeouttimeout, shellTrue) return output.decode(utf-8).strip() except Exception as e: log_warning(f设备 {serial} 执行失败: {e}) return None for cycle in range(0, 1000): for serial in device_list: run_adb(shell input keyevent 26, serial) # 按下电源键 time.sleep(5) run_adb(shell input keyevent 82, serial) # 唤醒 time.sleep(10) log_status(serial, cycle, OK)我的经验教训是硬件测试脚本最重要的不是功能的完整性而是异常处理的鲁棒性。一台设备 USB 松了、死机了、adb 掉线了脚本不能整个崩掉而是应该把异常设备记录下来、继续处理其他设备最后汇总一份哪些设备在什么周期、什么操作下失败的报告。你写脚本的时候要想象凌晨三点这个脚本无人值守——遇到正常的程序设计之外的情况没人帮你点掉那个弹窗。5.3 AI自动化办公哪些能落地哪些是噱头最后聊一下AI自动化办公。2025 年之后这几乎成为所有行业的热词。但我的观点依然很清醒AI 是自动化的加速器不是自动化的替代品。能落地的场景比如用 AI 辅助生成脚本代码、用自然语言描述需求让 Copilot 或 Claude 生成初步的 pytest 用例、让 LLM 分析测试失败日志并给出疑似根因。这些我实际用下来效率提升是实打实的。特别是分析日志这种体力活AI 很擅长做模式总结。不能直接落地的场景是那些寄希望于 AI 全自动处理主观判断的需求。比如让 AI 自动回复所有客户邮件或者让 AI 自动审核所有供应商单据在合规性和准确率没达到 99.9% 之前出了事还是要你背锅。我的建议是AI 负责初稿和草稿人负责最终确认和风险兜底这就相当于给自动化流程装了一道护栏。再说了AI 帮你生成代码你至少要能看懂代码、能改代码。如果连 pytest 的 fixture 是什么都不理解AI 给出的错误建议你也分辨不出来。所谓AI 替代程序员在自动化的语境里还早得很但会用 AI 的程序员替代不会用 AI 的程序员已经开始了。写到最后说点个人体会。做自动化这十年我最大的感受是脚本本身从来不值钱值钱的是你对业务的理解、对异常的处理、对边界的判断。一个刚入行的工程师可能三天就能把 pytest 用例跑起来但要写出一个能在凌晨三点无人值守、该重试的重试、该告警的告警、该跳过的跳过的自动化脚本需要踩过的坑远不止语法层面的东西。如果你正在学自动化我给你的建议是先把 Linux Shell 和 Python 基础打牢这是所有自动化的地基再挑一两个框架深入用pytest 必学UI 层 Playwright 性价比最高遇到坑不要慌把错误信息原样拿去搜索大概率你不是第一个遇到的人最重要的是每写一个脚本都问自己一句三个月后我回来看这段代码还能不能看懂如果能你算入门了如果看不懂现在就该补注释、加日志、抽配置了。
阅读完成 · 觉得有帮助？
