您可能认为由以前由谷歌，Facebook，Microsoft，Yahoo等组成的团队在构建移动设备和Web应用程序的工具和基础架构方面已经看到了这一切。

作为问题团队，我们当然是这么认为的。但刚开始不久，我们就遇到了一个新的挑战，即为我们的移动组织在这里超级工程．你知道我们遇到了什么障碍吗?

你有没有使用过优步骑手应用程序？您是否熟悉典型的流量请求您的骑行到目的地下车？我希望你们许多读这篇文章可能会回答这些问题。现在让我们看看你有多少可以回答下一个。

什么是优步的典型流量司机应用?如果你不是司机，很多人可能不会意识到甚至还有驱动程序应用程序．更少的人知道它是什么样子。(也许只有那些在优步上偷看司机手机的人才会这么想!)现在回到我们的问题:是什么让测试Uber移动应用程序与谷歌地图这样的应用程序有显著不同?现在你能猜到答案了吗?

乘客的体验在很大程度上取决于无数因素:可用的司机选择、接受乘坐请求、接车的预计时间，以及到乘客的路线等。此外，司机和乘客可以相互联系。当你考虑uberPOOL时，这种跨应用的互动就会变得更加复杂。uberPOOL中有第二名乘客，还有一个额外的接送点。因此，我们的框架需要运行涉及多个应用程序和跨应用程序交互的端到端测试。

旅行流程:我们独一无二的问题

想象一下我们的基本场景，如尾随跳闸流程（1）骑手请求骑行，驾驶员接受它（2）驾驶员去拿起骑手，旅行开始（3）目的地到达时（3）开始（3）行程结束，骑手和驾驶员互相速度。下图显示了在此方案中作为测试状态更改的应用程序之间发送的信号：

现在想象一个更复杂的互动，比如匹配的uberPOOL旅行。在这种情况下，一名司机和至少两名乘客将涉及。我们如何同步三个不同测试目标之间的交互，以便它们可以无缝合作?

回想一下，即使在涉及两个测试目标的基本骑车者方案中，测试也在两个不同的过程中运行。我们需要弄清楚如何在不同的设备/模拟器上进行测试，以彼此通信。

当我们第一次望着了Appium测试自动化框架，我们提出了一个初始解决方案：配置骑手和驱动程序测试以启动与不同端口的各自应用程序，以便它们可以彼此通信。然而，在尝试之后，我们观察到额外的开销客户机/服务器通信测试用例和Appium http服务器之间的关系使事情变得缓慢和不稳定。测试有时会神秘地失败，可能是由于客户机和服务器之间的网络连接，而且错误很难诊断和故障排除。我们对问题了解得越多，就越确信需要一个更健壮的解决方案。

介绍章鱼:我们超级有用的解决方案

试着思考在大学进行操作系统理论并研究交叉流程沟通。我们知道如果我们能够实施可靠的信令机制，问题将得到解决。所以在2015年春天，我们在我们打电话的平台 - 不可知论式测试赛道中为iOS和Android创建了一个解决方案章鱼．

使用以前的骑手驱动程序示例，章鱼启动了两个模拟器/仿真器。它启动驱动程序应用程序并在启动骑手应用程序并在另一个时运行驱动程序测试，并在另一个上运行骑手测试。此外，它处理两个测试之间的进程间通信。

因此，两个测试共同努力以测试使用信令的端到端驱动器/骑车者跳闸流程：信号与字符串一样简单。信号的含义由测试用例内的逻辑确定。（在这种情况下，骑手和驱动程序组件在一起工作以使信号感。）当模拟器/仿真器的任何实例写入信号时，它指定应发送信号的目标目标。章鱼负责将信号传送到指定目的地，例如，从一个测试目标到另一个测试目标。

八达通提供两种与信号相关的方法:

readSignal():字符串

从当前信号通道读取下一个信号。每个测试用例都绑定到一个信号通道（串为信号名称）它可以读取信号。

writeSignal (signalContent:字符串,目的地:字符串):布尔

将信号写入一个信号通道，以便与该信号通道绑定的测试目标可以使用该信号获取信号readSignal．

（作为理解这一点的方式，想象一下，每个模拟器/模拟器如何具有收件箱和发件箱。发件箱包含要传递给另一个模拟器的消息。例如，驱动程序发出箱说乘客1 driver_online．章鱼会复制driver_online到乘客1模拟器的收件箱。然后乘客1可以开始请求骑行。）

的实现readSignal和writeSignal在Android和iOS上是完全不同的:

安卓

从测试目标（即仿真器或Android设备），没有直接访问测试主机（运行测试的计算机）。因此，必须通过测试主机转发通信亚洲开发银行(一个命令行工具，可以让你与模拟器实例或连接的android设备进行通信)命令。

测试主机定期检查是否存在输出信号。每当测试目标写信号时，和/数据/ tmp / < signal_name > .out在相同的测试目标上创建，测试主机从文件中获得信号指令。Octopus查看该文件，并将其内容复制到信号要用于的相应测试目标。

iOS

UIAHost对象在iOS UI Automation中提供了一个方法叫做performtaskwithpathpargumentstimeout.，它在测试主机上执行命令（例如shell脚本），收集退出代码和输出。使用此功能，iOS测试目标（模拟器或iOS设备）能够直接访问测试主机（测试测试的计算机）。因此，信令的实现比Android上的信号更简单。

章鱼在行动

在一个带有一个超级车辆和两个骑手的测试世界中，模拟匹配的Uberpool之旅是什么样的？跟随下面的幻灯片，在我们的Uberpool示例中查看章鱼在uberpool示例中，从第一个幻灯片上的登录阶段，到最后一个幻灯片上的第一个下降。左上方的模拟器是驱动程序应用程序;中间和权利是骑手应用程序：

在模拟中，您可以看到骑手1(中间)请求搭车。因为这是一个合成环境，一旦驾驶员(左)接受请求，骑手2(右)就看不到可用的汽车。不过，我们显示的是优步拼车，所以一旦启动，司机又可以进行匹配的旅程。骑手2的位置和目的地符合条件，所以骑手2现在可以请求相同的车辆。司机把两个乘客都接起来，然后按照他们旅行的顺序把他们放下。最后，司机在旅程结束时给每个人打分。

如果您发现此博客有趣，请遵循雷竞技到底好不好用@Ubereng.接收有关移动测试缺课团队正在建造的冷却工具的更新。很高兴能够在这个基础架构上工作？你喜欢推动边界的建筑工具吗？来加入我们并制作溅！有很多的可能性可以研究。

标题图片来自Apple Chow在2015年春天的一幅画。