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活动中发现的。