之前写过一篇文章，里面提到了分布式自动化测试和容器化技术相结合的一些架构思路。但目前分布式运行并不是难点。急需解决的问题是针对特殊平台和复杂场景的测试，比如iOS平台在复杂业务场景下的自动化测试。移动应用的特点是易用性和简洁的UI，让用户在移动端完成一件事的路径尽可能短。所以总的来说，我们遇到的iOSAPP场景要比Web应用简单一些。所以一般情况下，iOS自动化测试不会遇到复杂的场景，测试反馈时间短，效率也比较高。运行环境只需要相应版本的macOS系统和Xcode环境即可。但对于大型企业的移动应用，如电商平台、共享出行平台等，主要涉及到几个问题：1.测试用例规模大导致测试反馈时间过长主流的移动自动化测试框架Appium和葫芦。我从事的大多数项目都使用了其中一种。但是在Xcode7之后，iOSSimulator变得越来越慢（做iOS的同学应该都有体会），而且不幸的是，在iOS10和Xcode8之后，苹果放弃了UIAutomation，导致大量高效常用的API不可用.并且到目前为止Appium还没有发布iOS10平台的正式版lib和APP，导致部分用户无法使用inspector定位元素（使用ARC的用户除外）。虽然官方建议不要使用XPath进行元素定位，但有些时候我们不得不这样做。杀手锏是iOS的自动化受限于Apple的单例（一台物理主机同时拥有一个且只有一个Instrument）。所有这些最终导致iOS自动化测试的时间过长，更不用说多个iOS设备的兼容性问题了。自动化实施过程的成本太高，让大多数组织和团队食之无味，弃之可惜。2.复杂的场景无法在一台机器上测试。对于复杂场景的应用，我们很难通过现有的框架在一台物理机上同时控制多个不同的模拟器，也不能随意切换到系统级控制。查看APP触发的通知等。可以通过一些合法的手段，使用虚拟化在iOS端做并发测试（记住是合法手段）。但是这还是逃不过物理机的巨大开销和虚拟机的性能损失。抛开这个问题不谈，在复杂的场景下，比如出行平台，需要一台机器作为乘客下单，需要更多不同地址位置的车主来测试订单推送优先级等等。对于这样复杂的场景，Appium是很难控制的。3.测试场景需要在不同的app之间切换。现在很多APP的功能不仅仅在应用本身，可能还需要和系统应用以及其他应用进行交互。例如，用户在被测APP中进行操作后，需要查看通知，或者在测试过程中，需要切换到无网络环境来测试APP的不同行为。想到这些复杂的场景和各种坑，估计打算做iOS测试的同学要开始打退堂鼓了。下面我们一步一步来解决这些问题：问题一：解决Instrument单例的局限性困扰了这个问题很久了，那么业界领先的互联网公司是怎么做的呢？有一次看到Uber的Showcase，机器上启动了5、6个模拟器，使用不同类型的账号登录（乘客、车主），每个模拟器执行不同的行为。由于是在实体机上运行iOS模拟器，所以速度和性能都得到了很好的保证。他们如何解决Instrument的局限性？我们可以通过苹果私有API同时操作不同型号的模拟器，对多个不同的模拟器进行批量操作，如启动、重置、安装、运行等：问题2：解决控制不同iOS的不同行为复杂场景中的模拟器。xcodebuild命令允许我们在我们想要的设备上运行WebDriverAgent，但是如果我们使用Apple的命令，我们只能在单个设备上安装和运行它。每个设备都会自动关闭，但只会保留命令中的目的地，并且会默认开启8100端口来检测这个设备：如果是这样的话，我们之前所做的一切工作岂不是毫无意义？不用担心，我们已经有你可以使用Apple提供的资源来为不同的设备启动不同的进程端口来进行监控。这时候我们可以使用curl命令来启动我们需要测试的APP，我们可以很方便的获取到当前正在运行的APP的session：curl-XPOST'-H"Content-Type:application/json"'-d"{\"desiredCapabilities\":{\"bundleId\":\"com.apple.Preferences\"}}"http://localhost:8101/sessionresponse:{"value":{"sessionId":"94A6580F-1F0F-4411-AC64-3E2525BBA5E1","capabilities":{"device":"iphone","browserName":"Settings","sdkVersion":"10.1","CFBundleIdentifier":"com.apple.Preferences"}},"sessionId":"94A6580F-1F0F-4411-AC64-3E2525BBA5E1","status":0}同时，对于不同的设备，我们可以通过HTTP服务器启动inspector，帮助我们定位APP中的元素，即使是系统应用：问题3：解决不同的测试场景需要APP切换。有了第二个问题的解决，只要执行类似的curl命令，就可以得到不同的APP，不同的sessionId。是时候放弃Appium了吗？通过Uber的Octopus框架和Appium正在使用的WebDriverAgent，不难发现这个方案的推广速度和乐观的前景。我们可以使用不同的curl命令对不同的Simulator和APP进行query、tap、typing、touchid等操作，相当于Appium提供的最常用的API，而且由于不需要调整AppiumAPI首先通过WebDriverAgent直接与元素进行交互，不同程度地提升了测试执行速度，并且由于其强大的可控性和灵活性，可以轻松进行并发操作，支持复杂的业务场景。我们只需要对不同的curl命令进行封装，结合各自APP的业务场景就可以轻松完成。成本？可以说大部分团队都没有引入移动自动化。最重要的原因是编写成本高，UI变化快。我个人认为这个解决方案的成本远大于它带来的价值。QA不再需要学习一门新语言来编写脚本。所有与APP元素的交互都可以通过HTTP请求完成，元素信息以易读的JSON呈现。我们可以通过任何语言和框架编写后端自动化测试来完成iOS自动化测试。下面我们通过测试ThoughtWorks的StartKit（请点击原文链接），对登录页面做一个简单的测试demo，我们已经在三个以上的项目中使用了这个测试方案。总结由于项目因素，我们的实际场景会比较有限，这可能会长期影响我们的解题思路。我们应该时不时跳出工作来思考，把简单的事情复杂化，这样我们才能在遇到复杂的问题时，简单的去做。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
