关于自动构建：

　　Xcode提供了命令行工具来通过命令行进行工程的构建，在Xcode4.5中命令行工具是默认不安装的，因此需要首先安装命令行工具，安装方式如下：

　　安装完成之后可以使用xcodebuild命令来进行工程的构建了;

　　开始的时候工程的构建是通过shell脚本来进行的，后来发现在jenkins中提供了一个Xcode Plugin的插件，通过该插件可以可视化的配置build的参数，这个插件终使用的仍然是xcodebuild的命令行;Xcode构建的配置如下：

　　这里的配置项的用法和说明在后面的提示中都有包括，那么说说项目中的一些需求，基本上现在的项目测试自动化脚本都是在测试环境运行，然后发布的内测包都是线上环境的，而又不想把这样的工作通过jenkins中的两个Job来实现，因此这里的处理方式是设置了两个Xcode Step，第一个构建测试环境下用于进行自动化验证的版本(上图)，第二个用于构建内测版本的线上环境(下图);

　　两者之间提供脚本进行环境的切换，目前的问题在于由于各个项目的开发不同，因此用来做环境切换的方式也会不同，这样导致了需要为每一个项目提供一个如下的环境切换脚本：

　　用于在构建测试版本之前把环境切换至测试环境;

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

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

　　应用安装到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来提供;