测试应用的功能通常是很简单的——我们遵循普通用户所采取的方法来使用它。如果我们不确定预期行为是什么，通常也会有某种方法能知道——询问别人，阅读需求，使用我们的直觉。负面测试遵循一些从正面测试中自然而直接地获取的原则。我们知道银行的“存款”不应该是负值；密码不应该是1MB的JPEG图片；电话号码中不应该包含字母。随着我们对应用进行测试并建立起正面的功能测试，建立反面测试就自然而然地成为下一步。那么这与安全测试有什么关系？

　　安全测试就是要提供证据表明，在面对敌意和恶意输入的时候，应用仍然能够充分地满足它的需求。

　　提供证据

　　在安全测试中，我们考虑无法接受的输入的全体集合——无限集——并重点关注那些很可能在我们软件的安全需求方面造成严重失效的输入子集——仍然是无限集。我们需要确定这些安全需求是什么，并决定什么类型的测试能够证明这些需求得到满足。这并不简单，但是通过逻辑和勤奋，我们能够向产品所有者提供有用的证据。

　　我们证明安全满足需求的方式将与证明功能满足要求的方法相同。我们建立输入，确定预期结果，然后建立并运行测试来锻炼系统。以我们与不熟悉安全测试的测试人员交往的经历来看，第一步和最后一步是最难的。设计反安全的输入和对软件进行测试是最难做的事情。大多数时间，预期的结果相当简单。如果我询问产品经理：“有人能够在不登录的情况下下载敏感数据吗？”。通常他很容易就会说不。因此，提供证据过程中较难的部分是创造出可能会造成这种状况的输入，然后确定这种状况是否会发生。

　　满足需求

　　有关软件工程学的ANSI/IEEE标准729将“需求”定义为用户为了解决问题或达成目标所需要的条件或功能，或为了满足合同、标准、规范或其他正式起效的文档，系统所必须拥有或满足的条件或功能。在得知需求的情况下，所有测试人员都进行测试直到满足需求。即使需求并不是以充斥着“该软件应当”语句的形式出现，软件测试人员也往往能够就正确的响应达成共识，然后以预期结果的形式将其整理到测试之中。

　　安全测试与功能测试相似，因为它同样也依赖于对“我们想要怎样的行为”的理解。当然也可以说，与功能测试相比，安全测试更加依赖于需求，因为它有更多可能的输入和输出可供筛选。在需求编写者的脑海里，安全行为的定义往往更加模糊，因为大多数软件都不是安全软件。该软件有一些其他方面的主要用途，而安全是一种必须存在的非功能性需求。因为对安全的关注不够，所以这方面的需求常常缺失或不完整。

　　充分地满足需求，这种想法如何？因为安全是一个不断发展的过程，而且因为安全通常不是我们的主要功能，所以我们并不总是只因为更安全就去做某件事。真正的软件安全实际上指的是风险管理。我们确保软件的安全程度满足我们的业务需要。有时，安全纯粹主义者会认为软件不够安全。只要它能够满足业务所有者——当这些所有者意识到风险并充分理解自己所承担的风险时——那么这个软件就足够安全。安全测试提供了必要的证据和信息，以便业主就承担多少安全风险方面做出知情决策。

　　安全测试是老调重弹

　　安全是一段旅程，而不是目的地。我们永远也无法做到能够宣称软件已经安全而我们的任务已完成的地步。在执行功能测试时，我们通常使用指定的、可接受的输入，这些输入将产生已知的、预期的结果。在安全测试中，并不存在同样的有限性来约束我们的期望。

　　设想我们正在测试这样一种需求：“对于最大不超过MAXINT的正整数，convertIntToRoman（int）函数将返回有效的罗马数字字符串”。如果我们只是在进行功能测试，我们将提供5作为输入并确保函数返回“V”。边界值测试将检查最大整数值，0，－1等取值。我们会检查“－5”作为输入时程序给出正确的异常处理，并确保输出不会是“－V”，而是适当定义的错误响应。最后，异常测试将使用等价类来确保函数在输入为3.42时不会返回“III.IVII”作为输出，并能够在输入是“Fork”等奇怪字符串时给出适当的错误处理。