问在测试软件时，我们可以假设用户不会在软件上执行如此愚蠢的操作吗？

EN

您可能不会在web应用程序的字段中输入随机值，但是肯定会有人这样做。

有些人是偶然地随机输入的，而另一些人则是故意试图破坏应用程序。在这两种情况下，您都不希望应用程序崩溃或显示其他不必要的行为。

对于第一种类型的用户，您不希望这样做，因为这会给他们带来糟糕的体验，并且可能会拒绝他们。

对于第二种类型的用户，他们通常没有高尚的意图，你不想让他们访问他们不应该访问的信息，或者允许他们拒绝真正的用户访问您的服务。

测试的标准做法不仅是验证天气良好的情况是否有效，而且还要检查异常的边缘案例，以发现潜在的问题，并确信攻击者无法轻松地访问您的系统。如果您的应用程序已经与随机输入崩溃，您不想知道攻击者可以如何处理巧尽心思构建的输入。

从不假设任何事情，

您不能假设任何用户都不会无意或故意地对您的软件做一些“愚蠢”的事情。用户可以不小心按错按钮，猫可以走过键盘，系统可能发生故障，他们的电脑可能被恶意软件劫持等等。

此外，用户本身也可能是恶意的，故意寻找破坏您的软件的方法，希望他们能够找到一种方法来利用它对他们有利。即使他们发现了一个他们无法利用的漏洞，他们发现的任何东西都可能刺激他们去探测你的系统，寻找他们可以攻击的东西，因为他们知道你的QA程序是缺乏的。

就测试而言，防范随机输入是有用的，但是选择完全随机的测试输入(即没有对任何用例或边缘用例进行特别考虑)几乎是无用的。测试的目的是根据雇主/客户/用户的要求和期望验证您的解决方案；这意味着您需要专注于针对所有边缘情况和边界条件，以及任何不符合用户预期工作流程的“退化”情况。

当然，您可能会运行一些测试，这些测试揭示了您后来认为不值得修复的bug；这可能是出于各种原因--相对于它对用户的影响而言，修复该bug可能太昂贵了，或者您可能会发现没有人使用的特性中的bug，或者该bug可能已经在系统中得到了很好的确认，以至于一些用户将其作为一项功能来处理。

或者，您可能正在编写一些定制的软件，这些软件拥有严格限制的“专家”用户群，在这些软件中，花费时间修复bug没有商业好处，因为这些用户能够使用错误软件完成他们的工作(例如，内部IT团队使用的诊断工具并没有提供任何收入，所以如果它偶尔崩溃，那么没有人愿意支付修复它所需的时间--他们只会告诉it团队接受错误)。

但是，只有了解这些bug，才能做出这些决定。例如，用户可能输入一个恶意输入，这会擦除整个数据库--如果您没有显式地针对这个场景进行保护和测试，那么您就无法确定这种情况是否会发生。将未发现的bug留在系统中的风险意味着，如果其中一个bug在现实世界中暴露出来并对您的用户产生重大影响，那么您就有可能面临真正的问题。

因此，虽然是否修复bug的决定可能需要软件所有者(通常是支付您的薪水的人)的一些投入，但决定是否测试bug，以及测试哪些案例是一个工程问题，需要在评估和项目规划中考虑到，考虑到时间/金钱/资源的限制，目标应该尽可能接近全面覆盖。

这里有很多很好的答案来描述为什么这很重要，但对于如何明智地保护应用程序却没有太多的建议。“标准实践”是在客户机和服务器上使用健壮的输入验证。非理性的输入很容易被保护，你只需拒绝任何在特定环境下没有意义的东西。例如，社会保险号码仅由破折号和数字组成；您可以安全地拒绝用户输入到社会保险号码字段中的任何其他内容。

在您编写的每个应用程序上都应该进行两种测试，它们都有不同的目的。您在自己的应用程序上所做的测试是肯定的测试；它的目的是证明该程序有效。测试人员在您的应用程序上所做的测试是负测试；它的目的是证明您的程序不工作。你为什么需要这个？因为你不是测试自己软件的最佳人选。毕竟，这东西是你写的，所以很明显它已经起作用了，对吧？

当您编写输入验证时，您将使用阳性测试来证明您的验证有效。测试人员将使用随机输入来试图证明它不工作。注意，随机输入的问题空间本质上是无界的；您的目标不是测试每个可能的排列，而是通过拒绝无效的输入来限制问题空间。

还要注意的是，最终用户并不是唯一一个为您的程序提供输入的用户。您编写的每个类都有自己的API和对被认为有效的输入的约束，因此健壮的验证(即“代码契约”)对您的类也很重要。这个想法是强化你的软件，使意想不到的行为是罕见的或不存在的，以最大限度的可能。

最后，工作流很重要。我看到了应用程序的崩溃，不是因为用户输入了一些荒谬的东西，而是因为它们在应用程序中以意想不到的顺序执行操作。您的应用程序应该意识到这种可能性，或者优雅地处理意外的工作流，或者要求用户按照指定的顺序执行操作。