移动自动化测试框架拓展

相关背景

目前国内许多公司都开始使用自动化测试，尤其是最近这几年，自动化测试更是受到了越来越多的青睐。常见公司产品的商业化，使其不可能做到一个产品结构的经常变动的。这就给自动化技术提供了基础。常见的自动化测试包括客户端和移动端，本文旨在讨论移动端的测试化。目前常见的移动自动化测试，主要分布在以下三个层面，UI层面、接口层面和单元测试。

虽然移动化测试能提高测试团队的测试效率，但也只是在特定场景下可以使用，是不可能替代人工测试的，只是一个辅助的工具。

相关技术

STF

个人觉着是提供一个移动端的资源池，通过RESTFUL框架我们可以获取所学要的移动端设备，是一个比较好的移动端设备管理工具。目前官网上说可以管理达1000台以上手机。

ADB

1. 客户端，运行在开发机器（电脑）上，你可以通过从shell输入adb命令来调用客户端，或者从其他Android工具如DDMS创建adb客户端。
2. 服务端，作为一个后台进程运行在开发机器（电脑）上，负责管理客户端和模拟器（设备）上的adb守护进程之间的通信。
3. 守护进程，作为后台进程运行在每个模拟机（设备）上。

你可以在sdk的platform-tools中找到adb工具。当你开启一个adb客户端，客户端首先检查是否有一个adb服务端已经在运行，如果没有，则启动服务端进程。当服务端启动时，它绑定到本地TCP端口5037来监听从adb客户端发送的命令，所有的adb客户端通过5037端口和服务端通信。

Appium

Appium是一个开源的、跨平台的自动化测试工具，支持IOS、Android和FirefoxOS平台。 通过Appium，开发者无需重新编译app或者做任何调整，就可以测试移动应用，可以使测试代码访问后端API和数据库。它是通过驱动苹果的UIAutomation和Android的UiAutomator框架来实现的双平台支持，同时绑定了Selenium WebDriver用于老的Android平台测试。开发者可以使用WebDriver兼容的任何语言编写测试脚本，如Java， OC， JS， PHP，Python， Ruby， C#，Clojure 和Perl语言。

Docker

Docker就是一个应用程序执行容器，类似虚拟机的概念。但是与虚拟化技术的不同点在于下面几点：

1. 虚拟化技术依赖物理CPU和内存，是硬件级别的；而docker构建在操作系统上，利用操作系统的containerization技术，所以docker甚至可以在虚拟机上运行。
2. 虚拟化系统一般都是指操作系统镜像，比较复杂，称为“系统”；而docker开源而且轻量，称为“容器”，单个容器适合部署少量应用，比如部署一个redis、一个memcached。
3. 传统的虚拟化技术使用快照来保存状态；而docker在保存状态上不仅更为轻便和低成本，而且引入了类似源代码管理机制，将容器的快照历史版本一一记录，切换成本很低。
4. 传统的虚拟化技术在构建系统的时候较为复杂，需要大量的人力；而docker可以通过Dockfile来构建整个容器，重启和构建速度很快。更重要的是Dockfile可以手动编写，这样应用程序开发人员可以通过发布Dockfile来指导系统环境和依赖，这样对于持续交付十分有利。
5. Dockerfile可以基于已经构建好的容器镜像，创建新容器。

Docker还有的优点包括，发布快、部署方便等。

 

Python

Python优势的最大有点就是比其他语言更简单易学，功能强大的解释型编程语言，它有简洁明了的语法，高效率的高层数据结构，能够简单而有效地实现面向对象编程python的特点比较简单易学，有丰富的库。

 

下面先从搭建STF环境说起。

Open STF环境的搭建

安装步骤：

• 在centos上安装Docker，很简单，直接 yum install docker 即可

• 开启docker服务 在centos中开启服务可以使用systemctl start serviceName.service，比如开启docker，systemctl start docker.service

• 拉取docker镜像文件，使用docker安装 STF 很简单，只需拉取以下5个镜像即可: 

    docker pull openstf/stf:latest 

    docker pull sorccu/adb:latest 

    docker pull rethinkdb:latest 

    docker pull openstf/ambassador:latest 

    docker pull nginx:latest

• 启动容器 先启动一个数据库

  docker run -d --name rethinkdb -v /srv/rethinkdb:/data --net host rethinkdb rethinkdb --bind all --cache-size 8192 --http-port 8090
  

  再启动adb service

  docker run -d --name adbd --privileged -v /dev/bus/usb:/dev/bus/usb --net host sorccu/adb:latest

  再启动stf

  docker run -d --name stf --net host openstf/stf stf local --public-ip 宿主机IP地址

  一定要注意启动顺序，STF 依赖 rethinkdb，所以要先启动 rethinkdb，启动完成后使用: docker ps -a 查看是否启动成功 

 

连接未安装STF 的电脑上的设备

首先保证其他电脑可以和安装STF 的系统通信，在未安装STF 的电脑上暴露adb端口，建议采用默认端口:5037，

adb -a -P 5037 fork-server server

如果出现以下错误:

在任务管理器中关掉adb.exe，重新运行上述命令。 

可能还会出现

reply fd for adb server to client communication not specified.

网上说通过：adb nodaemon server -a，但是我试了无论怎么做都会停留在这个界面

zewdeMacBook-Pro:~ zew$ adb nodaemon server -a -P 5037
adb I 08-31 19:13:00 77373 7125513 adb_auth_host.cpp:416] adb_auth_init...
adb I 08-31 19:13:00 77373 7125513 adb_auth_host.cpp:174] read_key_file '/Users/zew/.android/adbkey'...

 

最后解决问题是换了adb的版本，建议换成低版本adb，我换成的是2014年的adb版本

最后执行：adb -a -P 5037 fork-server server

 

接着这个以后我们就开始启动STF

docker启动STF遇到的一些问题

当我们执行试图启动的时候，在docker中删除原来的stf镜像，重新运行(10.138.61.121 是宿主机IP，10.138.20.194是远程的IP,5037 是宿主机暴露的adb端口),如果没有删除的话我们执行下面的命令

docker run -d --name stf --privileged=true --net host openstf/stf stf local --public-ip 10.138.61.121 --adb-host 10.138.20.194 --adb-port 5037  --allow-remote

会遇到这个问题：

Error response from daemon: Conflict. The container name "/stf" is already in use by container "c8d7f7e010206d185b7969fad8f92e955e8e4b2efb718fd02f82703f8b6b306c". You have to remove (or rename) that container to be able to reuse that name.

其实这个问题就是在于你的之前运行的docker的容器还没有退出，导致出现容器重名的情况，这时候我们需要删除容器

• docker rm c8d7f7e010206d185b7969fad8f92e955e8e4b2efb718fd02f82703f8b6b306c(镜像ID)

这时候会出现另外一个问题：

Error response from daemon: You cannot remove a running container c8d7f7e010206d185b7969fad8f92e955e8e4b2efb718fd02f82703f8b6b306c. Stop the container before attempting removal or force remove

此时输出错误是指你不能删除一个正在运行的容器，必须先停止它，才能够删除。于是我们执行：docker stop

我们发现又出现了错误

"docker stop" requires at least 1 argument. See 'docker stop --help'. Usage:  docker stop [OPTIONS] CONTAINER [CONTAINER...] [flags] Stop one or more running containers [[e-mail] ~]#  docker rm c8d7f7e010206d185b7969fad8f92e955e8e4b2efb718fd02f82703f8b6b306c Error response from daemon: You cannot remove a running container c8d7f7e010206d185b7969fad8f92e955e8e4b2efb718fd02f82703f8b6b306c. Stop the container before attempting removal or force remove

Docker本身提供了两种终止容器运行的方式，即docker stop与docker kill。

先来说说docker stop吧，当我们用docker stop命令来停掉容器的时候，docker默认会允许容器中的应用程序有10秒的时间用以终止运行。所以我们查看docker stop命令帮助的时候，会有上图的提示:

在docker stop命令执行的时候，会先向容器中PID为1的进程发送系统信号SIGTERM，然后等待容器中的应用程序终止执行，如果等待时间达到设定的超时时间，或者默认的10秒，会继续发送SIGKILL的系统信号强行kill掉进程。在容器中的应用程序，可以选择忽略和不处理SIGTERM信号，不过一旦达到超时时间，程序就会被系统强行kill掉，因为SIGKILL信号是直接发往系统内核的，应用程序没有机会去处理它。在使用docker stop命令的时候，我们唯一能控制的是超时时间，比如设置为20秒超时:docker stop --time=20 container_name

 

docker kill

接着我们来看看docker kill命令，默认情况下，docker kill命令不会给容器中的应用程序有任何gracefully shutdown的机会。它会直接发出SIGKILL的系统信号，以强行终止容器中程序的运行。通过查看docker kill命令的帮助，我们可以看到，除了默认发送SIGKILL信号外，还允许我们发送一些自定义的系统信号：

Usage:  docker kill [OPTIONS] CONTAINER [CONTAINER...] Kill one or more running containers Options:       --help            Print usage   -s, --signal string   Signal to send to the container (default "KILL")

比如，如果我们想向docker中的程序发送SIGINT信号，我们可以这样来实现： 1 docker kill --signal=SIGINT container_name 与docker stop命令不一样的地方在于，docker kill没有任何的超时时间设置，它会直接发送SIGKILL信号，以及用户通过signal参数指定的其他信号。 其实不难看出，docker stop命令，更类似于Linux系统中的kill命令，二者都是发送系统信号SIGTERM。而docker kill命令，更像是Linux系统中的kill -9或者是kill -SIGKILL命令，用来发送SIGKILL信号，强行终止进程。 在程序中接收并处理信号

了解了docker stop与docker kill的区别，我们能够知道，docker kill适合用来强行终止程序并实现快速停止容器。而如果希望程序能够gracefully shutdown的话，docker stop才是不二之选。这样，我们可以让程序在接收到SIGTERM信号后，有一定的时间处理、保存程序执行现场，优雅的退出程序。

一切都做好了以后我们在开始指定容器停止

 docker stop --time=20 stf

终止成功!

然后在删除

 docker rm c8d7f7e010206d185b7969fad8f92e955e8e4b2efb718fd02f82703f8b6b306c

删除成功!

docker run -d --name stf --privileged=true --net host openstf/stf stf local --public-ip 10.138.61.121 --adb-host 

然后我们在重新走一遍

docker run -d --name stf --privileged=true --net host openstf/stf stf local --public-ip 10.138.61.121 --adb-host 10.138.20.194 --adb-port 5037  --allow-remote

结果显示

成功，然后我们打开STF官网

截止到现在STF环境搭建完成。

 

Appium与stf连接

根据上一篇博客我们说到了如何去使用Appium完成自动化测试，根据上面的文章我们在服务器通过docker搭建了stf环境，那么二者如何了联系到一起呢。首先我们打开stf网页（http://10.138.61.121:7100/#!/control/emulator-5556）

 

然后在我的Mac系统(测试人员的电脑)终端输入这个命令：

zewdeMacBook-Pro:~ zew$ adb connect 10.138.61.121:7405
* daemon not running; starting now at tcp:5037
* daemon started successfully
connected to 10.138.61.121:7405

连接成功后验证一下，输入：adb devieces

拷贝左边的设备信息：10.1xx.xxx.1xx:7405

把设备信息防止到Pycharm的devicesName中

 

这样重新运行脚本就可以在STF网站看到远程的设备自动化运行的情况。

 

而且还能看到相关的日志打印情况