探索一个软件工程师的无限可能

在macOS中配置Web代理时，通常的做法是在控制面板中进行操作，System Preferences -> Network -> Advanced -> Proxies.

这种配置方式虽然可以实现需求，但缺点在于操作比较繁琐，特别是在需要频繁切换的情况下，效率极其低下。

基于该痛点，我们希望能避免重复操作，实现快速切换配置。

Terminal中实现网络代理配置

要避免在GUI进行重复的配置操作，比较好的简化方式是在Terminal中通过命令实现同样的功能。事实上，在macOS系统中的确是存在配置网络代理的命令，该命令即是networksetup。

获取系统已有的网络服务

首先需要明确的是，macOS系统中针对不同网络服务（networkservice）的配置是独立的，因此在配置Web代理时需要进行指定。

而要获取系统中存在哪些网络服务，可以通过如下命令查看：

1
2
3
4
5
6
7

$ networksetup -listallnetworkservices
An asterisk (*) denotes that a network service is disabled.

Wi-Fi
iPhone USB
Bluetooth PAN
Thunderbolt Bridge

如果计算机是通过Wi-Fi上网的，那么我们设置网络代理时就需要对Wi-Fi进行设置。

开启Web代理

通过networksetup命令对HTTP接口设置代理时，可以采用如下命令：

1
2

$ sudo networksetup -setwebproxy <networkservice> <domain> <port number> <authenticated> <username> <password>
# e.g. sudo networksetup -setwebproxy "Wi-Fi" 127.0.0.1 8080

执行该命令时，会开启系统的Web HTTP Proxy，并将Proxy设置为127.0.0.1:8080。

如果是对HTTPS接口设置代理时，命令为：

1
2

$ networksetup -setsecurewebproxy <networkservice> <domain> <port number> <authenticated> <username> <password>
# e.g. sudo networksetup -setsecurewebproxy "Wi-Fi" 127.0.0.1 8080

关闭Web代理

对应地，关闭HTTP和HTTPS代理的命令为：

1
2
3
4
5

$ sudo networksetup -setwebproxystate <networkservice> <on off>
# e.g. sudo networksetup -setwebproxystate "Wi-Fi" off

$ networksetup -setsecurewebproxystate <networkservice> <on off>
# e.g. sudo networksetup -setsecurewebproxystate "Wi-Fi" off

结合Shuttle实现一键配置

现在我们已经知道如何通过networksetup命令在Terminal中进行Web代理切换了，但如果每次都要重新输入命令和密码，还是会很麻烦，并没有真正地解决我们的痛点。

而且在实际场景中，我们通常需要同时开启或关闭HTTP、HTTPS两种协议的网络代理，这类操作如此高频，要是还能通过点击一个按钮就实现切换，那就优雅多了。

幸运的是，这种优雅的方式还真能实现，只需要结合使用Shuttle这么一款小工具。

Shuttle，简而言之，它可以将一串命令映射到macOS顶部菜单栏的快捷方式。我们要做的很简单，只需要将要实现的任务拼接成一条串行的命令即可，然后就可以在系统菜单栏中点击按钮运行整条命令。

例如，在Terminal中，要想在不手动输入sudo密码的情况下实现同时关闭HTTP和HTTPS的网络代理，就可以通过如下串行命令实现。

1

$ echo <password> | sudo -S networksetup -setwebproxystate 'Wi-Fi' off && sudo networksetup -setsecurewebproxystate 'Wi-Fi' off

类似地，我们还可以实现同时开启HTTP和HTTPS网络代理，更有甚者，我们还可以实现在同时开启HTTP和HTTPS网络代理后，启动mitmproxy抓包工具。

这一切配置都可以在Shuttle的配置文件~/.shuttle.json中完成。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

"hosts": [
  {
    "mitmproxy": [
      {
        "name": "Open mitmproxy",
        "cmd": "echo <password> | sudo -S networksetup -setwebproxy 'Wi-Fi' 127.0.0.1 8080 && sudo networksetup -setsecurewebproxy 'Wi-Fi' 127.0.0.1 8080 && workon mitmproxy && mitmproxy -p 8080"
      }
    ],
    "HTTP(S) Proxy": [
      {
        "name": "Turn on HTTP(S) Proxy",
        "cmd": "echo <password> | sudo -S networksetup -setwebproxy 'Wi-Fi' 127.0.0.1 8080 && sudo networksetup -setsecurewebproxy 'Wi-Fi' 127.0.0.1 8080"
      },
      {
        "name": "Turn off HTTP(S) Proxy",
        "cmd": "echo <password> | sudo -S networksetup -setwebproxystate 'Wi-Fi' off && sudo networksetup -setsecurewebproxystate 'Wi-Fi' off"
      },

    ],
  },
]

配置十分简洁清晰，不用解释也能看懂。完成配置后，在macOS顶部菜单栏中就会出现如下效果的快捷方式。

后续，我们就可以通过快捷方式实现一键切换HTTP(S)代理配置、一键启动mitmproxy抓包工具了。

说到mitmproxy这款开源的抓包工具，只能说相见恨晚，第一次使用它时就被惊艳到了，情不自禁地想给它点个赞！自从使用了mitmproxy，我现在基本上就不再使用Fiddler和Charles了，日常工作中HTTP(S)抓包任务全靠它搞定。

哦对了，mitmproxy不仅可以实现抓包任务，还可以跟locust性能测试工具紧密结合，直接将抓取的数据包生成locust脚本啊！

mitmproxy如此强大，本文就不再多说了，后续必须得写一篇博客单独对其详细介绍。

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

简述性能测试

提起性能测试，可能移动APP的从业人员会感觉比较混淆，因为在客户端（Android、iOS）中也有性能测试专项，主要涉及的是APP的启动时间、内存、包大小、帧率，流量等客户端相关的指标。在本博客之前的文章中，也包含了一些客户端性能测试的内容。需要说明的是，本文所讲解的性能测试都是针对服务器端，尤指Web系统的，与移动APP的性能测试完全是不同的领域。

那么，什么是服务端的性能测试呢？

先从大家都熟悉的功能测试说起吧。例如，我们要测试一个搜索功能，那么我们测试时，就会输入搜索关键词，点击搜索按钮，然后再去查看搜索结果，看结果是否跟我们输入的搜索关键词匹配，如果匹配则说明搜索功能实现正确。

那如何对该功能进行性能测试呢？

答案就是，N个人同时进行功能性操作的同时，在确保功能实现正确的前提下，考察服务端应用程序的各项性能指标，以及服务器硬件资源的使用情况。

当然，这个答案比较简单粗暴，但是它仍然包含了性能测试的基本特点：

• 以功能实现正确为前提
• 通常有一定的并发用户
• 重点考察服务器端在一定并发压力下的性能指标

最后，再明确下性能测试的目的。通常，对服务器端应用程序开展性能测试，是为了验证软件系统是否能够达到预期的性能指标，同时发现软件系统中存在的性能瓶颈，从而实现优化系统的目的。

性能测试方法的核心

根据不同的测试目的，性能测试可以分为多种类型，常见的有如下几类：

• 基准测试（Standard Testing）
• 负载测试（Load Testing）
• 压力测试（Stress Testing）
• 疲劳强度测试

首先说下基准测试。基准测试指的是模拟单个用户执行业务场景时，考察系统的性能指标。严格意义上来讲，基准测试并不能算作性能测试范畴，它跟功能测试并没有太大区别。差异在于，基准测试的目的更多地是关注业务功能的正确性，或者说验证测试脚本的正确性，然后，将基准测试时采集得到的系统性能指标，作为基准测试结果，为后续并发压力测试的性能分析提供参考依据。

负载测试，主要指的是模拟系统在正常负载压力场景下，考察系统的性能指标。这里说的正常负载，主要是指用户对系统能承受的最大业务负载量的期望值，即预计系统最大应该支持多大用户的并发量。通过负载测试，目的是验证系统是否能满足预期的业务压力场景。

和负载测试的概念比较接近的是压力测试。通俗地讲，压力测试是为了发现在多大并发压力下系统的性能会变得不可接受，或者出现性能拐点（崩溃）的情况。在加压策略上，压力测试会对被测系统逐步加压，在加压的过程中考察系统性能指标的走势情况，最终找出系统在出现性能拐点时的并发用户数，也就是系统支持的最大并发用户数。

最后再说下疲劳强度测试。其实疲劳强度测试的加压策略跟负载测试也很接近，都是对系统模拟出系统能承受的最大业务负载量，差异在于，疲劳强度测试更关注系统在长时间运行情况下系统性能指标的变化情况，例如，系统在运行一段时间后，是否会出现事务处理失败、响应时间增长、业务吞吐量降低、CPU/内存资源增长等问题。

通过对比可以发现，不同的性能测试类型，其本质的差异还是在加压策略上，而采用何种加压策略，就取决于我们实际的测试目的，即期望通过性能测试发现什么问题。明白了这一点，性能测试类型的差异也就不再容易混淆了。

结论要点1：性能测试手段的重点在于加压的方式和策略。

性能瓶颈定位的核心

在前面频繁地提到了性能指标，那性能指标究竟有哪些，我们在性能测试的过程中需要重点关注哪些指标项呢？

从维度上划分，性能指标主要分为两大类，分别是业务性能指标和系统资源性能指标。

业务性能指标可以直观地反映被测系统的实际性能状况，常用的指标项有：

• 并发用户数
• 事务吞吐率（TPS/RPS）
• 事务平均响应时间
• 事务成功率

而系统资源性能指标，主要是反映整个系统环境的硬件资源使用情况，常用的指标包括：

• 服务器：CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况等；
• 数据库：数据库连接数、数据库读写响应时长、数据库读写吞吐量等；
• 网络：网络吞吐量、网络带宽、网络缓冲池大小；
• 缓存（Redis）：静态资源缓存命中率、动态数据缓存命中率、缓存吞吐量等；
• 测试设备（压力发生器）：CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况等。

对于以上指标的具体含义我就不在此进行逐一说明了，大家可以自行搜索，务必需要搞清楚每个指标的概念及其意义。可能有些指标在不同的操作系统中的名称有些差异，但是基本都会有对应的指标，其代表的意义也是相通的。例如，处理器队列长度这个指标，在Windows中的指标名称是System\Processor Queue Length，而在Linux系统中则需要看load averages。

可能对于最后一项（测试设备）有些人不大理解，监控被测系统环境的相关硬件资源使用情况不就好了么，为什么还要关注测试设备本身呢？这是因为测试设备在模拟高并发请求的过程中，设备本身也会存在较高的资源消耗，例如CPU、内存、网卡带宽吃满，磁盘IO读写频繁，处理器排队严重等；当出现这类情况后，测试设备本身就会出现瓶颈，无法产生预期的并发压力，从而我们测试得到的数据也就不具有可参考性了。此处暂不进行展开，后面我会再结合实际案例，通过图表和数据对此详细进行说明。

需要说明的是，性能指标之间通常都是有密切关联的，单纯地看某个指标往往很难定位出性能瓶颈，这需要我们对各项性能指标的含义了然于胸，然后才能在实际测试的过程中对系统性能状况综合进行分析，找出整个系统真正的瓶颈。举个简单的例子，压力测试时发现服务器端CPU利用率非常高，那这个能说明什么问题呢？是服务端应用程序的算法问题，还是服务器硬件资源配置跟不上呢？光看这一个指标并不能定位出产生问题的真正原因，而如果仅因为这一点，就决定直接去优化程序算法或者升级服务器配置，最后也很难真正地解决问题。

结论要点2：性能瓶颈定位的重点在于性能指标的监控和分析。

引入性能测试工具

通过前面的讲解，我们已经知道性能测试的主要手段是通过产生模拟真实业务的压力对被测系统进行加压，与此同时监控被测系统的各项性能指标，研究被测系统在不同压力情况下的表现，找出其潜在的性能瓶颈。

那么，如何对系统进行加压，又如何对系统的指标进行监控呢？这里，就需要引入性能测试工具了。

当然，我们也可以先看下在不借助性能测试工具的情况下，如何手工地对系统进行性能测试。

假设现在我们要对前面提到的搜索功能进行负载测试，验证在20个并发用户下搜索功能的事务平均响应时间是否在3秒以内。

很自然地，我们可以想到测试的必要条件有如下几点：

• 20个测试人员，产生业务压力
• 1个指挥人员，对20个人员的协调控制，实现并发操作
• 1个结果记录人员，对每一个人员的操作耗时进行监控和记录
• 若干资源监控人员，实时查看被测系统的各项性能指标，对指标进行汇总、分析
• 1个结果统计人员，对20个用户各操作消耗的时长进行汇总，计算其平均值

可以看出，要通过人工来进行性能测试，操作上极为繁琐，需要投入的资源非常多，而这还仅仅是一个非常简单的场景。设想，如果要测试10000并发，服务器有好几十台，显然，这种情况下是完全不可能通过投入人力就能解决的。这也就是性能测试工具存在的必要性和诞生的背景。

性能测试工具的基本组成

当前，市面上已经有了很多性能测试工具，但不管是哪一款，基本都会包含如下几个核心的模块。

• 压力生成器（Virtual User Generator）
• 结果采集器（Result Collector）
• 负载控制器（Controller）
• 系统资源监控器（Monitor）
• 结果分析器（Analysis）

原理结构图如下所示：

对照前面手工进行性能测试的案例，不难理解，压力发生器对应的是众多测试人员，结果采集器对应的是结果记录人员，负载控制器对应的是指挥人员，资源监控器对应的是若干资源监控人员，结果分析器对应的是结果统计人员。

其中，压力发生器又是性能测试工具最核心的部分，它主要有两个功能，一是真实模拟用户操作，二是模拟有效并发。

然而，大多数性能测试工作人员可能都会忽略的是，当前市面上性能测试工具的压力发生器基本都是存在缺陷的。

先说下模拟真实用户操作。如果熟悉浏览器的工作原理，就会知道浏览器在加载网页的时候，是同时并发多个TCP连接去请求页面对应的HTTP资源，包括HTML、JS、图片、CSS，当前流行的浏览器普遍会并发6-10个连接。然而，性能测试工具在模拟单个用户操作的时候，基本上都是单连接串行加载页面资源。产生的差异在于，假如页面有100个资源，每个HTTP请求的响应时间约为100毫秒，那么浏览器采用6个连接并行加载网页时大概会需要1.7秒（100/6*100毫秒），而测试工具采用单连接串行加载就需要10秒（100*100毫秒），两者结果相差十分巨大。这也解释了为什么有时候我们通过性能测试工具测试得到的响应时间挺长，但是手动用浏览器加载网页时感觉挺快的原因。

再说下有效并发。什么叫有效并发？有效并发就是我们在测试工具中设置了1000虚拟用户数，实际在服务器端就能产生1000并发压力。然而现实情况是，很多时候由于测试设备自身出现了性能瓶颈，压力发生器产生的并发压力远小于设定值，并且通常测试工具也不会将该问题暴露给测试人员；如果测试人员忽略了这个问题，以为测试得到的结果就是在设定并发压力下的结果，那么最终分析得出的结论也就跟实际情况大相径庭了。不过，我们可以通过保障测试环境不存在瓶颈，使得实际生成的并发压力尽可能地与设定值一致；另一方面，我们也可以通过在测试过程中监控Web层（例如Nginx）的连接数和请求数，查看实际达到服务器端的并发数是否跟我们的设定值一致，以此来反推压力发生器的压力是否有效。

了解这些缺陷的意义在于，我们可以更清楚测试工具的原理，从而更准确地理解测试结果的真实含义。

性能测试工具推荐

经过充分的理论铺垫，现在总算可以进入正题，开始讲解工具部分了。

在性能测试工具方面，我重点向大家推荐Locust这款开源工具。目前阶段，该款工具在国内的知名度还很低，大多数测试人员可能之前都没有接触过。为了便于理解，我先将Locust与LoadRunner、Jmeter这类大众耳熟能详的性能测试工具进行简单对比。

通过对比，大家可能会疑惑，Locust也不怎么样嘛，资源监控也不支持，报告分析能力也这么弱，那为啥还要选择它呢？

授权方式这个就不说了。虽然LoadRunner是商业软件，价格极其昂贵，但是国内盗版横行，别说个人，就算是大型互联网公司，用正版的也没几个。

从功能特性的角度来讲，LoadRunner是最全面的，用户群体也是最多的，相应的学习资料也最为丰富。个人建议如果是新接触性能测试，可以先熟悉LoadRunner，借此了解性能测试工具各个模块的概念和功能，在此基础上再转到别的测试工具，也都比较好上手了。不过，LoadRunner只能在Windows平台使用，并且并发效率比较低，单台压力机难以产生较高的并发能力，这也是现在我弃用该款工具的主要原因。

同样地，Jmeter的并发机制也是基于线程，并发效率存在同样的问题；另外，Jmeter在脚本编写和描述方面是基于GUI操作，个人感觉操作比较繁琐（这个因人而异），因此不是很喜欢。

那么，我重点推荐的Locust有啥特别的地方呢？

如果从整体功能上来看的话，Locust的功能的确比较单薄。不过，作为性能测试工具最核心的压力发生器部分，却是非常不错的。抛开官方文档的介绍，个人觉得最赞的有两点。

首先是模拟用户操作，也就是测试脚本描述方面。Locust采用Pure Python脚本描述，并且HTTP请求完全基于Requests库。用过Requests的都知道，这个库非常简洁易用，但功能十分强大，很多其它编程语言的HTTP库都借鉴了它的思想和模式，如果将其评选为最好用的HTTP库之一（不限语言），应该也不会有太大的争议。除了HTTP(S)协议，Locust也可以测试其它任意协议的系统，只需要采用Python调用对应的库进行请求描述即可。

另外一点就是并发机制了。Locust的并发机制摒弃了进程和线程，采用协程（gevent）的机制。采用多线程来模拟多用户时，线程数会随着并发数的增加而增加，而线程之间的切换是需要占用资源的，IO的阻塞和线程的sleep会不可避免的导致并发效率下降；正因如此，LoadRunner和Jmeter这类采用进程和线程的测试工具，都很难在单机上模拟出较高的并发压力。而协程和线程的区别在于，协程避免了系统级资源调度，由此大幅提高了性能。正常情况下，单台普通配置的测试机可以生产数千并发压力，这是LoadRunner和Jmeter都无法实现的。

有了一个不错的引擎，外表装饰简陋点也都是可以接受的了。不过虽然Locust功能单薄，特别是在性能指标监控和测试报告图表方面比较缺失，但是Locust的代码结构清晰，核心代码量也只有几百行，可扩展性也非常不错。换言之，Locust的可玩性（hackable）极强，对于一个想深入挖掘性能测试工具原理的人来说，Locust非常适合。

好了，Locust的介绍暂且到这儿，后续我会再对Locust的使用方法和二次开发进行详细介绍，也算是弥补官方文档的不足吧。

前言

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

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

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

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

UI交互基础

UI交互是自动化测试的基础，主要分为三部分内容：定位控件、操作控件、检测结果。

控件定位

定位控件时，统一采用元素ID进行定位。这里的ID包括accessibility_id或accessibility_label，需要在iOS工程项目中预先进行设置。

另外，考虑到控件可能出现延迟加载的情况，定位控件时统一执行wait操作；定位成功后会立即返回控件对象，定位失败时会进行等待并不断尝试定位，直到超时（30秒）后抛出异常。

1

wait { id control_id }

源码路径：AppiumBooster/lib/pages/control.rb

控件操作

根据实践证明，UI的控件操作基本主要就是点击、输入和滑动，这三个操作基本上可以覆盖绝大多数场景。

• scrollToDisplay: 根据指定控件的坐标位置，对屏幕进行上/下/左/右滑动操作，直至将指定控件展示在屏幕中
• click: 通过控件ID定位到指定控件，并对指定控件进行click操作；若指定控件不在当前屏幕中，则先执行scrollToDisplay，再执行click操作
• type(text): 在指定控件中输入字符串；若指定控件不在当前屏幕中，则先执行scrollToDisplay，再执行输入操作
• tapByCoordinate: 先执行scrollToDisplay，确保指定控件在当前屏幕中；获取指定控件的坐标值，然后对坐标进行tap操作
• scroll(direction): 对屏幕进行指定方向的滑动

源码路径：AppiumBooster/lib/pages/actions.rb

预期结果检查

每次执行一步操作后，需要对执行结果进行判断，以此来确定测试用例的各个步骤是否执行成功。

当前，AppiumBooster采用控件的ID作为检查对象，并统一封装到check_elements(control_ids)方法中。

在实际使用过程中，需要先确定当前步骤执行完成后的跳转页面的特征控件，即当前步骤执行前不存在该控件，但执行成功后的页面中具有该控件。然后在操作步骤描述的expectation属性中指定特征控件的ID。

具体地，在指定控件ID的时候还可以配合使用操作符（!,||,&&），以此实现多种复杂场景的检测。典型的预期结果描述形式如下：

• A: 预期控件A存在；
• !A: 预期控件A不存在；
• A||B: 预期控件A或控件B至少存在一个；
• A&&B: 预期控件A和控件B同时存在；
• A&&!B: 预期控件A存在，但控件B不存在；
• !A&&!B: 预期控件A和控件B都不存在。

源码路径：AppiumBooster/lib/pages/inner_screen.rb

测试用例引擎（YAML）

对于自动化测试而言，自动化测试用例的组织与管理是最为重要的部分，直接关系到自动化测试用例的可复用性和可维护性。

经过综合考虑，AppiumBooster从三个层面来描述测试用例，从低到高分别是step、feature和testcase；描述方式推荐使用YAML格式。

steps（测试步骤描述）

首先是对于单一操作步骤的描述。

从UI层面来看，每一个操作步骤都可以归纳为三个方面：定位控件、操作控件和检查结果。

AppiumBooster的做法是，将App根据功能模块进行拆分，每一个模块单独创建一个YAML文件，并保存在steps目录下。然后，在每个模块中以控件为单位，分别进行定义。

现以如下示例进行详细说明。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

---
AccountSteps:
  enter Login page:
    control_id: tablecellMyAccountLogin
    control_action: click
    expectation: btnForgetPassword

  input test EmailAddress:
    control_id: txtfieldEmailAddress
    control_action: type
    data: leo.lee@debugtalk.com
    expectation: sectxtfieldPassword

  check if coupon popup window exists(optional):
    control_id: inner_screen
    control_action: has_control
    data: btnViewMyCoupons
    expectation: btnClose
    optional: true

其中，AccountSteps是steps模块名称，用于区分不同的steps模块，方便在features模块中进行引用。

描述单个步骤时，有三项是必不可少的：步骤名称、控件ID（control_id）和控件操作方式（control_action）。当控件操作方式为输入（type）时，则还需指定data属性，即输入内容。

在检查步骤执行结果方面，可通过在expectation属性中指定控件ID进行实现，前面在预期结果检查一节中已经详细介绍了使用方法。该属性可以置空或不进行填写，相当于不对当前步骤进行检测。

另外还有一个optional属性，对步骤指定该属性并设置为true时，当前步骤的执行结果不影响整个测试用例。

features（功能点描述）

各个模块的单一操作步骤定义完毕后，虽然可以直接将多个步骤进行组合形成对测试场景的描述，即测试用例，但是操作起来会过于局限细节；特别是当测试用例较多时，可维护性是一个很大的问题。

AppiumBooster的做法是，将App根据功能模块进行拆分，每一个模块单独创建一个YAML文件，并保存在features目录下。然后，在每个模块中以功能点为单位，通过对steps模块中定义好的操作步骤进行引用并组合，即可实现对功能点的描述。

以系统登录功能为例，功能点的描述可采用如下形式。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

---
AccountFeatures:
  login with valid test account:
    - AccountSteps | enter My Account page
    - AccountSteps | enter Login page
    - AccountSteps | input test EmailAddress
    - AccountSteps | input test Password
    - AccountSteps | login
    - AccountSteps | close coupon popup window(optional)

  login with valid production account:
    - AccountSteps | enter My Account page
    - AccountSteps | enter Login page
    - AccountSteps | input production EmailAddress
    - AccountSteps | input production Password
    - AccountSteps | login
    - AccountSteps | close coupon popup window(optional)

  logout:
    - AccountSteps | enter My Account page
    - SettingsSteps | enter Settings page
    - AccountSteps | logout

其中，AccountFeatures是features模块名称，用于区分不同的features模块，方便在testcase中进行引用。

在引用steps模块的操作步骤时，需要同时指定steps模块名称和操作步骤的名称，并以|进行分隔。

testcases（测试用例描述）

在功能点描述的基础上，AppiumBooster就可以在第三个层面，简单清晰地描述测试用例了。

具体做法很简单，针对每个测试用例创建一个YAML文件，并保存在testcases目录下。然后，通过对features模块中定义好的功能点描述进行引用并组合，即可实现对测试用例的描述。

同样的，在引用features模块的功能点时，也需要同时指定features模块名称和功能点的名称，并以|进行分隔。

如下示例便是实现了在商城中购买商品的整个流程，包括切换国家、登录、选择商品、添加购物车、下单完成支付等功能点。

1
2
3
4
5
6
7
8
9

---
Buy Phantom 4:
  - SettingsFeatures | initialize first startup
  - SettingsFeatures | Change Country to China
  - AccountFeatures | login with valid account
  - AccountFeatures | Change Shipping Address to China
  - StoreFeatures | add phantom 4 to cart
  - StoreFeatures | finish order
  - AccountFeatures | logout

另外，在某些测试场景中可能需要重复进行某一个功能点的操作。虽然可以将需要重复的步骤多写几次，但会显得比较累赘，特别是重复次数较多时更是麻烦。

AppiumBooster的做法是，在测试用例的步骤中可指定执行次数，并以|进行分隔，如下例所示。

1
2
3
4
5
6

---
Send random text messages:
  - SettingsFeatures | initialize first startup
  - AccountFeatures | login with valid test account
  - MessageFeatures | enter follower user message page
  - MessageFeatures | send random text message | 100

测试用例引擎（CSV）

基本上，YAML测试用例引擎已经可以很好地满足组织和管理自动化测试用例的需求。

但考虑到部分用户会偏向于使用表格的形式，因为表格看上去更直观一些，AppiumBooster同时还支持CSV格式的测试用例引擎。

testcases（测试用例描述）

采用表格来编写测试用例时，只需要在任意表格工具，包括Microsoft Excel、iWork Numbers、WPS等，按照如下形式对测试用例进行描述。

然后，将表格内容另存为CSV格式的文件，并放置于testcases目录中即可。

可以看出，CSV格式的测试用例和YAML格式的测试用例是等价的，两者包含的信息内容完全相同。

在具体实现上，AppiumBooster在执行测试用例之前，也会将两个测试用例引擎的测试用例描述转换为相同的数据结构，然后再进行统一的操作。

统一转换后的数据结构如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
  "testcase_name": "Login and Logout",
  "features_suite": [
    {
      "feature_name": "login with valid account",
      "feature_steps": [
        {"control_id": "btnMenuMyAccount", "control_action": "click", "expectation": "tablecellMyAccountSystemSettings", "step_desc": "enter My Account page"},
        {"control_id": "tablecellMyAccountLogin", "control_action": "click", "expectation": "btnForgetPassword", "step_desc": "enter Login page"},
        {"control_id": "txtfieldEmailAddress", "control_action": "type", "data": "leo.lee@debugtalk.com", "expectation": "sectxtfieldPassword", "step_desc": "input EmailAddress"},
        {"control_id": "sectxtfieldPassword", "control_action": "type", "data": 12345678, "expectation": "btnLogin", "step_desc": "input Password"},
        {"control_id": "btnLogin", "control_action": "click", "expectation": "tablecellMyMessage", "step_desc": "login"},
        {"control_id": "btnClose", "control_action": "click", "expectation": nil, "optional": true, "step_desc": "close coupon popup window(optional)"}
      ]
    },
    {
      "feature_name": "logout",
      "feature_steps": [
        {"control_id": "btnMenuMyAccount", "control_action": "click", "expectation": "tablecellMyAccountSystemSettings", "step_desc": "enter My Account page"},
        {"control_id": "tablecellMyAccountSystemSettings", "control_action": "click", "expectation": "txtCountryDistrict", "step_desc": "enter Settings page"},
        {"control_id": "btnLogout", "control_action": "click", "expectation": "uiviewMyAccount", "step_desc": "logout"}
      ]
    }
  ]
}

测试用例转换器（yaml2csv）

既然CSV格式的测试用例和YAML格式的测试用例是等价的，那么两者之间的转换也就容易实现了。

当前，AppiumBooster支持将YAML格式的测试用例转换为CSV格式的测试用例，只需要执行一条命令即可。

1

$ ruby start.rb -c "yaml2csv" -f ios/testcases/login_and_logout.yml

过程记录及结果存储

在自动化测试执行过程中，应尽量对测试用例执行过程进行记录，方便后续对问题根据定位和追溯。

过程记录方式

当前，AppiumBooster已实现的记录形式有如下三种：

• logger模块：可指定日志级别对测试过程进行记录
• 截图功能：测试用例运行过程中，在每个步骤执行完成后进行截图
• DOM source：测试用例运行过程中，在每个步骤执行完成后保存当前页面的DOM内容

测试结果存储

由于Appium分为Server端和Client端，因此AppiumBooster在记录日志的时候也将日志分为了三份：

• appium_server.log: Appium Server端的日志，这部分日志是由Appium框架打印的
• appium_booster.log: 包括测试环境初始化和测试用例执行记录，这部分日志是由AppiumBooster中采用logger模块打印的
• client_server.log: 同时记录AppiumBooster和Appium框架的日志，相当于appium_server.log和appium_booster.log的并集，优点在于可以清晰地看到测试用例执行过程中Client端和Server端的通讯交互过程

另外，当测试用例执行失败时，AppiumBooster会将执行失败的步骤截图和日志提取出来，单独保存到errors文件夹中，方便问题追溯。

具体地，每次执行测试前，AppiumBooster会在指定的results目录下创建一个以当前时间（%Y-%m-%d_%H:%M:%S）命名的文件夹，存储结构如下所示。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

2016-08-28_16:28:48
├── appium_server.log
├── appium_booster.log
├── client_server.log
├── errors
│   ├── 16_31_29_btnLogin.click.dom
│   ├── 16_31_29_btnLogin.click.png
│   ├── 16_32_03_btnMenuMyAccount.click.dom
│   └── 16_32_03_btnMenuMyAccount.click.png
├── screenshots
│   ├── 16_30_34_tablecellMyAccountLogin.click.png
│   ├── 16_30_41_txtfieldEmailAddress.type_leo.lee@debugtalk.com.png
│   ├── 16_30_48_sectxtfieldPassword.type_123456.png
│   ├── 16_31_29_btnLogin.click.png
│   └── 16_32_03_btnMenuMyAccount.click.png
└── xmls
    ├── 16_30_34_tablecellMyAccountLogin.click.dom
    ├── 16_30_41_txtfieldEmailAddress.type_leo.lee@debugtalk.com.dom
    ├── 16_30_48_sectxtfieldPassword.type_123456.dom
    ├── 16_31_29_btnLogin.click.dom
    └── 16_32_03_btnMenuMyAccount.click.dom

对于每一个测试步骤的截图和DOM，存储文件命名格式为%H_%M_%S_ControlID.ControlAction。采用这种命名方式有两个好处：

• 文件通过时间排序，对应着测试用例执行的步骤顺序
• 可以在截图或DOM中直观地看到每一步操作指令对应的执行结果

环境初始化

Appium Server

在执行自动化测试时，某些情况下可能会造成Appium Server出现异常情况（e.g. 500 error），并影响到下一次测试的执行。

为了避免这类情况，AppiumBooster在每次执行测试前，会强制性地对Appium Server进行重启。方式也比较简单暴力，运行测试之前先检查系统是否有bin/appium的进程在运行，如果有，则先kill掉该进程，然后再启动Appium Server。

需要说明的是，由于Appium Server的启动需要一定时间，为了防止运行Appium Client时Appium Server还未初始化完毕，因此启动Appium Server后最好能等待一段时间（e.g. sleep 10s）。

iOS/Android模拟器

在模拟器中运行一段时间后，也会存在缓存数据和文件，可能会对下一次测试造成影响。

为了避免这类情况，AppiumBooster在每次执行测试前，会先删除已存在的模拟器，然后再用指定的模拟器配置创建新的模拟器。

对于iOS模拟器，AppiumBooster通过调用xcrun simctl命令的方式来对模拟器进行操作，基本原理如下所示。

1
2
3
4

# delete iOS simulator: xcrun simctl delete device_id
$ xcrun simctl delete F2F53866-50A5-4E0F-B164-5AC1702AD1BD
# create iOS simulator: xcrun simctl create device_type device_type_id runtime_id
$ xcrun simctl create 'iPhone 5' 'com.apple.CoreSimulator.SimDeviceType.iPhone-5' 'com.apple.CoreSimulator.SimRuntime.iOS-9-3'

其中，device_id/device_type_id/runtime_id这些属性值可以通过执行xcrun simctl list命令获取得到。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$ xcrun simctl list
== Device Types ==
iPhone 5s (com.apple.CoreSimulator.SimDeviceType.iPhone-5s)
iPhone 6 (com.apple.CoreSimulator.SimDeviceType.iPhone-6)
== Runtimes ==
iOS 8.4 (8.4 - 12H141) (com.apple.CoreSimulator.SimRuntime.iOS-8-4)
iOS 9.3 (9.3 - 13E230) (com.apple.CoreSimulator.SimRuntime.iOS-9-3)
== Devices ==
-- iOS 8.4 --
    iPhone 5s (E1BD9CC5-8E95-408F-849C-B0C6A44D669A) (Shutdown)
-- iOS 9.3 --
    iPhone 5s (BAFEFBE1-3ADB-45C4-9C4E-E3791D260524) (Shutdown)
    iPhone 6 (F23B3F85-7B65-4999-9F1C-80111783F5A5) (Shutdown)
== Device Pairs ==

增强特性

除了以上基础特性，AppiumBooster还支持一些辅助特性，可以增强测试框架的使用体验。

Data参数化

在某些场景下，测试用例执行时需要动态获取数值。例如，注册账号的测试用例中，每次执行测试用例时需要保证用户名为未注册的，常见的做法就是在注册用户名中包含时间戳。

AppiumBooster的做法是，可以在测试步骤的data字段中，传入Ruby表达式，格式为${ruby_expression}。在执行测试用例时，会先对ruby_expression进行eval计算，然后用计算得到的值作为实际参数。

回到刚才的注册账号测试用例，填写用户名的步骤就可以按照如下形式指定参数。

1
2
3
4
5

input test EmailAddress:
  control_id: txtfieldEmailAddress
  control_action: type
  data: ${Time.now.to_i}@debugtalk.com
  expectation: sectxtfieldPassword

实际执行测试用例时，data就会参数化为`1471318368@debugtalk.com`的形式。

全局参数配置

对于某些配置参数，例如系统的登录账号密码等，虽然可以直接填写到测试用例的steps中，但是终究不够灵活。特别是当存在多个测试用例引用同一个参数时，涉及到参数改动时就需要同时修改多个地方。

更好的做法是，将此类参数提取出来，在统一的地方进行配置。在AppiumBooster中，可以在config.yml文件中配置全局参数。

1
2
3
4
5
6
7
8

---
TestEnvAccount:
  UserName: test@debugtalk.com
  Password: 123456

ProductionEnvAccount:
  UserName: production@debugtalk.com
  Password: 12345678

然后，在测试用例的steps就可以采用如下形式对全局参数进行引用。

1
2
3
4
5
6
7
8
9
10
11
12
13

---
AccountSteps:
  input test EmailAddress:
    control_id: txtfieldEmailAddress
    control_action: type
    data: ${config.TestEnvAccount.UserName}
    expectation: sectxtfieldPassword

  input test Password:
    control_id: sectxtfieldPassword
    control_action: type
    data: ${config.TestEnvAccount.Password}
    expectation: btnLogin

optional选项

在执行测试用例时，有时候可能会存在这样的场景：某个步骤作为非必要步骤，当其执行失败时，我们并不想将测试用例判定为不通过。

基于该场景，在测试用例设计表格中增加了optional参数。该参数值默认不用填写。但如果在某个步骤对应的optional栏填写了true值后，那么该步骤就会作为非必要步骤，其执行结果不会影响整个用例的执行结果。

例如，在电商类APP中，某些账号有优惠券，登录系统后，会弹出优惠券的提示框；而有的账号没有优惠券，登录后就不会有这样的弹框。那么关闭优惠券弹框的步骤就可以将其optional参数设置为true。

1
2
3
4
5
6
7

---
AccountSteps:
  close coupon popup window(optional):
    control_id: btnClose
    control_action: click
    expectation: !btnViewMyCoupons
    optional: true

命令行工具

AppiumBooster通过在命令行中进行调用。

1
2
3
4
5
6
7
8

$ ruby start.rb -h
Usage: start.rb [options]
    -p, --app_path <value>           Specify app path
    -t, --app_type <value>           Specify app type, ios or android
    -f, --testcase_file <value>      Specify testcase file(s)
    -d, --output_folder <value>      Specify output folder
    -c, --convert_type <value>       Specify testcase converter, yaml2csv or csv2yaml
        --disable_output_color       Disable output color

执行测试用例

指定执行测试用例时支持多种方式，常见的几种使用方式示例如下：

1
2
3
4
5
6
7
8
9
10
11
12

$ cd ${AppiumBooster}
# 执行指定的测试用例文件（绝对路径）
$ ruby run.rb -p "ios/app/test.zip" -f "/Users/Leo/MyProjects/AppiumBooster/ios/testcases/login.yml"

# 执行指定的测试用例文件（相对路径）
$ ruby run.rb -p "ios/app/test.zip" -f "ios/testcases/login.yml"

# 执行所有yaml格式的测试用例文件
$ ruby run.rb -p "ios/app/test.zip" -f "ios/testcases/*.yml"

# 执行ios目录下所有csv格式的测试用例文件
$ ruby run.rb -p "ios/app/test.zip" -t "ios" -f "*.csv"

测试用例转换

将YAML格式的测试用例转换为CSV格式的测试用例：

1

$ ruby start.rb -c "yaml2csv" -f ios/testcases/login_and_logout.yml

总结

什么才算是心目中理想的自动化测试框架？我也没有确切的答案。

为什么要登山？
因为山在那里。

在《使用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为例，在Sting基础类中添加一些展示颜色的方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

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

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

1
2
3
4
5
6
7

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

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

展示效果如下图所示。

是不是好看多了？

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

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

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

构建生成.app

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

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

1
2
3
4
5
6
7

# 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的要求在表格中编写一组基本的自动化测试用例，即可采用如下方式执行构建检查。

1
2

$ 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部分的内容。

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

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

测试脚本⎡工程化⎦

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

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

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

引入Minitest/RSpec

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

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

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

1
2
3
4
5
6
7
8
9
10

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

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

1
2
3
4
5
6

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# 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中，实现了对相关库文件的引用。

1
2
3
4
5
6
7
8

# filename: common/requires.rb

# load lib
require 'rspec'
require 'appium_lib'

# setup rspec
require_relative 'spec_helper'

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

1
2
3
4
5

[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对应的就是系统登录的测试用例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# 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@debugtalk.com' }
    wait { id('sectxtfieldPassword').type '123321' }
    wait { id('btnLogin').click }
    wait { id 'tablecellMyMessage' }
  end

end

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

1
2
3
4
5

➜ 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。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 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），因此我们可以将控件操作方法单独封装为一个模块，作为公共模块。

1
2
3
4
5
6
7
8
9
10
11

module Actions

  def click
    wait { @found_cell.click }
  end

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

end

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

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这样的形式来对控件进行操作了。

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

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

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

关于iOS的构建

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

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

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

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

源码 -> .archive -> .ipa

1
2
3
4
5
6
7
8

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

archive：对编译结果进行归档，会生成一个.xcarchive的文件，位于-archivePath指定的目录中。需要注意的是，对模拟器类型的sdk无法使用archive命令。

1
2
3
4
5
6
7
8

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

源码 -> .app -> .ipa

1
2
3
4
5
6
7

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

1
2
3
4
5
6

# convert .app file to ipa file
xcrun \
  -sdk iphoneos \
  PackageApplication \
  -v ${OUTPUT_FOLDER}/Release-iphoneos/xxx.app \
  -o ${OUTPUT_FOLDER}/Release-iphoneos/xxx.ipa

参数说明

xcodebuild/xctool参数：

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

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

xcrun参数：

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

补充说明

1、获取Targets、Schemes、Configurations参数

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

➜  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之前都清理一下上一次编译遗留的缓存文件。

1
2
3
4
5
6

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

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

3、处理Cocoapod依赖库

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

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

1
2
3
4

# 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中可以通过如下形式调用构建脚本。

1

$ 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通过如下形式来进行参数传递。

1
2
3
4
5
6

$ 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中。

1
2
3

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

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

1

appDownloadPage: (.*)$

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

1

<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这三个文件，那么我们就可以通过如下表达式来进行指定。

1

${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实现持续集成，构建脚本还可单独使用，使用方式如下：

1
2
3
4
5

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

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

1

$ 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！

AppiumBooster

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

write testcases in yaml (recommended)

Take DebugTalk+ Discover’s login and logout function as an example.

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# ios/testcases/Account.yml
---
AccountTestcases:
  login with valid account:
    - AccountSteps | enter My Account page
    - AccountSteps | enter Login page
    - AccountSteps | input EmailAddress
    - AccountSteps | input Password
    - AccountSteps | login
    - AccountSteps | close coupon popup window(optional)

  logout:
    - AccountSteps | enter My Account page
    - SettingsSteps | enter Settings page
    - AccountSteps | logout

In the testcases, each step is combined with two parts, joined by a separator |. The former part indicates step file located in ios/steps/ directory, and the latter part indicates testcase step name, which is defined in steps yaml files like below.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

# ios/steps/AccountSteps.yml
---
AccountSteps:
  enter My Account page:
    control_id: btnMenuMyAccount
    control_action: click
    expectation: tablecellMyAccountSystemSettings

  enter Login page:
    control_id: tablecellMyAccountLogin
    control_action: click
    expectation: btnForgetPassword

  input EmailAddress:
    control_id: txtfieldEmailAddress
    control_action: type
    data: leo.lee@debugtalk.com
    expectation: sectxtfieldPassword

  input Password:
    control_id: sectxtfieldPassword
    control_action: type
    data: 123456
    expectation: btnLogin

  login:
    control_id: btnLogin
    control_action: click
    expectation: tablecellMyMessage

write testcases in tables

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

In order to test the same 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.

run

Once the testcases are done, you are ready to run automation test on your app.

Run the automation testcases is very easy. You can execute ruby run.rb -h in the project root directory to see the usage.

1
2
3
4
5
6

➜  AppiumBooster git:(master) ✗ ruby run.rb -h
Usage: run.rb [options]
    -p, --app_path APP_PATH              Specify app path
    -t, --app_type APP_TYPE              Specify app type, ios or android
    -f, --testcase_file TESTCASE_FILE    Specify testcase file
        --disable_output_color           Disable output color

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

➜  AppiumBooster git:(master) ✗ ruby run.rb -p "ios/app/test.zip" -f "ios/testcases/Account.yml"
initialize appium driver ...
load testcase yaml file: /Users/Leo/MyProjects/AppiumBooster/ios/testcases/Account.yml
load steps yaml file: /Users/Leo/MyProjects/AppiumBooster/ios/steps/AccountSteps.yml
load steps yaml file: /Users/Leo/MyProjects/AppiumBooster/ios/steps/SettingsSteps.yml
start appium driver ...

======= start to run testcase suite: /Users/Leo/MyProjects/AppiumBooster/ios/testcases/Account.yml =======
B------ Start to run testcase: login with valid account
step_1: enter My Account page
btnMenuMyAccount.click     ...    ✓
step_2: enter Login page
tablecellMyAccountLogin.click     ...    ✓
step_3: input EmailAddress
txtfieldEmailAddress.type leo.lee@debugtalk.com    ...    ✓
step_4: input Password
sectxtfieldPassword.type 123456    ...    ✓
step_5: login
btnLogin.click     ...    ✓
step_6: close coupon popup window(optional)
btnClose.click     ...    ✓
E------ login with valid account

B------ Start to run testcase: logout
step_1: enter My Account page
btnMenuMyAccount.click     ...    ✓
step_2: enter Settings page
tablecellMyAccountSystemSettings.click     ...    ✓
step_3: logout
btnLogout.click     ...    ✓
E------ logout

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

Source Code

GitHub: https://github.com/debugtalk/AppiumBooster

背景描述

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

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

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

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

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

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

安装Jenkins

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

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

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

1

$ 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 src='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配置和构建脚本实现细节》。

借助上次“掉坑”的经历，我对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机制，也可以采用这种方式。

1
2
3
4

# 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，通常无需修改，保持默认即可。不过，如果一台计算机中存在多个秘钥对，就需要修改秘钥文件名，名称没有强制的命名规范，便于自己辨识即可。

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

➜ 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账户。

1
2
3
4
5

# 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的连接状态，会发现系统仍提示权限校验失败。

1
2

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

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

1
2
3
4
5
6
7

# 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)

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

1
2

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

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

1
2

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

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

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

1
2
3
4
5
6
7
8
9

➜ 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 leolee! You've successfully authenticated, but GitHub does not provide shell access.

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

1
2
3
4
5
6

➜ 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和leolee，在两个账号中各自有一个仓库，debugtalk/DroidMeter和DebugTalk/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。

1
2
3

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13

➜  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文件，在其中填写如下内容。

1
2
3
4
5
6
7
8
9
10
11

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

# DT
Host leolee
    HostName github.com
    User git
    IdentityFile ~/.ssh/dt_id_rsa

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

1
2

git@github.com:debugtalk/DroidMeter.git
git@github.com:DTSZ/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服务器的连通性时，可采用如下方式：

1
2
3
4

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

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

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

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

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

配置的方式如下：

在debugtalk/DroidMeter仓库中：

1

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

在DebugTalk/MobileStore.git仓库中：

1

➜ git remote add origin git@leolee:DebugTalk/MobileStore.git

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

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

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

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

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

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

在debugtalk/DroidMeter仓库中：

1

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

在DebugTalk/MobileStore.git仓库中：

1

➜ git remote add origin https://leolee@github.com/DebugTalk/MobileStore.git

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

Done!