iOS系统下的持续集成实践(3)

　　在构建完测试版本之后要准备进行内测版本的构建工作，这个时候需要再将环境切换至线上环境;

　　这种由于项目中提供的环境切换方式不统一导致的问题需要在后面和开发形成统一的共识，以减少切换脚本的多样性，形成同一个脚本来进行修改，减少维护问题;

　　应用安装到iPhone上需要的是一个ipa包，因此需要将构建出来的正式版本打包成ipa包，然后提供给内测下载服务器，而Xcode Plugin提供了打ipa包的功能，Xcode Plugin制作ipa的方式是通过xrun命令行来进行的，打包ipa的配置如下：

　　在制作ipa包的过程中需要提供mobileprovision文件和签名证书(注意提供给内测使用的ipa需要的是企业级证书，因此注意检查工程的配置或者提供shell脚本修改project的配置);

　　关于单元测试：

　　在上面的部分其实少了一部分就是关于单元测试的内容，iOS提供了一个单元测试的框架SenTestingKit，通过这个框架可以对iOS进行单元测试，而Xcode Plugin允许在每次构建的时候执行单元测试，因此就可以通过Build来及时的把问题反馈给开发，也更便于开发定位问题原因;

　　那为何在本地的整个持续集成中没有这部分的内容呢?关于这个问题的考虑是这样的，本地这边客户端对于业务的封装是通过提供一系列的Service实现，这些Service构成了客户端业务的SDK，负责实现客户端主要的业务逻辑，但是目前这些Service比较“薄”，基本都是对与后端的http请求，然后将对应的结果包装成为对象返回调用方，因此这部分的测试可以通过对于后端提供的http接口的测试来覆盖，因此在这里缺少了对于单元测试的描述。

　　关于自动化验证：

　　在进行这些所有工作之前其实第一个想到的是自动化，希望可以通过自动化来对主要功能进行验证，减少成本;于是就对目前的自动化框架进行了调研，参考了其他团队的方式，最终选择了使用athrun来作为本地的自动化测试框架;

　　Athrun对于iOS自动化提供了底层的支持，而业务线需要根据具体的情况去搭建上层的结构，就好比搭积木，底层的积木块提供了出来，搭成房子还是搭成汽车就是上层的事情了;

　　分析了一下iOS客户端的特点，一般来说客户端的界面不是很多，一个基础的业务操作基本都在一个界面中就可以完成，很少会出现跨越多个界面进行操作的基础业务操作，其次就是客户端每个界面上需要输入的数据都不会很多，因此也不太需要提供专门的数据层来对测试数据进行支持;针对以上的特点对于业务的自动化测试脚本进行了分层，由上至下分为了四层：

　　<!--[if !supportLists]-->1) <!--[endif]-->第一层是测试用例集层，该层负责整合测试用例集，物理的对于测试用例进行划分，按照一定的逻辑将测试用例整合起来;

　　<!--[if !supportLists]-->2) <!--[endif]-->第二层是测试用例层，该层提供了实际的测试用例脚本，测试用例由业务操作组合起来，形成各自的业务场景;

　　<!--[if !supportLists]-->3) <!--[endif]-->第三层是业务流层，该层提供了对于客户端应用的业务操作的封装，为测试用例层提供可复用的操作;

　　<!--[if !supportLists]-->4) <!--[endif]-->第四层是元素层，该层提供了操作界面元素的接口，这部分完全由athrun来提供;

　　代码的组织结构如下：

　　测试用例由业务流的操作组合而成，同时添加必要的验证，测试用例的结构如下所示：

　　而这些业务流的初始化与清理工作完全由每个应用的测试用例基类来进行处理，测试用例基类的写法如下：

　　随着自动化测试的开展和新的项目开展，新的问题也一个个的出现了，这些问题包括：

　　<!--[if !supportLists]-->1) <!--[endif]-->开始的时候没有使用jenkins，同时由于机器的IP地址没有办法固定下来，因此没有办法得到需要的测试报告，于是提供了一套机制来生成测试报告，测试报告的生成结果如下：

　　后来使用jenkins来进行持续集成，该测试报告生成方式被抛弃;

　　<!--[if !supportLists]-->2) <!--[endif]-->电影票客户端数据每天都需要更新，如此数据准备的操作需要放到自动化中来解决，于是提供数据准备和数据清理工作，提供@DataPrepare和@DataClear来进行数据准备和数据清理的配置;

　　<!--[if !supportLists]-->3) <!--[endif]-->测试环境有时候不太稳定，一些测试用例在第二次运行的时候就可以通过，问了解决这个问题提供了@Rerun标签来对失败的测试用例进行再次执行进行配置，允许设置重复执行的次数;

　　<!--[if !supportLists]-->4) <!--[endif]-->后来环境就更恶劣了，已经不是靠重复执行就可以解决的，同时也希望当测试环境有问题的时候就不要运行测试用例，为了解决这个问题提供了@CheckEnv标签来检查环境;

　　这些部分的特点都是与业务基本上没有相关性，因此在这里的做法是将这部分独立提成一个工程，该工程为各个业务的自动化脚本提供支持，同时在这个工程中处理了运行自动化脚本时的内存泄露和异常退出时再次运行无法启动app的问题;

原文转自：http://www.ltesting.net