这不只是要在应用程序死机时重启手机。尽管那肯定是一个软件质量问题，会给您带来些小麻烦，但它不会影响您的安全(除非您碰巧正在开车，如果这样的话，请您感到羞耻!)或使用服务。随着我们的技术不可避免地逐渐淡出背景，对我们做出反应的软件将成为我们的真实背景，即可以使我们四处走动，帮助我们进行交流以及让我们进行工作和协作的基础架构。
如果我们生活在软件世界中，并且希望生活在高质量的世界中，那么我们需要高质量的软件测试。我们需要进行测试以适应未来的发展，这意味着大大提高我们的测试框架的速度。尽管我们可以在人工驱动的测试上走得很远，而在静态代码分析之类的功能上可以增强它，但从规模上消除测试人员的偏见变得越来越困难。
考虑到软件测试的真正目的，我们要达到什么目的?从最细粒度的角度来看，我们正在尝试使软件沿尽可能多的代码执行路径运行，并且我们正在监视应用程序的行为以查看其在这些路径上的行为。我们得到期望的输出了吗?应用程序崩溃了吗?我们可以操纵该应用程序向我们显示我们不应该看到的数据吗?
了解到这一点，测试人员偏见的问题就变得很清楚。当我们尝试分析源代码以思考破坏软件的不同方法时，人类的认知将完全陷入极限。即使我们能想到逻辑可以采取的所有不同途径，我们需要花多少时间来这样做?以构建我们世界的软件的增长速度，我们如何期望与这种分析保持同步?
这是一个众所周知的问题，并且已经有很多方法消除了测试人员的偏见。这些方法之一是软件模糊化的概念。使用模糊测试的目的是通过随机，意外的输入来锤击软件，从而使软件沿意外的路径运行。捕获并分析程序的状态，如果软件以开发人员不想要的方式做出反应，则表示输入已触发“有趣的状态”(第2节)。
如果这种有趣的状态导致程序以不良方式(例如错误方式)运行，则可以进一步分析代码执行路径，然后我们可以确定是否存在错误或漏洞。
尽管此策略可以发挥作用，但它也是一个压倒性的过程。如果您考虑一下我们可以作为测试语料库或一组测试数据生成的数量庞大，数量无限的随机数据，那么很明显，我们可能浪费了多少个周期来测试输入，这些输入不会做任何新的或意外的事情。