在一文中，我对如何使用Jenkins搭建iOS/Android持续集成打包平台的基础概念和实施流程进行了介绍。本文作为配套，对搭建持续集成打包平台中涉及到的执行命令、构建脚本（/035aaf10acf5dd7c279c4fe423a57674

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

在这里，我们用到了HTML的标签，而Jenkins的Markup Formatter默认是采用Plain text模式，因此还需要对Jenkins对系统配置进行修改，在中已进行了详细说明，在此就不再重复。

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

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

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

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

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

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

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

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

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

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

• 完成配置文件替换和重启后，刚创建好的Job就已完成了大部分配置；
• 在Job Configure中根据项目实际情况调整配置，其中Git Repositories是必须修改的，其它配置项可选择性地进行调整。

微信公众号： 原文链接： 构建脚本&配置文件：

　　Appium框架原理介绍

　　基于Appium框架的自动化开发环境搭建

　　自动化case开发及分层结构设计

　　功能自动化接入持续集成方案

　　Android常用功能自动化框架比较

　　了解各个自动化框架的特性，结合产品自身特点，选取一个合适的框架尤为重要。

　　Appium框架原理介绍

　　testAccountLogin Case中，执行了两步操作：进入登录页面；执行登录操作。这两步操作都封装在Account类里面。由此引入自动化case的分层设计框架，如下图：

　　自动化开发过程中，经常遇到的一个问题是，随着产品的不断更新迭代，APP的UI会不断发生变化，自动化如何去应对这样的变化，如何降低其维护代价。case分层设计主要是基于自动化可维护性的考虑，可维护性是功能自动化最重要的评价指标之一，其直接决定了自动化是否能开展下去。试想case数量达到一定程度时，若没有采用封装、分层的设计思路，极有可能出现“牵一发而动全身”的问题。下图是标版自动化case的分层目录图。

　　doLogin()方法中执行了“输入用户名；输入密码；点击登录按钮；判断登录是否成功”操作，显然这几步操作都在UI层LoginUiAction类中。我们再查LoginUiAction.getInstance().

　　enterUsername()方法中做了什么，代码片段如下：

　　enterUsername()方法中，先根据id定位用户名输入框，然后清空输入框，再输入用户名，这些操作都是Appium Client中提供的API。至此演示了登录case的分层调用过程：cases—>business—>ui—>api。按照分层结构，只要业务逻辑不变，case维护任务主要放在ui层，上层无需改动，如此可极大减少case的维护代价。

　　在doLogin()方法中有一个“判断登录是否成功”的操作，断言操作是自动化测试用例中必不可少的一部分，下面就开始介绍自动化测试用例的书写规范。

　　自动化测试用例书写规范及注意事项

　　一条case一般需要包括如下几个要素：

　　数据准备指提前准备测试账号，假数据等；具体操作得按照业务测试同学提供的文本case来转化；验证点指自动化操作后，UI前后的变化点，比如登录后，首页会出现用户名、总资产、财富分等控件，这些都是验证点；清楚操作结果主要是基于case独立性的考虑，尽可能做到每条case是独立的，这样某条case fail了，也不会对其他case造成影响，当然这样会增加case的粒度，case稳定性会受影响，两者之间可自行平衡。

　　下面介绍case开发的注意事项：

　　2、UI操作需要合理的sleep

　　3、case独立性

　　5、注释及case前写明操作步骤

　　元素定位有ID/文本/控件类型/坐标四种方式，推荐使用ID,因为只要某个控件还存在，其ID变化的可能性很小，若其位置发生了变动，case都无需维护。

SDK中，配置好环境变量后，直接在命令行输入命令即可打开图形化工具，hierarchyviewer需要手机root，推荐使用uiautomatorviewer。如果有待测应用的源码，也可以通过源码来找ID，当然这种方式比较痛苦，但对熟悉业务及个人成长是有好处的，我最开始就是通过源码来找ID的。

　　case独立性前面已介绍，封装及注释容易理解，不做过多解释。

　　功能自动化接入持续集成方案

　　功能自动化一般用于项目集中测试、回归测试、dailybuild等，我们不可能通过IDE手动来运行case，一般可借助于jenkins或平台化的方式来批量执行case。下面介绍如何将功能自动化接入jenkins。

之前在项目中引入的单元测试使用的是JUnit，可以在构建前进行测试，这里在介绍一下使用Instrumentation 进行单元测试。使用Instrumentation进行测试，比之前多一些步骤，需要把打包apk上传到仓库，然后运行虚拟机，把apk安装到虚拟机中。

2. 被测项目的Jenkins设定中，“Goal 及選項” 加入install，用来把打包的apk上传到仓库中。

3. 建立另一个Jenkins专案，用来构建测试项目，测试项目的签名需要和被测项目一致。

4. 被测项目的Jenkins设定中增加“建置後動作”，“建置其他專案”，填写测试项目的名称，“Goal 及選項” 加入integration-test或者install以触发测试。install命令会包含执行integration-test，执行integration-test会讲apk上传到仓库并安装到设备，如果没有可运行的设备就会报错。所以如果项目只需要上传apk到仓库，不需要安装到设备的话，请用package

5. 测试项目的pom.xml中加入被测项目的依赖。

7. 构建被测项目，被测项目在完成构建后会自动触发测试项目的构建。