debugtalk (九毫)

深入浅出开源性能测试工具 Locust (使用篇 1)

debugtalk — Fri, 10 Mar 2017 20:18:21 +0800

在《【LocustPlus 序】漫谈服务端性能测试》中，我对服务端性能测试的基础概念和性能测试工具的基本原理进行了介绍，并且重点推荐了Locust这一款开源性能测试工具。然而，当前在网络上针对Locust的教程极少，不管是中文还是英文，基本都是介绍安装方法和简单的测试案例演示，但对于较复杂测试场景的案例演示却基本没有，因此很多测试人员都感觉难以将Locust应用到实际的性能测试工作当中。

经过一段时间的摸索，包括通读Locust官方文档和项目源码，并且在多个性能测试项目中对Locust进行应用实践，事实证明，Locust完全能满足日常的性能测试需求，LoadRunner能实现的功能Locust也基本都能实现。

本文将从Locust的功能特性出发，结合实例对Locust的使用方法进行介绍。考虑到大众普遍对LoadRunner比较熟悉，在讲解Locust时也会采用LoadRunner的一些概念进行类比。

概述

先从Locust的名字说起。Locust的原意是蝗虫，原作者之所以选择这个名字，估计也是听过这么一句俗语，“蝗虫过境，寸草不生”。我在网上找了张图片，大家可以感受下。

而Locust工具生成的并发请求就跟一大群蝗虫一般，对我们的被测系统发起攻击，以此检测系统在高并发压力下是否能正常运转。

在《【LocustPlus 序】漫谈服务端性能测试》中说过，服务端性能测试工具最核心的部分是压力发生器，而压力发生器的核心要点有两个，一是真实模拟用户操作，二是模拟有效并发。

在Locust测试框架中，测试场景是采用纯 Python 脚本进行描述的。对于最常见的HTTP(S)协议的系统，Locust采用 Python 的requests库作为客户端，使得脚本编写大大简化，富有表现力的同时且极具美感。而对于其它协议类型的系统，Locust也提供了接口，只要我们能采用 Python 编写对应的请求客户端，就能方便地采用Locust实现压力测试。从这个角度来说，Locust可以用于压测任意类型的系统。

在模拟有效并发方面，Locust的优势在于其摒弃了进程和线程，完全基于事件驱动，使用gevent提供的非阻塞IO和coroutine来实现网络层的并发请求，因此即使是单台压力机也能产生数千并发请求数；再加上对分布式运行的支持，理论上来说，Locust能在使用较少压力机的前提下支持极高并发数的测试。

脚本编写

编写Locust脚本，是使用Locust的第一步，也是最为重要的一步。

简单示例

先来看一个最简单的示例。

from locust import HttpLocust, TaskSet, task

class WebsiteTasks(TaskSet):
    def on_start(self):
        self.client.post("/login", {
            "username": "test",
            "password": "123456"
        })

    @task(2)
    def index(self):
        self.client.get("/")

    @task(1)
    def about(self):
        self.client.get("/about/")

class WebsiteUser(HttpLocust):
    task_set = WebsiteTasks
    host = "http://debugtalk.com"
    min_wait = 1000
    max_wait = 5000

在这个示例中，定义了针对http://debugtalk.com网站的测试场景：先模拟用户登录系统，然后随机地访问首页（/）和关于页面（/about/），请求比例为2:1；并且，在测试过程中，两次请求的间隔时间为1~5秒间的随机值。

那么，如上 Python 脚本是如何表达出以上测试场景的呢？

从脚本中可以看出，脚本主要包含两个类，一个是WebsiteUser（继承自HttpLocust，而HttpLocust继承自Locust），另一个是WebsiteTasks（继承自TaskSet）。事实上，在Locust的测试脚本中，所有业务测试场景都是在Locust和TaskSet两个类的继承子类中进行描述的。

那如何理解Locust和TaskSet这两个类呢？

简单地说，Locust类就好比是一群蝗虫，而每一只蝗虫就是一个类的实例。相应的，TaskSet类就好比是蝗虫的大脑，控制着蝗虫的具体行为，即实际业务场景测试对应的任务集。

这个比喻可能不是很准确，接下来，我将分别对Locust和TaskSet两个类进行详细介绍。

class HttpLocust(Locust)

在Locust类中，具有一个client属性，它对应着虚拟用户作为客户端所具备的请求能力，也就是我们常说的请求方法。通常情况下，我们不会直接使用Locust类，因为其client属性没有绑定任何方法。因此在使用Locust时，需要先继承Locust类，然后在继承子类中的client属性中绑定客户端的实现类。

对于常见的HTTP(S)协议，Locust已经实现了HttpLocust类，其client属性绑定了HttpSession类，而HttpSession又继承自requests.Session。因此在测试HTTP(S)的Locust脚本中，我们可以通过client属性来使用Python requests库的所有方法，包括GET/POST/HEAD/PUT/DELETE/PATCH等，调用方式也与requests完全一致。另外，由于requests.Session的使用，因此client的方法调用之间就自动具有了状态记忆的功能。常见的场景就是，在登录系统后可以维持登录状态的Session，从而后续 HTTP 请求操作都能带上登录态。

而对于HTTP(S)以外的协议，我们同样可以使用Locust进行测试，只是需要我们自行实现客户端。在客户端的具体实现上，可通过注册事件的方式，在请求成功时触发events.request_success，在请求失败时触发events.request_failure即可。然后创建一个继承自Locust类的类，对其设置一个client属性并与我们实现的客户端进行绑定。后续，我们就可以像使用HttpLocust类一样，测试其它协议类型的系统。

原理就是这样简单！

在Locust类中，除了client属性，还有几个属性需要关注下：

task_set: 指向一个TaskSet类，TaskSet类定义了用户的任务信息，该属性为必填；
max_wait/min_wait: 每个用户执行两个任务间隔时间的上下限（毫秒），具体数值在上下限中随机取值，若不指定则默认间隔时间固定为 1 秒；
host：被测系统的 host，当在终端中启动locust时没有指定--host参数时才会用到；
weight：同时运行多个Locust类时会用到，用于控制不同类型任务的执行权重。

测试开始后，每个虚拟用户（Locust实例）的运行逻辑都会遵循如下规律：

先执行WebsiteTasks中的on_start（只执行一次），作为初始化；
从WebsiteTasks中随机挑选（如果定义了任务间的权重关系，那么就是按照权重关系随机挑选）一个任务执行；
根据Locust类中min_wait和max_wait定义的间隔时间范围（如果TaskSet类中也定义了min_wait或者max_wait，以TaskSet中的优先），在时间范围中随机取一个值，休眠等待；
重复2~3步骤，直至测试任务终止。

class TaskSet

再说下TaskSet类。

性能测试工具要模拟用户的业务操作，就需要通过脚本模拟用户的行为。在前面的比喻中说到，TaskSet类好比蝗虫的大脑，控制着蝗虫的具体行为。

具体地，TaskSet类实现了虚拟用户所执行任务的调度算法，包括规划任务执行顺序（schedule_task）、挑选下一个任务（execute_next_task）、执行任务（execute_task）、休眠等待（wait）、中断控制（interrupt）等等。在此基础上，我们就可以在TaskSet子类中采用非常简洁的方式来描述虚拟用户的业务测试场景，对虚拟用户的所有行为（任务）进行组织和描述，并可以对不同任务的权重进行配置。

在TaskSet子类中定义任务信息时，可以采取两种方式，@task装饰器和tasks属性。

采用@task装饰器定义任务信息时，描述形式如下：

from locust import TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def test_job1(self):
        self.client.get('/job1')

    @task(2)
    def test_job2(self):
        self.client.get('/job2')

采用tasks属性定义任务信息时，描述形式如下：

from locust import TaskSet

def test_job1(obj):
    obj.client.get('/job1')

def test_job2(obj):
    obj.client.get('/job2')

class UserBehavior(TaskSet):
    tasks = {test_job1:1, test_job2:2}
    # tasks = [(test_job1,1), (test_job1,2)] # 两种方式等价

在如上两种定义任务信息的方式中，均设置了权重属性，即执行test_job2的频率是test_job1的两倍。

若不指定执行任务的权重，则相当于比例为1:1。

from locust import TaskSet, task

class UserBehavior(TaskSet):
    @task
    def test_job1(self):
        self.client.get('/job1')

    @task
    def test_job2(self):
        self.client.get('/job2')

from locust import TaskSet

def test_job1(obj):
    obj.client.get('/job1')

def test_job2(obj):
    obj.client.get('/job2')

class UserBehavior(TaskSet):
    tasks = [test_job1, test_job2]
    # tasks = {test_job1:1, test_job2:1} # 两种方式等价

在TaskSet子类中除了定义任务信息，还有一个是经常用到的，那就是on_start函数。这个和LoadRunner中的vuser_init功能相同，在正式执行测试前执行一次，主要用于完成一些初始化的工作。例如，当测试某个搜索功能，而该搜索功能又要求必须为登录态的时候，就可以先在on_start中进行登录操作；前面也提到，HttpLocust使用到了requests.Session，因此后续所有任务执行过程中就都具有登录态了。

脚本增强

掌握了HttpLocust和TaskSet，我们就基本具备了编写测试脚本的能力。此时再回过头来看前面的案例，相信大家都能很好的理解了。

然而，当面对较复杂的测试场景，可能有的同学还是会感觉无从下手；例如，很多时候脚本需要做关联或参数化处理，这些在LoadRunner中集成的功能，换到Locust中就不知道怎么实现了。可能也是这方面的原因，造成很多测试人员都感觉难以将 Locust 应用到实际的性能测试工作当中。

其实这也跟Locust的目标定位有关，Locust的定位就是small and very hackable。但是小巧并不意味着功能弱，我们完全可以通过 Python 脚本本身来实现各种各样的功能，如果大家有疑问，我们不妨逐项分解来看。

在LoadRunner这款功能全面应用广泛的商业性能测试工具中，脚本增强无非就涉及到四个方面：

关联
参数化
检查点
集合点

先说关联这一项。在某些请求中，需要携带之前从 Server 端返回的参数，因此在构造请求时需要先从之前请求的 Response 中提取出所需的参数，常见场景就是session_id。针对这种情况，LoadRunner虽然可能通过录制脚本进行自动关联，但是效果并不理想，在实际测试过程中也基本都是靠测试人员手动的来进行关联处理。

在LoadRunner中手动进行关联处理时，主要是通过使用注册型函数，例如web_reg_save_param，对前一个请求的响应结果进行解析，根据左右边界或其它特征定位到参数值并将其保存到参数变量，然后在后续请求中使用该参数。采用同样的思想，我们在Locust脚本中也完全可以实现同样的功能，毕竟只是 Python 脚本，通过官方库函数re.search就能实现所有需求。甚至针对 html 页面，我们也可以采用lxml库，通过etree.HTML(html).xpath来更优雅地实现元素定位。

然后再来看参数化这一项。这一项极其普遍，主要是用在测试数据方面。但通过归纳，发现其实也可以概括为三种类型。

循环取数据，数据可重复使用：e.g. 模拟 3 用户并发请求网页，总共有 100 个 URL 地址，每个虚拟用户都会依次循环加载这 100 个 URL 地址；
保证并发测试数据唯一性，不循环取数据：e.g. 模拟 3 用户并发注册账号，总共有 90 个账号，要求注册账号不重复，注册完毕后结束测试；
保证并发测试数据唯一性，循环取数据：模拟 3 用户并发登录账号，总共有 90 个账号，要求并发登录账号不相同，但数据可循环使用。

通过以上归纳，可以确信地说，以上三种类型基本上可以覆盖我们日常性能测试工作中的所有参数化场景。

在LoadRunner中是有一个集成的参数化模块，可以直接配置参数化策略。那在Locust要怎样实现该需求呢？

答案依旧很简单，使用 Python 的list和queue数据结构即可！具体做法是，在WebsiteUser定义一个数据集，然后所有虚拟用户在WebsiteTasks中就可以共享该数据集了。如果不要求数据唯一性，数据集选择list数据结构，从头到尾循环遍历即可；如果要求数据唯一性，数据集选择queue数据结构，取数据时进行queue.get()操作即可，并且这也不会循环取数据；至于涉及到需要循环取数据的情况，那也简单，每次取完数据后再将数据插入到队尾即可，queue.put_nowait(data)。

最后再说下检查点。该功能在LoadRunner中通常是使用web_reg_find这类注册函数进行检查的。在Locust脚本中，处理就更方便了，只需要对响应的内容关键字进行assert xxx in response操作即可。

针对如上各种脚本增强的场景，我也通过代码示例分别进行了演示。但考虑到文章中插入太多代码会影响到阅读，因此将代码示例部分剥离了出来，如有需要请点击查看《深入浅出开源性能测试工具 Locust（脚本增强）》。

GitHub 项目地址

https://github.com/debugtalk/Stormer

硬广

欢迎关注我的个人博客和微信公众号。

个人博客：http://debugtalk.com
微信公众号：DebugTalk

深入浅出开源性能测试工具 Locust (使用篇 1)

debugtalk — Wed, 22 Feb 2017 21:28:25 +0800

概述

而Locust工具生成的并发请求就跟一大群蝗虫一般，对我们的被测系统发起攻击，以此检测系统在高并发压力下是否能正常运转。

脚本编写

编写Locust脚本，是使用Locust的第一步，也是最为重要的一步。

简单示例

先来看一个最简单的示例。

from locust import HttpLocust, TaskSet, task

class WebsiteTasks(TaskSet):
    def on_start(self):
        self.client.post("/login", {
            "username": "test",
            "password": "123456"
        })

    @task(2)
    def index(self):
        self.client.get("/")

    @task(1)
    def about(self):
        self.client.get("/about/")

class WebsiteUser(HttpLocust):
    task_set = WebsiteTasks
    host = "http://debugtalk.com"
    min_wait = 1000
    max_wait = 5000

那么，如上 Python 脚本是如何表达出以上测试场景的呢？

那如何理解Locust和TaskSet这两个类呢？

这个比喻可能不是很准确，接下来，我将分别对Locust和TaskSet两个类进行详细介绍。

class HttpLocust(Locust)

原理就是这样简单！

在Locust类中，除了client属性，还有几个属性需要关注下：

task_set: 指向一个TaskSet类，TaskSet类定义了用户的任务信息，该属性为必填；
max_wait/min_wait: 每个用户执行两个任务间隔时间的上下限（毫秒），具体数值在上下限中随机取值，若不指定则默认间隔时间固定为 1 秒；
host：被测系统的 host，当在终端中启动locust时没有指定--host参数时才会用到；
weight：同时运行多个Locust类时会用到，用于控制不同类型任务的执行权重。

测试开始后，每个虚拟用户（Locust实例）的运行逻辑都会遵循如下规律：

先执行WebsiteTasks中的on_start（只执行一次），作为初始化；
从WebsiteTasks中随机挑选（如果定义了任务间的权重关系，那么就是按照权重关系随机挑选）一个任务执行；
根据Locust类中min_wait和max_wait定义的间隔时间范围（如果TaskSet类中也定义了min_wait或者max_wait，以TaskSet中的优先），在时间范围中随机取一个值，休眠等待；
重复2~3步骤，直至测试任务终止。

class TaskSet

再说下TaskSet类。

性能测试工具要模拟用户的业务操作，就需要通过脚本模拟用户的行为。在前面的比喻中说到，TaskSet类好比蝗虫的大脑，控制着蝗虫的具体行为。

在TaskSet子类中定义任务信息时，可以采取两种方式，@task装饰器和tasks属性。

采用@task装饰器定义任务信息时，描述形式如下：

from locust import TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def test_job1(self):
        self.client.get('/job1')

    @task(2)
    def test_job2(self):
        self.client.get('/job2')

采用tasks属性定义任务信息时，描述形式如下：

from locust import TaskSet

def test_job1(obj):
    obj.client.get('/job1')

def test_job2(obj):
    obj.client.get('/job2')

class UserBehavior(TaskSet):
    tasks = {test_job1:1, test_job2:2}
    # tasks = [(test_job1,1), (test_job1,2)] # 两种方式等价

在如上两种定义任务信息的方式中，均设置了权重属性，即执行test_job2的频率是test_job1的两倍。

若不指定执行任务的权重，则相当于比例为1:1。

from locust import TaskSet, task

class UserBehavior(TaskSet):
    @task
    def test_job1(self):
        self.client.get('/job1')

    @task
    def test_job2(self):
        self.client.get('/job2')

from locust import TaskSet

def test_job1(obj):
    obj.client.get('/job1')

def test_job2(obj):
    obj.client.get('/job2')

class UserBehavior(TaskSet):
    tasks = [test_job1, test_job2]
    # tasks = {test_job1:1, test_job2:1} # 两种方式等价

脚本增强

掌握了HttpLocust和TaskSet，我们就基本具备了编写测试脚本的能力。此时再回过头来看前面的案例，相信大家都能很好的理解了。

在LoadRunner这款功能全面应用广泛的商业性能测试工具中，脚本增强无非就涉及到四个方面：

关联
参数化
检查点
集合点

然后再来看参数化这一项。这一项极其普遍，主要是用在测试数据方面。但通过归纳，发现其实也可以概括为三种类型。

循环取数据，数据可重复使用：e.g. 模拟 3 用户并发请求网页，总共有 100 个 URL 地址，每个虚拟用户都会依次循环加载这 100 个 URL 地址；
保证并发测试数据唯一性，不循环取数据：e.g. 模拟 3 用户并发注册账号，总共有 90 个账号，要求注册账号不重复，注册完毕后结束测试；
保证并发测试数据唯一性，循环取数据：模拟 3 用户并发登录账号，总共有 90 个账号，要求并发登录账号不相同，但数据可循环使用。

通过以上归纳，可以确信地说，以上三种类型基本上可以覆盖我们日常性能测试工作中的所有参数化场景。

在LoadRunner中是有一个集成的参数化模块，可以直接配置参数化策略。那在Locust要怎样实现该需求呢？

硬广

欢迎关注我的个人博客和微信公众号。

个人博客：http://debugtalk.com
微信公众号：DebugTalk

[LocustPlus 序] 漫谈服务端性能测试

debugtalk — Wed, 02 Nov 2016 20:48:10 +0800

最近因为工作原因，我又拾起了老本行，开始做 Web 性能测试。之前虽然做过三四年的性能测试，但是在博客和开源项目方面都没有什么输出，一直是一个很大的遗憾。因此，近期打算围绕服务端性能测试的话题，将自己在这方面的经历进行整理。并且，最近使用的性能测试工具 Locust 感觉挺不错的，只是其功能比较单薄，特别是在性能指标监控和测试报告图表方面比较缺失，因此也打算在 Locust 的基础上做二次开发，打造一款自己用得顺手的性能测试工具，暂且将其命名为 LocustPlus 吧。

http://debugtalk.com/post/locustplus-talk-about-performance-test/

打造心目中理想的自动化测试框架 (AppiumBooster)

debugtalk — Wed, 07 Sep 2016 15:32:01 +0800

做过自动化测试的人应该都会有这样一种体会，要写个自动化 demo 测试用例很容易，但是要真正将自动化测试落地，对成百上千的自动化测试用例实现较好的可复用性和可维护性就很难了。

基于这一痛点，我开发了AppiumBooster框架。顾名思义，AppiumBooster基于Appium实现，但更简单和易于使用；测试人员不用接触任何代码，就可以直接采用简洁优雅的方式来编写和维护自动化测试用例。

原型开发完毕后，我将其应用在当前所在团队的项目上，并在使用的过程中，按照自己心目中理想的自动化测试框架的模样对其进行迭代优化，最终打磨成了一个自己还算用得顺手的自动化测试框架。

本文便是对AppiumBooster的核心特性及其设计思想进行介绍。在内容组织上，本文的各个部分相对独立，大家可直接选择自己感兴趣的部分进行阅读。

原文链接：http://debugtalk.com/post/build-ideal-app-automation-test-framework/ 项目源码：https://github.com/debugtalk/AppiumBooster

Jenkins 的输出日志也可以变得色色的

debugtalk — Tue, 16 Aug 2016 19:26:47 +0800

在《使用 Jenkins 实现持续集成构建检查》一文中，写到了这么一段话：

在这里，我们还可以通过--disable_output_color 开关将输出日志的颜色关闭。之所以实现这么一个功能，是因为在 Jenkins 中本来也无法显示颜色，但是如果还将 Terminal 中有颜色的日志内容输出到 Jenkins 中，就会出现一些额外的字符，比较影响日志的美观。

非常感谢热心的读者，及时地为我纠正了这一点。事实上，当前在 Jenkins 中，是可以通过安装插件来实现在输出日志中显示颜色的。

这个插件就是AnsiColor。

安装 && 配置

安装的方式很简单，【Manage Jenkins】->【Manage Plugins】，搜索AnsiColor进行安装即可。

安装完成后，在 Jenkins Project 的Configure页面中，Build Environment栏目下会多出Color ANSI Console Output配置项，勾选后即可开启颜色输出配置。

在ANSI color map的列表选择框中，存在多个选项，默认情况下，选择xterm即可。

保存配置后，再次执行构建时，就可以在Console中看到颜色输出了。

效果图

使用xctool命令编译 iOS 应用时，在 Jenkins 的Console output中会看到和Terminal中一样的颜色效果。

补充说明

需要说明的是，在输出日志中显示颜色，依赖于输出的日志本身。也就是说，如果输出日志时并没有ANSI escape sequences，那么安装该插件后也没有任何作用，并不会凭空给日志加上颜色。

例如，如果采用xcodebuild命令编译 iOS 应用，那么输出日志就不会显示颜色。

说到这里，再简单介绍下ANSI escape sequences。

ANSI escape sequences

ANSI escape sequences，也叫ANSI escape codes，主要是用于对 Terminal 中的文本字符进行颜色的控制，包括字符背景颜色和字符颜色。

使用方式如下：

33[字符背景颜色;字符颜色m{String}33[0m

其中，33[字符背景颜色;字符颜色m是开始标识，33[0m是结束标识，{String}是原始文本内容。通过这种形式，就可以对输出的文本颜色进行控制。

具体地，字符颜色和字符背景颜色的编码如下：

字符颜色（foreground color）：30~37

30:黑
31:红
32:绿
33:黄
34:蓝色
35:紫色
36:深绿
37:白色

字符背景颜色（background color）：40~47

40:黑
41:深红
42:绿
43:黄色
44:蓝色
45:紫色
46:深绿
47:白色

需要说明的是，字符背景颜色和字符颜色并非必须同时设置，也可以只设置一项。

代码示例

掌握了以上概念后，我们就可以通过对打印日志的代码进行一点调整，然后就可以让输出的日志更加美观了。

以 Ruby 为例，在String基础类中添加一些展示颜色的方法。

class String
  # colorization
  def colorize(color_code)
    "\e[#{color_code}m#{self}\e[0m"
  end

  def red
    colorize(31)
  end

  def green
    colorize(32)
  end

  def yellow
    colorize(33)
  end
end

然后，我们在打印日志时就可以通过如下方式来控制日志的颜色了。

# 步骤执行正常，输出为绿色
step_action_desc += "    ...    ✓"
puts step_action_desc.green

# 步骤执行异常，输出为红色
step_action_desc += "    ...    ✖"
puts step_action_desc.red

展示效果如下图所示。

是不是好看多了？

原文链接：http://debugtalk.com/post/make-Jenkins-Console-Output-Colorful/

使用 Jenkins 实现持续集成构建检查

debugtalk — Sun, 14 Aug 2016 19:58:05 +0800

通过《使用 Jenkins 搭建 iOS/Android 持续集成打包平台》和《关于持续集成打包平台的 Jenkins 配置和构建脚本实现细节》两篇文章，我们已经在原理概念和实践操作两个层面掌握了如何搭建一个完整的持续集成打包平台。

不过，在实际使用过程中，发现有时候还会存在一个问题。研发同学提交新的代码后，Jenkins 端可以成功执行构建，并生成安装包；然而在将安装包安装至移动设备时，却发现有时候会出现无法成功安装，或者安装后出现启动闪退的情况。

为了及时发现该类问题，我们还需要对每次构建生成的安装包进行检查。本文便是对构建检查涉及到的方法进行介绍。

构建生成`.app`

为了降低问题的复杂度，我们可以选择在模拟器中运行构建生成的安装包。之前在《从 0 到 1 搭建移动 App 功能自动化测试平台（1）：模拟器中运行 iOS 应用》也讲解过，要在模拟器中运行 iOS 应用，需要在 Xcode 中编译时选择模拟器类型，并且编译生成的文件后缀为.app。

对应的，构建生成.app的命令如下：

# build .app file from source code
xcodebuild \    # xctool
  -workspace ${WORKSPACE_PATH} \
  -scheme ${SCHEME} \
  -configuration ${CONFIGURATION} \
  -sdk ${SDK} \
  -derivedDataPath ${OUTPUT_FOLDER}

xcodebuild/xctool参数说明：

-workspace：需要打包的 workspace，后面接的文件一定要是.xcworkspace结尾的；
-scheme：需要打包的 Scheme，一般与$project_name相同；
-sdk：区分 iphone device 和 Simulator，可通过xcodebuild -showsdks获取，例如iphonesimulator9.3。
-configuration：需要打包的配置文件，我们一般在项目中添加多个配置，适合不同的环境，Release/Debug；
-derivedDataPath：指定编译结果文件的存储路径；例如，指定-derivedDataPath build_outputs时，将在项目根目录下创建一个build_outputs文件夹，生成的.app文件将位于build_outputs/Build/Products/${CONFIGURATION}-iphoneos中。

同样地，这里也可以使用xctool代替xcodebuild。

这里使用到的命令和参数基本上和《关于持续集成打包平台的 Jenkins 配置和构建脚本实现细节》一文中的大致相同，唯一需要特别注意的是-sdk参数。因为是要在模拟器中运行，因此-sdk参数要设置为iphonesimulator，而非iphoneos。

命令成功执行后，就会在指定的${OUTPUT_FOLDER}目录中生成${SCHEME}.app文件，这也就是我们构建生成的产物。另外，熟悉iOS的同学都知道，.app文件其实是一个文件夹，为了实现更好的存储，我们也可以额外地再做一步操作，将.app文件夹压缩转换为.zip格式，而且 Appium 也是支持读取.zip格式的安装包的。

至此，适用于 iOS 模拟器运行的构建产物已准备就绪。这里涉及到的脚本实现已更新至【debugtalk/JenkinsTemplateForApp】。

实现构建检查

那要怎样对构建生成的产物进行检查呢？

最简单的方式，就是在 iOS 模拟器中运行构建生成的.app，并执行一组基本的自动化测试用例。在执行过程中，如果出现无法成功安装，或者安装成功后启动出现闪退，或者自动化测试用例执行失败等异常情况，则说明我们最新提交的代码存在问题，需要通知研发同学及时进行修复。

而这些实现方式，其实我在《从 0 到 1 搭建移动 App 功能自动化测试平台》系列文章中都已经进行了详细讲解，并形成了一套较为成熟的自动化测试框架，【debugtalk/AppiumBooster】。

在此基础上，我们无需再做其它工作，只需要按照debugtalk/AppiumBooster的要求在表格中编写一组基本的自动化测试用例，即可采用如下方式执行构建检查。

$ cd ${AppiumBooster_Folder}
$ ruby run.rb -p "${OUTPUT_FOLDER}/${SCHEME}.app.zip" --disable_output_color > test_result.log

在如上命令中，通过-p参数指定构建生成的安装包，然后就可以在 iOS 模拟器中运行事先编写好的自动化测试用例，从而实现构建检查。

在这里，我们还可以通过--disable_output_color开关将输出日志的颜色关闭。之所以实现这么一个功能，是因为在 Jenkins 中本来也无法显示颜色，但是如果还将 Terminal 中有颜色的日志内容输出到 Jenkins 中，就会出现一些额外的字符，比较影响日志的美观。

现在，我们已经分别实现了代码构建和构建检查这两个核心的操作环节，而要执行最终的持续集成，我们还需要做最后一项工作，即在 Jenkins 中将这两个环节串联起来。

Jenkins 配置

关于 Jenkins 的相关基础概念、实施流程和配置细节，我在之前的文章中已经讲解得非常详细了。在此我就只进行一点补充。

要实现在构建完成后再运行一些额外的脚本，例如我们的构建检查命令，需要使用到 Jenkins 的一个插件，Post-Build Script Plug-in。

安装完该插件后，在 Jenkins 配置界面的Post-build Actions栏目中，Add post-build action选项列表中就会多出Execute a set of scripts选项。选择该项后，会出现如下配置界面。

选择Execute shell后，会出现一个文本框，然后我们就可以将构建检查的命令填写到里面。

在这里我们用到了${AppiumBooster_Folder}参数，该参数也需要通过String Parameter来进行定义，用于指定AppiumBooster项目的路径。

最后，为了便于将执行自动化测试用例的日志和执行构建的日志分开，我们将执行自动化测试用例的日志写入到了test_result.log文件中。然后，在Archives build artifacts中就可以通过${AppiumBooster_Folder}/test_result.log将执行构建检查的日志收集起来，并展示到每次构建的页面中。

延续一贯的开箱即用原则，我将使用 Jenkins 实现持续集成构建检查涉及到的 Jenkins 配置也做成了一套模板，并更新到【debugtalk/JenkinsTemplateForApp】中了，供大家参考。

写在最后

至此，通过本系列的几篇文章，关于如何使用 Jenkins 实现移动 APP 持续集成的相关内容应该都已经覆盖得差不多了。

不过，由于我个人的近期工作主要集中在 iOS 部分，因此在讲解的过程中都是以 iOS 为主。后续在将工作重心移到 Android 部分后，我会再在DebugTalk的这几篇文章中更新 Android 部分的内容。

从 0 到 1 搭建移动 App 功能自动化测试平台 (4)：自动化测试代码⎡工程化⎦

debugtalk — Fri, 29 Jul 2016 09:46:28 +0800

在本系列的上一篇文章中，我通过系统登录这一典型功能点，演示了编写自动化测试脚本的整个流程，并对测试脚本进行了初步优化。

在本文中，我将重点介绍如何对自动化测试脚本实现⎡工程化⎦的组织和管理。

测试脚本⎡工程化⎦

首先说下什么是测试脚本的工程化。

通过之前的工作，我们已经可以让单个自动化测试用例正常运行起来了。然而，这还只算是一个demo，一切才刚刚开始。

试想，一个项目的自动化测试用例少则数百，多则成千上万。如何将这些自动化测试用例组织起来？如何实现更好的可重用机制？如何实现更好的可拓展机制？这些都还是我们当前的 demo 所不具备的，也是我们需要通过“工程化”手段进行改造的原因。

引入 Minitest/RSpec

在 Ruby 中，说到测试首先就会想到 Minitest 或 RSpec，这是 Ruby 中用的最多的两个测试框架。通过这些框架，我们可以很好地实现对 Ruby 测试用例的管理。

同样地，由于我们的自动化测试脚本是采用 Ruby 编写的，因此我们也可以使用 Minitest/RSpec 来管理我们的自动化测试用例。

基于该想法，我们采用 RSpec 对之前的系统登录测试用例进行工程结构初始化。对于熟悉 Ruby 编程，或者有一定代码基础的同学而言，很自然地，可以将测试用例框架初始化为如下结构。

├── Gemfile
├── android
│   └── appium.txt
├── common
│   ├── requires.rb
│   └── spec_helper.rb
└── ios
    ├── appium.txt
    └── spec
        └── login_spec.rb

在Gemfile中，指定了项目依赖的库。

# filename: Gemfile
source 'https://gems.ruby-china.org'

gem 'rspec'
gem 'appium_lib'
gem 'appium_console'

在common/spec_helper.rb中，定义了模拟器和 RSpec 初始化相关的代码。

# filename: common/spec_helper.rb

def setup_driver
  return if $driver
  appium_txt = File.join(Dir.pwd, 'ios', 'appium.txt')
  caps = Appium.load_appium_txt file: appium_txt
  Appium::Driver.new caps
end

def promote_methods
  Appium.promote_appium_methods RSpec::Core::ExampleGroup
end

setup_driver
promote_methods

RSpec.configure do |config|

  config.before(:each) do
    $driver.start_driver
    wait { alert_accept }
  end

  config.after(:each) do
    driver_quit
  end

end

在common/requires.rb中，实现了对相关库文件的引用。

# filename: common/requires.rb

# load lib
require 'rspec'
require 'appium_lib'

# setup rspec
require_relative 'spec_helper'

在ios/appium.txt中，对 iOS 模拟器信息和测试包路径进行了配置。

[caps]
platformName = "ios"
deviceName = "iPhone 6s"
platformVersion = "9.3"
app = "/Users/Leo/MyProjects/AppiumBooster/ios/app/test.app"

在ios/spec/目录中，则是测试用例的内容。例如，ios/spec/login_spec.rb对应的就是系统登录的测试用例。

# filename: ios/spec/login_spec.rb
require_relative '../../common/requires'

describe 'Login' do

  it 'with valid account' do
    wait { id('btnMenuMyAccount').click }
    wait { id 'uiviewMyAccount' }

    wait { id('tablecellMyAccountLogin').click }
    wait { id 'uiviewLogIn' }

    wait { id('txtfieldEmailAddress').type 'leo.lee@dji.com' }
    wait { id('sectxtfieldPassword').type '123321' }
    wait { id('btnLogin').click }
    wait { id 'tablecellMyMessage' }
  end

end

通过以上代码结构初始化，我们的测试用例框架的雏形就形成了。接下来，在 Terminal 中切换到项目根目录，然后通过rspec ios命令就可以执行 ios 目录中的测试用例了。

➜ rspec ios
.

Finished in 2 minutes 7.2 seconds (files took 1.76 seconds to load)
1 example, 0 failures

完整的代码请参考debugtalk/AppiumBooster的1.FirstTest分支。

添加第二条测试用例

现在，我们尝试往当前的测试框架中添加第二条测试用例。

例如，第二条测试用例要实现启动后从当前地区切换至中国。那么，就可以新增ios/spec/change_country_spec.rb。

# filename: ios/spec/change_country_spec.rb
require_relative '../../common/requires'

describe 'Change country' do

  it 'from Hong Kong to China' do
    wait { id('btnMenuMyAccount').click }
    wait { id 'uiviewMyAccount' }

    wait { id('tablecellMyAccountSystemSettings').click }
    wait { id 'txtCountryDistrict' }

    wait { id('txtCountryDistrict').click }
    wait { id 'uiviewSelectCountry' }

    wait { id('tablecellSelectCN').click }

    wait { id('btnArrowLeft').click }
    wait { id 'uiviewMyAccount' }
  end

end

完整的代码请参考debugtalk/AppiumBooster的2.SecondTest分支。

现在我们凝视已经添加的两个测试用例，有发现什么问题么？

是的，重复代码太多。在每一步操作中，都要用id来定位控件，还要用wait来实现等待机制。

除此之外，当前代码最大的问题就是测试用例与控件映射杂糅在一起。造成的后果就是，不管是控件映射发生变动，还是测试用例需要修改，都要来修改这一份代码，维护难度较大。

重构：测试用例与控件映射分离

基于以上问题，我们首要的改造任务就是将测试用例与控件映射进行分离。

考虑到常用的控件操作方法就只有几个（click，type），因此我们可以将控件操作方法单独封装为一个模块，作为公共模块。

module Actions

  def click
    wait { @found_cell.click }
  end

  def type(text)
    wait { @found_cell.type text }
  end

end

然后，将 APP 中每一个页面封装为一个模块（module），将页面中的控件映射为模块的静态方法（method），并通过include机制引入方法模块。

例如，登录页面就可以封装为如下代码。

module Pages
  module Login
    class << self

      include Actions

      def field_Email_Address
        @found_cell = wait { id 'txtfieldEmailAddress' }
        self
      end

      def field_Password
        @found_cell = wait { id 'sectxtfieldPassword' }
        self
      end

      def button_Login
        @found_cell = wait { id 'btnLogin' }
        self
      end

    end
  end
end

module Kernel
  def login
    Pages::Login
  end
end

这里还用到了一点 Ruby 元编程技巧，就是将页面模块封装为一个方法，并加入到Kernel模块下。这样做的好处就是，我们可以在项目的任意地方直接通过login.button_Login.click这样的形式来对控件进行操作了。

完成以上改造后，系统登录测试用例就可以采用如下形式进行编写了。

describe 'Login' do

  it 'with valid account' do
    # switch to My Account page
    my_account.button_My_Account.click
    inner_screen.has_control 'uiviewMyAccount'

    # enter login page
    my_account.button_Login.click
    inner_screen.has_control 'uiviewLogIn'

    # login
    login.field_Email_Address.type 'leo.lee@dji.com'
    login.field_Password.type '123321'
    login.button_Login.click
    inner_screen.has_control 'tablecellMyMessage'
  end

end

完整的代码请参考debugtalk/AppiumBooster的3.RefactorV1分支。

To be continued ...

经过这一轮重构，我们的测试用例与控件映射已经实现了分离，测试用例的可重用性与可扩展性也得到了极大的提升。

然而，在当前模式下，所有的测试用例仍然是以代码形式存在的，新增和修改测试用例时都需要到工程目录下编辑 Ruby 文件。

那有没有一种可能，我们只需要在表格中维护自动化测试用例（如下图），然后由代码来读取表格内容就可以自动执行测试呢？

是的，这就是我们对测试框架进行⎡工程化⎦改造的下一个形态，也就是AppiumBooster现在的样子。

在下一篇文章中，我们再进行详细探讨。

关于持续集成打包平台的 Jenkins 配置和构建脚本实现细节

debugtalk — Tue, 26 Jul 2016 21:29:45 +0800

在《使用 Jenkins 搭建 iOS/Android 持续集成打包平台》一文中，我对如何使用 Jenkins 搭建 iOS/Android 持续集成打包平台的基础概念和实施流程进行了介绍。本文作为配套，对搭建持续集成打包平台中涉及到的执行命令、构建脚本（build.py），以及 Jenkins 的配置进行详细的补充说明。

当然，如果你不关心技术实现细节，也可以完全不用理会，直接参照【开箱即用】部分按照步骤进行操作即可。

关于 iOS 的构建

对 iOS 源码进行构建，目标是要生成.ipa文件，即 iOS 应用安装包。

当前，构建方式主要包括两种：

源码 -> .archive文件 -> .ipa文件
源码 -> .app文件 -> .ipa文件

这两种方式的主要差异是生成的中间产物不同，对应的，两种构建方式采用的命令也不同。

`源码` -> `.archive` -> `.ipa`

# build archive file from source code
xcodebuild \    # xctool
  -workspace ${WORKSPACE_PATH} \
  -scheme ${SCHEME} \
  -configuration ${CONFIGURATION} \
  -sdk ${SDK}
  archive -archivePath ${archive_path}

archive：打包命令，会生成一个.xcarchive的文件；archive 命令需要接一个参数-archivePath，即存放 Archive 文件的目录

# export ipa file from .archive
xcodebuild -exportArchive \
  -exportFormat format \
  -archivePath xcarchivepath \
  -exportPath destinationpath \
  -exportProvisioningProfile profilename \
  [-exportSigningIdentity identityname]
  [-exportInstallerIdentity identityname]

`源码` -> `.app` -> `.ipa`

# build .app file from source code
xcodebuild \    # xctool
  -workspace ${WORKSPACE_PATH} \
  -scheme ${SCHEME} \
  -configuration ${CONFIGURATION} \
  -sdk ${SDK}
  -derivedDataPath build

# convert .app file to ipa file
xcrun \
  -sdk iphoneos \
  PackageApplication \
  -v build/Release-iphoneos/xxx.app \
  -o build/Release-iphoneos/xxx.ipa

参数说明

xcodebuild/xctool参数：

-workspace：需要打包的 workspace，后面接的文件一定要是.xcworkspace结尾的；
-scheme：需要打包的 Scheme，一般与$project_name相同；
-sdk：区分 iphone device 和 Simulator；
-configuration：需要打包的配置文件，我们一般在项目中添加多个配置，适合不同的环境，Release/Debug；
-derivedDataPath：指定编译结果文件的存储路径；例如，指定-derivedDataPath build时，将在项目根目录下创建一个build文件夹，生成的.app文件将位于build/Build/Products/Release-iphoneos中。

除了采用官方的xcodebuild命令，还可以使用由 Facebook 开发维护的xctool。xctool命令的使用方法基本与xcodebuild一致，但是输出的日志会清晰很多，而且还有许多其它优化，详情请参考xctool的官方文档。

xcrun 参数：

-v：指定.app文件的路径
-o：指定生成.ipa文件的路径

补充说明

1、获取 Targets、Schemes、Configurations 参数

在填写target/workspace/scheme/configuration等参数时，如果不知道该怎么填写，可以在项目根目录下执行xcodebuild -list命令，它会列出当前项目的所有可选参数。

➜  Store_iOS git:(NPED) ✗ xcodebuild -list
Information about project "Store":
    Targets:
        Store
        StoreCI

    Build Configurations:
        Debug
        Release

    If no build configuration is specified and -scheme is not passed then "Release" is used.

    Schemes:
        Store
        StoreCI

2、清除缓存文件

在每次 build 之后，工程目录下会遗留一些缓存文件，以便下次 build 时减少编译时间。然而，若因为工程配置错误等问题造成编译失败后，下次再编译时就可能会受到缓存的影响。

因此，在持续集成构建脚本中，比较好的做法是在每次 build 之前都清理一下上一次编译遗留的缓存文件。

# clean before build
xctool \
  -workspace ${WORKSPACE_PATH} \
  -scheme ${SCHEME} \
  -configuration ${CONFIGURATION} \
  clean

clean：清除编译产生的问题，下次编译就是全新的编译了

3、处理 Cocoapod 依赖库

另外一个需要注意的是，若项目是采用 Cocoapod 管理项目依赖，每次拉取最新代码后直接编译可能会报错。这往往是因为其他同事更新了依赖库（新增了第三方库或升级了某些库），而本地还采用之前的第三方库进行编译，从而会出现依赖库缺失或版本不匹配等问题。

应对的做法是，在每次 build 之前都更新一下 Cocoapod。

# Update pod repository
pod repo update
# Install pod dependencies
pod install

4、修改编译包的版本号

通过持续集成打包，我们会得到大量的安装包。为了便于区分，比较好的做法是在 App 中显示版本号，并将版本号与 Jenkins 的BUILD_NUMBER关联起来。

例如，当前项目的主版本号为2.6.0，本次构建的BUILD_NUMBER为 130，那么我们就可以将本次构建的 App 版本号设置为2.6.0.130。通过这种方式，我们可以通过 App 中显示的版本号快速定位到具体到构建历史，从而对应到具体的代码提交记录。

要实现对 App 版本号的设置，只需要在打包前对Info.plist文件中的CFBundleVersion和CFBundleShortVersionString进行修改即可。在 Python 中，利用plistlib库可以很方便地实现对Info.plist文件的读写。

5、模拟器运行

如果持续集成测试是要运行在 iOS 模拟器上，那么就需要构建生成.app文件。

在前面讲解的两种构建方式中，中间产物都包含了.app文件。对于以.xcarchive为中间产物的方式，生成的.app文件位于output_dir/StoreCI_Release.xcarchive/Products/Applications/目录中。

不过，这个.app文件在模拟器中还无法直接运行，还需要在 Xcode 中修改Supported Platforms，例如，将iphoneos更改为iOS。详细原因请参考《从 0 到 1 搭建移动 App 功能自动化测试平台（1）：模拟器中运行 iOS 应用》

关于 Android 的构建

待续

关于构建脚本

对于构建脚本（build.py）本身，源码应该是最好的说明文档。

在build.py脚本中，主要实现的功能就四点：

执行构建命令，编译生成.ipa文件，这部分包含了关于iOS的构建部分的全部内容；
构建时动态修改Info.plist，将编译包的版本号与 Jenkins 的 BuildNumber 关联起来；
上传.ipa文件至pyger/fir.im平台，并且做了失败重试机制；
解析pyger/fir.im平台页面中的二维码，将二维码图片保存到本地。

需要说明的是，对于构建任务中常用的可配置参数，例如BRANCH/SCHEME/CONFIGURATION/OUTPUT_FOLDER等，需要在构建脚本中通过OptionParser的方式实现可传参数机制。这样我们不仅可以命令行中通过传参的方式灵活地调用构建脚本，也可以在 Jenkins 中实现参数传递。

之所以强调常用的可配置参数，这是为了尽可能减少参数数目，降低脚本调用的复杂度。像PROVISIONING_PROFILE和pgyer/fir.im账号这种比较固定的配置参数，就可以写死在脚本中。因此，在使用构建脚本（build.py）之前，需要先在脚本中配置下PROVISIONING_PROFILE和pgyer/fir.im账号。

另外还想多说一句，pyger/fir.im这类第三方平台在为我们提供便利的同时，稳定性不可控也是一个不得不考虑的问题。在我使用pgyer平台期间，就遇到了平台服务变动、接口时而不稳定出现 502 等问题。因此，最好的方式还是自行搭建一套类似的服务，反正我是打算这么做了。

Jenkins 的详细配置

对于 Jenkins 的详细配置，需要补充说明的有四点。

1、参数的传递

在构建脚本中，我们已经对常用的可配置参数实现了可传参机制。例如，在 Terminal 中可以通过如下形式调用构建脚本。

$ python build.py --scheme SCHEME --workspace Store.xcworkspace --configuration CONFIGURATION --output OUTPUT_FOLDER

那么我们在 Jenkins 中要怎样才能指定参数呢？

实际上，Jenkins 针对项目具有参数化的功能。在项目的配置选项中，勾选This project is parameterized后，就可以为当前 project 添加多种类型的参数，包括：

Boolean Parameter
Choice Parameter
Credentials Parameter
File Parameter
Multi-line String Parameter
Password Parameter
Run Parameter
String Parameter

通常，我们可以选择使用String Parameter来定义自定义参数，并可对每个参数设置默认值。

当我们配置了BRANCH、SCHEME、CONFIGURATION、OUTPUT_FOLDER、BUILD_VERSION这几个参数后，我们就可以在Build配置区域的Execute shell通过如下形式来进行参数传递。

$ python ${WORKSPACE}/Build_scripts/build.py \
    --scheme ${SCHEME} \
    --workspace ${WORKSPACE}/Store.xcworkspace \
    --configuration ${CONFIGURATION} \
    --output ${WORKSPACE}/${OUTPUT_FOLDER} \
    --build_version ${BUILD_VERSION}.${BUILD_NUMBER}

可以看出，参数的传递方式很简单，只需要预先定义好了自定义参数，然后就可以通过${Param}的形式来进行调用了。

不过你也许会问，WORKSPACE和BUILD_NUMBER这两个参数我们并未进行定义，为什么也能进行调用呢？这是因为 Jenkins 自带部分与项目相关的环境变量，例如BRANCH_NAME、JOB_NAME等，这部分参数可以在 shell 脚本中直接进行调用。完整的环境变量可在Jenkins_Url/env-vars.html/中查看。

配置完成后，就可以在Build with Parameters中通过如下形式手动触发构建。

2、修改 build 名称

在Build History列表中，构建任务的名称默认显示为按照 build 次数递增的BUILD_NUMBER。有时候我们可能想在 build 名称中包含更多的信息，例如包含当次构建的SCHEME和CONFIGURATION，这时我们就可以通过修改BuildName实现。

Jenkins 默认不支持BuildName设置，但可通过安装build-name-setter插件进行实现。安装build-name-setter插件后，在配置页面的Build Environment栏目下会出现Set Build Name配置项，然后在Build Name中就可以通过环境变量参数来设置 build 名称。

例如，要将 build 名称设置为上面截图中的StoreCI_Release_#130样式，就可以在Build Name中配置为${SCHEME}_${CONFIGURATION}_#${BUILD_NUMBER}。

除了在Build Name中传递环境变量参数，build-name-setter还可以实现许多更加强大的自定义功能，大家可自行探索。

3、展示二维码图片

然后再说下如何在Build History列表中展示每次构建对应的二维码图片。

需要说明的是，在上图中，绿色框对应的内容是BuildName，我们可以通过build-name-setter插件来实现自定义配置；但是红色框已经不在BuildName的范围之内，而是对应的BuildDescription。

同样地，Jenkins 默认不支持在构建过程中自动修改BuildDescription，需要通过安装description setter plugin插件来辅助实现。安装description setter plugin插件后，在配置页面的Build栏目下，Add build step中会出现Set build description配置项，添加该配置项后就会出现如下配置框。

该功能的强大之处在于，它可以在构建日志中通过正则表达式来匹配内容，并将匹配到的内容添加到BuildDescription中去。

例如，我们想要展示的二维码图片是在每次构建过程中生成的，因此我们首先要获取到二维码图片文件。

我的做法是，在build.py中将蒲公英平台返回的应用下载页面地址和二维码图片地址打印到 log 中。

appDownloadPage: https://www.pgyer.com/035aaf10acf5dd7c279c4fe423a57674
appQRCodeURL: https://o1wjx1evz.qnssl.com/app/qrcodeHistory/fe7a8c9051f0c7fc0affc78f40c20a4b5e4bdb4c77b91a29501f55fd9039c659
Save QRCode image to file: /Users/Leo/.jenkins/workspace/DJI_Plus_Store_iOS/build_outputs/QRCode.png

然后，在Set build description配置项的Regular expression就可以按照如下正则表达式进行匹配：

appDownloadPage: (.*)$

接下来，就可以在Description中对匹配到的结果进行引用。

<img src='${BUILD_URL}artifact/build_outputs/QRCode.png'>\n<a href='\1'>Install Online</a>

在这里，我们用到了 HTML 的标签，而 Jenkins 的Markup Formatter默认是采用Plain text模式，因此还需要对 Jenkins 对系统配置进行修改，在《使用 Jenkins 搭建 iOS/Android 持续集成打包平台》中已进行了详细说明，在此就不再重复。

通过以上方式，就可以实现前面图片中的效果。

4、收集编译成果物

在上面讲解的展示二维码图片一节中，用到了${BUILD_URL}artifact/build_outputs/QRCode.png一项，这里的 URL 就是用到了编译成果物收集后保存的路径。

Archives build artifacts是 Jenkins 默认自带的功能，无需安装插件。该功能在配置页面的Post-build Actions栏目下，在Add post-build action的列表中选择添加Archives build artifacts。

添加后的配置页面如下图所示：

通常，我们只需要配置Files to archive即可。定位文件时，可以通过正则表达式进行匹配，也可以调用项目的环境变量；多个文件通过逗号进行分隔。

例如，假如我们想收集QRCode.png、StoreCI_Release.ipa、Info.plist这三个文件，那么我们就可以通过如下表达式来进行指定。

${OUTPUT_FOLDER}/*.ipa,${OUTPUT_FOLDER}/QRCode.png,${OUTPUT_FOLDER}/*.xcarchive/Info.plist

当然，目标文件的具体位置是我们在构建脚本（build.py）中预先进行处理的。

通过这种方式，我们就可以实现在每次完成构建后将需要的文件收集起来进行存档，以便后续在 Jenkins 的任务页面中进行下载。

也可以直接通过归档文件的 URL 进行访问。例如，上图中QRCode.png的 URL 为Jenkins_Url/job/JenkinsJobName/131/artifact/build_outputs/QRCode.png，而Jenkins_Url/job/JenkinsJobName/131/即是${BUILD_URL}，因此可以直接通过${BUILD_URL}artifact/build_outputs/QRCode.png引用。

总结

至此，《使用 Jenkins 搭建 iOS/Android 持续集成打包平台》一文中涉及到的 Jenkins 配置和构建脚本实现细节均已补充完毕了。相信大家结合这两篇文章，应该会对如何使用 Jenkins 搭建 iOS/Android 持续集成打包平台的基础概念和实现细节都有一个比较清晰的认识。

对于还未完善的部分，我后续将在博客中进行更新。

操作手册请参考文章末尾的【开箱即用】部分，祝大家玩得愉快！

开箱即用

GitHub 地址：https://github.com/debugtalk/JenkinsTemplateForApp

1、添加构建脚本

在构建脚本中配置PROVISIONING_PROFILE和pgyer/fir.im账号；
在目标构建代码库的根目录中，创建Build_scripts文件夹，并将build.py拷贝到Build_scripts中；
将Build_scripts/build.py提交到项目中。

除了与 Jenkins 实现持续集成，构建脚本还可单独使用，使用方式如下：

$ python ${WORKSPACE}/Build_scripts/build.py \
    --scheme ${SCHEME} \
    --workspace ${WORKSPACE}/Store.xcworkspace \
    --configuration ${CONFIGURATION} \
    --output ${WORKSPACE}/${OUTPUT_FOLDER}

2、运行 jenkins，安装必备插件

$ nohup java -jar jenkins_located_path/jenkins.war &

3、创建 Jenkins Job

在 Jenkins 中创建一个Freestyle project类型的 Job，先不进行任何配置；
然后将config.xml文件拷贝到~/.jenkins/jobs/YourProject/中覆盖原有配置文件，重启 Jenkins；
完成配置文件替换和重启后，刚创建好的 Job 就已完成了大部分配置；
在Job Configure中根据项目实际情况调整配置，其中Git Repositories是必须修改的，其它配置项可选择性地进行调整。

4、done！

基于 Ruby 实现的移动 App 自动化测试框架

debugtalk — Thu, 21 Jul 2016 19:16:44 +0800

AppiumBooster

AppiumBooster helps you to write automation testcases in tables, without writing a snippet of code.

write testcases

You can write testcases in any table tools, including MS Excel and iWork Numbers, and even in plain CSV format.

Take DJI+ Discover's login and logout function as an example.

In order to test these functions above, you can write testcases in tables like this.

After the testcases are finished, export to CSV format, and put the csv files under ios/testcases/ directory.

That's all you need to do, and now you are ready to run automation test on your app.

run

Run the automation testcases is very easy. Just execute ruby run.rb in the project root directory.

➜  AppiumBooster git:(master) ✗ ruby run.rb

AppiumBooster will load all the csv test suites and then excute each suite sequentially.

➜  AppiumBooster git:(master) ✗ ruby run.rb
initialize appium driver ...
start appium driver ...
alert accepted!
======= start to run testcase suite: ./ios/testcases/Account-Login and Logout.csv =======
load csv testcase file: ./ios/testcases/Account-Login and Logout.csv ...
B------ Start to run testcase: Login with valid account
step_1: Enter My Account Page
control_element.click    ...    ✓
uiviewMyAccount exsits?    ...    ✓
step_2: Enter Login Page
control_element.click    ...    ✓
uiviewLogIn exsits?    ...    ✓
step_3: Input Email Address
control_element.type 'leo.lee@dji.com'    ...    ✓
step_4: Input Password
control_element.type '123456'    ...    ✓
step_5: Login
control_element.click    ...    ✓
tablecellMyMessage exsits?    ...    ✓
step_6: Check if coupon popup window exists
inner_screen.has_control 'btnViewMyCoupons'    ...    ✓
btnClose exsits?    ...    ✓
step_7: Close coupon popup window
control_element.click    ...    ✓
!btnClose no longer exsits?    ...    ✓
E------ Login with valid account

B------ Start to run testcase: Logout
step_1: Enter My Account Page
control_element.click    ...    ✓
uiviewMyAccount exsits?    ...    ✓
step_2: Enter System Settings
control_element.click    ...    ✓
btnLogout exsits?    ...    ✓
step_3: Click Logout
control_element.click    ...    ✓
Do you want to log out? exsits?    ...    ✓
step_4: Confirm logout alert
alert accepted!
alert_accept    ...    ✓
tablecellMyAccountLogin exsits?    ...    ✓
E------ Logout

============ all testcases have been executed. ============
quit appium driver.

Source Code

GitHub: http://debugtalk.com/post/Introduction-to-AppiumBooster/

使用 Jenkins 搭建 iOS/Android 持续集成打包平台 (附 GitHub，开箱即用)

debugtalk — Tue, 28 Jun 2016 16:50:10 +0800

背景描述

根据项目需求，现要在团队内部搭建一个统一的打包平台，实现对 iOS 和 Android 项目的打包。而且为了方便团队内部的测试包分发，希望在打包完成后能生成一个二维码，体验用户（产品、运营、测试等人员）通过手机扫描二维码后就能直接安装测试包。

该需求具有一定的普遍性，基本上所有开发 APP 的团队都可能会用到，因此我将整个需求实现的过程整理后形成此文，并且真正地做到了零基础上手，到手即飞、开箱即用，希望能对大家有所帮助。

首先，先给大家展示下平台建设完成后的整体效果：

该平台主要实现的功能有 3 点：

定期对 GitHub 仓库进行检测，若有更新则自动执行构建打包；
构建成功后根据 ipa/apk 生成二维码，并可在历史构建列表中展示各个版本的二维码，通过手机扫描二维码可直接安装对应版本；
在构建结果页面中展示当次构建的成果物（Artifact，如.ipa、.app、.apk、info.plist等文件），供有需要的用户进行下载。

接下来，本文就开始对平台建设的完整实现过程进行详细介绍。

安装 Jenkins

Jenkins 依赖于 Java 运行环境，因此需要首先安装Java。

安装 Jenkins 的方式有多种，可以运行对应系统类型的安装包，可以通过 docker 获取镜像，也可以直接运行war包。

我个人倾向于直接运行war包的形式，只需下载jenkins.war后，运行如下命令即可启动 Jenkins。

$ nohup java -jar jenkins_located_path/jenkins.war --httpPort=88 &

如果不指定httpPort，Jenkins 的默认端口为 8080。

Jenkins 插件

Jenkins 有非常多的插件，可以实现各种功能的扩展。

针对搭建的 iOS/Android 持续集成打包平台，我使用到了如下几个插件。

GIT plugin
SSH Credentials Plugin
Git Changelog Plugin: 获取仓库提交的 commit log
build-name-setter：用于修改 Build 名称
description setter plugin：用于在修改 Build 描述信息，在描述信息中增加显示 QRCode（二维码）
Post-Build Script Plug-in：在编译完成后通过执行脚本实现一些额外功能
Xcode integration: iOS 专用（可选）
Gradle plugin: Android 专用（可选）

安装方式也比较简单，直接在 Jenkins 的插件管理页面搜索上述插件，点击安装即可。

创建项目（Job）

在 Jenkins 中，构建项目以 Job 的形式存在，因此需要针对每个项目创建一个 Job。有时候，一个项目中可能有多个分支同时在进行开发，为了分别进行构建，也可以针对每个分支创建一个 Job。

创建 Job 的方式有多种，本次只需要创建Freestyle project类型的即可。

Main page -> New Item -> Freestyle project

对于一个持续集成打包平台，每次打包都由 4 步组成：触发构建、拉取代码、执行构建、构建后处理。对应的，在每个 Job 中也对应了这几项的配置。

配置 Git 代码仓库

要对项目进行构建，配置项目的代码仓库是必不可少的。由于当前我们的项目托管在 GitHub 私有仓库中，因此在此需要对Git进行配置。

在【Source Code Management】配置栏目下，如果之前GIT plugin安装成功，则会出现Git选项。

配置 Git 代码仓库时，有三项是必须配置的：仓库 URL 地址（Repository URL）、仓库权限校验方式（Credentials），以及当前 Job 需要构建的代码分支（Branches to build）。

在配置Repository URL时，选择HTTPS URL或SSH URL均可。不过需要注意的是，Credentials要和Repository URL对应，也就是说：

如果Repository URL是HTTPS URL形式的，那么Credentials就要采用 GitHub 用户名密码的校验方式；而且，如果在 GitHub 中开启了2FA（two-factor authentication），那么还需要在 GitHub 中创建一个Personal access token，输入密码时将这个Personal access token作为密码进行输入。
如果Repository URL是SSH URL形式的，那么就需要先在 Jenkins 所在的服务器上创建一个SSH秘钥对，并将公钥添加到 GitHub 的SSH keys中，然后在填写Credentials时，选择SSH Username with private key的校验方式，填入 GitHub Username、SSH 私钥、以及创建SSH秘钥对时设置的Passphrase。

如果对 Git 权限校验的概念还比较模糊，可以参考《深入浅出 Git 权限校验》。

在配置Branches to build时，可以采用多种形式，包括分支名称（branchName）、tagName、commitId等。其中分支名称的形式用的最多，例如，若是构建master分支，则填写refs/heads/master，若是构建develop分支，则填写refs/heads/develop。

除了以上关于 Git 的必填配置项，有时根据项目的实际情况，可能还需要对 Jenkins 的默认配置项进行修改。

比较常见的一种情况就是对clone的配置进行修改。

在 Jenkins 的默认配置中，clone代码时会拉取所有历史版本的代码，而且默认的超时时限只有 10 分钟。这就造成在某些项目中，由于代码量本身就比较大，历史版本也比较多，再加上网络环境不是特别好，Jenkins 根本没法在 10 分钟之内拉取完所有代码，超时后任务就会被自动终止了（错误状态码 143）。

这种问题的解决方式也很简单，无非就是两种思路，要么少拉取点代码（不获取历史版本），要么提高超时时限。对应的配置在Advanced clone behaviours中：

Shallow clone：勾选后不获取历史版本；
Timeout (in minutes) for clone and fetch operation：配置后覆盖默认的超时时限。

配置构建触发器

代码仓库配置好了，意味着 Jenkins 具有了访问 GitHub 代码仓库的权限，可以成功地拉取代码。

那 Jenkins 什么时候执行构建呢？

这就需要配置构建触发策略，即构建触发器，配置项位于【Build Triggers】栏目。

触发器支持多种类型，常用的有：

定期进行构建（Build periodically）
根据提交进行构建（Build when a change is pushed to GitHub）
定期检测代码更新，如有更新则进行构建（Poll SCM）

构建触发器的选择为复合选项，若选择多种类型，则任一类型满足构建条件时就会执行构建工作。如果所有类型都不选择，则该Jenkins Job不执行自动构建，但可通过手动点击【Build Now】触发构建。

关于定时器（Schedule）的格式，简述如下：

MINUTE HOUR DOM MONTH DOW

MINUTE: Minutes within the hour (0-59)
HOUR: The hour of the day (0-23)
DOM: The day of the month (1-31)
MONTH: The month (1-12)
DOW: The day of the week (0-7) where 0 and 7 are Sunday.

通常情况下需要指定多个值，这时可以采用如下 operator（优先级从上到下）：

*适配所有有效的值，若不指定某一项，则以*占位；
M-N适配值域范围，例如 7-9 代表 7/8/9 均满足；
M-N/X或*/X：以 X 作为间隔；
A,B,C：枚举多个值。

另外，为了避免多个任务在同一时刻同时触发构建，在指定时间段时可以配合使用H字符。添加H字符后，Jenkins 会在指定时间段内随机选择一个时间点作为起始时刻，然后加上设定的时间间隔，计算得到后续的时间点。直到下一个周期时，Jenkins 又会重新随机选择一个时间点作为起始时刻，依次类推。

为了便于理解，列举几个示例：

H/15 * * * *：代表每隔 15 分钟，并且开始时间不确定，这个小时可能是:07,:22,:37,:52，下一个小时就可能是:03,:18,:33,:48；
H(0-29)/10 * * * *：代表前半小时内每隔 10 分钟，并且开始时间不确定，这个小时可能是:04,:14,:24，下一个小时就可能是:09,:19,:29；
H 23 * * 1-5：工作日每晚 23:00 至 23:59 之间的某一时刻；

配置构建方式

触发策略配置好之后，Jenkins 就会按照设定的策略自动执行构建。但如何执行构建操作，这还需要我们通过配置构建方式来进行设定。

常用的构建方式是根据构建对象的具体类型，安装对应的插件，然后采用相应的构建方式。例如，若是构建Android应用，安装Gradle plugin之后，就可以选择Invoke Gradle script，然后采用Gradle进行构建；若是构建iOS应用，安装Xcode integration插件之后，就可以选择Xcode，然后选择Xcode进行构建。

该种方式的优势是操作简单，UI 可视化，在场景不复杂的情况下可以快速满足需求。不过缺点就是依赖于插件已有的功能，如果场景较复杂时可能单个插件还无法满足需求，需要再安装其它插件。而且，有些插件可能还存在一些问题，例如对某些操作系统版本或 XCode 版本兼容不佳，出现问题时我们就会比较被动。

我个人更倾向于另外一种方式，就是自己编写打包脚本，在脚本中自定义实现所有的构建功能，然后在Execute Shell中执行。这种方式的灵活度更高，各种场景的构建需求都能满足，出现问题后也能自行快速修复。

另外，对于 iOS 应用的构建，还有一个需要额外关注的点，就是开发者证书的配置。

如果是采用Xcode integration插件进行构建，配置会比较复杂，需要在 Jenkins 中导入开发证书，并填写多个配置项。不过，如果是采用打包脚本进行构建的话，情况就会简单许多。只要在 Jenkins 所运行的计算机中安装好开发者证书，打包命令在 Shell 中能正常工作，那么在 Jenkins 中执行打包脚本也不会有什么问题。

构建后处理

完成构建后，生成的编译成果物（ipa/apk）会位于指定的目录中。但是，如果要直接在手机中安装ipa/apk文件还比较麻烦，不仅在分发测试包时需要将好几十兆的安装包进行传送，体验用户在安装时也还需要通过数据线将手机与计算机进行连接，然后再使用 PP 助手或豌豆荚等工具进行安装。

当前比较优雅的一种方式是借助蒲公英（pgyer）或fir.im等平台，将ipa/apk文件上传至平台后由平台生成二维码，然后只需要对二维码链接进行分发，体验用户通过手机扫描二维码后即可实现快速安装，效率得到了极大的提升。

上传安装包文件，生成二维码

不管是蒲公英还是fir.im，都有对应的 Jenkins 插件，安装插件后可以在Post-build中实现对安装包的上传。

除了使用 Jenkins 插件，fir.im还支持命令上传的方式，蒲公英还支持HTTP Post接口上传的方式。

我个人推荐采用命令或接口上传的方法，并在构建脚本中进行调用。灵活是一方面，更大的好处是如果上传失败后还能进行重试，这在网络环境不是很稳定的情况下极其必要。

Jenkins 成功完成安装包上传后，pgyer/fir.im平台会生成一个二维码图片，并在响应中将图片的 URL 链接地址进行返回。

展示二维码图片

二维码图片的 URL 链接有了，那要怎样才能将二维码图片展示在 Jenkins 项目的历史构建列表中呢？

这里需要用到另外一个插件，description setter plugin。安装该插件后，在【Post-build Actions】栏目中会多出description setter功能，可以实现构建完成后设置当次 build 的描述信息。这个描述信息不仅会显示在 build 页面中，同时也会显示在历史构建列表中。

有了这个前提，要将二维码图片展示在历史构建列表中貌似就可以实现了，能直观想到的方式就是采用HTML的img标签，将<img url='qr_code_url'>写入到 build 描述信息中。

这个方法的思路是正确的，不过这么做以后并不会实现我们预期的效果。

这是因为 Jenkins 出于安全的考虑，所有描述信息的Markup Formatter默认都是采用Plain text模式，在这种模式下是不会对 build 描述信息中的 HTML 编码进行解析的。

要改变也很容易，Manage Jenkins -> Configure Global Security，将Markup Formatter的设置更改为Safe HTML即可。

更改配置后，我们就可以在 build 描述信息中采用HTML的img标签插入图片了。

另外还需要补充一个点。如果是使用蒲公英（pyger）平台，会发现每次上传安装包后返回的二维码图片是一个短链接，神奇的是这个短连接居然是固定的（对同一个账号而言）。这个短连接总是指向最近生成的二维码图片，但是对于二维码图片的唯一 URL 地址，平台并没有在响应中进行返回。在这种情况下，我们每次构建完成后保存二维码图片的 URL 链接就没有意义了。

应对的做法是，每次上传完安装包后，通过返回的二维码图片短链接将二维码图片下载并保存到本地，然后在 build 描述信息中引用该图片的 Jenkins 地址即可。

收集编译成果物（Artifacts）

每次完成构建后，编译生成的文件较多，但是并不是所有的文件都是我们需要的。

通常情况下，我们可能只需要其中的部分文件，例如.ipa/.app/.plist/.apk等，这时我们可以将这部分文件单独收集起来，并在构建页面中展示出来，以便在需要时进行下载。

要实现这样一个功能，需要在【Post-build Actions】栏目中新增Archive the artifacts，然后在Files to archive中通过正则表达式指定成果物文件的路径。

设置完毕后，每次构建完成后，Jenkins 会在Console Output中采用设定的正则表达式进行搜索匹配，如果能成功匹配到文件，则会将文件收集起来。

总结

本文主要是对如何使用 Jenkins 搭建 iOS/Android 持续集成打包平台的基础概念和实施流程进行了介绍。对于其中涉及到的执行命令、构建脚本（build.py），以及 Jenkins 的详细配置，出于篇幅长度和阅读体验的考虑，并没有在文中进行详细展开。

为了实现真正的开箱即用，我将 Jenkins 的配置文件和构建脚本抽离出来形成一套模板，只需要导入到 Jenkins 中，然后针对具体的项目修改少量配置信息，即可将这一套持续集成打包平台运行起来，实现和文章开头插图中完全相同的功能效果。

详细内容请阅读《关于持续集成打包平台的 Jenkins 配置和构建脚本实现细节》。

在 Jenkins 中安装什么插件能实现这个效果呢？

debugtalk — Tue, 21 Jun 2016 21:36:45 +0800

请问下，在 Jenkins 中安装什么插件能实现这个效果呢？

我试过Build Name Setter Plugin，通过 FILE 的形式设置 Build Name 后会产生乱码。

还请了解这个的多多指教。

深入浅出 Git 权限校验 (最熟悉的陌生概念)

debugtalk — Fri, 17 Jun 2016 09:48:59 +0800

借助上次“掉坑”的经历，我对 Git 权限校验的两种方式重头进行了梳理，形成了这篇总结记录。

在本地计算机与 GitHub（或 GitLab）进行通信时，传输主要基于两种协议，HTTPS和SSH，对应的仓库地址就是HTTPS URLs和SSH URLs。

首先需要强调的是，HTTPS URLs和SSH URLs对应的是两套完全独立的权限校验方式，主要的区别就是HTTPS URLs采用账号密码进行校验，SSH URLs采用SSH秘钥对进行校验。平时使用的时候我们可以根据实际情况，选择一种即可。

HTTPS URLs

GitHub 官方推荐采用HTTPS URLs的方式，因为该种方式适用面更广（即使在有防火墙或代理的情况下也同样适用），使用更方便（配置更简单）。

采用HTTPS URLs地址clone/fetch/pull/push仓库时，事先无需对本地系统进行任何配置，只需要输入 GitHub 的账号和密码即可。不过如果每次都要手动输入账号密码，也是一件很繁琐的事情。

好在已经有多个机制可以让操作不用这么麻烦。

在 Mac 系统中，在启用Keychain机制的情况下，首次输入 GitHub 账号密码后，认证信息就会自动保存到系统的Keychain中，下次再次访问仓库时就会自动读取Keychain中保存的认证信息。

在非 Mac 系统中，虽然没有Keychain机制，但是 Git 提供了credential helper机制，可以将账号密码以 cache 的形式在内存中缓存一段时间（默认 15 分钟），或者以文件的形式存储起来（~/.git-credentials）。当然，Mac 系统如果不启用Keychain机制，也可以采用这种方式。

# cache credential in memory
$ git config --global credential.helper cache
# store credential in ~/.git-credential
$ git config --global credential.helper store

在credential.helper设置为store的情况下，首次输入 GitHub 账号密码后，就会自动保存到~/.git-credentials文件中，保存形式为https://user:pass@github.com；下次再次访问仓库时就会自动读取~/.git-credentials中保存的认证信息。

另一个需要说明的情况是，如果在 GitHub 中开启了2FA（two-factor authentication），那么在本地系统中输入 GitHub 账号密码时，不能输入原始的密码（即 GitHub 网站的登录密码），而是需要事先在 GitHub 网站中创建一个Personal access token，后续在访问代码仓库需要进行权限校验的时候，采用access token作为密码进行输入。

SSH URLs

除了HTTPS URLs，还可以采用SSH URLs的方式访问 GitHub 代码仓库。

采用SSH URLs方式之前，需要先在本地计算机中生成SSH keypair（秘钥对，包括私钥和公钥）。默认情况下，生成的秘钥位于$HOME/.ssh/目录中，文件名称分别为id_rsa和id_rsa.pub，通常无需修改，保持默认即可。不过，如果一台计算机中存在多个秘钥对，就需要修改秘钥文件名，名称没有强制的命名规范，便于自己辨识即可。

如下是创建秘钥对的过程。

➜ ssh-keygen -t rsa -b 4096 -C "mail@debugtalk.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/Leo/.ssh/id_rsa): /Users/Leo/.ssh/debugtalk_id_rsa
Enter passphrase (empty for no passphrase): <myPassphrase>
Enter same passphrase again: <myPassphrase>
Your identification has been saved in /Users/Leo/.ssh/debugtalk_id_rsa.
Your public key has been saved in /Users/Leo/.ssh/debugtalk_id_rsa.pub.
The key fingerprint is:
SHA256:jCyEEKjlCU1klROnuBg+UH08GJ1u252rQMADdD9kYMo mail@debugtalk.com
The key's randomart image is:
+---[RSA 4096]----+
|+*BoBO+.         |
|o=oO=**          |
|++E.*+o.         |
|+ooo +o+         |
|.o. ..+oS. .     |
|  .  o. . o      |
|      .    .     |
|       .  .      |
|        ..       |
+----[SHA256]-----+

在创建秘钥的过程中，系统还建议创建一个名为passphrase的东西，这是用来干嘛的呢？

首先，单独采用密码肯定是不够安全的。如果密码太简单，那么就很容易被暴力破解，如果密码太复杂，那么用户就很难记忆，记录到小本子里面更不安全。

因此，SSH keys诞生了。SSH秘钥对的可靠性非常高，被暴力破解的可能性基本没有。不过，这要求用户非常谨慎地保管好私钥，如果别人使用你的计算机时偷偷地将你的私钥拷走了，那么就好比是别人拿到了你家里的钥匙，也能随时打开你家的门。

基于以上情况，解决办法就是在SSH keys之外再增加一个密码，即passphrase。只有同时具备SSH private key和passphrase的情况下，才能通过SSH的权限校验，这就大大地增加了安全性。当然，这个passphrase也不是必须的，在创建秘钥对时也可以不设置passphrase。

另外，如果每次权限校验时都要输入passphrase，这也是挺麻烦的。好在我们不用再担心这个问题，因为ssh-agent可以帮我们记住passphrase，Mac 系统的 Keychain 也可以记住passphrase，这样我们在同一台计算机中就不用重新输入密码了。

秘钥对创建好以后，私钥存放于本地计算机（~/.ssh/id_rsa），将公钥（~/.ssh/id_rsa.pub）中的内容添加至 GitHub 账户。

# copy the contents of id_rsa.pub to the clipboard
➜ pbcopy < ~/.ssh/id_rsa.pub

# paste to GitHub
# Login GitHub, 【Settings】->【SSH and GPG keys】->【New SSH Key】

不过，如果此时检测本地计算机与 GitHub 的连接状态，会发现系统仍提示权限校验失败。

➜ ssh -T git@github.com 
Permission denied (publickey).

这是因为在本地计算机与 GitHub 建立连接的时候，实际上是本机计算机的ssh-agent与 GitHub 服务器进行通信。虽然本地计算机有了私钥，但是ssh-agent并不知道私钥存储在哪儿。因此，要想正常使用秘钥对，需要先将私钥加入到本地计算机的ssh-agent中（添加过程中需要输入passphrase）。

# start ssh-agent in the background
➜ eval "$(ssh-agent -s)"
Agent pid 78370

➜ ssh-add ~/.ssh/id_rsa
Enter passphrase for /Users/Leo/.ssh/id_rsa: <myPassphrase>
Identity added: /Users/Leo/.ssh/id_rsa (/Users/Leo/.ssh/id_rsa)

添加完成后，就可以查看到当前计算机中存储的密钥。

➜ ssh-add -l                
4096 SHA256:xRg49AgTxxxxxxxx8q2SPPOfxxxxxxxxRlBY /Users/Leo/.ssh/id_rsa (RSA)

再次检测本地计算机与 GitHub 的连接状态，校验就正常通过了。

➜ ssh -T git@github.com
Hi djileolee! You've successfully authenticated, but GitHub does not provide shell access.

后续再进行clone/fetch/pull/push操作时，就可以正常访问 GitHub 代码仓库了，并且也不需要再重新输入账号密码。

而且，将私钥加入ssh-agent后，即使删除私钥文件，本地计算机仍可以正常访问 GitHub 代码仓库。

➜ rm -rf ~/.ssh
➜ ssh-add -l    
4096 SHA256:xRg49AgTxxxxxxxx8q2SPPOfxxxxxxxxRlBY /Users/Leo/.ssh/id_rsa (RSA)
➜ ssh -T git@github.com
The authenticity of host 'github.com (192.30.252.130)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,192.30.252.130' (RSA) to the list of known hosts.
Hi djileolee! You've successfully authenticated, but GitHub does not provide shell access.

只有执行ssh-add -D或ssh-add -d pub_key命令，将私钥从ssh-agent删除后，认证信息才会失效。

➜ ssh-add -d ~/.ssh/id_rsa.pub
Identity removed: /Users/Leo/.ssh/id_rsa.pub (mail@debugtalk.com)
➜ ssh-add -l
The agent has no identities.
➜ ssh -T git@github.com
Permission denied (publickey).

同时使用多个 GitHub 账号

熟悉了HTTPS URLs和SSH URLs这两种校验方式之后，我们再来看之前遇到的问题。要想在一台计算机上同时使用多个 GitHub 账号访问不同的仓库，需要怎么做呢？

为了更好地演示，现假设有两个 GitHub 账号，debugtalk和djileolee，在两个账号中各自有一个仓库，debugtalk/DroidMeter和DJIXY/MobileStore（公司私有库）。

前面已经说过，HTTPS URLs和SSH URLs对应着两套独立的权限校验方式，因此这两套方式应该是都能单独实现我们的需求的。

不过在详细讲解 Git 权限校验的问题之前，我们先来回顾下 Git 配置文件的优先级。

Git 配置存储位置及其优先级

Unix-like系统中，保存 Git 用户信息的主要有 3 个地方（Mac 系统多一个Keychain）：

/etc/gitconfig：存储当前系统所有用户的 git 配置信息，使用带有--system选项的git config时，配置信息会写入该文件；
~/.gitconfig或~/.config/git/config：存储当前用户的 git 配置信息，使用带有--global选项的git config时，配置信息会写入该文件；
Keychain Access：在开启Keychain机制的情况下，进行权限校验后会自动将账号密码保存至Keychain Access。
仓库的 Git 目录中的 config 文件（即repo/.git/config）：存储当前仓库的 git 配置信息，在仓库中使用带有--local选项的git config时，配置信息会写入该文件；

在优先级方面，以上 4 个配置项的优先级从上往下依次上升，即repo/.git/config的优先级最高，然后Keychain Access会覆盖~/.gitconfig中的配置，~/.gitconfig会覆盖/etc/gitconfig中的配置。

基于`SSH`协议实现多账号共存

先来看下如何采用SSH URLs实现我们的需求。

在处理多账号共存问题之前，两个账号均已分别创建SSH秘钥对，并且SSH-key均已加入本地计算机的ssh-agent。

➜ ssh-add -l
4096 SHA256:lqujbjkWM1xxxxxxxxxxG6ERK6DNYj9tXExxxxxx8ew /Users/Leo/.ssh/dji_id_rsa (RSA)
4096 SHA256:II2O9vZutdQr8xxxxxxxxxxD7EYvxxxxxxbynx2hHtg /Users/Leo/.ssh/id_rsa (RSA)

在详细讲解多账号共存的问题之前，我们先来回想下平时在 Terminal 中与 GitHub 仓库进行交互的场景。

➜  DroidMeter git:(master) git pull
Already up-to-date.
➜  DroidMeter git:(master) touch README.md
➜  DroidMeter git:(master) ✗ git add .
➜  DroidMeter git:(master) ✗ git commit -m "add README"
➜  DroidMeter git:(master) git push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 310 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@debugtalk:debugtalk/DroidMeter.git
   7df6839..68d085b  master -> master

在操作过程中，本地计算机的ssh-agent与 GitHub 服务器建立了连接，并进行了账号权限校验。

当本地计算机只有一个 GitHub 账号时，这个行为并不难理解，系统应该会采用这个唯一的 GitHub 账号进行操作。那如果本地计算机中有多个 Github 账号时，系统是根据什么来判断应该选择哪个账号呢？

实际情况是，系统没法进行判断。系统只会有一个默认的账号，然后采用这个默认的账号去操作所有的代码仓库，当账号与仓库不匹配时，就会报权限校验失败的错误。

那要怎样才能让系统正确区分账号呢？这就需要我们手动进行配置，配置文件即是~/.ssh/config。

创建~/.ssh/config文件，在其中填写如下内容。

# debugtalk
Host debugtalk
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa

# DJI
Host djileolee
    HostName github.com
    User git
    IdentityFile ~/.ssh/dji_id_rsa

要理解以上配置文件的含义并不难，我们可以对比看下两个项目的SSH URLs：

git@github.com:debugtalk/DroidMeter.git
git@github.com:DJISZ/Store_Android.git

其中，git是本地ssh-agent与 GitHub 服务器建立SSH连接采用的用户名（即User），github.com是 GitHub 服务器的主机（即HostName）。

可以看出，如果采用原始的SSH URLs，由于User和HostName都相同，本地计算机并不知道应该采用哪个SSH-key去建立连接。

因此，通过创建~/.ssh/config文件，在Host中进行区分，然后经过CNAME映射到HostName，然后分别指向不同的SSH-key，即IdentityFile。由于HostName才是真正指定 GitHub 服务器主机的字段，因此这么配置不会对本地ssh-agent连接 GitHub 主机产生影响，再加上Host别名指向了不同的SSH-key，从而实现了对两个 GitHub 账号的分离。

配置完毕后，两个 GitHub 账号就可以通过Host别名来进行区分了。后续再与 GitHub 服务器进行通信时，就可以采用Host别名代替原先的github.com。例如，测试本地ssh-agent与 GitHub 服务器的连通性时，可采用如下方式：

➜ ssh -T git@debugtalk 
Hi debugtalk! You have successfully authenticated, but GitHub does not provide shell access.
➜ ssh -T git@djileolee
Hi djileolee! You have successfully authenticated, but GitHub does not provide shell access.

可以看出，此时两个账号各司其职，不会再出现混淆的情况。

不过，我们还遗漏了很重要的一点。在本地代码仓库中执行push/pull/fetch等操作的时候，命令中并不会包含Host信息，那系统怎么知道我们要采用哪个 GitHub 账号进行操作呢？

答案是，系统还是没法判断，需要我们进行配置指定。

显然，不同的仓库可能对应着不同的 GitHub 账号，因此这个配置不能配置成全局的，而只能在各个项目中分别进行配置，即repo/.git/config文件。

配置的方式如下：

在debugtalk/DroidMeter仓库中：

➜ git remote add origin git@debugtalk:debugtalk/DroidMeter.git

在DJIXY/MobileStore.git仓库中：

➜ git remote add origin git@djileolee:DJIXY/MobileStore.git

配置的原理也很容易理解，就是将仓库的Host更换为之前设置的别名。添加完毕后，后续再在两个仓库中执行任何git操作时，系统就可以选择正确的SSH-key与 GitHub 服务器进行交互了。

基于`HTTPS`协议实现多账号共存

再来看下如何采用HTTPS URLs实现我们的需求。

有了前面的经验，我们的思路就清晰了许多。采用HTTPS URLs的方式进行 Git 权限校验后，系统会将 GitHub 账号密码存储到Keychain中（Mac 系统），或者存储到~/.git-credentials文件中（Git credential helper）。

不管是存储到哪里，我们面临的问题都是相同的，即如何在代码仓库中区分采用哪个 GitHub 账号。

配置的方式其实也很简单：

在debugtalk/DroidMeter仓库中：

➜ git remote add origin https://debugtalk@github.com/debugtalk/DroidMeter.git

在DJIXY/MobileStore.git仓库中：

➜ git remote add origin https://djileolee@github.com/DJIXY/MobileStore.git

配置的原理也很容易理解，将 GitHub 用户名添加到仓库的 Git 地址中，这样在执行 git 命令的时候，系统就会采用指定的 GitHub 用户名去Keychain或~/.git-credentials中寻找对应的认证信息，账号使用错乱的问题也就不复存在了。

Done!

GitHub 权限校验失败给我的启发

debugtalk — Wed, 15 Jun 2016 17:57:34 +0800

背景描述

众所周知，在 GitHub 中，每个仓库都有两个地址，分别基于HTTPS协议和SSH协议，两个协议对应的 URL 地址（repository_url）形式如下所示：

# HTTPS
https://github.com/DJIXY/MobileStore.git
# SSH
git@github.com:DJIXY/MobileStore.git

正常情况下，只要在本地正确地配置好了git账号，采用这两个地址中的任意一个，都可以通过git clone repository_url获取代码。

但最近我在 Macbook Air 中clone公司托管在 GitHub 私有库中的代码时，发现无法通过HTTPS协议的地址clone代码，始终提示remote: Repository not found.的错误。

➜ git clone https://github.com/DJIXY/MobileStore.git
Cloning into 'MobileStore'...
remote: Repository not found.
fatal: repository 'https://github.com/DJIXY/MobileStore.git/' not found

首先，这个代码仓库是确实存在的，而且地址肯定也是没有问题的，通过 URL 地址也能在浏览器中访问到对应的 GitHub 仓库页面。

其次，在本地对git的配置也是没有问题的，通过SSH协议的地址是可以正常clone代码的。

➜ git clone git@github.com:DJIXY/MobileStore.git
Cloning into 'MobileStore'...
Warning: Permanently added the RSA host key for IP address '192.30.252.131' to the list of known hosts.
remote: Counting objects: 355, done.
remote: Compressing objects: 100% (3/3), done.

并且，如果在HTTPS协议的 URL 地址中加上 GitHub 账号，也是可以正常clone代码的。

➜ git clone https://djileolee@github.com/DJIXY/MobileStore.git
Cloning into 'MobileStore'...
remote: Counting objects: 355, done.
remote: Compressing objects: 100% (3/3), done.

更奇怪的是，在我的另一台 Mac Mini 中，采用同样的账号配置，两种协议的 URL 地址却都能正常clone代码，仔细地对比了两台电脑的git配置，都是一样的。

➜ cat ~/.git-credentials
https://djileolee:340d247cxxxxxxxxf39556e38fe2b0baxxxxxxxx@github.com
➜
➜ cat ~/.gitconfig
[credential]
    helper = store

那问题出在哪儿呢？

定位分析

通过 Google 得知，产生remote: Repository not found.报错的原因主要有两个，一是仓库地址错误，二是权限校验不通过。显然，第一个原因可以直接排除，在 Macbook Air 中出现该问题应该就是账号权限校验失败造成的。

对背景描述中的现象进行整理，重点关注两个疑点：

通过HTTPS协议的 URL 地址进行git clone时，系统没有提示让输入用户名密码，就直接返回权限校验失败的异常；
在HTTPS协议的 URL 地址中加上 GitHub 用户名，就可以正常clone，而且，系统也没有提示输入密码。

这说明，在系统中的某个地方，应该是保存了 GitHub 账号密码的，所以在未指定账号的情况下，git clone时系统就不再要求用户输入账号密码，而是直接读取那个保存好的账号信息；但是，那个保存的 GitHub 账号密码应该是存在问题的，这就造成采用那个账号信息去 GitHub 校验时无法通过，从而返回异常报错。

基于以上推测，寻找问题根源的当务之急是找到保存 GitHub 账号密码的地方。

通过查看 Git 官方文档，存储 Git 用户信息的地方有三个：

/etc/gitconfig：存储当前系统所有用户的 git 配置信息；
~/.gitconfig或~/.config/git/config：存储当前用户的 git 配置信息；
仓库的 Git 目录中的 config 文件（即repo/.git/config）：存储当前仓库的 git 配置信息。

这三个配置项的优先级从上往下依次上升，即repo/.git/config会覆盖~/.gitconfig中的配置，~/.gitconfig会覆盖/etc/gitconfig中的配置。

回到当前问题，由于还没有进入到具体的 Git 仓库，因此repo/.git/config可直接排除；然后是查看当前用户的 git 配置，在当前用户 HOME 目录下没有~/.config/git/config文件，只有~/.gitconfig，不过在~/.gitconfig中并没有账号信息；再去查看系统级的 git 配置信息，即/etc/gitconfig文件，但发现当前系统中并没有该文件。

找遍了 Git 用户信息可能存储的地方，都没有看到账号配置信息，那还可能存储在哪儿呢？

这时基本上是毫无思路了，只能靠各种胡乱猜测，甚至尝试采用 Wireshark 分别在两台 Mac 上对git clone的过程进行抓包，对比通讯数据的差异，但都没有找到答案。

最后，无意中想到了 Mac 的Keychain机制。在 Mac OSX 的Keychain中，可以保存用户的账号密码等credentials，那 git 账号会不会也保存到Keychain中了呢？

在 Macbook Air 中打开Keychain Access应用软件，搜索github，果然发现存在记录。

而且，github.com这一项还存在两条记录。一条是我的个人账号debugtalk，另一条是公司的工作账号djileolee。

至此，真相大白！！！

在我的 Macbook Air 中，Keychain Access中保存了我的 GitHub 个人账号（debugtalk），该账号是没有权限访问公司私有仓库的。但是在 Terminal 中执行git clone命令时，系统优先读取了我的个人账号，并用该账号向 GitHub 发起校验请求，从而造成读取公司私有仓库时权限校验失败。然而，在HTTPS协议的 URL 地址中加上 GitHub 工作账号（djileolee）时，由于此时指定了账号名称，因此在Keychain中读取账号信息时就可以找到对应账号（包含密码），并且在无需输入密码的情况下就能成功通过 GitHub 的权限校验，进而成功clone得到代码。

原因弄清楚之后，解决方式就很简单了，在Keychain中删除个人账号，然后就正常了。

总结回顾

但是，问题真的解决了么？

并没有！

简单粗暴地在 Keychain 中将个人 GitHub 账号删除了，虽然再次访问公司代码仓库时正常了，那我要再访问个人仓库时该怎么办呢？

貌似并没有清晰的思路。虽然网上也有不少操作指导教程，但是对于操作背后的原理，还是有很多不清晰的地方。

再回到前面的背景描述，以及定位问题的整个过程，不由地悲从中来。使用 GitHub 好歹也有好几年了，但是连最基本的概念都还一头雾水，所以遇到问题后只能靠瞎猜，东碰西撞，最后瞎猫碰到死耗子。

GitHub 的HTTPS协议和SSH协议，这本来就对应着两套完全独立的权限校验方式，而我在HTTPS协议不正常的情况下还去查看SSH协议，这本来就实属多余。

借助这次“掉坑”的经历，我对Git权限校验的两种方式重头进行了梳理，并单独写了一篇博客，《深入浅出 Git 权限校验》，虽然花了些时间，但总算是扫清了萦绕多年的迷雾，感觉倍儿爽！

如果你也对Git的权限校验没有清晰的了解，遇到权限校验出错时只能“换一种方法试试”，也不知道怎么让一台计算机同时支持多个 GitHub 账号，那么也推荐看下那篇博客。

关于促销活动页面测试的那些事儿

debugtalk — Fri, 10 Jun 2016 14:43:04 +0800

这篇文章来说说促销活动页面测试的那些事儿。

什么是促销活动页面？

通常电商平台在节假日会做一些促销活动，而活动的宣传方式，主要会采用 H5 静态页面的形式，也就是本文中要讲的促销活动页面。

这些活动页面的特点是元素构成很简单，在页面中只包含一些促销商品的图片及其价格，而且价格往往都是写死在页面中，不会涉及到从数据库中读取，完完全全的静态页面；当然，促销活动页面的目的是将用户流量导向电商平台，因此在页面的图片或购买按钮背后会配上 URL 链接，用户点击链接后会跳转至电商平台对应的购买页面，活动页面也就完成了使命，这往往就是活动页面的全部内容。

这么看来，促销活动页面跟街上发的传单非常相似，只是传单是纸质的，而活动页面是网页的罢了。

促销活动页面为什么要这么做呢？

四方面原因。

第一，促销活动页面的目的性很强，就是为了主推几款特价商品，因此，商品和价格完全写死也不会有任何问题。

第二，促销活动页面的时效性很强，为促销活动而生，生命周期就那么几天，促销活动结束后这个活动页面也就作废了，因此也不用考虑复用的问题。

第三，从投入的人力成本和工作量考虑，促销活动页面的制作只需要设计师和前端工程师就能完成，无需后台开发人员进行配合，也无需对当前的电商平台进行任何功能调整。

第四，电商平台在做促销活动时，往往会通过各种渠道进行推广，因此活动页面的访问流量是非常巨大的；而采用静态页面的形式，不仅可以极大地提高页面加载速度（图片等静态资源可以通过 CDN 存储），而且可以极大地减轻流量对电商平台服务器端的压力（用户在浏览活动页面的时候并不会与电商平台进行任何交互）。至于点击链接进入电商平台的流量嘛，毕竟转换率总是存在的，转换以后的流量会小很多，而这部分流量才是真正有效的。

如何对活动页面进行测试

那么，就这么简单的一个静态页面，还需要对它进行测试么？

咋一看，貌似还真没有可测试的内容，因为页面中就找不到一个真正意义上的功能点。

然而，历史经验表明，在软件工程中无论多简单的功能，都是有可能出现 bug 的。针对活动页面的形式，我们需要重点关注如下几点。

1、商品信息一致性

促销活动页面中的商品信息都是由前端工程师写死的，而非从电商平台的数据库中读取后进行展示。因此，在实际操作中，活动页面上的信息，特别是价格数据，有可能和电商平台中的商品不一致，这个是我们在测试的时候需要重点关注的。

测试方式很简单，依次点击各个商品的链接，验证跳转的商品页面是否与促销活动页面中的商品信息一致即可。

2、页面跳转行为一致性

点击链接跳转页面，应该算是活动页面中唯一具有动作行为的功能了。而对于链接跳转而言，会存在两种形式，一种是在当前页面中加载商品页面，另一种是在新窗口中加载商品页面。

本来两种形式区别并不大，采用哪种形式都可以，但是从追求完美的角度出发，我们还是需要保证活动页面中的所有链接的跳转行为都是相同的。

因此，在测试时，逐一点击所有的链接，验证所有链接跳转行为是否一致即可。

3、页面兼容性

作为促销活动页面，虽然商品信息是最核心的内容，但是为了能吸引尽量多的用户，页面的设计往往花了很多功夫，力求精美。然而，用户访问活动页面的设备和浏览器五花八门，有可能是采用 PC 浏览器，有可能是采用 iPhone 设备，也可能是采用各种品牌和型号的 Android 设备，精心设计的活动页面在某些设备或浏览器上很有可能就出现样式混乱的情况。因此，促销活动页面的浏览器兼容性也是 z 在测试时需要重点关注的。

差异在哪儿呢？差异就是不同的浏览器内核，不同的设备操作系统，不同的屏幕分辨率。

当然，我们也不可能在所有类型的设备和浏览器上都测一遍，但是主流的浏览器内核和移动设备还是要尽量覆盖的。

推荐的测试方式如下：

针对不同浏览器内核的测试，在电脑上采用 Chrome、IE、Firefox、Safari 浏览器分别加载活动页面；
针对不同移动设备类型的测试，在 iPhone 和 Android 设备上加载活动页面，iPhone 和 Android 设备均只选一款即可；
针对不同屏幕分辨率的测试，可以在 PC 浏览器中打开开发者工具，里面可以模拟不同分辨率的设备加载页面，前面提到的浏览器基本都支持这个功能。

4、文案准确性

对于促销活动而言，吸引眼球的文案肯定是必不可少的，这也是在测试时需要重点关注的。

对于文案方面的测试，可以重点从以下几个方面进行考核。

首先，由于文案通常是由需求方提供，而活动页面是由设计师或前端工程师制作，因此有可能在制作页面的过程中出现了偏差，这个需要测试时仔细核对。

另外，文案中出现错别字的情况也比较多，这个也需要格外注意，尽量杜绝这样的低级错误。

还有一种情况，活动促销页面是面向某个国家的用户，语言可能是非汉语也非英语，这个时候周围谁也看不懂文案里面到底写的是啥。这个时候，只能请需求方再三进行确认，文案描述正确是一方面，另一方面就是需要考虑到目标国家的地域文化，不要出现产生歧义和误解的情况。

总结

以上内容便是从促销活动页面进行展开，联想到的关于测试的一些内容。

可以看出，即使是再简单的东西，也是需要进行测试的，而且测试需要考虑的因素也非常多。另一方面，这也说明测试并不应该仅仅局限于技术层面，只有当我们站在业务和质量保障的角度，才会有更开阔的视野。

从 0 到 1 搭建移动 App 功能自动化测试平台 (3)：编写 iOS 自动化测试脚本

debugtalk — Mon, 30 May 2016 19:20:23 +0800

通过前面三篇文章，我们已经将 iOS 自动化功能测试的开发环境全部准备就绪，也学习了 iOS UI 控件交互操作的一般性方法，接下来，就可以开始编写自动化测试脚本了。

在本文中，我将在 M 项目中挑选一个功能点，对其编写自动化测试脚本，演示编写自动化测试用例的整个流程。

语言的选择：Python or Ruby？

之前介绍 Appium 的时候也提到，Appium 采用 Client-Server 的架构设计，并采用标准的 HTTP 通信协议；Client 端基本上可以采用任意主流编程语言编写测试用例，包括但不限于 C#、Ruby、Objective-C、Java、node.js、Python、PHP。

因此，在开始编写自动化测试脚本之前，首先需要选定一门编程语言。

这个选择因人而异，并不涉及到太大的优劣之分，基本上在上述几门语言中选择自己最熟悉的就好。

但对我而言，选择却没有那么干脆，前段时间在 Python 和 Ruby 之间犹豫了很久，经过艰难的决定，最终选择了 Ruby。为什么不考虑 Java？不熟是一方面，另一方面是觉得采用编译型语言写测试用例总感觉太重，这活儿还是解释型语言来做更合适些。

其实，最开始本来是想选择 Python 的，因为 Python 在软件测试领域比 Ruby 应用得更广，至少在国内，不管是公司团队，还是测试人员群体，使用 Python 的会比使用 Ruby 的多很多。

那为什么还是选择了 Ruby 呢？

我主要是基于如下几点考虑的：

从 Appium 的官方文档来看，Appium 对 Ruby 的支持力度，或者说是偏爱程度，貌似会更大些；在Appium Client Libraries列表中将 Ruby 排在第一位就不说了，在Appium Tutorials中示例语言就只采用了 Ruby 和 Java 进行描述。
Appium_Console是采用 Ruby 编写的，在 Console 中执行的命令基本上可直接用在 Ruby 脚本中。
后续打算引入 BDD（行为驱动开发）的测试模式，而不管是 cucumber 还是 RSpec，都是采用 Ruby 开发的。

当然，还有最最重要的一点，身处于珠江三角洲最大的 Ruby 阵营，周围 Ruby 大牛云集，公司的好多业务系统也都是采用 Rails 作为后台语言，完全没理由不选择 Ruby 啊（测试用例还可以拉人一起写啊^_^）。

第一个测试用例：系统登录

在测试领域中，系统登录这个功能点的地位，堪比软件开发中的Hello World，因此第一个测试用例就毫无悬念地选择系统登录了。

在编写自动化测试脚本之前，我们首先需要清楚用例执行的路径，路径中操作涉及到的控件，以及被操作控件的属性信息。

对于本次演示的 APP 来说，登录时需要先进入【My Account】页面，然后点击【Login】进入登录页面，接着在登录页面中输入账号密码后再点击【Login】按钮，完成登录操作。

确定了操作路径以后，就可以在Appium Ruby Console中依次操作一遍，目的是确保代码能正确地对控件进行操作。

第一步要点击【My Account】按钮，因此先查看下 Button 控件属性。要是不确定目标控件的类型，可以直接执行page命令，然后在返回结果中根据控件名称进行查找。

[1] pry(main)> page :button
...（略）
UIAButton
   name, label: My Account
   id: My Account => My Account
nil

通过返回结果，可以看到【My Account】按钮的 name、label 属性就是“My Account”，因此可以通过button_exact('My Account')方式来定位控件，并进行点击操作。

[2] pry(main)> button_exact('My Account').click
nil

执行命令后，观察 iOS 模拟器中 APP 的响应情况，看是否成功进入“My Account”页面。

第二步也是类似的，操作代码如下：

[3] pry(main)> button_exact('Login').click
nil

进入到登录页面后，再次查看页面中的控件信息：

[4] pry(main)> page
...（略）
UIATextField
   value: Email Address
   id: Email Address => Email Address
UIASecureTextField
   value: Password (6-16 characters)
   id: Password (6-16 characters) => Password (6-16 characters)
UIAButton
   name, label: Login
   id: Log In => Login
       登录     => Login
...（略）

第三步需要填写账号密码，账号密码的控件属性分别是UIATextField和UIASecureTextField。由于这两个控件的类型在登录页面都是唯一的，因此可以采用控件的类型来进行定位，然后进行输入操作，代码如下：

[5] pry(main)> tag('UIATextField').type 'leo.lee@dji.com'
""
[6] pry(main)> tag('UIASecureTextField').type '123456'
""

执行完输入命令后，在 iOS 模拟器中可以看到账号密码输入框都成功输入了内容。

最后第四步点击【Login】按钮，操作上和第二步完全一致。

[7] pry(main)> button_exact('Login').click
nil

执行完以上四个步骤后，在 iOS 模拟器中看到成功完成账号登录操作，这说明我们的执行命令没有问题，可以用于编写自动化测试代码。整合起来，测试脚本就是下面这样。

button_exact('My Account').click
button_exact('Login').click
tag('UIATextField').type 'leo.lee@dji.com'
tag('UIASecureTextField').type '12345678'
button_exact('Login').click

将以上脚本保存为login.rb文件。

但当我们直接运行login.rb文件时，并不能运行成功。原因很简单，脚本中的button_exact、tag这些方法并没有定义，我们在文件中也没有引入相关库文件。

在上一篇文章中有介绍过，通过arc启动虚拟机时，会从appium.txt中读取虚拟机的配置信息。类似的，我们在脚本中执行自动化测试时，也会加载虚拟机，因此同样需要在脚本中指定虚拟机的配置信息，并初始化Appium Driver的实例。

初始化代码可以通过Appium Inspector生成，基本上为固定模式，我们暂时不用深究。

添加初始化部分的代码后，测试脚本如下所示。

require 'rubygems'
require 'appium_lib'

capabilities = {
    'appium-version' => '1.0',
    'platformName' => 'iOS',
    'platformVersion' => '9.3',
}
server_url = "http://0.0.0.0:4723/wd/hub"
Appium::Driver.new(caps: capabilities).start_driver
Appium.promote_appium_methods Object

# testcase: login
button_exact('My Account').click
button_exact('Login').click
tag('UIATextField').type 'leo.lee@dji.com'
tag('UIASecureTextField').type '123456'
button_exact('Login').click

driver_quit

优化测试脚本：加入等待机制

如上测试脚本编写好后，在 Terminal 中运行ruby login.rb，就可以执行脚本了。

运行命令后，会看到 iOS 虚拟机成功启动，接着 App 成功进行加载，然后自动按照前面设计的路径，执行系统登录流程。

但是，在实际操作过程中，发现有时候运行脚本时会出现找不到控件的异常，异常信息如下所示：

➜ ruby login.rb
/Library/Ruby/Gems/2.0.0/gems/appium_lib-8.0.2/lib/appium_lib/common/helper.rb:218:in `_no_such_element': An element could not be located on the page using the given search parameters. (Selenium::WebDriver::Error::NoSuchElementError)
    from /Library/Ruby/Gems/2.0.0/gems/appium_lib-8.0.2/lib/appium_lib/ios/helper.rb:578:in `ele_by_json'
    from /Library/Ruby/Gems/2.0.0/gems/appium_lib-8.0.2/lib/appium_lib/ios/helper.rb:367:in `ele_by_json_visible_exact'
    from /Library/Ruby/Gems/2.0.0/gems/appium_lib-8.0.2/lib/appium_lib/ios/element/button.rb:41:in `button_exact'
    from /Library/Ruby/Gems/2.0.0/gems/appium_lib-8.0.2/lib/appium_lib/driver.rb:226:in `rescue in block (4 levels) in promote_appium_methods'
    from /Library/Ruby/Gems/2.0.0/gems/appium_lib-8.0.2/lib/appium_lib/driver.rb:217:in `block (4 levels) in promote_appium_methods'
    from login.rb:28:in `<main>'

更奇怪的是，这个异常并不是稳定出现的，有时候能正常运行整个用例，但有时在某个步骤就会抛出找不到控件的异常。这是什么原因呢？为什么在Appium Ruby Console中单步操作时就不会出现这个问题，但是在执行脚本的时候就会偶尔出现异常呢？

原来，在我们之前的脚本中，两条命令之间并没有间隔时间，有可能前一条命令执行完后，模拟器中的应用还没有完成下一个页面的加载，下一条命令就又开始查找控件，然后由于找不到控件就抛出异常了。

这也是为什么我们在Appium Ruby Console中没有出现这样的问题。因为手工输入命令多少会有一些耗时，输入两条命令的间隔时间足够虚拟机中的 APP 完成下一页面的加载了。

那针对这种情况，我们要怎么修改测试脚本呢？难道要在每一行代码之间都添加休眠（sleep）函数么？

也不用这么麻烦，针对这类情况，ruby_lib实现了wait机制。将执行命令放入到wait{}中后，执行脚本时就会等待该命令执行完成后再去执行下一条命令。当然，等待也不是无休止的，如果等待 30 秒后还是没有执行完，仍然会抛出异常。

登录流程的测试脚本修改后如下所示（已省略初始化部分的代码）：

wait { button_exact('My Account').click }
wait { button_exact('Login').click }
wait { tag('UIATextField').type 'leo.lee@dji.com' }
wait { tag('UIASecureTextField').type '123456' }
wait { button_exact('Login').click }

对脚本添加wait机制后，之前出现的找不到控件的异常就不再出现了。

优化测试脚本：加入结果检测机制

然而，现在脚本仍然不够完善。

我们在Appium Ruby Console中手工执行命令后，都是由人工肉眼确认虚拟机中 APP 是否成功进入下一个页面，或者返回结果是否正确。

但是在执行自动化测试脚本时，我们不可能一直去盯着模拟器。因此，我们还需要在脚本中加入结果检测机制，通过脚本实现结果正确性的检测。

具体怎么做呢？

原理也很简单，只需要在下一个页面中，寻找一个在前一个页面中没有的控件。

例如，由 A 页面跳转至 B 页面，在 B 页面中会存在“Welcome”的文本控件，但是在 A 页面中是没有这个“Welcome”文本控件的；那么，我们就可以在脚本中的跳转页面语句之后，加入一条检测“Welcome”文本控件的语句；后续在执行测试脚本的时候，如果页面跳转失败，就会因为找不到控件而抛出异常，我们也能通过这个异常知道测试执行失败了。

当然，对下一页面中的控件进行检测时同样需要加入等待机制的。

登录流程的测试脚本修改后如下所示（已省略初始化部分的代码）：

wait { button_exact('My Account').click }
wait { text_exact 'System Settings' }

wait { button_exact('Login').click }
wait { button_exact 'Forget password?' }

wait { tag('UIATextField').type 'leo.lee@dji.com' }
wait { tag('UIASecureTextField').type '12345678' }
wait { button_exact('Login').click }
wait { text_exact 'My Message' }

至此，系统登录流程的自动化测试脚本我们就编写完成了。

To be continued ...

在本文中，我们通过系统登录这一典型功能点，演示了编写自动化测试用例的整个流程。

在下一篇文章中，我们还会对自动化测试脚本的结构进行进一步优化，并实现测试代码工程化。

从 0 到 1 搭建移动 App 功能自动化测试平台 (2)：操作 iOS 应用的控件

debugtalk — Sun, 29 May 2016 19:49:49 +0800

写在前面

前两天微信突然发来一条系统消息，提示DebugTalk可以开通原创标识了（同时也有了评论功能），虽然一直在期待，但没想到来得这么快，着实是个不小的惊喜。

另外，最近在公众号后台也收到好几个朋友的信息，有的是询问某某部分什么时候能发布，有的是希望能加快更新速度。说实话，收到这样的信息虽然会有压力，但真的挺开心的，因为这说明DebugTalk至少能给一部分人带去价值，这说明这件事本身还是值得坚持去做的。

不过，在更新频率这件事儿上，的确是要跟大家说抱歉了。因为DebugTalk发布的内容全都是原创，主题基本上都是来源于我日常测试工作的经验积累，或者我近期学习一些测试技术的收获总结，这也意味着，我写的东西很多时候并不是自己完全熟悉的（完全掌握的东西也没有足够的动力专门花时间去写）。

就拿最近连载的《从 0 到 1 搭建移动 App 功能自动化测试平台》系列来说，由于我也是边探索边总结，因此中途难免会遇到一些意想不到的坑，造成额外的耗时，而且为了保证文章能尽量通俗易通，我也需要对涉及到的内容充分进行理解，并且经过大量实践进行验证，然后才能站在半个初学者、半个过来人的角度，重新整理思路，最后以尽可能流畅的思路将主题内容讲解清楚。

基于这些原因，DebugTalk要做到每日更新是很难了，但是保证每周发布 1~2 篇还是可以的，希望大家能理解。

关于 UI 控件

在上一篇文章中，我们成功地通过 Appium Inspector 调用模拟器并运行 iOS 应用，iOS 的自动化测试环境也已全部准备就绪了。

那么接下来，我们就可以开始实现自动化测试了么？

貌似还不行。在开始之前，我们先想下什么是 APP 功能自动化测试。

APP 的功能自动化测试，简单地来说，就是让功能测试用例自动地在 APP 上执行。具体到每一个测试用例，就是能模拟用户行为对 UI 控件进行操作，自动化地实现一个功能点或者一个流程的操作。再细分到每一步，就是对 UI 控件进行操作。

因此，在正式开始编写自动化测试用例之前，我们还需要熟悉如何与 APP 的 UI 控件进行交互操作。

在 iOS 系统中，UI 控件有多种类型，常见的有按钮（UIAButton）、文本（UIAStaticText）、输入框（UIATextField）等等。但不管是对什么类型的 UI 控件进行操作，基本都可以分解为三步，首先是获取目标控件的属性信息，然后是对目标控件进行定位，最后是对定位到的控件执行动作。

获取 UI 控件信息

在 Appium 中，要获取 iOS 的 UI 控件元素信息，可以采用两种方式：一种是在前一篇文章中提到的 Appium Inspector，另一种是借助 Ruby 实现的appium_console，在 Terminal 中通过命令进行查询。

Appium Inspector

运行 Appium Server，并启动【Inspector】后，整体界面如下图所示。

现对照着这张图对 Appium Inspector 进行介绍。

在右边部分，是启动的模拟器，里面运行着我们的待测 APP。我们可以像在真机中一样，在模拟器中执行任意功能的操作，当然，模拟器跟真机毕竟还是有区别的，跟传感器相关的功能，例如摄像头、重力感应等，是没法实现的。

在左边部分，就是Appium Inspector。Inspector 主要由如下四个部分组成：

预览界面区：显示画面与模拟器界面一致；不过，当我们在模拟器中切换界面后，Inspector 的预览区中显示图像并不会自动同步，若要同步，需要点击【Refresh】按钮，然后 Inspector 会将模拟器当前 UI 信息 dump 后显示到预览区；在预览区中，可以点击选择任意 UI 控件。
UI 信息展示区：展示当前界面预览区中所有 UI 元素的层级关系和 UI 元素的详细信息；在预览区中点击选择任意 UI 控件后，在“Details”信息框中展示选中控件的详细信息，包括 name、label、value、xpath 等属性值；通过层级关系，我们也能了解选中控件在当前界面树状结构中所处的具体位置。
交互操作区：模拟用户在设备上的操作，例如单击（tap）、滑动（swipe）、晃动（shake）、输入（input）等；操作动作是针对预览界面区选中的控件，因此在操作之前，务必需要先在预览区点击选择 UI 元素。
脚本生成区：将用户行为转换为脚本代码；点击【Record】按钮后，会弹出代码区域；在交互操作区进行操作后，就会实时生成对应的脚本代码；代码语言可通过下拉框进行选择，当前支持的语言类型有：C#、Ruby、Objective-C、Java、node.js、Python。

在实践操作中，Inspector 最大的用途就是在可以可视化地查看 UI 元素信息，并且可以将操作转换为脚本代码，这对初学者尤为有用。

例如，在预览区点击选中按钮“BUY NOW”，然后在 UI 信息展示区的 Details 窗口就可以看到该按钮的所有属性信息。在交互操作区点击【Tap】按钮后，就会模拟用户点击“BUY NOW”按钮，并且在脚本区域生成当次按钮点击的脚本（选择 Ruby 语言）：

find_element(:name, "BUY NOW >").click

如上就是使用Appium Inspector的一般性流程。

Appium Ruby Console

有了Appium Inspector，为什么还需要Appium Ruby Console呢？

其实，Appium Ruby Console也并不是必须的。经过与多个熟悉Appium的前辈交流，他们也从未用过Appium Ruby Console，这说明Appium Ruby Console并不是必须的，没有它也不会影响我们对Appium的使用。

但是，这并不意味着Appium Ruby Console是多余的。经过这些天对Appium的摸索，我越发地喜欢上Appium Ruby Console，并且使用的频率越来越高，现在已基本上很少使用Appium Inspector了。这种感觉怎么说呢？Inspector相比于Ruby Conosle，就像是GUI相比于Linux Terminal，大家应该能体会了吧。

Appium Inspector的功能是很齐全，GUI 操作也很方便，但是，最大的问题就是使用的时候非常慢，在预览界面区切换一个页面常常需要好几秒，甚至数十秒，这是很难让人接受的。

在上一节中也说到了，Inspector 最大的用途就是在可以可视化地查看 UI 元素信息，并且可以将操作转换为脚本代码。但是当我们对Appium的常用 API 熟悉以后，我们就不再需要由工具来生成脚本，因为自己直接写会更快，前提是我们能知道目标控件的属性信息（type、name、label、value）。

在这种情况下，如果能有一种方式可以供我们快速查看当前屏幕的控件属性信息，那该有多好。

庆幸的是，在阅读Appium官方文档时，发现Appium的确是支持命令行方式的，这就是Appium Ruby Console。

Appium Ruby Console是采用 Ruby 语言开发的，在使用方式上面和 Ruby 的irb很类似。

在使用Appium Ruby Console时，虚拟机的配置信息并不会从 GUI 中读取，而是要通过配置文件进行指定。

配置文件的名称统一要求为appium.txt，内容形式如下所示：

[caps]
platformName = "ios"
platformVersion = '9.3',
app = "/path/to/UICatalog.app.zip"
deviceName = "iPhone Simulator"

其中，platformName指定虚拟机操作系统类型，“ios”或者"android"；platformVersion指定操作系统的版本，例如 iOS 的'9.3'，或者 Android 的'5.1'；app指定被测应用安装包的路径。这三个参数是必须的，与 Inspector 中的配置也能对应上。

在使用Appium Ruby Console时，首先需要启动Appium Server，通过GUI或者Terminal均可。

然后，在 Terminal 中，进入到appium.txt文件所在的目录，执行arc命令即可启动Appium Ruby Console。arc，即是 appium ruby console 首字母的组合。

➜ ls
appium.txt
➜ arc
[1] pry(main)>

接下来，就可以通过执行命令查询当前设备屏幕中的控件信息。

使用频率最高的一个命令是page，通过这个命令可以查看到当前屏幕中所有控件的基本信息。

例如，当屏幕停留在前面截图中的页面时，执行page命令可以得到如下内容。

[1] pry(main)> page
UIANavigationBar
   name: HomeView
   id: Home => Home
       米    => m
       去看看  => View
UIAButton
   name, label: tabbar category gray
UIAImage
   name: dji_logo.png
UIAButton
   name, label: tabbar cart gray
UIATableView
   value: rows 1 to 4 of 15
UIAPageIndicator
   value: page 2 of 2
UIATableCell
   name: For the first time ever in a hand held camera, the Osmo brings professional, realtime cinema-quality stabilization.
   id: 米 => m
UIAStaticText
   name, label, value: For the first time ever in a hand held camera, the Osmo brings professional, realtime cinema-quality stabilization.
   id: 米 => m
UIAStaticText
   name, label, value: OSMO
UIAButton
   name, label: SHOP NOW >
UIATableCell
   name: Ronin
UIAStaticText
   name, label, value: Ronin
UIAStaticText
   name, label, value: Phantom
   id: 米 => m
... (略)
UIAButton
   name, label: Store
   value: 1
   id: 门店 => Store
... (略)
UIAButton
   name, label: My Account
   id: My Account => My Account
nil

通过返回信息，我们就可以看到所有控件的 type、name、label、value 属性值。如果在某个控件下没有显示 label 或 value，这是因为这个值为空，我们可以不予理会。

由于page返回的信息太多，可能不便于查看，因此在使用page命令时，也可以指定控件的类型，相当于对当前屏幕的控件进行筛选，只返回指定类型的控件信息。

指定控件类型时，可以通过 string 类型进行指定（如 page "Image"），也可通过 symbol 类型进行指定（如 page :cell）。指定的类型可只填写部分内容，并且不分区大小写。

[2] pry(main)> page "Image"
UIAImage
   name: dji_logo.png
nil
[3] pry(main)> page :cell
UIATableCell
   name: DJI’s smartest flying camera ever.
   id: 米 => m
UIATableCell
   name: Ronin
UIATableCell
   name: Phantom
   id: 米 => m
nil

如果需要查看当前屏幕的所有控件类型，可以执行page_class命令进行查看。

[4] pry(main)> page_class
14x UIAButton
8x UIAStaticText
4x UIAElement
4x UIATableCell
2x UIAImage
2x UIAWindow
1x UIAPageIndicator
1x UIATableView
1x UIAStatusBar
1x UIANavigationBar
1x UIATabBar
1x UIAApplication
nil

基本上，page返回的控件信息已经足够满足绝大多数场景需求，但有时候情况比较特殊，需要enabled、xpath、visible、坐标等属性信息，这时就可以通过执行source命令。执行source命令后，就可以返回当前屏幕中所有控件的所有信息，以 xml 格式进行展现。

定位 UI 控件

获取到 UI 控件的属性信息后，就可以对控件进行定位了。

首先介绍下最通用的定位方式，find。通过find命令，可以实现在控件的诸多属性值（name、label、value、hint）中查找目标值。查询时不区分大小写，如果匹配结果有多个，则只返回第一个结果。

[5] pry(main)> find('osmo')
#<Selenium::WebDriver::Element:0x..febd52a30dcdfea32 id="2">
[6] pry(main)> find('osmo').label
"Osmo"

另一个通用的定位方式是find_element，它也可以实现对所有控件进行查找，但是相对于find，可以对属性类型进行指定。

[7] pry(main)> find_element(:class_name, 'UIATextField')
#<Selenium::WebDriver::Element:0x31d87e3848df8804 id="3">
[8] pry(main)> find_element(:class_name, 'UIATextField').value
"Email Address"

不过在实践中发现，采用find、find_element这类通用的定位方式并不好用，因为定位结果经常不是我们期望的。

经过反复摸索，我推荐根据目标控件的类型，选择对应的定位方式。总结起来，主要有以下三种方式。

针对 Button 类型的控件（UIAButton），采用button_exact进行定位：

[9] pry(main)> button_exact('Login')
#<Selenium::WebDriver::Element:0x..feaebd8302b6d77cc id="4">

针对 Text 类型的控件（UIAStaticText），采用text_exact进行定位：

[10] pry(main)> text_exact('Phantom')
#<Selenium::WebDriver::Element:0x1347e89100fdcee2 id="5">

针对控件类型进行定位时，采用tag；如下方式等价于find_element(:class_name, 'UIASecureTextField')。

[11] pry(main)> tag('UIASecureTextField')
#<Selenium::WebDriver::Element:0x..fc6f5efd05a82cdca id="6">

基本上，这三种方式就已经足够应付绝大多数测试场景了。当然，这三种方式只是我个人经过实践后选择的定位方式，除了这三种，Appium还支持很多种其它定位方式，大家可自行查看Appium官方文档进行选择。

另外，除了对控件进行定位，有时候我们还想判断当前屏幕中是否存在某个控件（通常用于结果检测判断），这要怎么做呢？

一种方式是借助于Appium的控件查找机制，即找不到控件时会抛出异常（Selenium::WebDriver::Error::NoSuchElementError）；反过来，当查找某个控件抛出异常时，则说明当前屏幕中不存在该控件。

[12] pry(main)> button_exact('Login_invalid')
Selenium::WebDriver::Error::NoSuchElementError: An element could not be located on the page using the given search parameters.
from /Library/Ruby/Gems/2.0.0/gems/appium_lib-8.0.2/lib/appium_lib/common/helper.rb:218:in `_no_such_element'

该种方式可行，但比较暴力，基本上不会采用这种方式。

另一种更好的方式是，查找当前屏幕中指定控件的个数，若个数不为零，则说明控件存在。具体操作上，将button_exact替换为buttons_exact，将text_exact替换为texts_exact。

[12] pry(main)> buttons_exact('Login').count
1
[13] pry(main)> buttons_exact('Login_invalid').count
0

除此之外，基于 Ruby 实现的appium_lib还支持exists方法，可直接返回 Boolean 值。

[14] pry(main)> exists { button_exact('Login') }
true
[15] pry(main)> exists { button_exact('Login_invalid') }
false

对控件执行操作

定位到具体的控件后，操作就比较容易了。

操作类型不多，最常用就是点击（click）和输入（type），这两个操作能覆盖 80% 以上的场景。

对于点击操作，才定位到的控件后面添加.click方法；对于输入操作，在定位到的输入框控件后面添加.type方法，并传入输入值。

例如，账号登录操作就包含输入和点击两种操作类型。

[16] pry(main)> find_element(:class_name, 'UIATextField').type 'leo.lee@dji.com'
""
[17] pry(main)> find_element(:class_name, 'UIASecureTextField').type '123456'
""
[18] pry(main)> button_exact('Login').click
nil

To be continued ...

在本文中，我们学习了对 iOS UI 控件进行交互操作的一般性方法，为编写自动化测试脚本打好了基础。

在下一篇文章中，我们就要正式开始针对 iOS 应用编写自动化测试脚本了。

从 0 到 1 搭建移动 App 功能自动化测试平台 (1)：模拟器中运行 iOS 应用

debugtalk — Sat, 21 May 2016 19:27:35 +0800

在上一篇文章中，我对本系列教程的项目背景进行了介绍，并对自动化测试平台的建设进行了规划。

在本文中，我将在已准备就绪的 iOS 自动化测试环境的基础上，通过 Appium 调用模拟器运行 iOS 应用。内容很是基础，熟悉的同学可直接略过。

iOS 应用安装包的基础知识

作为完全的 iOS 新手，困惑的第一个问题就是 iOS 安装包文件。

在 Android 系统中，安装 App 的途径很多，除了各类应用市场，普通用户也经常直接下载 apk 安装包文件后手动进行安装，因此大家对 Android 的安装包文件都比较熟悉。

但是对于 iOS 系统就不一样了，由于我们普通用户在 iOS 上安装应用的时候基本上只能通过 Apple Store 进行安装（未越狱），没有机会接触原始的安装包文件，因此往往连 iOS 应用的安装包到底是什么格式后缀都不清楚。

现在我们想在 Appium App 中通过模拟器运行被测应用，需要指定 iOS app 的安装包路径，因此需要首先获得一个 iOS app 安装包。

那么 iOS app 的安装包长啥样呢？

或者在这个问题之前，我们先来看下另一个问题：对于 iOS 设备来说，如果不通过 Apple Store，我们可以怎样安装一个应用？

针对这个问题，我搜了些资料，也请教了周围的同事，了解到的途径有如下几个：

企业证书：该种方式适用于企业内部；通过企业证书编译出的 iOS 应用，无需上传至 Apple Store，即可无限制的安装到企业员工的 iOS 设备中。只是需要解决的一个问题是，由于 iOS 设备没有文件管理器，没法将安装包拷贝到 iOS 设备中，因此常用的做法是将安装包（.ipa文件）上传至一些下载服务器（例如fir.im），并生成二维码，然后用户扫描二维码后即可通过浏览器下载安装包并进行安装。由此联想到另外一个方法，通过微信文件传输助手将安装包（.ipa）传输至 iOS 设备，然后再进行安装应该也是可以的吧？这种方法不知在原理上是否可行，因为在试验时由于安装包大于 30M，微信无法传输，所以没能进行验证。
Xcode：该种方式适用于 iOS 开发者；开发者在 Xcode 中连上 iOS 设备对源码进行编译，编译生成的应用会自动安装至 iOS 设备。当然，该种方式也是需要 iOS 开发者证书。
PP 助手：该种方式适用于普通用户；PP 助手是一个非苹果官方的设备资源管理工具，可以实现对未越狱的 iOS 设备进行应用管理，也可以安装本地.ipa文件，前提是.ipa文件具有合适的签名。

在上面列举的安装应用的途径中，反复提到了.ipa文件，那.ipa应该就是 iOS 应用程序的后缀了吧？暂且这么认为吧。

再回到前面的场景，要在 iOS 模拟器中运行 iOS 应用，我们是否可以找研发人员要一个.ipa安装包文件，然后就能在模拟器中加载运行应用呢？

刚开始的时候我是这么认为的。于是我获取到.ipa文件后，在App Path中填写该文件的路径，然后启动 Appium Server；接着我再打开 Inspector 时，发现 iOS 模拟器启动了，但是在应用启动的时候就出问题了，始终无法正常启动，感觉像是启动崩溃，反复尝试多次仍然如此。

再次经过 Google，总算是明白出现问题的原因了，总结下来有如下几点：

不管是从 Apple Store 或 iTunes 上下载的应用，还是在 Xcode 中针对真机设备编译生成的.ipa文件，都是面向于 ARM 处理器的 iOS 设备，只能在真机设备中进行安装；
而在 Mac OSX 系统中运行的 iOS 模拟器，运行环境是基于 Intel 处理器的；
因此，若是针对真机设备编译生成的.ipa文件，是无法在 iOS 模拟器中正常运行的，毕竟处理器架构都不一样；
要想在 iOS 模拟器中运行应用，则必须在 Xcode 中编译时选择模拟器类型；编译生成的文件后缀为.app。

准备`.app`文件

接下来，就说下如何获取.app文件。

虽然是测试人员，不会对被测 iOS 项目贡献代码，但是也不能总是找研发帮忙编译生成.app文件。所以，在本地搭建完整的 iOS 项目开发环境还是很有必要的。

对于 iOS 开发环境的搭建，当前社区中应该已经有了很多完整的教程，我在这儿就不详细描述了，只简单说下我搭建过程中涉及到的几个点。

首先，Mac OSX、Xcode、Apple Developer Tools 这些基础环境的安装，在上一篇文章中已经进行说明了；

然后，申请项目源码的访问权限，git clone到本地；

接着是项目依赖环境的问题；通常一个较大型的 iOS 项目都会引用许多第三方库，而这些依赖库并不会直接保存到项目仓库中，通常是采用CocoaPods进行管理；简单地说，CocoaPods是针对Swift和Objective-C项目的依赖管理器，类似于 Java 中的Maven，Ruby 中的Gem，Python 中的pip。

当然，iOS 项目的依赖管理工具也不是只有CocoaPods一个，如果是采用的别的依赖管理器，请自行查找对应的资料。

采用CocoaPods管理的项目，在项目根目录下会包含Podfile和Podfile.lock文件，里面记录了当前项目依赖的第三方库以及对应的版本号。

安装CocoaPods很简单，采用gem即可。

$ sudo gem install cocoapods

然后，进入到 iOS 项目的目录，执行pod install命令即可安装当前项目的所有依赖。

$ cd Project_Folder
$ pod install
Re-creating CocoaPods due to major version update.
Analyzing dependencies
.....（略）
Downloading dependencies
.....（略）
Generating Pods project
Integrating client project
Sending stats
Pod installation complete! There are 27 dependencies from the Podfile and 28 total pods installed.

关于CocoaPods的更多信息，请自行查看官方网站

在依赖安装完成后，正常情况下，就可以在 Xcode 中编译项目了。

没有别的需要注意的，将 target 选择为模拟器（iOS Simulator）即可。而且针对模拟器进行编译时，也不会涉及到开发者证书的问题，项目配置上会简单很多。待后续讲到真机上的自动化测试时，我再对证书方面的内容进行补充。

编译完成后，在 Products 目录下，就可以看到XXX.app文件，这里的XXX就是项目名称；然后，选中XXX.app文件，【Show in Finder】，即可在文件目录中定位到该文件。

接下来，将XXX.app文件拷贝出来，或者复制该文件的Full path，怎样都行，只要在Appium的App Path中能定位到该文件就行。

模拟器中运行 iOS 应用

被测应用.app准备就绪后，接下来就可以在 iOS 模拟器中运行了。

回到前面的那张图。启动Appium app后，对于模拟器运行的情况，在iOS Settings中必须设置的参数项就 3 个，App Path、Force Device和Platform Version。对于真机运行的情况，后续再单独进行说明。

设置完毕后，点击【Launch】，启动Appium Server。

然后，点击图中红框处的按钮，即可通过Inspector启动模拟器，并在模拟器中加载 iOS 应用。

在模拟器中，我们可以像在真机中一样，体验被测应用的各项功能；并且，在 Appium 的日志台中，可以实时查看到日志信息。

经历的一个坑

整个过程是挺简单的，不过，在探索过程中我还是有遇到一个坑。

通过Inspector启动模拟器时，总是弹框报错，报错形式如下。

刚开始出现这问题时百思不得其解，因为提示的信息并不明显，Google 了好一阵也没找到原因。最后只有详细去看日志信息，才发现问题所在。

在日志中，发现的报错信息如下：

[iOS] Error: Could not find a device to launch. You requested 'iPhone 6 (8.4)', but the available devices were: ["Apple TV 1080p (9.2) [98638D25-7C82-48DF-BDCA-7F682F951533] (Simulator)","iPad 2 (9.2) [5E22F53E-EAB3-45DF-A1DD-10F58E920679] (Simulator)","iPad 2 (9.3) [4B2D2F9A-C099-4C13-8DE9-27C826A521C2] (Simulator)","iPad Air (9.2) [825E4997-9CD8-4225-9977-4C7AE2C98389] (Simulator)","iPad Air (9.3) [E4523799-E35F-4499-832B-12CF33F09144] (Simulator)","iPad Air 2 (9.2) [8057039D-F848-453E-97EC-2F75CAEA2E77] (Simulator)","iPad Air 2 (9.3) [0B8F49DA-832A-4248-BA1D-9DA5D11E31FD] (Simulator)","iPad Pro (9.2) [AF1F2D06-3067-41B5-AC2B-4B0ED88BF5D9] (Simulator)","iPad Pro (9.3) [C39617A6-9D91-4C0B-B25B-741BD57B016C] (Simulator)","iPad Retina (9.2) [D3C694E1-E3B4-47BE-AB5E-80B3D4E22FC2] (Simulator)","iPad Retina (9.3) [907C7B06-ED2C-48AC-AC46-04E4AD6E0CA3] (Simulator)","iPhone 4s (9.2) [1A786195-94E3-4908-8309-7B66D84E4619] (Simulator)","iPhone 4s (9.3) [3F76F34B-5A8F-4FD1-928D-56F84C192DDD] (Simulator)","iPhone 5 (9.2) [0D79A4CA-71EB-48A6-9EE4-172BEF3EB4E0] (Simulator)","iPhone 5 (9.3) [04270D44-F831-4253-95F2-3D205D2BC0D9] (Simulator)","iPhone 5s (9.2) [13A16C07-3C5B-4B04-A94B-B40A63238958] (Simulator)","iPhone 5s (9.3) [D30A7B34-BA01-4203-80DA-FAEA436725F9] (Simulator)","iPhone 6 (9.2) [5D01650F-2A31-4D53-A47A-CCF7FD552ADD] (Simulator)","iPhone 6 (9.3) [2F0810F6-C73B-4BA4-93BA-06D4B6D96BDA] (Simulator)","iPhone 6 Plus (9.2) [9A840B78-E6CE-4D18-BE83-16B590411641] (Simulator)","iPhone 6 Plus (9.3) [27C6557A-B09D-4D8A-9846-DA8FE0A8E8D5] (Simulator)","iPhone 6s (9.2) [E7F5B8A5-0E85-404F-A4D4-191D63E7EC1B] (Simulator)","iPhone 6s (9.3) [6F702911-13C2-472C-9ECD-BADD4385CB77] (Simulator)","iPhone 6s (9.3) + Apple Watch - 38mm (2.2) [B63FFAA4-00A4-473B-9462-3664F41F9001] (Simulator)","iPhone 6s Plus (9.2) [58837F78-511A-4F0B-9DDF-782E3B9935BD] (Simulator)","iPhone 6s Plus (9.3) [C31003C6-DCE2-414D-AD7F-376F6FA995B0] (Simulator)","iPhone 6s Plus (9.3) + Apple Watch - 42mm (2.2) [E3154768-CA23-45CC-90E5-2D0386A57B7D] (Simulator)"]

问题在于，我设置iOS Settings时，将Force Device设置为"iPhone 6"，将Platform Version设置为“8.4”，但是经过组合，iPhone 6 (8.4)并不在可用的模拟器设备列表中。

再来看日志中提示的可用设备，发现“iPhone 6”设备对应的Platform Version只有“9.2”和“9.3”。然后回到iOS Settings，发现Platform Version的下拉框可选项就没有“9.2”和“9.3”，最新的一个可选版本也就是“8.4”。

这应该是Appium app的一个 bug 吧。不过好在Platform Version参数虽然是通过下拉框选择，但是也可以在框内直接填写内容。于是我在Platform Version设置框内填写为“9.3”，然后再次启动时，发现 iOS 模拟器就可以正常启动了。

To be continued ...

现在，我们已经成功地通过 Appium Inspector 调用模拟器并运行 iOS 应用，接下来，我们就要开始尝试编写自动化测试用例了。

在下一篇文章中，我们将对 Appium Inspector 的功能进行熟悉，通过 Inspector 来查看 iOS 应用的 UI 元素信息，并尝试采用脚本语言与 UI 进行交互操作。

从 0 到 1 搭建移动 App 功能自动化测试平台：(0) 背景介绍和平台规划

debugtalk — Fri, 20 May 2016 12:24:41 +0800

背景

最近新加入 DJI 的某项目组（以下均已 M 指代），需要从零开始搭建功能自动化测试平台。

简单地说，M 是一个典型的移动互联网产品，客户端包括 iOS 和 Android，并在 app 中通过 WebView 嵌入了 H5，后端基于 Ruby on Rails 实现。

当前阶段，M 项目除了 Rails Server 端采用 Jenkins+RSpec 实现了部分的持续集成功能外，客户端部分的部署和测试工作都还是完全依赖于手工操作。

基于当前项目的开发模式，我对整个 M 项目实现持续集成自动化测试的架构流程进行了规划，初步计划的架构图如下图所示。最终的目标是希望能实现：不管是 Rails Server，还是 App(iOS/Android)，以及 H5，当任意部分存在代码提交时，系统能自动拉取最新代码进行部署并执行自动化回归测试，及时地将执行情况反馈给开发人员。

目标确定后，便是分阶段进行实现，需要开发的模块包括：

自动化测试平台（Automated Test Platform）：满足 iOS/Android/H5 的自动化功能测试，包括模拟器和真机的测试；
测试管理平台（Test Management Platform）：实现自动化测试用例管理、手动下发测试任务、测试结果报表展现、Dashboard 等功能；
打包平台（Pack System）：实现 iOS/Android 的自动化构建；
服务端自动化测试（Rails）：将服务端 Rails 的自动化测试接入测试管理平台；
持续集成流程打通：对 Jenkins 进行二次开发，与测试管理平台打通，实现全流程的持续集成自动化测试。

而本系列教程，《从 0 到 1 搭建移动 App 功能自动化测试平台》，便是对整个实践过程的一个记录。

需要说明的是，之前我个人的工作经历主要在服务端性能测试、Android 客户端性能测试（测试开发）方向，对于客户端的自动化测试基本上没有经验积累，特别是 iOS 系统的测试，以前更是完全没有接触过。因此本系列教程只能算是个人在探索路上的学习总结和记录，可能会存在一些错误的观点，还请前辈们多多指教。

自动化测试框架的选择

在愿景图中，绿色方框（Automated Test Platform）负责移动应用客户端（iOS/Android/H5）自动化测试的调度和执行，是整个自动化测试平台的核心。

因此，在搭建自动化测试平台之前，首先需要选择一个合适的自动化测试框架。

对于移动应用的自动化测试框架，当前市面上已经有很多成熟的开源项目。针对当前项目的实际情况，我主要参考如下选择标准：

同时支持 iOS、Android、H5，且尽量能保持接口统一，减少开发维护成本；
编程语言支持 Python/Ruby；
用户量大，文档丰富。

经过筛选，Appium 无疑是最佳的选择。

Appium 简介

对于 Appium 的详细介绍，大家可参考Appium官方文档，我就不再重复引用。

不过对于 Appium，仍然有几点很赞的理念值得强调。

采用 Appium 时，无需对被测应用做任何修改，也无需嵌入任何东西；
Appium 对 iOS 和 Android 的原生自动化测试框架进行了封装，并提供了统一的 API（WebDriver API），减少了自动化测试代码的维护工作量；
Appium 采用 Client-Server 的架构设计，并采用标准的 HTTP 通信协议；Server 端负责与 iOS/Android 原生测试框架交互，无需测试人员关注细节实现；Client 端基本上可以采用任意主流编程语言编写测试用例，减少了学习成本。

环境准备（iOS）

在 Appium 中测试 iOS 时，依赖于 Apple 开发环境，因此，在运行 Appium 之前需要先确保如下环境安装正确。

Mac OS X >= 10.7
XCode >= 4.6.3
Apple Developer Tools (iPhone simulator SDK, command line tools)

如上几个环境安装比较简单，直接在 Apple Store 中安装即可。

在安装 Appium 之前，为了确保 Appium 的相关依赖已经准备就绪，可以使用appium-doctor来进行验证。

appium-doctor是一个用于验证 appium 安装环境的工具，可以诊断出Node/iOS/Android环境配置方面的常见问题。

appium-doctor采用node.js编写，采用npm即可在 Terminal 中进行安装：

$ npm install appium-doctor -g

安装完毕后，执行appium-doctor命令即可对Appium的环境依赖情况进行检测；指定--ios时只针对 iOS 环境配置进行检测，指定--android参数时只针对 Android 环境配置进行检测，若不指定则同时对 iOS 和 Android 环境进行检测。

$ appium-doctor --ios                                                                                                                               
info AppiumDoctor ### Diagnostic starting ###
info AppiumDoctor  ✔ Xcode is installed at: /Applications/Xcode.app/Contents/Developer
info AppiumDoctor  ✔ Xcode Command Line Tools are installed.
info AppiumDoctor  ✔ DevToolsSecurity is enabled.
info AppiumDoctor  ✔ The Authorization DB is set up properly.
info AppiumDoctor  ✔ The Node.js binary was found at: /usr/local/bin/node
info AppiumDoctor  ✔ HOME is set to: /Users/Leo
info AppiumDoctor ### Diagnostic completed, no fix needed. ###
info AppiumDoctor 
info AppiumDoctor Everything looks good, bye!
info AppiumDoctor

若检测结果全部通过，则说明 Appium 的相关依赖已经准备就绪，接下来可以继续安装 Appium。

安装 Appium

根据前面的介绍，Appium 采用 Client-Server 的架构设计，因此安装 Appium 时需要分别安装 Server 部分和 Client 部分。

通常情况下，我们说的 Appium 都是指代的 Server 部分。Appium 的安装有多种方式：可以通过源码编译安装，也可以在 Terminal 中通过npm命令安装，另一种是直接下载appium.dmg后安装应用程序。

在这里推荐运行Appium app的方式，除了 GUI 界面操作更直观以外，更重要的一个原因是，相比于命令行运行方式，Appium app多了一个Inspector模块，可以调用模拟器运行被测应用程序，并且可以很方便地在预览页面中查看 UI 元素的层级结构和详细控件属性，极大地提高编写测试脚本的效率。

至于 Client 部分，其实我们原本可以不安装任何东西，只需要任意选择一门开发语言，然后直接基于 WebDriver 的 C/S 协议（JSON Wire Protocol）即可编写自动化测试代码。但是这样做的话工作量会比较大，因为要去处理一些跟协议相关的工作。所幸 Appium 项目已经针对众多主流的编程语言，将底层协议处理相关的工作封装为 Library，通过调用这些 Library，可以极大地简化我们编写测试用例的工作量。

而说的需要安装的 Client 部分，其实也就是安装这些 Library。选定编写测试用例的语言后，我们就可以针对性地进行安装。

例如，如果选择 Ruby 语言，那么需要安装的 Library 就是appium_lib，安装方式如下：

$ gem install appium_lib

如果选择 Python 语言，那么需要安装的 Library 就是Appium-Python-Client，安装方式如下：

$ pip install Appium-Python-Client

对于其它编程语言，请自行参考官方文档。

To be continued ...

iOS 的自动化测试环境已基本准备就绪了，接下来我们想做的第一件事，就是在模拟器中运行 iOS 应用。

在下一篇文章中，我们将从 clone 项目源码为起点，编译生成 iOS app，在 Appium 中调用模拟器中运行 iOS app，并分享实践过程中遇到的一些坑。

Android App 持续集成性能测试：启动流量 (2)

debugtalk — Thu, 12 May 2016 21:07:00 +0800

在上一篇文章中，介绍了一种测试 Android App 启动流量的方法。当时也提到了，通过读取/proc/uid_stat/<UID>/目录下的tcp_rcv和tcp_snd文件，只能得到 App 的流量总值，无法得到更细化的数据。

例如，UC 浏览器国际版在启动后，会和美国的服务器进行通讯交互，如果我们想测试浏览器在启动后与美国服务器的通讯流量，要怎么实现呢？。

本文便是针对这类场景的测试需求，讲解如何采用tcpdump测试得到更细化的流量数据。

tcpdump

tcpdump，是一个在 Unix-like 系统中通用的网络抓包工具，当然，这个工具在 Android 系统中也是可以使用的。

对于工具本身，本文不做过多介绍。为了防止有读者之前完全没有tcpdump的使用经验，在这里我只简单地进行几点说明：

大多 Android 系统默认未集成 tcpdump 工具，我们需要事先将专门针对 Android 系统编译好的的 tcpdump 导入到 Android 系统，例如/data/local/tmp/tcpdump；当然，我们也不用自己编译，在androidtcpdump网站就可以下载到编译好的 tcpdump 二进制文件。
运行tcpdump工具时需要 root 权限。
tcpdump 命令支持许多参数，常见的有：
- -i指定网卡（interface），any表示不限网卡；
- -c指定接收的 packets 数量，接收完成后自动停止抓包；
- -w指定输出文件，输出文件的格式为 pcap；
- -s(--snapshot-length) 指定在每个 packet 中最多截取的字节数，设置为 0 时表示截取上限取默认值 262144；
- -v/-vv/-vvv，指定输出的详细程度，针对流量测试，我们不需要非常详尽的输出数据，取-v即可。

基于以上对tcpdump的介绍，我们要测试浏览器在启动后与美国服务器的通讯流量，就只需要先启动浏览器，然后在adb shell中执行以下命令即可。

1|shell@hammerhead:/ $ su -c /data/local/tmp/tcpdump -v -i any -s 0 -c 2000 -w /sdcard/us.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
2000 packets captured
2024 packets received by filter
0 packets dropped by kernel

在这里之所有指定接收 packets 数为 2000，是因为浏览器启动后并不是立即与美国服务器进行通讯。所以在这里设置了一个比较大的值，确保浏览器与美国服务器的异步通讯数据能包含在这 2000packets 之中。当然，这个 2000 只是一个工程实践得到的经验值，具体取多少还是要依赖于具体场景。

经过一段时间的抓包后，就生产了抓包结果，即/sdcard/us.pcap。

人工分析 pcap 文件

拿到 pcap 文件只是第一步，我们必须要对这个文件进行解析才能得到我们想要的结果。

那么，通过什么方法解析 pcap 文件呢？

先简单介绍下 pcap。pcap，即packet capture的缩写，是一种通用的网络抓包数据存储格式。既然是通用，因此它除了可以被tcpdump解析外，还支持被多种网络工具解析，其中，就包括大家熟知的wireshark。

至于为什么有了tcpdump还要用wireshark来解析，这主要还是因为wireshark是图形界面，操作和使用上更友好一些。

在wireshark中分析 pcap 文件十分简单，只需要直接打开文件，就可以看到抓包过程中捕获的所有网络通讯数据。不过，由于我们抓包获得的数据是系统层面的，除了我们关注的与美国服务器的通讯交互外，还包含了非常多的其它通讯信息。

好在wireshark有非常强大的筛选功能。对于本案例，我们可以先确定出美国服务器的 host 或 IP，例如 host 为ucus.ucweb.com，那么我们就可以在筛选器中通过http.host == "ucus.ucweb.com"语句，即可筛选出所有本地与美国服务器的通讯交互数据。

对于更丰富的筛选功能，大家可以根据实际需求查询wireshark的帮助文档，在此就不再进行展开。

从上图的筛选结果中可以看到，美国服务器的地址为168.235.199.134。那接下来如何查看通讯的流量大小呢？

首先，找出该次请求的TCP Stream。

在筛选出的TCP Stream中，将各条记录的 Length 进行求和，即可得到总的大小。

例如，发送流量的总和，即100.84.126.160->168.235.199.134的总和，加和总值为 3722bytes；接收流量的总和，即168.235.199.134->100.84.126.160的总和，加和总值为 6300bytes。

当然，这里只是为了讲解计算流量的原理，实际上，我们并不需要去进行这个计算，可以直接读取得到总值。

【Statistics】->【Endpoints】

在 Endpoints 界面中，选择TCP tab，勾选“Limit to display filter”，即可看到通讯流量汇总数据。

可以看出，这个的汇总数值与前面计算得到的数值完全相同。

自动化测试脚本

通过前面的人工分析，我们已经掌握了分析特定流量的一般性方法。然而，要想将此种场景的流量测试加入持续集成自动化测试系统，采用以上方法显然是不行的。

那么，要怎样才能在代码中完成对 pcap 文件的分析呢？

好在已经有前辈做了相应的工作，在 GitHub 上就找到了一个开源项目pcap2har，可以实现对 pcap 文件的解析。

pcap2har项目的详细介绍请大家自行查看项目文档。

针对本文中的测试场景，解析 pcap 文件的代码实现如下。

#!/usr/bin/env python
#coding=utf-8

import dpkt
from pcap2har import pcap
from pcap2har import http


def parsePcapFile(pcap_file, target_host):
    # parse pcap file
    dispatcher = pcap.EasyParsePcap(filename=pcap_file)

    traffic_total = 0
    traffic_receive_total = 0
    traffic_send_total = 0
    url_list = []

    # stream为tcp数据流，当为长链接时一个tcp流里面可以有多个http请求
    for stream in dispatcher.tcp.flows():
        # fwd为请求大小，如果小于200则肯定不是正常的HTTP请求，忽略
        if stream.fwd.caplen < 200:
            continue

        pointer = 0
        while pointer < len(stream.fwd.data):
            try:
                myrequest = http.Request(stream.fwd, pointer) #解析请求头
            except dpkt.Error as error:  # if the message failed
                break
            except:
                raise

            pointer += myrequest.data_consumed
            myhead = myrequest.msg.headers

            # 请求头大小<200时忽略
            if myrequest.data_consumed < 200:
                continue

            if myhead["host"] == target_host:
                traffic_receive_total += stream.rev.caplen
                traffic_send_total += stream.fwd.caplen
                traffic_total += stream.streamlen
                url_list.append(myrequest.fullurl)

    traffic_data = {
        'total': traffic_total,
        'tcp_snd': traffic_send_total,
        'tcp_rcv': traffic_receive_total,
        'url_list': url_list
    }
    return traffic_data


if __name__ == '__main__':
    pcap_file = ""
    target_host = "ucus.ucweb.com"
    print parsePcapFile(pcap_file, target_host)
    # output: {'url_list': ['http://ucus.ucweb.com/usquery.php'], 'total': 10022, 'tcp_rcv': 6300, 'tcp_snd': 3722}

Android App 持续集成性能测试：启动流量 (1)

debugtalk — Tue, 03 May 2016 19:36:10 +0800

本文对 Android App 的启动流量测试进行介绍。这里的启动流量指的是网络流量，即 App 在启动时发起网络请求和接收网络响应时传输的网络数据量。

说起流量，也许大家的第一反应就是 tcpdump/wireshark 这类网络抓包工具。的确，Android 系统确实也支持tcpdump工具，通过tcpdump，我们可以实现非常精准的流量测试。但tcpdump也有个问题，就是它捕捉到的流量是系统层面的，我们很难区分捕捉得到的流量数据是否都是当前 apk 产生的。

其实，对于特定 apk 的整体流量数据，在 Android 系统中都会存储到对应文件中，我们完全可以通过读取对应文件来获得当前 apk 的流量信息。

get app UID

与流量相关的状态数据存储在/proc/uid_stat/<UID>/目录下，其中，<UID>表示 apk 对应的 UID。

关于 UID，简单地进行下说明。在 Linux 系统中，UID 表示的是 User Identifier，主要用于表示是哪位用户运行了该程序。但在 Android 系统中，由于 Android 系统本身就为单用户系统，这时 UID 就被赋予了新的使命，主要用于实现数据共享。具体地，Android 系统为每个应用都分配了一个 UID，不同 apk 的 UID 几乎都是互不相同的，而对于不同 UID 的 apk，不能共享数据资源。之所以用“几乎”，是因为有时候同一厂家会存在多个产品，并且希望能在多个 apk 之间实现数据共享，这个时候，便可通过在 menifest 配置文件中指定相同的 sharedUserId，然后在 Android 系统中安装应用时便会分配相同的 UID。

获取 app UID 的方式有多种，最简单的方式应该还是从/data/system/packages.list中读取，并通过 apk 的<PKGNAME>找到对应的 UID。

root@hammerhead:/ # cat /data/system/packages.list | grep com.UCMobile.trunk                   
com.UCMobile.trunk 10084 0 /data/data/com.UCMobile.trunk default 3003,1028,1015

在这里，10084 即是com.UCMobile.trunk的 UID。

获取流量数据

流量数据分为接收流量（tcp_rcv）和发送流量（tcp_snd）两部分，这两个状态数值我们可以通过读取/proc/uid_stat/<UID>目录下的两个文件得到。

shell@hammerhead:/ $ cat /proc/uid_stat/10084/tcp_rcv                          
3446837
shell@hammerhead:/ $ cat /proc/uid_stat/10084/tcp_snd                          
134366

通过这种方式，我们就可以读取得到指定 apk 在当前时刻的累计流量数值。

获得启动流量数据

有了前面的基础，我们要测试启动流量就很好实现了。只需要在启动前采集下累计流量数值，然后启动应用，完成启动后再采集一次累计流量数值，前后两次累计数值的差值便是当次启动耗费的流量数。需要注意的是，由于很多时候 apk 在启动后，会在系统后台异步加载一些数据资源，因此为了保证我们采集到当次启动耗费的全部流量数值，我们在启动应用后最好能等待一段时间。

root@hammerhead:/ # cat /proc/uid_stat/10084/tcp_snd                           
15068
root@hammerhead:/ # cat /proc/uid_stat/10084/tcp_rcv                           
98021

# start app activity, sleep 10s

root@hammerhead:/ # cat /proc/uid_stat/10142/tcp_snd                           
23268
root@hammerhead:/ # cat /proc/uid_stat/10142/tcp_rcv                           
965651

采集到前后两次流量数值后，即可计算得到当次启动耗费的总流量。

当次启动总流量 = (23268 + 965651) - (15068 + 98021) = 875830 bytes

当然，这里的启动还分为好几种，包括首次安装启动、非首次安装启动、覆盖安装启动等。具体的启动方式可根据实际场景来定，但在统计流量的方法方面都是相同的。

总结

本文讲解了 Android App 启动流量测试的一种方法。然而，本次介绍的方法也存在一定局限性，因为/proc/uid_stat/<UID>/目录下的tcp_rcv和tcp_snd文件中都只记录了总值，如果我们只关注总体的流量数值还好，但要是我们希望能测试得到更细化的数据，该方法就没法满足我们的测试需求了。

举个例子，UC 浏览器国际版在启动后，会和美国的服务器进行通讯交互。现在，我们想测试 UC 浏览器国际版在启动后与美国服务器的通讯流量。

显然，本文中介绍的方法是没法实现上述例子中的测试需求的。那例子中的场景要怎么测呢？这就还是得用到tcpdump，在下一篇文章中我会再详细进行介绍。

debugtalk (九毫)

深入浅出开源性能测试工具 Locust (使用篇 1)

概述

脚本编写

简单示例

class HttpLocust(Locust)

class TaskSet

脚本增强

GitHub 项目地址

硬广

深入浅出开源性能测试工具 Locust (使用篇 1)

概述

脚本编写

简单示例

class HttpLocust(Locust)

class TaskSet

脚本增强

硬广

[LocustPlus 序] 漫谈服务端性能测试

打造心目中理想的自动化测试框架 (AppiumBooster)

Jenkins 的输出日志也可以变得色色的

安装 && 配置

效果图

补充说明

ANSI escape sequences

代码示例

使用 Jenkins 实现持续集成构建检查

构建生成.app

实现构建检查

Jenkins 配置

写在最后

从 0 到 1 搭建移动 App 功能自动化测试平台 (4)：自动化测试代码⎡工程化⎦

测试脚本⎡工程化⎦

引入 Minitest/RSpec

添加第二条测试用例

重构：测试用例与控件映射分离

To be continued ...

Read More ...

关于持续集成打包平台的 Jenkins 配置和构建脚本实现细节

关于 iOS 的构建

源码 -> .archive -> .ipa

源码 -> .app -> .ipa

参数说明

补充说明

关于 Android 的构建

关于构建脚本

Jenkins 的详细配置

1、参数的传递

2、修改 build 名称

3、展示二维码图片

4、收集编译成果物

总结

开箱即用

1、添加构建脚本

2、运行 jenkins，安装必备插件

3、创建 Jenkins Job

4、done！

Read More ...

基于 Ruby 实现的移动 App 自动化测试框架

AppiumBooster

write testcases

run

Source Code

使用 Jenkins 搭建 iOS/Android 持续集成打包平台 (附 GitHub，开箱即用)

背景描述

安装 Jenkins

Jenkins 插件

创建项目（Job）

配置 Git 代码仓库

配置构建触发器

配置构建方式

构建后处理

上传安装包文件，生成二维码

展示二维码图片

收集编译成果物（Artifacts）

总结

Read More ...

在 Jenkins 中安装什么插件能实现这个效果呢？

深入浅出 Git 权限校验 (最熟悉的陌生概念)

HTTPS URLs

构建生成`.app`

`源码` -> `.archive` -> `.ipa`

`源码` -> `.app` -> `.ipa`

基于`SSH`协议实现多账号共存

基于`HTTPS`协议实现多账号共存

准备`.app`文件