应用 Visual Studio 2010 辅助敏捷测试（下）

相关链接

应用Visual Studio 2010 辅助敏捷测试（上）

实现自动化测试用例——自动化测试用例框架

随着需求的不断变化和迭代的深入，代码库不可避免的会有频繁的签入和签出，此时测试人员一项很重要的任务就是要预防回归问题发生。执行手工测试用例可以帮助我们预防及和发现回归问题，但是它的执行效率太低，无法胜任频繁执行的要求。这时就我们需要考虑采用自动化测试用例完成这项工作。决定是否采用自动化测试是有很多因素决定，其中很重要的一条就是自动测试的收益，下面的公式从概念上解释了如何来计算这个收益，当收益值大于1 的时候，实施自动化测试就是合算的；否则，就是不合算的。

图1：计算收益公式

这其中，开发和维护自动测试的成本是影响这个收益的重要因素，为此VS 2010 提供了一整套的解决方案，帮助测试团队减少这部分成本，这包括前面我们所提到的测试计划和用力管理工具，以及后面将会要介绍的生成和实验室管理。此外，Visual Studio 提供了多种测试工程模板，帮助测试人员开发自动化的测试用例，如下图所示。

图2： Visual Studio 提供的多种测试模板

这些测试工程模板可以帮助测试自动化工程师，在 Visual Studio 集成开发环境中创建和管理单元测试、功能测试、Web 性能测试、负载测试等等一系列的自动化测试用例。这其中，编码的 UI 测试（Coded UI Test，以下简称为 CUIT）是首次出现，是 VS 2010 测试部分一大亮点。测试人员可以通过它使用 C#或者 VB.NET 语言编写自动化测试用例，从用户界面层驱动 Web、Winform 或者是 WPF 的应用。CUIT 为测试用例的自动化提供了一个框架、API 和可扩展的接口，测试人员可以很轻松地开发出所要的自动化测试用例。其实 CUIT 背后的测试自动化实现技术对大家并不陌生，下面列出针对 Web、WinForm 和 WPF 应用的测试技术基础。对每种技术的支持采用的是插件的形式实现的，VS 2010 包括了如下的三种插件：

• Document Object Model（DOM）插件 : IE 7/8 HTML/AJAX
• User Interface Automation（UIA）插件 : WPF
• Microsoft Active Accessibility（MSAA）插件 : Winform，Win32 和 MFC 。MSAA 插件是默认选项，用来支持出其它两者之外的任何应用。

CUIT 现在支持主要的微软平台，详细的内容可以参见 MSDN : Supported Configuration and Platforms for Coded UI Tests and Action Recordings 。对于那些尚不支持的平台或者 UI 控件，CUIT 提供了很好的扩展机制，允许大家针对自己的特殊应用进行扩充，下图就是 CUIT 框架的体系结构图 。

图 3：CUIT 框架的体系结构

开发自动化测试用例对于有效预防回归问题的出现时非常必要，在实际应用中应该特别注意它的合理比例关系和灵活的策略，包括：自动化用例和手工用例的比例、UI 和非 UI 测试用例的比例关系。自动化测试用例、执行、分析和维护它们都是需要一定投入的，对于敏捷项目而言时间资源的紧缺尤为突出，所以在任何时候团队都要根据自身的资源，有选择性进行测试用例的自动化，通常情况下应该优先自动化那些高优先级的测试用例。

对于 UI 和非 UI 的自动化测试用例而言，应该是以非 UI 的单元测试和功能测试为主，UI 测试未必要的补充。基于 UI 自动化测试用例有它独特优点，例如：它从真实用户角度出发进行测试，即涵盖了界面层、逻辑层和数据层，自动化人员不需要了解被测试应用的代码实现细节等；但是相对于非 UI 测试它也有着先天的不足，包括：执行速度相对比较慢、易受干扰不稳定等。所以在自动化过程中，能用非 UI 测试覆盖的功能尽可能采用非 UI 的测试覆盖，如：API 单元测试等，UI 测试用例只用来实现最基本用户故事的验收测试（Acceptance Test）。

早测试和经常测试——封闭签入和滚动生成

敏捷开发中最可怕的事情莫过于在迭代最后一两天进行测试，结果发现了严重功能缺陷或者回归缺陷，导致不能按计划发布给用户试用。要想彻底解决这样的问题，一方面要在迭代开发阶段测试人员就要参与进来，从客户的角度出发对功能需求和设计文档进行文档测试，即文档评审。测试人员和开发还有项目经理一起从源头上保障将要实现的功能是用户想要的。另一方面就是要在迭代的早期就开始就开始测试，特别前几个迭代已经实现好的自动化测试用例，尽早的执行它们可以有效地避免回归问题的出现。在 TFS 2010 上专门提供封闭签入（Gated Check-in）、滚动生成（Rolling Builds）和持续集成（Continuous Integration）等功能，帮助敏捷团队实现早测试和经常测试。这其中封闭签入和滚动生成是对敏捷团队比较实用的功能。

图 4：选择签入方式

封闭签入是 TFS 2010 提供的一种新的代码签入方式，在配置这项功能后，当用户要签入任何代码时，系统会先将用户本地要签入的代码打包成一个搁置集（shelve-set），然后提交到服务器端，TFS 生成（Build）服务先从 TFS 源代码控制器中同步项目的最新代码，再将提交的代码与之进行自动合并，然后进行编译，如果编译成功，则执行配置的自动化测试用例，如果测试用例全部通过则代码会被自动签入到代码库中，否则返回错误信息给用户，代码是不会进入到代码库。表面上看是与产品测试没有直接关系，但实际上它和测试以及最终产品质量的密不可分。因为代码签入是整个开发过程中发生最为频繁的操作，每次签入代码的质量直接影响着日常的开发活动。对于绝大多数的开发团队来说，check in 代码前不仅要保证编译通过，同时还要最大限度的保证新代码不会破坏已有的功能，也就是要执行测试用例去验证。Gated Check-in 中提到的“Build 成功”，实际上包含两部分内容：编译成功和测试用例执行成功，有了它作为保护代码库的第一道屏障，就可以保证它在任何适合都是可编译，并且达到一定质量标准的。

滚动生成是在 VS 2008 种就有的功能，当 TFS 检测到在它所监控的范围内有任何新的代码变化被签入后，它就启动对最新的代码库进行生成验证，该验证包括编译和运行指定的自动化测试用例。之所以称之为“滚动”，因为它是在一个生成验证操作完成后再去探测有没有新的签入发生，对这期间发生的所有新签入进行新的生成验证。这里需要再强调一下滚动生成的重要意义：它看似只是一个自动生成代码的功能，但实际上起着协调整个开发团队、时刻监控代码库质量、以及尽早暴露产品问题的作用。因为滚动生成时刻都在不停的运转着，对于任何代码签入它都保持着警觉，会去自动验证编译是否成功，自动化测试用例是否都能通过。它就像一个不知疲倦的“代码守护者”一样监控着代码库，第一时间发现其中的任何问题，将问题通知给整个团队，从而避免了问题的积累和拖延。这非常符合敏捷开发中“今日问题今日解决，不要拖到以后”的原则，它帮你最早的发现问题、报告问题，开发团队则应该建立制度要及时响应滚动生成所报告的问题，把它作为 Priority 为 0 或 1 的高优先级问题去对待和解决。

封闭签入和滚动生成都是来保护代码库的正确性和产品质量，它们是否在功能上重复反而让我们不敏捷了呢？其实两者并不重复，只是各有侧重，将它们搭配使用才会发挥其最大效能。封闭签入是在代码进入代码库之前进行验证，签入提交者一般希望竟快知道结果，以便决定下一步的工作，所以封闭签入的时间（编译和运行测试用例）不要太长（10-20 分钟）。这也就决定了我们加入的测试用例不能太多，只添加那些高优先级的测试用例，保证主要的用户故事不被破坏。滚动生成是在代码签入后在后台执行的，由于不存在着与用户的交互等待，所以它执行时间可以更长（几个小时），可以为它加入更多的测试用例，从而全面验证代码库的质量，一旦有任何问题它可以及时通知团队进行修复，这种验证是在几个小时或者每天都在发生的，保证了敏捷对频繁测试的。

完整的自动化测试解决方案——实验室管理

在谈到软件自动化测试的时候，很多人会误以为实现了自动化测试用例就是自动化测试，其实不然，自动化测试仅是测试自动化的一个重要步骤，绝对不等同于自动化测试。一个完整的自动化测试应该包括：构建、部署、执行测试用例、分析测试结果并作出结论。在前面的自动测试的收益公式中，我们可以看到减少自动测试的维护成本，是提高自动测试收益的重要因素之一。VS 2010 的实验室管理（Lab Management）与测试用例管理、生成管理、源代码控制、工作项管理等功能相结合，为自动化测试提供了这样一个完整的解决方案，目标就是要降低了自动测试的运营和非维护成本，下面这张图展示了实验室环境的系统构架图。

图 5：实验室环境的系统构架图

实验室管理功能充分利用了微软的虚拟化技术，包括：Hyper-V 和 System Center Virtual Machine Manager （SCVMM），快速创建干净的虚拟测试环境并进行产品生成和部署，然后执行指定的测试用例集，将结果以报表的形式呈现出来，方便对此产品质量进行分析，如下图所示：

图 6：虚拟测试环境

图 7：测试结果

同时，利用虚拟技术的环境快照功能，对于那些难于复现或者环境相关的 Bug，利用虚拟环境的快照技术，可以为开发人员准确的复现 Bug 出现的环境，从而能够快速的进行诊断和及时修复。

总结

Visual Studio 2010 作为 Visual Studio 系列中一个非常重要的版本，为测试人员和团队提供了一整套解决方案，包括：测试计划和用例管理、创建自动化测试用例、测试用例的自动执行、以及实验室管理等。这些功能强调了测试作为整个软件过程的重要角色的作用，促进了测试人员与其它角色的有效沟通与协作，非常适合于敏捷团队使用来完成测试工作。

工具不是万能的，但没有合适的工具辅助也是万万不能的。对于工具在敏捷开发的作用，应该用辩证的观点来看待。不能片面唯工具论，毕竟软件开发过程是人、工具和过程三者共同作用的结果，工具影响着人和过程，同时人和过程也影响着工具所能发挥的效力。所以这决定了工具的引入和部署应该是一个渐进的和逐步适应的过程，特别是对 Visual Studio 2010 这样比较大型和综合性的工具。下面是三个向大家推荐的与 Visual Studio 测试相关的微软论坛，希望能够对大家有所帮助。

• Testing with Visual Studio Test Manager (MTM)
• Visual Studio UI Automation Testing (includes CodedUI)

Visual Studio Team System - Testing 参考文献

1. A different way of presenting the Visual Studio 2010 testing tools
2. Content Index for Coded UI Test
3. Series on Coded UI Test Extensibility
4. Microsoft Test Runner series – part 7 – Exploratory Testing
5. Testing the Application

关于作者

周京生，微软亚太研发集团服务器与开发工具事业部软件开发测试工程师，目前主要负责 Visual Studio 生命周期管理工具对 C/C++ 支持工具的测试工作。自 2006 年加入事业部以来，一直致力于架构工具的设计开发以及如何使用架构工具促进软件开发生命周期管理。周京生先后参与了 Visual Studio 2005 SDK 和 Visual Studio 2008 的测试工作。在刚刚发布的 Visual Studio 2010 旗舰版中，周京生和团队共同完成了多种 UML 建模工具的开发和测试工作。

注：本文已收录在架构师（7 月刊），更多内容请下载架构师。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。