3.2 将测试移到云端
作为专业的测试团队，我们很容易厘清该如何同时地测试一台服务器和一项服务。但是如何将现有的自动化测试丰富的资产应用到服务空间？最终的答案是：在线测试（Testing in Production, TiP），在当时看来这是我们之前决不会做的事情。我们的起点是一些现有的工具和资产，如表3-2所示。
① 用于描述软件公司使用自己的产品这种情况。
因为Exchange是世界上功能最复杂的产品之一，所以我们已经建了一个庞大的工程流水线来开发和测试我们的产品。其中仅测试实验室就有大约5000台机器用于运行日常的测试和预检入（pre-check-in）的测试。在这些机器模拟测试场景（如具有多级动态目录的网站、不同的故障转移配置、多角色配置等）的复杂拓扑结构中，我们每周对Exchange的80 000次自动部署进行相关测试。到2007年年末，我们已经编写了将近70 000个自动化测试用例来对产品进行验证，我们每天都运行这些自动化测试用例，且每次提交代码之前必须运行其中的某些测试用例。我们使用Microsoft Visual Studio作为我们自动化测试工具的开发环境，大部分是使用C#语言进行开发的，但也有少部分是使用JavaScript和C++语言进行开发。
与大多数微软的产品研发团队一样，我们要吃自己的狗食。在很多文章和博客上都谈到“如何把产品当狗食来吃”的概念。在这里，指整个Exchange团队将他们的邮箱装在团队的dog food（beta版）环境中或者基于云端的dog food环境中，为了增加复杂性，我们让两个dog food环境无缝地协同工作，即便每两周都要升级到最新版本，也是如此。
这一级别的自动化允许我们建立单一的主代码分支，并使之在多个产品单元之间具有一致的文件版本。这是通过维护一定数量的编译错误（构建过程中断）和最小范围的回归来完成的。在dog food中有了自己的邮箱，可以允许我们很快地找出被测试忽略的功能问题，并能增强对正在构建的产品性能的自信心。因为我们正转向基于服务的自动化，所以继续获得这种自信是非常重要的。我们采用的新工具和模型如表3-3所示。
我们的每一个新工具和过程都吸取了推出Exchange Server产品时的经验。对于我们来说，解决如何与别的服务进行集成，以及如何在产品数据中心进行传统的测试活动，是一个新的转折点。
3.2.1 TiP测试策略的目标
我们设定的TiP测试策略目标是：
积极主动地发现产品线所存在的问题；
积极测试服务dog food；
验证新的产品上线；
确认配置变更或升级不会导致任何中断；
通过我们的附属服务进行合作方注销测试，如Windows Live ID；
衡量并帮助提高现有的系统中心运行管理器（system center operations manager，SCOM）监控方案；
发现潜在的缺陷；
工程团队可以使用这些测试来了解产品试验。
有了适当的目标之后，就要将它们作为测试——尤其是TiP测试的指导原则，并保证它们与整个Exchange项目的目标是一致的。我们最终选中了一组专注于效率和重用的原则。效率原则是指在复杂度最低的环境中用最快的速度找出正确的bug集合，OneBox是最主要的资产。另外，我们还选择将许多OneBox测试环境搭建在数据中心。使用以上方法时，会出现很多因数据中心网络和安全设置所产生的额外bug。重用变得至关重要，因为它意味着将现有的资产和过程扩展到数据中心和产品中，用于更快地产生好的测试结果。
3.2.2 指导原则
我们使用以下原则来指导我们的开发：
没有独立的团队，现有功能的测试团队都要参与。
产品中同样的代码库意味着我们应该尝试着复用整个产品和测试资产（自动化测试、测试装置、测试工具和流程），但是现在就在产品线上。
在实验室完成功能测试，意味着我们要在产品线上做进一步的测试，通过扮演客户的角色来验证用户体验。一些TiP方法利用可测试性特性深入到在线网站的堆栈中去，但是在最初实施时，我们坚持使用模拟终端用户进行黑盒测试的方法。
对测试场景的设计应该考虑其测试的广度，而非深度（即尽可能多地描述测试场景的覆盖面，同时测试场景的执行尽可能地快）
【真知灼见】
明确自己的目标，并为自动化测试设计可以实现的指导原则。
