存在许多定义安全要求的方法。为简单起见，我想说定义一项安全要求，即需要对在为正在制定的特定用例构建误用案例时遇到的威胁进行建模。尽管如此，最终，一些安全要求处于架构级别，而其他安全要求处于代码级别。
我能想到的任何这些级别的安全要求中的大多数似乎都有测试用例（无论是否自动化）。尽管如此，在一些例子中：比如需要阻止一个故意的后门，对我来说，值得在安全要求中制定。
有两种安全要求：
安全功能绝对应该有一个精确的测试用例，这些都是可以测试的。
另一方面，“安全功能”要求实际上要求否定：无注入、无XSS、无溢出、无后门......
虽然可以测试这些以证明不满足要求，但您无法证明它们是. “你不能在……中测试安全性”
就像任何其他非功能性需求一样，单个测试用例不足以证明需求。例如正常运行时间要求：“系统将同时支持 2000 个用户，1 周内不会崩溃”。你能证明这不会发生吗？不，您可以针对它进行测试，如果它失败了，您会知道的，但您不能肯定不同 在不同的情况下，一组用户不会导致它崩溃。
更好的是额外的要求（正如@beth所说）进行审查，并且要求应该围绕审查本身：谁可以做，什么类型的审查，需要修复什么等。
重要的部分是要明确您定义的要求类型：消极的、“保证”类型的安全功能要求，或积极的安全功能。
后者可以有常规的测试用例，前者可以通过不同的方式进行检查。如果您不确定它是哪种类型的需求，您可能需要进一步分解它。
（例如，“密码必须是安全的”应翻译为：“密码应存储为加盐散列”、“散列应为加密安全算法”、“数据存储上的强 ACL”、“不要在电子邮件或网页中公开密码“等等。其中一些是功能特性，一些是非功能性安全需求。有些可以通过测试用例进行测试，有些可以通过 pentest 进行测试，还有一些可以通过代码审查进行测试。
绝对不。安全性通常不是可以通过测试来验证的。正如 Dijkstra 曾经写过的，“程序测试可以用来显示错误的存在，但永远不能显示它们不存在！” 对于计算机安全来说尤其如此。
在需求需要可测试的想法中嵌入了一大堆误解：
妄想。 哎呀，如果我的所有需求都可以使用一些黑盒测试轻松检查，那不是很好吗？如果我有一匹小马不是很好吗？抱歉，事实并非如此。把它吸起来并处理它。
我换一种说法。你听说过深夜醉汉在离开酒吧去汽车的路上丢了钥匙的故事吗？旁观者问他为什么要在 100 英尺外的灯柱下看，醉汉说“那是灯所在的地方”。人们会这样。我们必须记住，需求分析不是关于容易检查的事情。相反，它是关于我们需要什么。这是关于客户的需求。这就是为什么它们被称为需求，而不是成就。
错位的期望。 大多数开发人员一生中的大部分时间都在构建功能。如果您想检查该功能是否存在并且似乎可以工作，那么测试是一种很好的方法。因此，许多开发人员习惯于将测试视为执行各种质量保证任务的方式。但那是狭隘的、狭隘的想法。
安全性不是一项功能。功能是关于确保在用户要求时发生好事。安全性是关于确保在用户没有预料到的时候不会发生坏事。您无法通过功能测试来验证安全性。
换句话说，安全就是要确保当有恶意对手以意想不到的方式攻击您的系统时，不会出现意外。测试是以预期的方式戳系统，因此并不能告诉我们当系统被对手戳时会发生什么。
认为测试就是质量保证的全部。 确保系统安全在某些方面是一个质量保证问题。在安全保证方面，测试通常不是适合这项工作的工具。
安全需要不同的方法。最适合检查系统是否安全并满足其安全要求的一些方法往往涉及：威胁分析、架构安全分析、安全代码审查、静态分析工具的应用、模糊测试和渗透测试。不熟悉安全领域的人往往不知道这些方法，或者没有意识到它们在评估复杂软件系统的安全性中所起的重要作用。
Gary McGraw 喜欢将渗透测试称为“坏度计”。这是一个有两个极端的仪表：一方面，“你的安全性真的很糟糕”，另一方面你得到“不知道”。它永远无法告诉您您的安全性很好；它只能传递坏消息，但没有坏消息并不意味着你有很好的安全性。
有一些安全需求可以通过测试来验证：主要是“安全特性”。但安全性不仅仅是安全功能。软件保障从根本上不同于安全功能。
示例：一个合理的要求是“系统应该包含一种重置我的密码的方法”。这是一项功能，可以通过测试进行合理检查。另一方面，另一个合理的要求是“密码重置功能不应危及安全”。这是一项安全保证要求，您无法通过测试对其进行检查。
所以，不，安全要求不一定是可测试的。有很多安全要求无法通过测试轻松检查其合规性；需要其他方法。
PS 最后一句话：您必须阅读Bruce Schneier 关于安全保证的文章。正是目标。Schneier 指出，我们经常以错误的方式考虑安全性：我们一开始就假设系统是安全的，直到被证明是错误的。Schneier 指出这是倒退的。他建议，如果您希望您的系统是安全的，更好的方法是先假设它是不安全的，直到证明并非如此。（而且，我会插话，测试在证明系统安全方面不会非常有用。只是生活中的事实）
我会说 - “是的，它们需要是可测试的”以及“如果你有一个不可测试的需求，你需要重写”。但我为国防部工作，我的直觉反应是巴甫洛夫式的反射，因为它是基于任何理性的想法。
我经常看到无法测试的高级需求。而且我认为“没有故意后门”的要求可能就是这种情况。但是您需要深入了解一些针对预防措施的要求，例如：
我不确定您的企业如何使用测试以外的要求......在我的情况下，未能满足商定的客户要求可能是违反合同的原因，所以我们小心不要让任何不可能的负面因素进入世界将意味着大规模的范围缩小。
在 DSA 和 ECDSA 签名算法中，在生成签名时，有一个值k，必须在给定的范围内随机均匀地选择。均匀随机性对于安全性非常重要（偏差可以被利用到密钥恢复攻击中），因此相关标准（例如 ECDSA 的 X9.62）将均匀性作为绝对要求进行了说明。但它本质上也是不可测试的……这是一个问题。
X9.62 使用的解决方案是还有“已批准”（带有大写字母）伪随机数生成器，可用于生成 k——但这并不能解决问题，因为这些已批准的 RNG 必须使用“熵字符串”和实际的熵是不可测试的。
因此，虽然有不可测试的安全要求是可以避免的，但有时你不能没有。
编辑：但是，在 DSA 和 ECDSA 的特定情况下，您可以将签名算法转换为另一种向后兼容但具有确定性并因此可测试的算法。请参阅RFC 6979。这并没有使主要观点无效，即不能总是获得可测试性；但这是一个非常有价值的特性，如果可以实现的话，它值得付出相当多的努力。