【常见问题】MeterSphere 测试计划长时间 running 问题分析及解决方法


飞致云 发布于 2023-09-06 / 1767 阅读 / 0 评论 /

1 测试计划执行说明

MeterSphere 测试计划开始执行时,指定资源池将从站点地址下载执行文件,然后将不同类型的测试用例调度到对应的环境执行中,其中接口用例在node-controller容器中执行,性能测试在临时创建的JMeter容器执行,UI用例则在对应的不同的浏览器容器中执行。整个执行过程,kafka 实时监听执行结果,并最终由data-streaming 将执行结果写入数据库,详细的执行过程,可参考下图:

如果测试计划执行过程中,某些用例因某些异常原因而未执行完成,那么测试计划就会因为未收到结束通知一直处于 running 状态,接口自动化测试异常是导致这个问题的主要原因,本文将介绍常见的原因以及对应的解决方法。

2 常见原因及分析

2.1 资源池原因

2.1.1 node-controller 状态异常

正常情况下,在资源池所在的服务器上执行 msctl status 命令可以看到 ms-node-controller 容器的状态是 healthy。如果其状态不是 healthy,则用例执行阻塞,导致测试计划状态一直处于 running 状态。这时在资源池节点使用 docker logs -f ms-node-controller 命令查看容器日志,根据日志报错分析原因和解决,先确保 node-controller 容器运行正常。

2.1.2 node-controller 内存不足

问题现象

测试计划串行执行可以正常执行结束,并行时部分用例长期处于 running 状态无法正常结束,而长时间等待后,测试计划报告中,接口用例状态是error或stopped,而用例报告详情中每个步骤都是success状态,测试计划报告状态为running。

原因分析

MeterSphere 接口测试支持并发执行,其允许的最大并发数在“系统设置”-“测试资源池”中进行设置,默认并发数为50,意思是在后台会生成 50 个线程池。如果没有用例执行,线程都是释放状态,如果有用例执行,会有对应数量的线程变为活跃状态,而活跃状态的线程占用的内存与接口用例的复杂度有关。如果系统默认的资源池并发数设置太大,例如500以上,而资源池既 ms-node-controller 服务的可用内存不足以支撑大并发时,将导致线程没有足够资源执行完成用例而中途异常终止。

解决方法

  • 如果资源池勾选了用于接口测试,那么并发数不建议设置太大,默认的 50 并发即可。

  • 修改 node-controller 的配置文件,默认路径为/opt/metersphere/docker-compose-node-controller.yml,将 mem_limit 参数调大(默认为1g),然后执行 msctl reload 命令重新加载。

2.2 Kafka原因

2.2.1 kafka网络问题

问题现象

/opt/metersphere/logs/node-controller/info.log 日志中会出现以下报错信息:
”[kafka-producer-network-thread | producer-1] WARN  o.apache.kafka.clients.NetworkClient 775 - [Producer clientId=producer-1] Connection to node 1 (/xx.xx.xx.xx:9092) could not be established. Broker may not be available。“

原因分析

测试计划执行中,有可能网络出现异常,导致 kafka 无法正常接收消息,每个用例都无法接收到完整的响应体消息,这种情况会导致所有执行中的用例都处于running状态。

解决方法

检查并确保资源池跟kafka之间网络畅通。

# 进入ms-node-controller容器
docker exec -it ms-node-controller sh
# 判断网络情况,如果返回open则网络畅通
nc -zv ip port(输入kafka所在服务器的ip和端口)

如果网络资源池到kafka的网络不畅通,需要检查kafka容器状态以及是否存在防火墙等网络限制。

2.2.2 kafka消息太大

问题现象

kafka容器日志会出现以下报错信息:“RecordTooLargeException:   The request included a message larger than the server will accept。“

原因分析

当个别用例响应体太大,导致消息大小超过 kafka 默认限制时,kafka 将无法接收执行结果消息,该用例会一直处于 running 中。

解决方法

修改 kafka 的配置文件,将 MeterSphere 服务器上 /opt/metersphere/docker-compose-kafka.yml 文件中的 MESSAGE_MAX_BYTES (单个消息的最大字节数)参数值调大,然后再使用 msctl reload 命令重新加载。

2.3 用例本身原因

问题现象

只有固定的某条用例一直 running 中,其余用例都能正常执行结束。

原因分析

如果用例使用资源池运行时,由于自身原因一直执行中,也会导致测试计划报告整体状态为running。这种情况需要观察日志,追踪一直处于 running 用例在执行过程是否出现了异常。

解决方法

首先需要在测试计划报告中找到running用例的报告Id,根据Id在 /opt/metersphere/logs/node-controller/ms-jmeter-run.log 中追踪执行过程,观察执行中是否有异常日志。例如:一条正常执行结束的用例报告,在日志中会包含完整的从run到testEnded的过程,如果没有testEnded日志,则用例会一直处于running状态。

其次可以在页面上进行排查。例如某条接口自动化用例在测试计划中一直running,可以打开场景详情修改该用例的参数再次调试,以及禁用掉可能导致用例一直执行的步骤逐步排查出问题原因。

3 其它思路

如果上述排查手段均未发现异常,可以使用排除法逐步定位问题点。比如确定是否每一次执行测试报告都会出现问题,使用不同的资源池执行是否都会出现问题等,逐步确定问题的复现条件。



是否对你有帮助?