|
ad-hoc这个术语意味着缺少组织结构或并不是有条有理的。当你谈论随机测试时，它意味着没有正式流程的情况下执行黑盒测试或行为测试。
在这里，正式的流程是指具有类似需求文档，测试计划，测试用例，适当的测试计划的安排和执行测试的顺序。并且测试期间执行的任何操作通常不作记录。
这样做主要目的是试图发现无法在传统流程或正式流程的软件测试周期内发现的缺陷。
由于已经知道，这种测试的本质在于没有一个正式的或结构化的测试方式。在执行这种随机测试技术时,很明显,测试人员没有通过记住任何特定用例来执行，只是带着打破系统的目的。
因此，更加明显的是，这种直观的或创造性的测试方法要求测试人员是非常熟练的，有能力，并有深入而系统的知识。随机测试确保测试执行的完成，并且在确定测试bucket的有效性方面非常有用。
让我们先从一个随机测试的例子开始：
下面是当涉及到用户界面向导的情况下我们如何才能执行测试的例子。
假设您需要创建一个使用这个UI向导板执行某种任务的计划或模板。向导是一系列包含名称,描述,等需要用户输入的窗格。随着向导的进行:假设一个窗格,用户数据输入后需要UI向导添加与数据相关联的上下文并弹出框来完成向导的部署或激活向导。
为了测试这个测试人员会进行如下常规测试：
通过有效数据成功完成向导，并创建计划。
中途取消向导。
编辑并创建针对整个向导的计划。
删除创建的计划，看看有没有遗忘的部分。
在向导中输入负值，看看是否有相应的错误信息。
现在，对于上述的例子下面有一些随机测试的测试案例，可以用来执行以揭开尽可能多的缺陷：
在试图添加反例样本时,添加一些不受限制的特殊字符看看是否能被妥善处理。例如有时向导不限制{或[括号,但在某些情况下这可能与编写代码的语言有所冲突,并导致非常不可靠的行为。
另一个试验是专门针对弹出窗口的。用户可以使弹出窗口启动,然后试着按下键盘上的退格键。很多时候我发现这样做,会使背景向导完全消失,整个先前输入的用户数据全都丢失了!
随机测试的特点：
如果你注意到上面的场景中，你会看到有关这种类型的测试的一些非常明显的特点。
他们是：
他们总是符合测试目标。但他们却试图执行某些极端的测试意图打破系统。
测试人员需要对要测试的系统有完整的知识和了解。这个测试的结果是为了发现bug，并试图突出测试过程中的漏洞。
同时看看上面的两个测试,自然反应会是,这类的测试只能执行一次，不可重复测试，除非它与缺陷有关。
我们何时做随机测试?
这确实是个相当重要的问题!
大部分的时间测试团队总是需要在有限的时间内测试太多的功能。在这有限的时间内有很多的正式流程的测试也需要完成。在这种情况下，用来进行临时测试的机会就很少。但是从我的经验来说即使只有一轮随机测试，也可以创造奇迹，使产品质量得到提高并找到许多设计问题的。
因为随机测试更多的是“非正统”的测试技术，不需要结构化，一般的建议是，它需要在当前测试bucket执行完毕后进行。另一种观点是，在没有足够时间完成详细测试的情况下就可以进行。
在我看来，我觉得随机测试几乎可以在任何时候进行——在开始的时候，向中间部分或接近尾声的时候!它可以在任何给定的时间进行。然而，随机测试何时进行能够带来最大好处就需要有经验的测试人员在深入了解被测试系统的情况下进行判断。
什么时候不能执行?
如果前面的问题是相当重要的，那这个问题就是极为重要!
虽然我们已经明白了随机测试是富有成效的，作为一个有能力的测试人员，我们还需要知道在什么时候我们不应该使用随机测试。虽然这是根据测试者来自由决定的，但在这里有一些关于何时随机测试并不必要的建议和例子。
当测试用例中存在问题的情况下避免使用随机测试。在这种情况下，有必要记录测试用例的故障之处，然后验证或重新测试缺陷，来解决问题。因此，在这里并不适用。
也可能在某些情况下，客户可能被请来进行软件测试版的测试。在这样的情况下，随机测试就不应该进行。
另一种情况是当只是添加了一个非常简单的用户界面时。传统的正向测试和负面测试在这里应该就足以找出所有的缺陷。
1.合伙测试：
进行此类的测试将需要一个测试人员和一个开发人员针对同一个模块进行工作。在开发人员完成了该模块的单元测试后，测试人员和开发人员坐在一起，同时对这个模块进行测试。通过此类测试可以使双方从更广泛的范围对模块的功能进行研究。开发者将了解测试人员对模块进行的各种不同的测试，而测试人员将了解模块的固有设计，这将有助于他避免设计无用的测试场景，从而避免了找到无效的缺陷。它会帮助大家通过对方的思考方式来思考。
#2.配对测试：
此类测试是由两个测试人员对具有相同测试设置的模块一起进行测试。这种类型的测试背后的考虑是，通过两个测试人员之间的头脑风暴，来找到更多的思路，方法以及缺陷。彼此可以共享测试以及对于观测结果的记录文档。
#3.猴子测试：
这个试验主要在单元测试level执行。测试人员通过完全随机的方式进行测试,以确保系统能够承受任何崩溃。这种测试可以进一步分为两类。
随机测试的好处：
它保证了测试人员尽可能的更有创造力。
------------
这在如下方面增加了测试的质量和效率：
最大优点是，测试人员可以找到比传统测试方法更加多的缺陷，因为他们可以应用各种创新的方法来测试软件。
这种形式的测试可以在系统生命周期的任何阶段使用;它不仅限于测试团队。开发人员也可以进行这项测试，来帮助他们写更好的代码，并预测可能发生的问题。
可以与其他测试结合来获得更好的效果，有时可以缩短所需的测试时间。这将生成更好的测试用例并进一步生成更高质量的产品。
不要求任何文件，防止了额外的测试人员的负担。测试人员可以专注于真正理解底层架构。
除非没有太多的时间用来测试，这个方法在测试覆盖面和质量方面非常有价值。
特设测试的缺点：
特设的检测也有一些缺点。让我们来看看一些明显的缺点：
因为它不是非常有组织的测试，又没有执行的文件，最明显的问题是，测试方案的所有细节需要由测试人员来记忆。尤其当场景中有许多不同模块之间交互的时候就是更大的挑战了。
随后从所述的第一点来看，这也将导致缺陷在随后的尝试中无法重现。
另外一个很重要的问题是所做努力的可说明性。因为这类测试没有计划的，也没有办法来解释测试花费的时间和精力。
特设的测试必须由团队中非常熟悉项目的测试人员来进行，因为它需要有前瞻性以及直觉来预见潜在的缺陷。
最佳做法，使这个测试更有效：
我们已经详细地探讨了随机测试相关的优势和劣势。
理想情况下，随机测试应该可以用在系统开发生命周期的任何阶段，但如果不以适当的方式进行就可能浪费宝贵的测试时间而且代价很高。所以，下面给出几个建议来使测试更有效：
#1.找出缺陷多发的部分：
当你对测试特定部分的软件有一定的了解的话，你会认可有一定的功能，比别的更有可能出错。如果你对系统不太熟悉，那就继续进行，打开针其功能的V / S缺陷的检查。某个特定功能的缺陷越多，就可以告诉你，它的易受影响。你应该精确地选择那个部分来进行随机测试。这被证明是暴露出一些严重的缺陷的非常有效的方式。
#2.构建专业知识：
毫无疑问，拥有更多的经验的测试人员，会更具直觉，会比没有经验的人更擅长猜测缺陷会在哪里。我会说，有经验与否，就是通过冒险尝试并在测试的系统上构建专业知识来决定的。是的，有经验的测试人员具有优势，多年来积累的经验能够派上用场，但新的测试人员应该以此为平台，以获得尽可能多的知识，尽可能地设计出更好的随机方案。
#3.创建测试种类：
一旦你知道的哪些功能需要进行测试，留出几分钟的时间来决定你将如何对需要测试的功能进行分类。举例来说，你应当首先测试最明显以及最为用户经常使用的功能，因为这些会对该软件的成功来说至关重要。然后，你可以对功能进行优先级排序分类，并一段一段的测试。
另一个例子证明这是特别重要的是，当存在模块之间的集成的情况。在这种情况下，很可能发生异常。使用分类将有助于触发这类问题至少一次或两次。
#4.有一个粗略的计划：
是的，是的，这一点可能使你迷惑，我们描述的随机测试应该没有任何规划或文档。这个的想法还是坚持了随机测试的本质，只是还是有一些简单的计划，记下你打算如何进行测试。
一个非常基本的例子是，有时你可能只是无法记住所有你想要进行的测试。因此，简单的记下来，将确保您不会错过任何东西。
#5.工具：
让我们举一个大家都经历过的例子。很多时候，如果你注意观察，功能测试本身是成功的，没有行为缺陷报告。然而幕后的记录可以看出一些被测试人员忽略的例外，因为它不妨碍测试目标。这可能性很高。因此，学习能够查出这些问题的工具是非行有用的。
#6.记录文档以找到更多的缺陷：
再次声明，我明白，这可能会引起一些鄙视，文档并不一定要详细,只是一个小纸条供自己参考，记录覆盖的不同场景,各个步骤导致的偏差以及记录这些缺陷为特定测试功能类别。这将帮助你提高整体的测试bucket，以及决定如何对测试用例即兴发挥或根据需要进行添加。
结论：
我们已经详细讨论了随机测试技术——它的优势，劣势，各种适合或不适合使用的情况。
这是一个保证了迎合测试人员的创造力发挥到最大的测试技术。在我的整个测试的职业生涯中，我从进行随机测试中获得最大的满意度，因为对创新毫无限制，你最终会变得更有知识。
说了这么多，从上面的所有信息总结下来，最主要的是决定如何利用随机测试的优势,使其对整个测试过程和产品质量增加价值。
|
