ad-hoc这个术语意味着缺少组织结构或并不是有条有理的。当你谈论随机测试时，它意味着没有正式流程的情况下执行黑盒测试或行为测试。
在这里，正式的流程是指具有类似需求文档，测试计划，测试用例，适当的测试计划的安排和执行测试的顺序。并且测试期间执行的任何操作通常不作记录。
这样做主要目的是试图发现无法在传统流程或正式流程的软件测试周期内发现的缺陷。
由于已经知道，这种测试的本质在于没有一个正式的或结构化的测试方式。在执行这种随机测试技术时,很明显,测试人员没有通过记住任何特定用例来执行，只是带着打破系统的目的。
因此，更加明显的是，这种直观的或创造性的测试方法要求测试人员是非常熟练的，有能力，并有深入而系统的知识。随机测试确保测试执行的完成，并且在确定测试bucket的有效性方面非常有用。
让我们先从一个随机测试的例子开始：
下面是当涉及到用户界面向导的情况下我们如何才能执行测试的例子。
假设您需要创建一个使用这个UI向导板执行某种任务的计划或模板。向导是一系列包含名称,描述,等需要用户输入的窗格。随着向导的进行:假设一个窗格,用户数据输入后需要UI向导添加与数据相关联的上下文并弹出框来完成向导的部署或激活向导。
为了测试这个测试人员会进行如下常规测试：
- 通过有效数据成功完成向导，并创建计划。
- 中途取消向导。
- 编辑并创建针对整个向导的计划。
- 删除创建的计划，看看有没有遗忘的部分。
- 在向导中输入负值，看看是否有相应的错误信息。
现在，对于上述的例子下面有一些随机测试的测试案例，可以用来执行以揭开尽可能多的缺陷：
- 在试图添加反例样本时,添加一些不受限制的特殊字符看看是否能被妥善处理。例如有时向导不限制{或[括号,但在某些情况下这可能与编写代码的语言有所冲突,并导致非常不可靠的行为。
- 另一个试验是专门针对弹出窗口的。用户可以使弹出窗口启动,然后试着按下键盘上的退格键。很多时候我发现这样做,会使背景向导完全消失,整个先前输入的用户数据全都丢失了!
随机测试的特点：
如果你注意到上面的场景中，你会看到有关这种类型的测试的一些非常明显的特点。
他们是：
- 他们总是符合测试目标。但他们却试图执行某些极端的测试意图打破系统。
- 测试人员需要对要测试的系统有完整的知识和了解。这个测试的结果是为了发现bug，并试图突出测试过程中的漏洞。
- 同时看看上面的两个测试,自然反应会是,这类的测试只能执行一次，不可重复测试，除非它与缺陷有关。
我们何时做随机测试？
这确实是个相当重要的问题！
大部分的时间测试团队总是需要在有限的时间内测试太多的功能。在这有限的时间内有很多的正式流程的测试也需要完成。在这种情况下，用来进行临时测试的机会就很少。但是从我的经验来说即使只有一轮随机测试，也可以创造奇迹，使产品质量得到提高并找到许多设计问题的。
因为随机测试更多的是“非正统”的测试技术，不需要结构化，一般的建议是，它需要在当前测试bucket执行完毕后进行。另一种观点是，在没有足够时间完成详细测试的情况下就可以进行。
在我看来，我觉得随机测试几乎可以在任何时候进行——在开始的时候，向中间部分或接近尾声的时候！它可以在任何给定的时间进行。然而，随机测试何时进行能够带来最大好处就需要有经验的测试人员在深入了解被测试系统的情况下进行判断。
什么时候不能执行？
如果前面的问题是相当重要的，那这个问题就是极为重要！
虽然我们已经明白了随机测试是富有成效的，作为一个有能力的测试人员，我们还需要知道在什么时候我们不应该使用随机测试。虽然这是根据测试者来自由决定的，但在这里有一些关于何时随机测试并不必要的建议和例子。
- 当测试用例中存在问题的情况下避免使用随机测试。在这种情况下，有必要记录测试用例的故障之处，然后验证或重新测试缺陷，来解决问题。因此，在这里并不适用。
- 也可能在某些情况下，客户可能被请来进行软件测试版的测试。在这样的情况下，随机测试就不应该进行。
- 另一种情况是当只是添加了一个非常简单的用户界面时。传统的正向测试和负面测试在这里应该就足以找出所有的缺陷。
(待续)
【英文原文：http://www.softwaretestinghelp.com/ad-hoc-testing/】
{测试窝原创译文，译者：大头}
译者简介：大头，在读日本九州大学修士，计算机专业，主研究方向为文本挖掘，及自然语言处理。
