在Jenkins下集成SwiftMonkey

在把swiftmonkey跑起来之后，首先想到就是要把它集成到Jenkins上，然后以后只要在Jenkins上定时触发就好了，就不需要每次自己去跑起来，然后对于APP一崩溃就停止monkey测试这一点，也总是想着有空去研究一下，让它也能像Android的monkey测试一样，可以忽视崩溃继续跑，而也只有这样，才能对APP进行更好更持久的随机压力测试。于是就迎来了今天的工作。

一、集成到Jenkins

Jenkins的安装，以及iOS打包集成的东西这里不会再讲，网上关于这些资料也太多，我这里主要就讲一下如何把swiftmonkey在Jenkins上跑起来。

首先，新建或者copy你要集成的iOS自动打包项目，最好手动拉一份全新的代码回来，然后在Jenkins下该项目目录下，用xcode打开工程，然后就开始把swiftmonkey集成到APP项目上，具体的操作见我的另外一篇文章《在OC项目下实现SwiftMonkey》，这里也不再赘述。

完成swiftmonkey的集成后，如果是在xcode上面，直接product->test，就可以把monkey跑起来了，但是在Jenkins下，只能通过命令行来操作了，大家也都知道xcodebuild，但是，xcodebuild如何执行product->test呢？

当时我在网上也找了蛮久的资料，研究了下xcodebuild的用法和各个参数等，也问了几个iOS开发，都表示不知道，于是继续网上找，后面搜索到搜狐测试团队分享的一篇文章，有提到如何在Jenkins上用模拟器跑单元测试，上面带的一个shell命令让我眼前一亮！

$ xcodebuild test -scheme testCI -sdk iphonesimulator7.0 -destination OS=7.0,name="iPhone Retina (4-inch)" -configuration Debug 2>&1 | ocunit2junit

首先是xcodebuild test，让我忍不住就认为这就是我要找的命令！但参数里带有“-scheme”和“-sdk”，对着两个参数的值如何来的，原文没有提到，然后继续翻xcodebuild的使用说明的时候，终于看到了“xcodebuild -list”和“xcodebuild -showsdks”；这两个参数搞定了，那对于一台真机或者模拟器的机器来说，要怎么描述呢？

我先在mac终端上按照命令的格式去执行，然而，真机并没有什么反应！！！

心塞，难道这个命令不对？但我心里是不愿意相信的，于是我又想着，先在模拟器上执行，看看O不OK先，试了下发现，模拟器还真启动起来了，但是为啥真机就不行呢？带着疑问继续度娘，无意在一篇文章说提到对“-sdk”的解释里面说“iphoneos是真机”，带着激动的心情把这个参数值修改好之后我执行命令：

$ xcodebuild test -scheme MyScheme -sdk iphoneos -destination OS=10.2,name="iPhone"

出错了！提示

xcodebuild:error:Unable to find a destination matching the provided destination specifier:{OS:10.2}

当时想着用“OS=10.2”来指定一台设备，本身好像并不靠谱，就又联想到之前搞macaca monkey测试的时候，有用到一个设备的udid，于是我就把“OS=10.2”改成“id=device udid”：

$ xcodebuild test -workspace myproject.xcworkspace -scheme myscheme -sdk iphoneos -destination id = "my device udid" name = "iphone name"

激动！跑起来了！于是赶紧把这个命令贴到Jenkins的monkey项目中的“Build”配置的“Execute shell”上（当然，提前是在你已经在shell打开到工程目录了），然后立即构建项目，可以跑起来，噢耶！

完成了集成swiftmonkey到Jenkins下之后，下一步，就是考虑，要怎么解决APP崩溃之后monkey就停止的问题了。

二、解决APP崩溃之后monkey测试就停止的问题

当时有两种思路，一种是既然国外友人实现了这个monkey的功能，想必肯定也支持忽视崩溃继续运行的功能，只需要找到对应的代码，修改一下默认参数之类就好了，于是就去研究swiftmonkey的代码，发现代码就一个while循环执行随机生成的事件，并没有自己设想的设置，然后要去改动swiftmonkey的代码，也暂时没那个冲动；然后另外一种思路就是，搞一个守护进程，在APP崩溃掉之后把它起起来，但是后来仔细一想，刚才不是已经用命令把swiftmonkey跑起来了吗，失败之后再执行一次命令，不就好了吗？

于是，课题变成了，在Jenkins上，如果在命令失败之后，继续执行下一条命令。在 https://stackoverflow.com/questions/14392349/dont-fail-jenkins-build-if-execute-shell-fails 找到了答案，把命令改成：

$ xcodebuild test -workspace myproject.xcworkspace -scheme myscheme -sdk iphoneos -destination id = "my device udid" name = "iphone name"||true

保存，然后立即构建，monkey跑起来了，过了一段时间去看Jenkins执行结果，发现这个构建，已经变为成功，而之前的monkey也停止了。这说明，我们把这条命令在执行monkey崩溃之后，也算是一条成功执行的命令，那就可以继续执行后面的命令，但是我们后面的命令，实际上也还是这条命令，所以，使用脚本搞定它就OK啦！

#！/bin/sh

while true

do

      xcodebuild test -workspace myproject.xcworkspace -scheme myscheme -sdk iphoneos -destination id = "my device udid" name = "iphone name"||true

done

把脚本放到项目目录下（这样就不用另外打开脚本存放的路径啦），增加文件执行权限：

$ chmod 777 xcodebuild.sh

然后Jenkins的“Execute shell”上把原来xcodebuild test的命令换成：

$ sh ./xcodebuild.sh

立即构建，大功告成！

三、总结

虽然在以上的讲解那里，我也把当时自己面临的问题，以及解决思路都写了出来，但是实际上，也仍然比上面写的遇到的问题要多，都是一个个研究尝试然后才得到解决的，甚至当中换成其他思路去执行，都有，只不过为了让这篇文章能更鲜明一点，才把相关的问题当主线串起来，其他跟主题关系不那么大的，但是又是实际遇到的，就没有讲了，还是那句话，只有执行过，才知道自己是不是真的掌握了，也只有去执行了，遇到问题了，才会去思考，会去寻求答案，最终解决问题，当问题都解决之后，那种兴奋之情，是无法言表的！