自动化测试最佳实践连载七

　第3章　移动到云端：TiP的演化——在线的持续回归测试

　　Ken Johnston

　　Felix Deschamps

　　来自微软公司的Ken Johnston和 Felix Deschamps讲述了他们是如何通过在云端实施自动化测试，从而将基于产品的自动化测试变更为基于服务的自动化测试的。微软的邮件服务产品Microsoft Exchange Server中绝大多数的测试已经实施自动化了，而且其中大量的自动化是可以重用的。大多数测试人员对于“在线测试”（Testing in Production, TiP）这个概念还比较陌生，但是这一章解释了为什么进行持续监测是必要且有益的，同时为那些也正在考虑这么做的人提供了一些非常有用的小窍门。案例发生在美国，经历了3年多的时间，毫无疑问，使用到了微软公司的一些工具，如表3-1所示。

　　表3-1　案例研究特征

　　3.1　本案例研究的背景

　　你会将一个价值十亿美元的业务作为赌注放在云端吗？

　　Exchange 2007的发布对我们团队来说是非常令人振奋的。在刚推出这款产品的时候，我们已经成功地对产品架构进行重新设计，以使它能在本地的.Net平台上运行，从而转化到通过“角色”（role）来支持服务器管理，把64位机器作为目标平台，采用Windows PowerShell作为自动化服务器管理的工具箱。我们已经做好了迎接下一个挑战的准备！

　　那时，微软的总架构师Ray Ozzie正准备构建微软云计算未来的发展蓝图。我们都很清楚，云计算将会越来越重要，而正好Exchange产品也在寻求这种百年一遇的重大商机。通过云计算，我们可以在为客户降低成本的同时，给他们提供更好的服务，同时，我们也可以将Exchange产品中的业务发展壮大。

　　实施云计算这一举措也为我们引入了更多的问题。我们如何构建一组特性来吸引IT专业人员升级到Wave 14 （发布名称为Microsoft Exchange Server 2010）版本，同时又能以某一服务作为目标呢？我们又该如何对产品架构重新进行设计，以使它能够在运行遍布全球的服务前提下实现规模经济效益呢？何况现在我们不仅仅需要构建所需的软件，而且还要构建数据中心，这从何做起？

　　我们进入到完整的原型和发现模式。我们学习了很多新的web服务概念，以便通过冗余将服务进行纵向和横向扩展：

　　我们需要对多租户进行架构设计，这样单个服务实例就能服务于多个客户组织（租户）。

　　我们将为了满足某个功能的一组逻辑上的机器确定为不同的单元（有时称为小群组），这样有利于规划所获取的单元。

　　服务必须是遍布全球的，以支持业务连续性规划（Business Continuance Planning，BCP），并通过区域市场减少延迟。

　　我们学习了如何使服务成为一种业务，以及为什么必须对固定资产费（Capital Expenditure, CAPEX，如购买新的服务器开销等）、运营费用（Operational Expenditure，OPEX，比如给经营服务的员工发放工资等）以及总销货成本（Cost Of Goods Sold，COGS）进行管理。懂得了服务器并不是像变魔法似的出现在数据中心，恰恰相反，我们必须提前一年就拟定采购计划，同时，对整个数据中心的空间大小、供电和网络配置也要进行安排。对于那些曾经从事过一段时间的服务工作的人来说，这听起来都是些基本的知识，但是我们想让整个团队的人员都清楚这些服务理念，并真正懂得我们将服务业务实施云策略的意义。

　　受到以上学习过程的启发，我们决定使用以下的一组原理来推动Wave 14的发布：

　　复用和扩展现有的基础设施。

　　Exchange将保留一个代码库。

　　我们的团队是一个整体，不会分裂为服务工程团队和服务运营团队两个独立的团队。

　　3.2　将测试移到云端

　　作为专业的测试团队，我们很容易厘清该如何同时地测试一台服务器和一项服务。但是如何将现有的自动化测试丰富的资产应用到服务空间？最终的答案是：在线测试（Testing in Production, TiP），在当时看来这是我们之前决不会做的事情。我们的起点是一些现有的工具和资产，如表3-2所示。

　　表3-2　Exchange产品测试的现有工具和资产

　　① 用于描述软件公司使用自己的产品这种情况。

　　因为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所示。

　　表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方法利用可测试性特性深入到在线网站的堆栈中去，但是在最初实施时，我们坚持使用模拟终端用户进行黑盒测试的方法。

　　对测试场景的设计应该考虑其测试的广度，而非深度（即尽可能多地描述测试场景的覆盖面，同时测试场景的执行尽可能地快）

　　【真知灼见】

　　明确自己的目标，并为自动化测试设计可以实现的指导原则。

　　3.3　如何实施TiP

　　第一步是让测试经理也支持这些指导原则，然后再与团队的资深成员紧密合作，并根据所有主要功能区对原则进行评审。这一过程保证了我们之间没有隔阂，并且能够很好地在不同领域利用测试人员的专业技术知识。这个虚拟团队定义了40多个场景，这些场景代表了视为最重要的功能的宽度。

　　【真知灼见】

　　避免白费力气做重复的工作；尽可能地复用现有的自动化测试件。

　　第二步是决定如何将上面的40多个场景在整个产品系统中具体实施。如前所述，我们要尽可能地重用已有的资产，所以我们集中精力尽快定义和开发出所需的测试。最初实施时，我们决定使用现有的测试执行框架来运行测试，那样的话，就可以重用现有的测试报告工具、机器管理等，这也使得我们可以利用现有的自动化测试库。

　我们的第一次实施的具体结构见图3-1。每小时执行引擎都会自动部署一台新机器，并安装相应的客户库、工具和测试，也安装一个“云定义”文件，该文件以一种通用方法描述了目标环境。测试本身并不知道目标环境的任何信息，通过这种抽象的方法我们可以指向某个数据中心、某个逻辑单元或者某台特定的机器（实际上现在是在预检入工作流中完成的）。

　　【小窍门】

　　另一种级别的抽象：将测试从机器和它们所运行的环境中分离出来。

　　图3-1是TiP系统拓扑结构的第一个版本，具有如下特点：

　　1）部署一台自动化测试主机，在特定的数据中心运行测试。

　　2）将测试结果发送到Focus测试执行（Focus Test Execution, FTE）服务器上，它将对测试结果进行处理（Focus是工具的名称）。

　　3）结果将保存到一个公用数据库上。

　　4）在运行过程中，TiP诊断服务周期性地对结果进行收集。

　　5）收集的结果会返回给数据库。

　　6）遇到问题时，产品bug会自动显示出来。

　　7）诊断服务给管理区发送一个请求信息，包含分页调度和报警信号的逻辑信息。

　　8）请求信息被发送到SCOM根管理系统（Root Management System，RMS）进行处理。SCOM的警报解除了，同时启动相应的响应处理机制。

图3-1　Exchange TiP第一个版本的系统拓扑结构

　　最初，在将服务提供（为用户注册和新建邮箱）给新用户之前，我们通过测试来验证服务的新部署。后来我们发现，尽管如此，与传统的以软件为中心的世界中我们只需保证软件质量不同的是，我们现在所经营的服务是一直变化的。不仅配置（域名系统（Domain Name System, DNS）、补丁、新的租户等）经常发生变化，更新的变化也很多，这意味着随着时间的增长，可能会遇到没有测试过或预料到的更新或者小的配置变动。根据我们的经验，即便是对产品来说安全的改变也可能会使服务中断。这也是为什么我们决定采用连续运行测试的方式，而不仅仅只是在进行部署的时候运行一次。

　　TiP具有一点类似产品服务监控器的作用；然而，相比于传统的轻量级服务监控，我们所运行的测试集更深入，端到端（end-to-end）场景鲁棒性更强。同样，TiP测试就变成了煤矿中的金丝雀，能对潜在用户面临问题提供更早的警报。过去是使用其他构建在Microsoft System Center顶端的基于代理的监控解决方案，然而，这些代理只是停留在单机器层面。TiP测试作为最终用户来运行，并且当它们使用性能降低的时候，会发出警告。

　【真知灼见】

　　不要仅仅通过一种途径来实施自动化，尽可能使用多种有用的方法。不同方法之间可以互补并且往往比单独使用一个方法更有效。

　　作为我们整个决策的一部分，我们决定停止使用第三方服务，像Gomez和Keynote。虽然在整个决策中非常重要，这种类型的监控关注的主要是一些比较片面的场景（比如登录）的服务可用性。与此同时，TiP场景的宽度比其他测试要小（高级测试只有40个测试用例，而实验室运行的端到端的场景中有70 000多个测试），所以比一般服务的深度肯定是要大些。

　　通过使用自己的基础设施，例如，我们可以很容易地给手机的ActiveSync协议添加新的验证信息，这在传统的黑盒监控环境中是很难做到的，因为协议具有复杂性。另一方面是敏捷度，根据产品环境和测试本身，在数据中心我们可以进行更改并对更改作出快速回应。因此，正如只关注单机器的SCOM监控基础设施一样，这些TiP测试对外部黑盒测试是一种补充，而不是取代它。

　　3.4　每月服务评审记分卡样例

　　每个月都会对总体的服务质量（Quality of Service, QoS）进行一次评审，同时，根据上个月的结果进行有针对性的改进也是要进行评审的。这种评审有利于持续改进总体服务，并帮助改进TiP套件。这种每月的评审是由经理发起的，并且他每个月都参与其中，推动问答(Q&A)环节的进行。这也是他每个月深入实况网站并对其进行改进的一次机会。经理的支持和带动作用对任何一个类似这样的项目都是至关重要的，而我们从一开始就很幸运。图3-2所示是一个记分卡的例子。

图3-2　调整记分卡中的事故和调整情况

　　3.4.1　阅读记分卡

　　当你看到TiP记分卡时，提出的第一个最典型的问题就是：怎么阅读记分卡？这是一个很好的问题。

　　首先需要注意的是，图3-2中所示的记分卡只是每月进行评审的幻灯片中的某一页。首先将每月的数据放到一个很大的Excel数据表格中，然后高级管理层和其他团队将Excel中的每项数据放到一页幻灯片中进行评审。

　　图3-3显示了将记分卡按不同的区域进行分解后的情况。区域1提供了指向Excel表格中具体行的标记。因为幻灯片中空间有限，所以只显示了最近3个月的数据，但事实上，Excel电子表格包含的不仅仅只是这3个月的数据。在评审过程中，每个人都有这个Excel电子表格的一份副本，并通过在自己的笔记本电脑上进行评审来对幻灯片的内容进行更新。

　　区域2是细分（drill-down）后的区域的名字。在给出的例子中该区域的名称是“事故及调整情况”。

　　区域3是从Excel表格报表中拉出的数据。包括度量的名称以及最近3个月的数据。在图3-3所示的样例中，数据根据事故数量和服务组件，按月显示。当整个Exchange 云端服务的某个组件发生了一次故障，并需要人工干预来进行解决，则称为一次事故（incident）。通过最近3个月的数据，即便在已经达到每月目标的前提下，还可以帮助我们确认服务的发展趋势是好是坏。

图3-3　事故记分卡区域中的事故和调整

区域4是整个记分卡最重要的部分。在每个月评审之前还有一个预评审，是由负责改进该区域服务的工程师进行的。在遇到事故和调整的情况下，测试、开发和运营团队中的成员都会派代表参与预评审。他们分析数据，找出异常值和负面走向线。风险区域和关注区域分别用绿色和红色的圆点标记。在图3-2中，黑色的实心圆点代表红色，或者是PPT幻灯片中应关注的区域。有时候他们知道某一个度量的趋势走向不好的具体原因，但是更多的时候，他们只能进行猜测。此时就要依靠虚拟小组的成员来找出负面走向度量和异常值的根本原因。上述调查的结果就是图3-3中记分卡区域4的内容。通常，如果造成负面走向的根本原因是已知的，那么区域4中的内容就是一些总结性的建议补救方法。

　　【真知灼见】

　　对报表进行裁剪，使它仅提供你所需要的有用信息。

　　3.4.2　对事故和调整报表的处理

　　根据事故和调整记分卡，可以分析各个方面引起的事故。引起事故的原因包括SCOM服务器级别的监控器、TiP服务级别的监控器，以及与第三方监控一起运行的一些监控器，旨在保证我们与全球市场都有联系。影响我们减少用户方面bug的能力的两个主要因素是：一是监控过程中遗漏的真正问题的数量和严重性，另一个是等待时间(Time To Engage, TTE)。在整个行业和微软公司内部都有很多计算TTE的公式。对于Exchange来说，TTE是指从产品事故开始到找到合适的工程师（开发人员或测试人员）着手修复该故障所花费的时间（以分钟计算）。一般来说，不管是在业务时间还是之外，导致TTE很慢的最典型的原因是监控器遗漏。这两个度量紧密相关，并且是每个月关注的重点之一。它们中只要有一个出现问题，我们就要考虑需要更新哪个监控方案（SCOM、TiP，或第三方监控），有时候会给这3种监控方案都增加监控器。

　　TiP功能可用性记分卡用来提供粒子级别上服务可用性指标。可用性是通过以下公式来计算的：

　　通过为每个特性运行TiP，我们可以发现非客户影响的小的服务中断的发生，如ActiveSync中断。子服务中这种短暂的中断可能并不会对客户产生影响，但是却代表了服务的风险和退化。间歇失效或者（挂起）队列，与服务提供一样，通常都是可以在这个记分卡上显示出来的，但是并不是在关注调整的那张记分卡上（见图3-4）。

图3-4　TiP 功能可用性记分卡

　　【真知灼见】

　　经常利用自动化测试生成的信息来监控服务的发展、寻求进一步提高、保持自动化优势的前景，这是非常重要的。

　　（未完待续...）

qileilove