两年前，我们重写了我们
移动端（iOS，
Android）的应用，使用了原生的开发栈（native development stacks）代替我们以前定制开发的
Web 栈(custom web-stack)。这给了我们在关于项目在那里/怎样下载、缓存、释放等等方面一个更好的控制。它分别深入地和
操作系统整合在一起，提供在底层调整修改所有系统的一整套工具。
测试是我们开发的一个重要部分，但在转换到原生的之后，我们没有了 A/B 测试的能力。并不是每个测试都可以用到生产中，但即使是失败的测试也能帮助我们理解如何才能更好地改进。失去的这部分能力变成了一个我们要应对的挑战。
A/B 测试
要把我们的应用移植到 iOS 和 Android 上，需要来自不同团队的人来进行协作，每四周就要产生一个新的修复一些 bug 和带有一些新特性的二进制软件包。在我们发布一些更新之后，对于我们很重要的事情是要去明白：
● 新特性的使用情况
● bug 修复后的运行情况和稳定性
● 用户界面改进之后用户是怎么使用这个应用及在哪里花的时间多
为了去了解这些事情，我们需要一个移动端进行 A/B 测试的基础组件，这个组件能让我们的用户分别使用不同版本的应用（版本 A 和版本 B），这些版本在除某些特别需要测试的部分外，其他各层面都是一样的。所以我们创造了 Airlock，一个可以让我们比较不同版本应用的度量数据（metric data）和进行各种各样测试的
测试框架，这帮助我们决定采用那个版本或者后续如何迭代。
从一点一滴中建成
我们尽可能从最简单的试验开始：使用已有的 Web-Stack A/B 分箱（binning system）系统。我们构造了一个测试：把聊天按钮换成文字"Chat"的试验。当应用启动的的时候，它会发送一个到我们服务器上的网络请求，询问这个试验的参数。当有回应返回后，我们就会更新按钮。一些员工会有按钮，另一些员工会有文字"Chat"。我们期望这仅仅会影响信息发送的数量（看起来不会太多），其他的东西不会受影响。
曝光日志
当这个版本的应用公开发布了，我们等待数据能稳定下来，然后发现看到文字"Chat" 的版本会更热衷于使用这个应用。是不是我们发现了什么秘密，或者诱惑般的魔法？沮丧地说，并不是。我们遇到了很多 bug，其中一个很大的问题是，某个组件并不能正确地缓冲数值。由于这是个大的系统，基础设施（the infrastructure）必须要是 "防弹的"，不然收集到的数据就没用了。
从服务器开始的数据管道决定某个人的版本是属于那种变体的。然后，数据就会被打包，接着发送到设备上，设备分析返回的信息然后保存。接着，这个值会被用于重新配置 UI，然后最终在屏幕上显示。问题是我们在依靠服务器对我们数据分析的分类。一个简单的 bug 就导致了一大群用户在使用有别于我们期望的的变种版本。服务器还在坚持："我告诉了设备去显示字符串！" 但在某处地方这个语句变得有点令人模糊（一个在客户端存贮逻辑上的 bug）。
一个试验的部署图：
上面图表展示了一个试验的部署。浅绿色的条柱是试验用户的数量，黑绿色的条柱是实际被影响的用户数。我们可以看到，服务器和设备的数据区别还是很大的: 在第一天，大多数用户收到这个配置，但大多数用户没有留意到我们试验。
当问题不仅仅是设备收到返回的数据，而需要加上我们的数据分析需要知道什么时候收到信息，然后把它正确地显示在 UI 上时，问题变得更大了。即使信息能正确地到达，在 UI 不正确时也有一个延迟。我们通过
添加双向握手（wo-way handshake）解决了这个问题。设备请求用于试验的数据，服务器记录它发出的回应。因此，即使某用户没有看到我们想让他看到的，我们仍然可以进行正确性分析（但也必须意识到选择性偏差（selection bias）的问题，还有分发时由于某些原因变得不平均）。
可伸缩性
在进行了几个月这样的"课程"之后，我们必须将支持两个试验的系统升级支持整个应用的系统。这个促使 Airlock 发生变革的试验是以前我们原想着进化和简化我们应用内的导航模块而开发的。在经历这几个月之后，我们把这个应用改变了很多，你可以去下载 Facebook for iPhone 来体验一下，这里面很多是测试的功劳。
随后，Airlock 被用于支持更多的试验，其请求的参数，数据的记录、客户端计算等等都快速地变多。Airlock 充分地被用于测试原生的应用，使得我们的应用运行得前所未有的轻快，伴随着测试的自由，再测试，和评估测试结果，我们期望能建造更好的测试和创造更好的用户体验。