“探索式”的测试（Ad hoc Test）

　　“Ad hoc”原意是指“特定的，一次性的”。这样的测试也可以叫Exploratory Test。

　　什么叫“特定”测试？或者“探索式”的测试？

　　就是为了某一个特定目的进行的测试，就这一次，以后一般也不会重复测试。在软件工程的实践中，“Ad hoc”大部分是指随机进行的、探索性的测试。

　　比如：测试人员阿毛拿到了一个新的构建，按计划是进行模块A的功能测试，但是他灵机一动，想看看另一个功能B做得如何，或者想看看模块A在某种边界条件下会出现什么问题，于是他就“Ad hoc”一把，居然在这一功能模块中发现了不少小强。

　　“Ad hoc”也意味着测试是尝试性的，“我来试试，在这个对话框中一通乱按，然后随意改变窗口大小，看看会出什么问题……”，如果没问题，那么以后也不会再这么做了。

　　一般情况下，测试人员不会花很多时间进行特定测试，但是在一些缺乏管理的团队中，很多时候测试人员不知道自己此时应该做什么，只好做一些看似“Ad hoc”的测试，比如随机测试各个功能的各个方面。这些测试理论上都应该由测试管理人员规划好属于各个功能模块的测试用例。

　　在一个团队中，“Ad hoc”太多是一个管理不好的标志，因为“Ad hoc”是指那些一时想到要做，但是以后也没有计划经常重复的测试计划。

　　问：我听说有人是“Ad hoc”测试的高手，这是什么意思？

　　答：有很多测试人员会按部就班地进行测试，但是还有一些人头脑比较灵活，喜欢另辟蹊径，测试一些一般人不会想到的场景，这些人往往会发现更多的小强。开发人员对这样的“Ad hoc”高手是又爱又恨。

　　问：看问题要分两方面，有些“Ad hoc”发现的小强在正常使用软件中几乎不会出现，我们要不要花时间“Ad hoc”？

　　答：现在一些成功的通用软件的用户以百万计，按部就班的测试计划很难包括很多实际的场景，这时，“Ad hoc”测试能够发现重要的问题；另外一些风险很大的领域，例如安全性，一旦出了问题，威胁就会相当大，这时要多鼓励一些“Ad hoc”测试，以弥补普通测试的不足。从这个意义上说，“Ad hoc”测试可以用来衡量当前测试用例的完备性，如果你探索了半天，都没有发现什么在现有测试用例之外的问题，那就说明现有的测试用例是比较完备的。

　　“Ad hoc”测试的测试流程是不可重复的，因为它的测试都是“特定”测试，没法重复。由于这一原因，“Ad hoc”测试不能自动化，就这一点而言，还达不到CMM的第二级——可重复级。

　　作为管理人员来说，如果太多的小强是在“Ad hoc”出来的，那我们就要看看测试计划是否基于实际的场景，开发人员的代码逻辑是否完善，等等。同时，要善于把看似“Ad hoc”的测试用例抽象出来，囊括到以后的测试计划中。

　　回归测试（Regression Test）

　　问：我听说不少关于Regression Test的介绍，但是它到底是怎么“回归”法？回归到哪里去？我还是没搞懂。

　　答：Regress的英语定义是： return to a worse or less developed state。是倒退、退化、退步的意思。

　　在软件项目中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那这个模块就出现了一个“退步”（Regression），从正常工作的稳定状态退化到不正常工作的不稳定状态。

　　在一个模块的功能逐步完成的同时，与此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过，我们就得到了此模块的功能基准（Baseline）。

　　假如，在3.1.5版本，模块A的测试用例125是通过的，但是测试人员发现在新的版本3.1.6，这个测试用例却失败了，这就是一个“倒退”。在新版本上运行所有已通过的测试用例以验证有没有“退化”情况发生，这个过程就是一个“Regression Test”。如果这样的“倒退”是由于模块的功能发生了正常变化（由于设计变更的原因）引起的，那么测试用例的基准就要修改，以便和新的功能保持一致。

　　针对一个Bug Fix（拖鞋），我们也要作Regression Test。

　　（1）验证新的代码的确把缺陷改正了。

　　（2）同时要验证新的代码没有把模块的现有功能破坏，没有Regression。

　　所以对于“回归测试”中的“回归”，我们可以理解为“回归到以前不正常的状态”。

　　回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题。在微软的实践中，在一个项目的最后稳定阶段，所有人都要参加测试，以验证所有已经修复过的Bug的确得到了修复，并且没有在最后一个版本中“复发”，这是一个大规模的、全面的“回归测试”。