使用开源框架好处是它是免费的, 因此它也有一个缺点, 遇到问题的时候, 没有专门的人来响应我们, 毕竟社区的人都是挤出自己业余时间来帮你解答问题. 那么作为框架的使用者, 并且对使用方式和上下文了解最清楚的我们, 遇到问题自己的排查能力也是很重要的.
spawn ENOMEM
我遇到的第一个问题是, 前一天自动化跑的还是好好的, 第二天打开自动化报告发现了如下错误:
Error: browserContext.nexPage: spawn ENOMEM上网查了一下, 基本都在说是因为内存不足导致的问题. 可是前后两天都没有增加新的用例, 不应该有这样的问题. 看了一下监控, 发现内存使用情况跟昨天是一样的, 并没有超过内存的80%.
同样的环境, 同样的用例最后产生了差别, 那只能怀疑是运行时自动化镜像出了问题, 于是我把前后两天的镜像都起了一个docker容器, 进去检查安装包的版本, 里面有几个依赖包小版本升级了, 果断先做了降级. 第二天就没有再看到这个错误, 应该是这几个小版本产生了内存泄漏.
Connection reset by peer
这个问题发生在小长假后来, 自动化报告出错了.报了下面这个错误
Connection reset by peer有了第一个问题经验, 我先去看了一下前后两个的镜像里的安装包版本, 发现都是一致的. 又去网上查了一下, 这个主要是远程服务器发起了重新连接的指令.
看了一下报错都是集中出现在测试用例的最后一个测试集, 并且是tear down中的关闭浏览器操作, 看了一下执行时间都在2min左右, 对比其他测试集的关闭浏览器操作, 发现时间是逐步上升的情况. 我又仔细检查了之前的每个测试集, 是否存在没有关闭浏览器的情况, 怀疑是不是因为之前没有关闭浏览器导致一直占用系统资源, 因为我在运行中一直开启录屏. 发现收效甚微, 因为playwright应该是默认每个测试集结束会自动关闭浏览器的.
再看一下监控, 内存和cpu都是健康状态, 系统负载和io确实在报错的时间段有一个峰值, 看来就是跟io有关. 回想确实最近一直在增加ui用例, ui运行时间也是越来越长, 问题应该就是这里没跑了, 这时候我再检查一下代码, 看到我在启用context时候加了这一条配置
recordHar={"path":"${OUTPUT_DIR}/${SUITE_NAME}.har"}也就是自动化运行过程中, 它会记录浏览器与每一个网站的交互. 当时是因为在自动化早期阶段, 想要记录自动化到底覆盖了哪些页面, 方便查漏补缺, 加了这个配置, 这样在自动化结束时候解析里面的数据. 现在自动化用例多起来后就不用这个指标了, 那么这个配置其实也是没有用的. 于是我就去掉了这个配置. 没想到第二天这个问题就解决了. less is more.
综上, 自动化框架也是一款工具, 并且它的售后效率比较低. 这就需要我们要有自己排查与解决问题的能力. 最后祝大家元宵节快乐.