应用Visual Studio 2010 辅助敏捷测试 (二)

二、集成测试环境 – Microsoft Test Manager

    在过去的十几年中，为了适应了软件项目的复杂度和规模的不断膨胀，软件开发工具和框架得到了长足的发展，而测试工具则始终是块短板 ，特别是对于那些需要手工完成的测试任务而言，进展就更为缓慢，例如：现在很多团队仍然使用Word或者Excel这样“原始”工具来管理测试用例。通过对业界的调查和分析，我们发现70%的软件测试工作仍然是通过手工或者简单的脚本来完成的，在测试团队中不具备编程能力和仅有基本脚本编写能力的测试人员仍然是测试的主力。

    要让你的项目敏捷起来，对于那些仍以手工测试为主的团队而言是一个非常大的挑战，如何提高手工测试工作的效率将是实现敏捷的成败关键。在VS 2010中，微软首次为测试人员设计了一款专用的集成测试环境，称为微软测试管理器2010（Microsoft Test Manager 2010，以下简称为MTM）。之所以称之为集成测试环境，是因为MTM的功能涵盖了测试计划、测试用例、手动测试用例的执行和录制回放、自动测试用例执行、创建信息丰富的Bug、验证Bug、以及与测试实验室管理相关的对策是自动化相关的功能等。下图展示的是MTM测试计划的操作界面，它以树形的层次结构来组织测试用例。

    《敏捷序言》强调：“可工作的软件重于完备的文档”，那么是不是意味着敏捷测试也不需要测试计划呢？当然不是。敏捷的本质是要去除软件过程所有造成时间浪费地方，不需要的是那些动辄就几十或上百页的文档。敏捷对文档要求是要简明扼要，一两页列出测试要点计划还是必须的，较短迭代周期（1-4周）也不可能要求文档面面俱到。敏捷需要更快的对功能进行验证，是不是不需要编写测试用例直接根据用户故事或者功能需求进行探索性测试就可以了？当然也不是。功能需求和用户故事勾画出的是一棵大树躯干和主要枝杈，而那测试用例则不但要准确描述出躯干和主枝，还要描述出细小的枝杈和绿叶的正确位置。从某种意义上讲，测试用例在敏捷中的作用和地位应该更为加强，它扮演着详细功能文档的角色。功能需求和设计文档可以简单，但测试用例可不是这样，相反我认为敏捷对测试用例的设计和管理要求更高。

    每个迭代周期，团队都会专注于实现不同的产品功能，用户故事虽然描述了功能的内容，但并不足以覆盖所有相关的内容。很多由用户故事展开和关联的功能一般在文档中会体现出来，需要测试人员在早期围绕着用户故事测试展开需求文档测试（需求评审），已明确那些未严格定义出来的内容，以测试用例的形式明确和记录下来。由1个简单用户故事就有可能扩展为1+N用户可能执行的执行片段，也就我们测试用例。当你有M个用故事，需要Ｍ个迭代周期来完成产品，那么就会有 ( M + N₁ + N_{2 …} + N_M) 个测试用例，不把它们落实到笔头上，很容易就会丢失一些重要的测试细节。此外，在敏捷方法中需求变化比较快，随着多个迭代的深入，文档的变化往往赶不上产品功能的变化，这时唯一能够赶上这个变化的只有测试用例，应为只有它准确地反映了产品的变化，否则测试用例就是无法通过的。

    在MTM 中，测试用例被分类至各个测试用例集，结构十分清晰。测试用例只是逻辑上从属于某个测试用例集，并没有物理从属关系，即一个测试用例可以同时被分在多个测试用例集内，比如某个测试用例性质上是一个性能测试，但是由于该用户故事的诉求就是性能改进，我们也就很自然得可以将其作为该用户故事的验收测试，此时我们就可以将此测试用例添加到验收测试和性能测试两个测试用例集中；另一个例子是给每个用户故事都定义了不少测试，这些测试用例都应该能在用户故事测试用例集下找到，但是这些测试既可能是手动测试也可能是自动化测试用例，所以它们又会被本别归类至这两个测试用例集。在这种逻辑分类的支持下，我们可以很容易的根据需要指定运行测试集中一部分测试用例。比如，我们可以定义一个签入测试的测试用例集，挑选最基本的若干个测试置入其中，这样在每次签入前通过运行这个测试用例集就能帮助我们确保签入的代码不至于破坏最基本的功能，即保证了版本随时可运行可测试，这无疑为测试带来了更多的方便。具体如何创建测试用例集的结构，团队可以根据自己项目的特点，灵活运用此功能，制定分类规则以提高工作的效率。

    很多测试团队仍然在使用Word或者是Excel管理测试用例，有些是使用专门的测试用例管理工具，使用独立的数据库来存储测试用例信息。MTM相对于这些工具的优点在于，它的所有数据都是存储在TFS上，测试用例使用的是Test Case工作项。由于同存储在TFS 上，所以可以轻松的实现与其它数据项的关联，例如：在上一部分我们介绍的不同类型工作项之间关联，此外还可以把Test Case与代码关联，即将测试用例与自动化测试代码关联。这样在MTM中，也可以直接管理和运行自动化测试用例，使MTM兼具了管理手工测试用例和自动化测试用例的能力。

    探索性测试（Exploratory Testing）是测试人员在对被测试系统的功能进行不断了解和学习的过程中进行测试，包括：设计测试用例、执行测试、以及汇报测试结果。与传统的测试相比，它不需要事先定义好的齐备的测试文档，更强调测试人员在对系统不断地学习中，边了解边测试，它在很大程度上给测试人员更多地自由和想象空间，充分发挥他们的创造力，在不断地学习中找到测试的灵感和快乐。这种测试的灵感和快乐对于组建和培养一支热爱测试的团队是非常非常重要，它会让测试人员觉得自己不是执行重复测试劳动机器，而是一个有着创造力和灵光的团队成员。MTM也支持探索测试功能，用户可以使用MTM创建一个仅有一个测试步骤的测试用例，然后执行它，Test Runner工具会辅助执行手动测试。它会记录下所有用户的操作，一旦发现有Bug时候，可以直接选择‘Create exploratory bug’直接创建一个Bug。

    Bug是测试工作最重要的产出之一，也是测试和开发人员之间重要接触点。每个提交的Bug都应该详细记录下如何重现（reproduce）的步骤，这是衡量Bug质量的重要因素之一。因为不可重现的Bug是没有意义的，只会耽误开发人员和项目经理的时间。偶尔出现不可重现的Bug还是可以理解的，但如果经常出现，那就会引来开发人员的抱怨和不满，久而久之会造成开发和测试之间的不信任。好的Bug应该是有清晰和详细的重现步骤，期望的结果和实际得到结果，并提供尽可能多的信息，例如：出现问题的产品版本编号、语言、操作系统的版本以及日志信息等。大多数情况下，用文字进行描述的内容就可以了，但如果能配上一张问题现场截图，或者对于更为复杂的Bug，配上一段小的录像，这样的Bug会给开发人员快速诊断和修复产品问题带来很大帮助，大大提升测试和开发人员之间的协作效率，避免了不可重现Bug在开发和测试之间推来推去的“Bug乒乓”现象。然而要收工创建这样一个信息丰富的Bug，是需要很多时间的。MTM提供了这样的功能为帮助测试人员创建这样高质量Bug，它实现了多种诊断数据适配器（Diagnostic Data Adapters），在测试确认Bug的过程中，这些适配器会在后台运行收集大量的数据，包括：执行操作、系统配置、IntelliTrace已经操作过程的录像等，当测试人员要创建一个Bug时，这些信息会被自动添加的Bug中，如下图所示，测试仅需填写很少的内容就可以创建好一个信息丰富的Bug。

三、实现自动化测试用例 – 自动化测试用例框架

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

    这其中，开发和维护自动测试的成本是影响这个收益的重要因素，为此VS 2010提供了一整套的解决方案，帮助测试团队减少这部分成本，这包括前面我们所提到的测试计划和用力管理工具，以及后面将会要介绍的生成和实验室管理。此外，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框架的体系结构图 。

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

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

全文收录于2010年InfoQ中国《架构师》7月刊 “Visual Studio 2010之美”，作者：软件测试开发工程师周京生。