WEBUI自动化平台开发过程遇到的问题整理

WEBUI开发 过程遇到的问题整理:

1.接入ibu-parent jar包

出现的问题:大量的jar冲突,以及jar包禁用规则等

2.部署失败,vi/health点火失败

问题原因:点火时,服务器会调用/vi/health接口,以判断服务是否启动成功
解决方案:增加/vi/health接口

3.接入dal:

出现的问题:创建bean失败
问题原因:guava jar包版本太高,导致dal依赖的这个jar包里的一个方法找不到;但降低到dal要求的版本后,case执行会报错
解决方案:exclusion掉dal jar包引入的guava,另行导入中间版本的guava jar包

4.接入dal后点火失败

问题原因:点火时,服务器回调用/apps接口,以判断数据库是否连接成功
解决方案:增加/apps接口,随便找个库连一下即可

5.服务器上没有浏览器,无法在浏览器上执行case,且本地调试需要在服务器执行一段命令

解决方案:
第一步:另建资源项目,资源项目里放浏览器安装包和本地调试的jar包
第二步:在应用项目中,新建init.sh文件,将浏览器安装命令,和本地调试服务器要执行的命令都放在该文件中,则项目在发布过程中打镜像时会执行该文件中的命令
遇到问题:打镜像的时候提示 can not open chrome…
原因:GITLAB_PRIVATE_TOKEN=“r_Vv-nb8tk4kExve5xy3”
这里的token不是feed token,而是person access token

6.执行case时,提示找不到driver文件

问题原因:是因为deploy用户没有该文件的执行权限
解决方案:init.sh文件中新增给driver增加权限的命令

7.执行case时提示:bind() failed: Cannot assign requested address (99)

问题原因:case执行失败与该问题无关,是因为服务器不能访问外网导致
解决方案:增加浏览器代理

8.本地调试,服务器连接办公网络失败

第一个问题:连接我自己的电脑失败,是因为服务器只允许访问办公网络部分端口,将端口号指定为80后解决该问题
第二个问题:连接5楼同事电脑失败,网络问题,待解决

9.执行case报错:unknown-error-session-deleted-because-of-page-crash-from-unknown-error-cannot,查看日志可知页面打开后元素已找到,但页面突然崩溃,导致后续测试步骤执行失败

解决方案:options.addArguments("–disable-dev-shm-usage");
详见:https://stackoverflow.com/questions/53902507/unknown-error-session-deleted-because-of-page-crash-from-unknown-error-cannot

10.接入公司邮件发送接口:

经常遇到邮件未发送问题,增加邮件发送补偿逻辑,前端增加邮件补发入口

11.定时任务,原本用的是quartz,但是新建相关库表时,不支持联合主键,于是在quartz相关库表新增了id字段,新增后定时任务执行异常

解决方案:接入公司任务调度框架qschedule
问题:项目启动后任务列表查不到任务
解决方案:去掉quartz相关的所有配置及代码,并更新接口的声明方式

12 出海:通过将vpn封装成带权限的代理,在启动浏览器时安装到浏览器中,模拟海外用户

遇到的问题:
linux服务器无法打开浏览器界面运行case,而安装浏览器代理必须要打开浏览器界面
解决方案:
增加windows服务器
遇到的问题:
公司运维并不提供windows服务器,所以我们实际是增加了一台windows机器,将windows机器作为node节点与linux机器连接,让用例在windows机器上打开浏览器界面运行,问题是:如何区分本地调试机器和windows服务器呢?
解决方案:
增加配置文件,将windows服务器写到配置文件中,非本地调试的用例仅分配到配置文件中的机器上运行

13. 执行完用例总会残余一些未关闭的浏览器,长此以往未关闭的浏览器会占用大量cpu,影响用例执行的成功率,浪费系统资源

解决方案:
每个用例执行结束后,关闭浏览器,但经实验发现,仍然有未关闭的浏览器
解决方案:
使用finally,不管用例执行是否抛出异常,只要不是本地调试失败的用例,都在最后关闭浏览器,经实验,仍然有未关闭的浏览器
最后,经检查,发现是有测试用例使用了两次get(url)方法,导致同一个用例打开了两个浏览器窗口,而用例执行结束后只关闭了最后打开的浏览器,前边打开的浏览器没有关闭导致
解决方案:
规范用例编写原则
ps:并未彻底解决该问题

14. 应用发布后触发执行对应的自动化用例

遇到的问题:
开发在自测阶段,部署十分频繁,当用例量特别大的时候,会出现第一次部署触发的用例尚未执行完,而开发已经在进行第二次部署,中间会出现用例打开页面都返回502,而导致用例出现大范围失败;且因为频繁部署,机器也会压力较大
解决方案:

  1. 开发自测阶段,不触发用例执行(如何区分是否是自测阶段?)
  2. 仅对release的部署触发用例执行(一般发布前才会合release,这个时候触发用例执行是否会太晚?)
    ps:鉴于开发并不会主动触发自动化用例的执行,故对该逻辑暂不修改

15. 远程服务器残余未关闭的浏览器和驱动进程

  • 解决方案1:
    尝试使用chromeDriverService,失败:无法从Node机上读取file
  • 解决方案2:
    将node机的file直接放在项目里,从项目里读取,失败:chromeDriver实际启动的是本地服务,并不是远程
  • 解决方案3:
    hub启动命令增加timeo了
    browserTimeout: 当普通的超时机制失败时,它用作备份超时机制,通常应在网格/服务器环境中使用该机制,以确保崩溃/丢失的进程不会停留太长时间,从而污染了运行时环境。
    方案3尝试结果:失败,仍残余很多浏览器进程
  • 解决方案4:
    非出海任务设置使用无头隐身模式浏览器

为什么不直接杀进程:

  1. 杀进程会杀掉所有浏览器,若此时有任务在执行,会直接执行失败
  2. 由于目前接了应用部署自动触发执行用例,所以每天执行的用例量,每天杀一次进程也未必能解决该问题
  • 解决方案5:
第一步:优化代码,将driver的值传递改为引用传递,避免driver在传递过程中丢失导致浏览器无法正常关闭。
值传递:指在调用函数时将实际参数复制一份传递到函数中,这样在函数中如果对参数进行修改,将不会影响到实际参数
public class StringBase {
 
    public static void main(String[] args) {
        int c = 66; //c 叫做实参
        String d = "hello"; //d 叫做实参
 
        StringBase stringBase = new StringBase();
        stringBase.test5(c, d); // 此处 c 与 d 叫做实参
 
        System.out.println("c的值是:" + c + " --- d的值是:" + d);
    }
    
    public void test5(int a, String b) { // a 与 b 叫做形参
public class StringBase {
 
    public static void main(String[] args) {
        int c = 66; //c 叫做实参
        String d = "hello"; //d 叫做实参
 
        StringBase stringBase = new StringBase();
        stringBase.test5(c, d); // 此处 c 与 d 叫做实参
 
        System.out.println("c的值是:" + c + " --- d的值是:" + d);
    }
    
    public void test5(int a, String b) { // a 与 b 叫做形参
        a = 55;
        b = "no";
    }
}a = 55;
        b = "no";
    }
}

【运行结果】
c的值是:66 — d的值是:hello

可以看出通过方法传递后,int 类型与 String 类型的原值并没有受到前面 test5 方法执行后的影响,还是输出了原值。这种形为通常被说成值传递。如果原值经过 test5 方法后被改变了,这种形为通常被描述为引用传递。

引用传递:是指在调用函数时将实际参数的地址直接传递到函数中(的形参),那么在函数中对参数所进行的修改,将影响到实际参数。形参为指向实参地址的指针,当对形参的指向操作时,就相当于对实参本身进行的操作。
第二步 配置node参数,增加maxSession(用例执行中最多可并发打开的浏览器数),maxInstance(最多可建立的会话数),maxInstance不能大于maxSession.

到此步,执行大量用例会出现较多的浏览器打开失败问题

第三步 将node节点的任务分配改为由selenium自动分配

目前截止到此步,没有再出现node服务器因残余大量浏览器进程而导致机器cpu爆满卡死的现象,也没有出现执行大量用例时打开浏览器失败问题,仍在观察中。。

16.打开页面提示“无法访问此网站”

可能的原因:

  1. 公司网络带宽限制
  2. 静态资源并发连接数限制
  3. http并发连接数限制

排查过程:

  1. 首先排查http连接数
    由于目标页面是https,首先需要了解https和http的区别:
    https是基于http协议,通过ssl或tls对请求数据进行加密和验证对方身份以及保护数据完整性
browserhttp/1.1http/1.0
IE1166
chrome4+66

为验证该问题是否为执行case并发数超过浏览器并发连接数上限导致,将并发执行case数改为最大18

17.Exception in thread “main” org.openqa.selenium.InvalidSelectorException: invalid selector: Failed to execute ‘send’ on ‘XMLHttpRequest’: Failed to load ‘https://www.trip.com/’

报错的原因是:Chrome默认不支持本地的AJAX请求!

解决问题的办法是:给Chrome浏览器添加启动参数:–disable-web-security 或者 --allow-file-access-from-files

具体步骤参见:http://jingyan.baidu.com/article/7c6fb4281d685780642c900a.html
参考:https://www.cnblogs.com/wankun/p/5025436.html

18. fat1环境服务器运行2天后,node节点就无法连接到主节点

1 查看hub节点进程情况

netstat -ant | grep 4444

发现进程正常
2. 查看java服务

ps -ef | grep java

发现大量waited_closed进程
猜测,可能是因为hub节点配置的超时时间太长,以至于TCP协议已自动断开连接,而HUB节点却还因超时时间未到,而继续等待,以至于导致大量僵尸进程
解决方案: 修改HUB节点超时时间或去掉超时设置

19. node节点运行一段时间后,会出现无法创建session的错误

经过排查,发现运行一段时间后,c盘因缓存数据而饱满,D盘appData的数据高达几十G
解决方案:每天空闲时定时清理C盘缓存,D判断appData里的数据

d:
cd /users
taskkill /f /im chrome.exe
taskkill /f /im chromedriver.exe
rd D:\Users\jjqi\AppData\Local\Temp /S/Q
powercfg -h off
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Dagger是网易杭州研究院QA团队开发的一个轻量级、运行稳定的WebUI自动化测试框架,主要基于Selenium及TestNg可以认为是对Selenium进行二次封装的一个框架(俗称 造轮子 )。之所以把这个轮子开源出来,主要在于经过了公司内部多个项目的实践,也取得了不错的成效,因此,希望开源以后可以对大家有所帮助及参考。 设计理念 Dagger首先是一个WebUI自动化框架,提供了赖以操纵浏览器的一些API。API数量不多,少于20个,但从实践上,已经基本涵盖95%的应用场景了(其余5%比较 个性 的自动化操作一般是封装在业务逻辑层面,有时候甚至会须要hack) Dagger其次是一个测试框架,使用TestNg管理和运行用例,TestNg相关断言内嵌于上述API中。因此,在我们的测试用例里面不应该看到单独的TestNg断言的 Dagger还是一种设计风格:简约。无论是Dagger框架本身还是基于Dagger编写的测试用例,都是十分light及straightforward的,以至于会让人感觉有点土。但实践中,这两者确保了低成本、易用性、可维护性 WebUI自动化从业界看,难推进,易烂尾,原因基本在于:维护成本高、运行速度慢、稳定性差 Dagger专注于WebUI自动化,从技术上克服了速度与稳定问题(见下文)。只封装够用的浏览器操作为API,并充分简化/强化这些API,以简约的风格去降低自动化的学习及使用成本。同时,在实践中,我们主要使用Dagger编写冒烟用例、其次是主干用例,少写逻辑复杂功能,不写边边角角功能,让用例也保持清爽(在整个自动化实施过程中,会定期进行用例Review),同样易于后期维护 主要特性 API极少,易于上手,详见这里. 提供比较完备的文档,便于快速入门,详见这里. 支持单机多浏览器并发执行,大大缩短用例执行时间,详见这里 通过修改TestNg源码实现失败用例自动重运行(详见这里)由此几乎消除WebUI自动化中常见的虚假失败 默认使用Chrome浏览器,原因详见这里 失败用例自动截屏 后续工作 加入Flex/Flash自动化支持 如何使用 Dagger十分适合中小型团队从零开始WebUI自动化,这样的话,只须要直接下载整个Dagger代码就行了,Dagger本身都已经配置好了,下载后看一下使用文档就可以直接开始写用例了 也可以把Dagger打成Jar包,导入已有的自动化框架中,详见这里 标签:Dagger  自动化测试

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值