linux下Appium+Python移动应用自动化测试实战---4.Android Emulator Headless

系列文章：linux下Appium+Python移动应用自动化测试实战

linux下Appium+Python移动应用自动化测试实战—1.环境准备
linux下Appium+Python移动应用自动化测试实战—2.配置Android App调试环境
linux下Appium+Python移动应用自动化测试实战—3.手把手教你定位元素编写测试用例
linux下Appium+Python移动应用自动化测试实战—4.Android Emulator Headless

---

腊月二十九写的那篇手把手定位元素编写用例的文章，没想到在4天的时间获得了2000多的阅读量。作为一个成熟的概念和框架，没想到热度竟然还这么高。博主果断放弃了今天下午的10公里越野，加快推出Android Emulator的headless模式相关文章。

---

前言

通过前面的几篇文章，相信基本上都能够上手appium+python进行android应用的自动化测试工作了。但是在当今DevOps大行其道的日子里，如果要让这种自动化框架在CICD的持续集成环境里面顺利跑起来，可能还是有点问题的。首先，CICD的服务器以Linux居多；其次，Linux服务器一般情况下都是运行在命令行模式下；最后，传统的android emulator运行的时候占用了大量的系统资源。 这个时候，Android Emulator的headless模式就是比较好的选择了。从28.0.25版本开始，Android Emulator支持headless模式运行。这篇文章将带领大家使用Emulator的headless模式。

---

一、关于Emulator

我没有研究过Google的意图是什么，竟然在Anndroid SDK下面设置了两个emulator可执行程序。一个是${ANDROID_SDK_HOME}/tools/emulator， 另一个是${ANDROID_SDK_HOME}/emulator/emulator，可能Google有它自己的考虑。这里要说的的是，一般情况下命令行运行android模拟器，用的是${ANDROID_SDK_HOME}/emulator/emulator，我本地linux下验证的时候，${ANDROID_SDK_HOME}/tools/emulator会报各种异常。 为了保证emulator能够正常运行，在设置PATH环境变量的时候，emulator最好要放在tools的前面。

二、关于Headless模式

网络上有各种关于headless的方法和描述，比如emulator-headless， -no-skin，isHeadless=true等等。在最新的Android Emulator 30.3.5下（注意这里是Android Emulator的版本，不是Android Studio的版本），这些都不靠谱，直接添加参数-no-window即可。

emulator -avd EMULATOR_NAME -no-window

这个时候你可能会碰到如下图所示的一些类似audio等相关的错误提示，如果被测内容不相关的话，可以忽略。

三、关于linux下程序的后台执行

这个不再赘述，无非就是用&还是用nohup。具体的区别大家自己问问度娘或者狗狗。

四、整体的执行脚本

这个也很简单，根据正常运行的顺序，执行相关的命令即可。将如下内容写入到shell脚本automation_test.sh中，并赋予其执行权限。

# 修改/dev/kvm的属主为当前用户，否则因为权限问题启动android模拟器失败
sudo chown -R ${
     USER}:${
     USER} /dev/kvm
sleep 5s
# 后台启动appium服务用于监听界面操作，并把相关内容输出到文件appium_out.txt中
appium > ./appium_out.txt &
sleep 5s
# 后台启动android模拟器，并把相关内容输出到文件emulator_out.txt中
emulator -avd Nexus_4_API_25 -no-window > ./emulator_out.txt &
sleep 20s
# 后台运行自动化测试用例，并输出结果到test_result.txt中
pytest calculator.py > ./test_result.txt &

命令行下直接执行automation_test.sh脚本。
$ bash automation_test.sh
执行如下图。

执行过程中，可以看到整个屏幕没有相关界面弹出。执行结束后，目录下多了几个txt文件，查看相关输出文件内容，重点查看测试结果输出文件即可。
如下图，可见本次执行的4个测试用例全部通过。