基于 KIF 的 iOS UI 自动化测试和持续集成(8)

我们希望在代码改动发生的时候就做到尽早发现代码改动带来的问题，所以使用 “Poll SCM” 在当代码仓库有新的 pull request 的时候触发相应 Job 完成构建，Job 的执行结果作为这个 pull request 能否合入的衡量指标之一；同时为支持客户端支持 daily build ，Job 使用 "Build periodically" 在每天 daily build 打包前完成一次自动构建。
Job 需要支持命令行构建才能实现持续集成，如上一部分提到，我们可以借助 xcodebuild/xctool 实现单命令行构建。同时为了衡量 Job 的执行结果，我们需要在 Job 执行完成后生成相应的测试报告和代码覆盖率报告，使用 xcodebuild/xctool 这样的命令行工具，只需要配置相关的参数即可获取相应的 XML 测试报告文件。
Jenkins 中 JUnit Plugin 插件可以将 XML 形式的测试报告转化成一种随时间推移的测试结果图表，向我们展示测试的结果和测试的稳定性； Cobertura plugin 插件可以将 XML 形式的覆盖率文件转化成一种随时间推移的代码覆盖率图表。如下图是 Job 中测试报告的代码覆盖率和测试结果的示例，通过下面的图表，我们可以清晰地看到测试是否通过，检查代码的测试覆盖范围，并对比历史的测试结果和代码覆盖率来推断和定位问题。

3. KIF 自动化测试在 Jenkins 持续集成过程中遇到的问题

我们的测试用例覆盖了第一次安装启动的操作。在初期，这个用例经常失败。经过排查发现，持续集成系统中的模拟器设备重置操作并没有覆盖所有的设备，UI 测试 Job 运行时，Job 选择的模拟器设备上可能遗留了其他 Job 构建的相同的 app 产物，导致我们的 Job 构建产物并不是第一次安装启动。所以在脚本中我们遍历所有模拟器设备，将其进行重置。

我们的测试用例在输入框输入文字时，经常出现输入不全而导致失败的问题。比如在输入框中输入 'beijing' ，失败后提示：Failed to get text in field; instead, it was 'beiji' 。经过排查，发现持续集成系统中的机器性能有高有低，在低性能机器中更容易发生此问题，再研究 KIF 框架源码发现，KIF 默认设置的键盘敲击时延为一个常数，对于低性能机器来说这个敲击时延较短，容易漏掉输入，所以我们在 KIFTypist.m 源码文件中适当增加 (NSTimeInterval) keystrokeDelay 的时长来避免输入不全的问题。

原文转自：https://zhuanlan.zhihu.com/p/22283843