大多数软件从业人员不喜欢“随机测试”这个术语，因为它意味着测试过程或者测试目的的缺失，但其实随机测试在软件测试的生命周期里扮演着重要的角色。“随机测试”是黑盒测试下包含的一个过程，是最不正式的测试方法。在随机测试过程中，测试员不需要执行测试用例，不与分配的测试任务绑定。测试人员在随机测试中只需要使用他们的直觉和经验。

　　测试人员必须在没有任何合适的计划和文档的情况下，完全依靠自己的直觉寻找bug。如果由一个熟练的测试人员来执行随机测试的话，一般都会发现在常规测试周期里没有发现的问题。有时候，如果在开发周期的较晚阶段才开始测试的话，随机测试是能够执行的唯一一种测试方式。

　我以前做测试员的时候，我被告知应该专注于测试分配给我的功能，确保客户在使用这些功能的时候不会遇到任何问题，术语叫做“功能owner”。但是我想做一些不同的事情，我厌倦了随着版本发布周期为每一个产品执行相同的动作。于是在两轮系统集成测试后，我开始应用自己的知识，在没有使用任何测试用例的情况下对整个产品进行测试，而不是只测试那些分配给我的功能。结果很好。我发现了很好的问题，这些问题是从一开始就存在在产品里的。分析这些问题之后发现，是由于需求文档里缺少相关信息导致这些问题的。

　　基于我的发现，我和我的测试组长一起去找我的测试经理，试图让他相信，如果整个测试团队能够在系统集成测试完成之后执行一轮随机测试的话，将有机会发现更多可能在常规测试周期中错过的问题。要说服他很难，因为在测试方法和测试策略的文档里，没有提到任何跟随机测试有关的信息。我们已经完成了两轮系统集成测试，正在等待新的版本/构建来执行回归测试，之后是由产品管理团队负责的可接受性测试。测试经理因为我发现的问题，也想加入一轮随机测试，所以他拿着我发现的问题去找管理层，试着说服整个管理团队，争取加一周时间用来做随机测试。不知怎么地，我们得到了管理层的支持，获准加入一轮随机测试。整个测试团队需要仅仅使用我们的测试技巧，依靠我们对产品的了解和直觉来进行随机测试。一周随机测试结束之后，结果如下：

　　1、发现了两轮SIT测试的20%的缺陷（阻碍级别和高优先级）；

　　2、发现了两轮SIT测试的10%的缺陷（中优先级）；

    随机测试的最好用途之一是用来发现探索。阅读需求说明书或者产品规格用例说明书通常不能完全弄清楚一个软件系统的实际行为。甚至用户文档也不能准确描述一个程序看起来和感觉起来是怎么回事。随机测试能够发现你的测试策略的漏洞，并且能够揭示本来不明显的子系统之间的关系。以这种方式，随机测试被当做是检验测试完整性的一个工具。可以通过随机测试发现漏掉的测试用例然后把他们添加到你的测试库中。如果用这种方法可以发现新的测试用例的话，这标志着你应该分析下深层次的原因。

　　如果用这种方法可以发现新的测试用例的话，这标志着你应该分析下深层次的原因。问问自己或者自己的测试团队，我们应该执行何种类型的测试？通过随机测试发现的缺陷往往是漏掉的一大类测试用例的个例而已。随机测试的另一种用途是确定你的其余测试活动的优先级。

　　随机测试还可以有效提高代码覆盖率。一般而言，在常规测试设计里添加新的测试用例后，需要做大量工作，比如制定计划，执行测试，然后才能最终确定代码覆盖率提高了多少。更有效率的方法是通过重复的随机测试来快速确定你的代码覆盖率是否得到了提升。如果正好提升了你需要的代码覆盖率，你就可以把这些新的场景添加到你已有的测试用例里了。

　　一个好的随机测试人员（随机测试可以由有经验的测试人员快速高效的执行）需要理解那些低级别的功能的设计目的和详情需求。开发团队做出了什么样的选择，以及这些选择有些什么缺点？作为一名测试人员，我们较少关注开发过程中制定的正确决定。随机测试执行起来像是黑盒测试。这意味着你必须检查所有可能已经用到了的主要设计模式。这样你就可以把测试范围缩小到更少的用例。

关键词：软件测试学校