为什么分离系统的功能/非功能方面对我作为测试人员很重要

我在项目一开始就做出了这样的区分（无论是在起草战略还是在实施战略期间）。它有助于使非功能性或“隐式”（被忽略、遗忘或完全忽略的另一个词）需求对所有相关人员都足够“明确”。这使我能够确定和沟通我们立即关注的地方（和多少）以及我们计划如何在一段时间内满足系统的关键非功能方面（为什么我说在一段时间内是在阐述非功能性需求）。

这当然很好；因为作为项目的“前灯”，您想照亮前方的一切。

做出这种区分然后将其包括在您的计划中的几个例子/好处可能是

• 作为测试人员，我不编写单元测试（由开发人员编写，作为 TDD 的一部分），但因为单元测试满足非功能性需求，例如可测试性、可维护性或可扩展性；我总是可以把它作为我策略的一部分，并指出正确的参考或缺乏参考。
• 同样，我不是安全专家，但我可能会强调安全或漏洞是合理的问题，并让专家处理。

关于非功能性需求的一些阐述

非功能性需求在很大程度上是交叉和隐含的，一旦我们注意到它们；它必须在整个项目生命周期中持续不断地努力。Mike Cohn 将这些称为“约束”，并表示这些类似于我们在本博客中的每个敏捷冲刺中必须支付的税款。

我主要从 Brian Marick 的测试象限中得出功能性/非功能性的区别，这在Lisa Crispin 和 Janet Gregory的《敏捷测试》一书中也有详细说明。

对我来说，面向业务的测试主要是功能性的，面向技术的测试弥补了非功能性的需求。

我们对事物进行分类是因为我们认为我们需要以不同的方式对待这些类别。在不知道如何使用答案的情况下，很难就为什么区分功能测试和非功能测试很重要发表意见。重要的目的是什么？有时人们在这些论坛上问这样的问题是因为他们在工作面试或课堂上没有答案。在这种情况下，这个问题似乎比实际更重要。也许这里就是这种情况。

在我看来，“非功能性需求”只是一种笨拙的说法，即“隐含的需求”或“不言而喻的需求”或“不言而喻的需求”。

出于预算目的区分功能测试和非功能测试似乎很重要。一些非功能性需求被区别对待，因为它们已经变得专业化，例如国际化测试和安全测试。有时专业化被外包给其他团体或其他公司，因为在内部维持专业知识过于昂贵或耗时。

在我看来，非功能性需求的测试计划必须像功能性需求一样明确。一旦测试计划明确，二分法就无关紧要了。

每当您将测试分组到一组测试中时，您都可能会按照某个类别进行分组。例如，我们有几套功能测试，可以针对每个日常构建运行。我们还有其他针对安全性、电池、可靠性（非功能性类别）的测试。其中一些套件的运行频率较低。

尽管我们不一定要明确区分结构、功能、非功能或行为测试，但这些类别可以帮助我们对测试套件进行建模，以便我们可以针对特定的重点领域设计测试。

让我们考虑一下两者之间的区别：

• 功能需求 (FR) 往往是由客户/最终用户明确要求的，通常用“它必须这样做”或“它不能那样做”来表达
• 非功能性需求 (NFR) 往往是模糊的或通用的（例如符合 ISO 12345 标准）或经验提醒您做的事情（例如使用良好的编码标准、考虑安全性等）。

作为捕获需求的分析师，我们将它们分开处理，因为在需求分析级别它们是不同的东西......但是一旦整理到规范中（以任何形式），它们就变成了需求。

因此，作为测试人员，区分是不必要的。重要的是您的测试涵盖了所有需求（功能性和非功能性），并且存在足够的测试用例来证明所有需求都已得到充分满足。

事实上，即使作为开发人员，区别也很模糊 - 重要的是代码（或开发过程）满足所有要求。

--

当然，在敏捷团队中，一个人经常身兼数职，但当只戴一顶测试人员的帽子时：

虽然我理解这种区别，但在我的职业生涯中，这对我来说从来都不是一个重要的区别。

我同意这一点。