6月自动化与工控技术热点：从Playwright到工控安全与RPA实操

本来没打算专门写一期月度汇总但这个月后台私信和技术群里讨论的内容实在有点杂有人问Playwright到底能不能替代Selenium有人在工控群里贴出“自动化许可证管理器(0086:000300)找不到许可证”的报错截图还有人被跨境电商多平台订单抓取的工作流折腾到凌晨。把这堆消息放在一起看其实正好串成了一张自动化与工控领域的技术热点图——从自动化测试框架、接口自动化到工控国产化平台、工控安全标准再到Ansible运维自动化和RPA工作流覆盖面比我上个月预想的宽不少。这篇就按我自己的关注顺序把6月值得留意的资讯和实操经验整理出来给做自动化测试、工控开发、运维自动化的朋友做一份速查参考。1. 本月自动化与工控领域的整体动向1.1 自动化测试依然是讨论热度中心6月多个技术社区和群里出现频率最高的关键词依然集中在接口自动化、UI自动化、自动化测试框架这三大块。不过细看大家讨论的具体内容和前一两个月已经有了明显区别。接口自动化不再只是“发一个请求、断言一个状态码”这么简单大家开始关心数据驱动怎么设计、不同环境怎么自动切换、断言粒度如何把握、失败日志怎么收敛才能快速定位问题。UI自动化这边Selenium的老牌地位还在但Playwright和Cypress的讨论量明显上升尤其是Playwright几乎每个自动化测试话题下面都有人提起。很多人已经在盘算要不要把老项目从Selenium迁到Playwright但又担心迁移成本和脚本重写的风险。这个月我看到的共识是新项目可以直接考虑Playwright老项目则要按模块逐步替换不要一次性推倒重来。1.2 工业控制与工控安全进入更多人的视野与互联网测试开发岗位的关注点不同工控圈子这个月的讨论更多集中在工控安全、标准规范和软件授权问题上。很多做PLC、SCADA、HMI项目的朋友开始交流怎么对OT资产做盘点怎么对工控网络做分区隔离参考哪些国际通行的工业网络安全标准来指导安全加固。能感受到工控安全正在从“安全部门单独关心”变成“现场工程师也要懂”的基础能力。另一个高频问题是西门子博途、WinCC等工控软件环境下的授权管理器报错尤其是一条“0086:000300”找不到许可证的提示几乎每隔一段时间就会有人截图来问。虽然不算新技术问题但每年都有新入行的人在这里卡住后续我会单独写排查思路。1.3 从热词里读出的技术趋势如果把这个月出现较多的热搜词做一次简单归类能看到三个明显趋势。自动化测试开始和AI能力结合Claude UI自动化测试、Codex生成代码、AI语义断言这类词条频繁出现工控方向更关注国产硬件平台和标准合规龙芯2K3000与轨道交通AFC系统、工控安全相关标准成为典型话题自动化运维与RPA的边界在变模糊Ansible自动化运维项目和跨境电商多平台订单抓取这类RPA工作流被同一批人同时关注。这些趋势说明自动化正在从单一工具使用走向平台化、智能化和合规化。别小看这种变化它直接影响下一步的技术选型方向。2. 工业控制与国产化平台热点2.1 龙芯2K3000与轨交AFC系统的国产化实践轨道交通AFC系统也就是自动售检票系统是国产化工控平台一个很有代表性的落地场景。闸机、售票机、自助终端这些设备核心工作无非是扫码、读写票卡、控制门禁、联网对账听起来不复杂但有一个硬性要求7x24小时稳定运行响应时间必须控制在很窄的范围内而且设备生命周期可能长达五到十年。龙芯2K3000这类面向工控嵌入式场景的SoC优势在于外围接口齐全串口、CAN、USB、网口都能直接引出算力也足够跑AFC终端的业务逻辑。真正决定项目能不能落地的不只是CPU本身而是三件事操作系统的BSP是否完善、外设驱动是否齐全、协议栈有没有现成支持。以AFC闸机为例第一步应该先梳理外设清单二维码扫码器、NFC读写模块、显示屏、钱箱、门控IO、以太网口各自需要什么接口第二步到开发板上逐个验证驱动兼容性第三步做性能摸底在真实业务负载下看CPU占用、IO响应抖动和长时间运行稳定性。我在看这类项目时有个习惯不要只盯芯片主频要重点问BSP里的内核版本、有没有实时性补丁、GPIO和串口控制库是否开放以及上游社区是否活跃。国产平台最大的坑往往不是芯片算力而是外围生态不成熟外设驱动和工控协议栈反而会耗费大量时间。2.2 工控安全里的标准规范与许可证管理企业做工控安全建设时经常会提到IEC 62443等系列标准。这个体系的核心思路是分区隔离、纵深防御把工控网络划分成不同的安全区域在各区域之间做好访问控制和流量监控。落地到具体项目常用动作包括资产盘点、网络分区、协议白名单、日志审计、补丁管理。需要提醒的是标准规范是指导性的落地时必须结合工艺连续性要求不能因为安全策略而影响正常生产节拍。这个月被问最多的实操问题还是“自动化许可证管理器(0086:000300)找不到许可证”。这个报错在博途、WinCC等西门子工控软件里非常典型我的排查顺序如下。先确认授权类型是单机授权还是网络浮动授权单机授权就检查系统时间、授权管理器服务状态、授权文件路径网络授权先ping授权服务器再确认授权通信端口是否可达打开授权管理器看能否识别到授权识别不到就先重装授权管理器如果刚更新过系统补丁或安全软件还要检查授权文件有没有被误清理。这个报错里大概率是系统时间不对、授权路径被改动、授权服务没有启动这三个原因。还有一点必须强调不要图省事去找非正规工具绕过授权检查工控软件授权一旦出问题会直接影响产线合规使用才是唯一可靠的路。2.3 工控项目选型心得做工控项目选型多数人第一反应是看CPU主频但工控场景更该关注的是外围指标。接口数量是否够用串口、CAN、网口、USB各要预留多少协议栈是否齐备Modbus、CANopen、Profinet这些常用协议有没有现成SDK设备是否支持宽温和无风扇设计轨交、户外机柜对温度容忍度要求很高供货周期和设备生命周期是否匹配很多设备要稳定供应五到十年中途换方案代价极高。我这里还有一个实操建议拿样机把实际业务程序跑上48小时重点关注内存占用趋势、CPU使用率、IO抖动和长时间运行后的稳定性。这种压力摸底比单纯跑benchmark有价值得多能提前暴露很多“宣传参数好看但实际扛不住”的问题。3. 自动化测试与软件工具链动态3.1 从Selenium到Playwright浏览器自动化测试怎么选6月好几个技术群的争论焦点是“要不要从Selenium迁到Playwright”。我自己的看法是新项目优先考虑Playwright老项目按模块逐步替换不要一股脑全量迁移。先看一张简单对比表。工具优势需要注意的地方Selenium生态老、支持语言多、老项目兼容性好需要额外管理浏览器驱动等待逻辑较弱Playwright自动等待、多上下文、Trace Viewer、代码生成社区相对年轻部分老插件需要适配Cypress上手快、调试体验好、文档友好多标签页和iframe支持需要额外处理Playwright让我最舒服的一点是自动等待机制再也不用在代码里到处塞sleep。比如下面这个登录用例页面跳转、按钮可点、元素出现都会自动等待代码干净很多。from playwright.sync_api import sync_playwright def test_login(page): page.goto(https://example.com/login) page.fill(#username, test_user) page.fill(#password, 123456) page.click(button[typesubmit]) page.wait_for_selector(.dashboard) assert page.locator(.user-name).inner_text() test_user这段代码里没有一处time.sleep但基本不会出现元素还没加载完就报错的问题。从Selenium迁移过来时有个经验值得记住不要试图一次性重写所有旧脚本先挑最核心、最常用、最容易出问题的20%用例做试点验证稳定性之后再逐步扩展。另外要注意公司内网环境可能需要提前确认浏览器安装和依赖拉取的网络策略。3.2 接口自动化框架pytest requests 数据驱动接口自动化的标准套路其实已经非常成熟这个月大家讨论的更多是工程化细节。一个相对完整的框架通常包含这几层请求封装用requests.Session统一管理cookies、超时、重试逻辑用例管理用pytest组织用例配合fixture处理前置和后置数据驱动把测试数据放到yaml、json或Excel里一个用例跑多组数据断言封装不只断言HTTP状态码还要断言业务码和关键字段报告输出集成Allure或者pytest-html方便查看失败详情。热词里有一个“python接口自动化如何自动切换环境”这是很多团队都会遇到的诉求。最简单的方式是在conftest.py里读取环境变量把不同环境的地址维护成字典。import os import pytest pytest.fixture(scopesession) def base_url(): env os.getenv(TEST_ENV, dev) urls { dev: https://dev-api.example.com, staging: https://staging-api.example.com } return urls[env]这样在本地跑默认用dev环境在CI里只需要设置TEST_ENVstaging所有用例就会自动切到预发布环境。断言方面我也想多说一句断言越具体越好尽量校验业务字段而不是只检查返回码同时失败信息里一定要带上响应体否则出问题还要翻日志定位效率会低很多。3.3 App自动化与手机端自动化测试App自动化这个月的讨论热度不低核心工具还是Appium和Airtest。Appium适合跨平台、复杂手势、混合应用测试Airtest的图像识别在游戏App和嵌入式设备测试里效率更高。真机群管理是另一个大坑USB连接不稳定、设备离线、权限弹窗反复出现都会让自动化脚本变脆。一个小技巧是同一网段的设备可以用adb无线连接统一管理提前把App首次启动的权限弹窗处理脚本固化到用例里能省掉大量“偶发失败”。另外看到AutoJS这类工具出现在热搜里我多提醒一句这类脚本工具用来做个人设备自动化、辅助日常操作没有问题但不要拿去做批量营销、刷量之类的灰色用途。轻则账号被限制重则要承担法律风险完全不值得。3.4 AI辅助测试的趋势观察这个月讨论较多的还有AI自动生成测试脚本包括Claude UI自动化测试、Codex生成pytest用例等方向。我试用下来的感受是AI目前最适合做三件事根据需求描述自动补基础用例、分析失败日志并定位大概率原因、给页面元素补充可读性更高的定位标签。但AI还不适合直接全自动维护一套大型测试工程尤其是涉及复杂业务状态流转和跨系统数据校验时AI生成的断言经常会忽略边界条件。比较稳妥的用法是把AI当成一个结对工程师它给初稿、你来做审查和补强。实际落地时可以试着让AI先把中文需求转成测试用例列表再转成pytest框架代码你会发现它能帮你省掉很多重复劳动但最终稳定性还是要靠人来把关。4. 自动化运维与RPA工作流新思路4.1 Ansible与自动化运维项目落地Ansible在自动化运维里的地位一直很稳这个月关键词里“Ansible自动化运维项目”再次出现。它之所以流行核心原因是无代理架构基于SSH就能跑学习和部署成本都比较低。实际落地建议分四步走。先做资产梳理和Inventory分组把生产、测试、不同业务线的主机分清楚再写Playbook处理基础配置比如系统参数、用户权限、软件安装然后用Roles把任务按职责拆开方便复用和维护最后接入CI/CD或AWX做定时巡检、配置变更和回滚。热词里还有一个“AI Agent Harness自动化运维”这是偏前沿的方向用大模型读取运行日志、判断是否需要回滚、生成修复命令。我的态度是它可以当辅助工具但现阶段不建议让它全自动操作生产环境。最稳妥的用法是AI给出建议人审批通过后再执行既能享受效率提升又能避免误操作。4.2 WorkBuddy与跨境电商多平台订单抓取工作流跨境电商多平台订单抓取一直是RPA的典型场景。如果你只有一个店铺每天定时登录后台采集订单用浏览器自动化就能解决如果店铺数量多平台接口肯定是首选RPA只做兜底。一个通用工作流大致是这样的先确认每个平台是否提供开放API、令牌额度和消息推送机制能走API的优先走API不能覆盖的页面再用RPA浏览器自动化补全数据落库前做去重和订单状态映射避免重复和错乱统一生成对账单推送到企业微信、钉钉或邮件。以WorkBuddy为代表的可视化RPA平台核心价值是把步骤编排成流程图不写代码也能跑通基础流程。但订单抓取最怕的不是登录失败而是页面结构悄无声息地变化。所以每个采集步骤都要加字段级校验和异常告警一旦发现抓取数量或字段内容和预期不符立刻通知人工介入。4.3 Excel工作流自动化与AI辅助问到最高频的还有“如何用AI建立自动化Excel工作流”很多不是程序员出身的朋友也想让日报、对账、报表合并这些重复工作自动跑起来。这里给一条最容易上手的路线。第一步把重复操作拆开你是要从多个Excel里读数据做合并还是要做格式统一或者是生成图表第二步优先用Python加pandas、openpyxl写脚本而不是去录制宏因为宏在数据格式变化时维护成本很高第三步让AI帮你写初版代码但一定要在样本数据上完整跑一遍确认结果无误再做全量执行第四步把脚本接到定时任务或文件监视器上实现“文件一放进去就自动处理”。举个例子合并多个分店的销售Excelpandas读取目录下所有文件concat之后按月份groupby汇总再写回结果表二十多行代码就能搞定。真正的难点往往在数据清洗环节比如表头不一致、空值处理、编码问题。AI能帮你写八成代码剩下两成的数据判断需要你根据业务规则去把关。5. 常见问题与排查技巧实录5.1 自动化脚本最常见的“隐形杀手”这个月在各个群里帮人看脚本发现很多问题其实是相似的。我把最常见的几类原因整理成一张速查表。现象常见原因处理思路脚本本地稳定、CI随机失败并发冲突、测试数据相互污染控制用例并行度保证数据隔离元素定位偶尔失败动态ID、动态类名或加载时序用显式等待和稳定定位属性进入不了页面内部元素iframe、Shadow DOM上下文问题先切换到对应上下文再定位断言偶发失败断言粒度过粗或过细只断言关键业务字段下载文件出现异常浏览器下载行为不一致统一配置下载路径并做超时处理一个反复出现的经验是如果脚本本地没问题、上了CI就随机失败建议先查并发和资源竞争再看等待时间最后看测试数据独立性。很多人一上来就加大time.sleep只会把问题盖住并不能根治。5.2 工控软件许可证与环境的排查思路前面提到“自动化许可证管理器(0086:000300)找不到许可证”在工控软件里很常见我这里展开说下排查步骤。确认授权类型是单机授权还是网络浮动授权这决定了后续排查方向单机授权检查系统时间时间漂移是最容易忽略的原因检查授权文件路径是否被改动环境变量是否指向旧路径在Windows服务里确认授权管理器服务是否启动相关服务没起来就手动拉起网络授权先ping授权服务器地址再确认端口通不通如果刚更新过安全软件或系统补丁检查授权文件是否被误清理必要时加入白名单。我见过不少案例最后查下来只是系统时间被改快了几个小时授权管理器就认为授权失效了。排查时不要一上来就重装软件先按上面的顺序逐项验证大多数情况十分钟内能定位。5.3 月更博主的一点真实避坑建议我做月度汇总有个习惯会把本月遇到的问题按环境类、代码类、数据类分成三堆然后为每一个问题浓缩出一句可执行的处理方法。比如“授权报错先看系统时间”“CI随机失败先查数据隔离”“元素定位不稳定优先找data-testid”。这句话可以写进团队文档也可以贴在工位上下次再遇到同类问题就能快速反应。还有一个小技巧想分享给所有人做自动化项目不管测试还是运维一定要在最开始记录好“环境指纹”包括操作系统版本、浏览器版本、Python或Java版本、依赖锁文件、中间件版本。很多看起来诡异的问题最后都逃不开版本漂移这四个字。环境信息一致了问题基本就解决了一半。