用Visual Studio实践敏捷测试（二）上

    本文的第一部分(上、下)着重介绍了测试人员在敏捷开发过程中，需要完成的一些测试准备工作。对于读者来说，这些工作项可能会比较陌生，但在敏捷开发中却对保证开发的质量和速度起到了很重要的作用。在这一部分中，我们将进入大家较为熟悉的实际测试阶段，为大家介绍测试任务的执行以及Bug的管理。

    在整个敏捷软件开发流程中，存在着各种测试任务。比如，伙伴测试（Buddy Test）、常规的测试运行（Test Run）、Bug的验证、Bug大扫除（Bug Bash）、Dogfooding等等。但是，无论具体任务如何变化，测试总是以3种形式存在的：执行测试用例、Ad-hoc测试和实际使用产品。这里我重点介绍两种重要却不太常见的测试任务，以囊括解释这3种形式的测试是如何进行的。

伙伴测试

    在开发人员第一次签入某个功能（或者签入重大的修复）之前，为保证构造的稳定性，往往会先将代码通过Team Foundation Server（TFS）的搁置集（shelveset）发给相关的测试人员做伙伴测试。伙伴测试常常是测试人员同某一新功能的第一次亲密接触，是实际测试的开端。同时，它也是一种非正式的手动测试，因为这些代码尚未签入，测试人员发现的问题并不构成bug，他们也不会将其记录到Bug数据库中。

    在伙伴测试中，测试人员需要关注以下几点：

• 功能：开发人员新实现的（或是改动过的）行为是否如预期的那样工作
• 边界：开发人员实现（或改动过）的行为是否完整，是否忽略了某些特殊情况
• 回归：那些原先能正常工作的功能是否被新的改动破坏，是否产生回归错误

    那么，如何入手来做伙伴测试呢？这里就需要我们前面提到过的2种不同形式的测试：

1. 执行测试计划

    在伙伴测试时，执行一次制定好的测试计划是一个好主意。在真正接触到产品功能前制定好的测试计划，可以提示测试人员各处细节，使得伙伴测试更全面；同时测试计划也有助于保持测试人员的客观性。这将很好的覆盖到功能测试，也能照顾到大部分的边界测试。

    通过在Test Manager中切换至的Test标签（如图1所示），我们就可以在Test Runner工具中执行测试计划中的测试用例。

图1 测试标签

    图2所显示的是Test Runner在运行测试时的样子。左边是Test Runner界面，这里会依次列出选择运行的测试用例的测试步骤（如果测试用例带有多组数据，则该测试用例会被列出多次，每次显示不同的数据）。右边的部分相当于普通的桌面，你可以在这里执行Test Runner中列出的测试步骤，并在Test Runner中标注每个测试步骤是否执行成功、记录执行结果、或是截取运行时的屏幕截图，也可以直接创建Bug。测试步骤、运行的结果、运行时的环境等各种信息，不但会被添加进运行结果报告中，还可以被直接添加到Bug中。同时Test Runner还支持将手动执行的测试步骤“录制”下来，这样下次运行同一个测试用例时，就不用手工操作了，可以让Test Runner自动执行。

图2 Test Runner

 

 

2. Ad-hoc测试

    既定的测试计划并不足以覆盖测试人员在伙伴测试中所有关注的重点。于是我们需要引进一个新的机制——Ad-hoc测试。Ad-hoc测试一种比较随机的、自由的手动测试，有时我们也称其为“玩自己的产品”。它不需要事前详细的计划，也不需要全面的覆盖。它可以只是随意的试用某个功能，也可以是用各种数据“折磨”某个功能。它可以是专注于一个功能，也可以是随意的在几个功能间切换。大多数时候Ad-hoc测试就是灵光一现的“如果我在这一步这样做会怎样呢？”而这恰恰是最容易发现bug的一种测试。因为写成文档的测试计划往往都是比较主要的用户场景，开发人员也会偏重于保证这些场景能够正确工作。而Ad-hoc这种随机的测试却往往能深入到一些意想不到的地方，找出隐藏的问题。

    不过从伙伴测试的关注点出发，在这里我们做Ad-hoc测试时可以有一些重点：开发人员关于其改动的意见、测试人员基于以往的经验容易出错的地方以及与改动相关的主要的用户场景。这样Ad-hoc测试就能帮助测试人员覆盖一部分边界情况，以及回归测试。

    Ad-hoc测试可以发生在开发周期的任何时间。几个常见的场合包括新功能签入后团队成员的试用、每周一次团队成员的Bug大扫除等。

    做Ad-hoc测试也可以利用之前我们介绍的Test Runner工具。首先，在你的测试计划中添加一个Ad-hoc测试专用的测试用例，执行它之后就可以利用同样利用Test Runner来来记录包括操作步骤在内各种信息了。使用这种方式的最大好处就是避免了在随机测试中测试步骤难以记录下来的问题。

    Test Manager中另一个为Ad-hoc测试提供方便的功能是虚拟机。切换至Lab Center（如图3所示），就可以在此创建虚拟环境用于运行测试，不同的操作系统、语言等等。而且Lab Center能保存虚拟环境，从以前保存的环境中直接创建一模一样的虚拟机。通过虚拟环境的重建，开发人员可以很容易的自己创建出完全一样的环境来重现Bug，进而避免了由于环境原因导致的Bug无法重现的问题。

图3 Lab Center

    测试人员在完成伙伴测试后，会发布一个伙伴测试报告。报告的内容应该包括：哪些功能是经测试能正常工作的、在测试过程中发现的问题以及这些问题的重现步骤和结果。开发人员就可以在签入代码前修复这些问题，或是经过团队讨论后先签入代码并将没有修复的问题提交到bug数据库。而作为测试人员，一件后续工作是重新审阅测试计划，确认发现的问题是否能被已有的测试覆盖，并视其严重程度决定是否添加进测试计划。

    在伙伴测试的流程中，再一次体现了一些我们已经重复过多次的、在敏捷开发中的一些重要概念：保证构造的稳定、尽早修复问题、团队成员之间紧密合作。

Dogfooding——实际使用产品

    Dogfooding字面上的意思是吃狗粮，这里实际指的是完全作为一个用户来使用自己的产品。这是一个在微软内部非常强调的概念。就比如我们Visual Studio开发团队使用的开发工具就是正在开发的新版本的Visual Studio，我们习惯于每隔几天或几周就更换至最新的构造，以便能第一时间体验最新的产品功能，抢在用户之前发现使用中可能出现的问题。

    使用“半成品”的代价是显而易见的——不稳定的环境、不好用的功能，但是带来的好处也是十分丰厚：一方面提供了大量“免费”的手动测试，另一方面团队成员充分理解用户场景、感受用户体验后，能更有目的性的去提高产品质量——特别是对于一些设计上不方便使用的功能，可能在Triage讨论时会觉得没有必要修复，但是一旦让团队成员自己使用后，他们可能就迫不及待的想要改进了。

    而且Dogfooding并不仅限于产品开发团队本身，在产品比较稳定之后，我们还会邀请公司内部的其他兄弟团队来试用产品。比如，在windows发布之前，公司里几乎所有的同事都会换上最新的试用版。不少很棒的Bug都是在这种大规模的Dogfooding活动中发现的。

林俊彦

本文精简版收录于《程序员》7月刊。