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

前言

做过自动化测试的人应该都会有这样一种体会，要写个自动化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!

背景描述

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

1
2
3
4

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

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

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

1
2
3
4

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

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

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

1
2
3
4
5

➜ git clone git@github.com:XY/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代码的。

1
2
3
4

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

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

1
2
3
4
5
6

➜ cat ~/.git-credentials
https://leolee:340d247cxxxxxxxxf39556e38fe2b0baxxxxxxxx@github.com
➜
➜ cat ~/.gitconfig
[credential]
truehelper = 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，另一条是公司的工作账号leolee。

至此，真相大白！！！

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

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

总结回顾

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

并没有！

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

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

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

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

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

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

在微信公众号debugtalk中输入Git权限校验，获取《深入浅出Git权限校验》。

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

什么是促销活动页面？

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

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

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

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

四方面原因。

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

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

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

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

如何对活动页面进行测试

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

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

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

1、商品信息一致性

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

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

2、页面跳转行为一致性

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

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

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

3、页面兼容性

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

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

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

推荐的测试方式如下：

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

4、文案准确性

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

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

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

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

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

总结

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

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