Ad-hoc Test的测试介绍

“Ad Hoc” 原意是指 “特定的，一次性的”；就是为了某一个特定目的进行的测试，就这一次，以后一般也不会重复测试或是尝试性测试某种情况，来检测是否有问题 所以并非像许多测试人员所讲的是”猴子测试”，误理解了什么是Ad Hoc Testing；正确的测试应是在测试过程中， “ad hoc”测试可以用来衡量当前测试用例的完备性，设计某些特定的，一次性的测试用例，去检查在现有测试用例之外的问题，假如测试时，未发现什么问题，说明现有的测试用例是比较完备的，反之，则不是。 如果你想了解更多关于Ad Hoc Testing请查看这个链接中的介绍: http://www.testingcraft.com/ad_hoc_testing.pdf 关于Ad-hoc测试的基本知识 “Ad-Hoc” 原意是指 “特定的，一次性的”，这里专指“随机的，自由的”测试。在软件测试中除了根据测试样例和测试说明书进行测试外，还需要进行随机测试(Ad-hoc testing)，主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行样例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。 随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试 (Regression testing)一起进行。 理论上，每一个被测软件版本都需要执行随机测试，尤其对于最后的将要发布的版本更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉，执行随机测试越容易。只有不断的积累测试经验，包括具体的测试执行和对缺陷跟踪记录的分析，不断总结，才能提高。 关于Ad-hoc测试的简短问答 问：什么叫“特定”测试？或者“探索式”的测试？ 就是为了某一个特定目的进行的测试，就这一次，以后一般也不会重复测试。在软件工程的实践中，“ad hoc”大部分是指随机进行的，探索性的测试。比如：测试人员阿毛拿到了一个新的Build，按计划是进行模块A的功能测试，但是他灵机一动，想看看另一个功能B做得如何，或者想看看模块A在某种边界条件下会出现什么问题，于是他就“ad hoc”一把，居然在这一功能模块中发现了不少Bug。 “ad hoc”也意味着测试是尝试性的，“我来试试，在这个对话框中一通乱按，然后随意改变窗口大小，看看会出什么问题…”， 如果没问题，那么以后也不会再这么做了。 一般情况下，测试人员不会花很多时间进行特定测试，但是在一些缺乏管理的团队中，很多时候测试人员不知道自己此时应该做什么，只好做一些看似“ad hoc” 的测试，比如随机测试各个功能的各个方面。这些测试理论上都应该由测试管理人员规划好属于各个功能模块的测试用例中。 在一个团队中，“ad hoc”太多是一个管理不好的标志，因为“ad hoc”是指那些一时想到要做，但是以后也没有计划经常重复的测试计划。 问：我听说有人是“ad hoc”测试的高手，这是什么意思？ 答：有很多测试人员会按部就班地进行测试，但是还有一些人头脑比较灵活，喜欢另辟蹊径，测试一些一般人不会想到的场景，这些人往往会发现更多的Bug。开发人员对这样的“ad hoc”高手是又爱又恨。 问：同时看问题要分两方面，有些“ad hoc”发现的Bug在正常使用软件中几乎不会出现，我们要不要花时间“ad hoc”？ 答：现在一些成功的通用软件的用户以百万计，按部就班的测试计划很难包括很多实际的场景，这时，“ad hoc”测试能够发现重要的问题；另外一些风险很大的领域，例如安全性，一旦出了问题，威胁就会相当大，这时要多鼓励一些“ad hoc”测试，以弥补普通测试的不足。从这个意义上说，“ad hoc”测试可以用来衡量当前测试用例的完备性，如果你探索了半天，都没有发现什么在现有测试用例之外的问题，那就说明现有的测试用例是比较完备的。 “ad hoc”测试的测试流程是不可重复的，因为它的测试都是“特定”测试，没法重复。由于这一原因，“ad hoc”测试不能自动化，就这一点而言，还达不到CMM的第二级 – 可重复级。 作为管理人员来说，如果太多Bug是在“ad hoc”出来的，那我们就要看看测试计划是否基于实际的场景，开发人员的代码逻辑是否完善，等等。同时，要善于把看似“ad hoc”的测试用例抽象出来，包括到以后的测试计划中。 问：做好“ad hoc”测试有什么窍门？ 随机测试有些小窍门，可以帮助测试人员更有效的发现bug。 窍门一，在发现很多bug的地方，一定可以发现更多的bug。我们在做随机测试的时候，往往会先统计一下，上周哪些模块被发现的bug最多，那么这周一定要狠狠的在那个模块里发掘一下。 窍门二，做到知己知彼。知己就是要了解自己在哪些方面有特长，多发挥这些特长；知彼主要是了解两方面，一是程序本身哪些地方最复杂，最薄弱，这些地方最容易发生什么错误，二是程序员最容易在哪些地方犯哪些错误。前者通过对程序的熟悉可以比较好的掌握，后者可以通过CQ(BUG管理工具)分析得到。 窍门三，多和程序员沟通。在和程序员沟通的过程中，你可以知道很多你前所未知的东西，你可以通过验证这些东西，来发现未知的bug，并且可以激发你运用更多的测试手段来测试。 本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wayne_ran/archive/2008/01/08/2030915.aspx