对我来说，这是一个非功能性要求，即使关键用户对安装文件夹位置有一些要求（为了更好地与其他软件包集成）。

更新：

可用功能检测的测试仍然放在功能需求区域，因为：

• 软件在某些情况下可以bin-deploy，手动安装后可以使用一些优化的库
• 某些库仅适用于某些平台（例如仅适用于 .NET 4.0，或仅适用于 Python 2.x）

一个小例子：部署的软件应该检测并使用支持 CUDA 的 GPU。将有 3 组测试：

1. 对于正常的代码路径
2. 对于 CUDA 代码路径
3. 用于正确的 CUDA 检测（GPU 可以在安装后升级/降级）

我同意 alexandrul 的回答，但有一些小警告。

首先，这取决于安装程序的作用。如果它只是一个普通的正常安装，它将属于非功能性。如果安装程序中有一些选项会极大地影响应用程序的功能（即：添加/不添加特定功能），我通常会将其放在我的功能测试中（当我仍然认为将两者分开时） .

正如我在此回复中指出的可访问性测试 - 应该将其视为功能测试还是非功能测试？我喜欢http://www.lessons-from-history.com/node/83中的以下定义“功能需求指定系统应该做什么”“非功能需求指定系统应该如何运行”

我们一直将设置/升级测试视为功能测试，因为我们本质上是在测试安装程序引擎应该做什么。当然，对于带有多个配置对话框的复杂安装程序包，您也有一个行为元素。

您可能还想查看http://www.testingmentor.com/imtesty/2011/02/21/state-transition-testing-thinking-in-models/以获取测试流程示例，以及用于测试的组合测试用于设置/升级的复杂配置矩阵。

Lyndon 提出了一些很好的观点，这取决于您的安装程序所做的事情。过去与他们合作时，我主要处理的是 SaaS，而不再是客户端应用程序，但我过去的工作中有一些，我们主要对它们进行功能测试。理由是我们不只是处理安装，虽然那是存在的，但我们需要处理卸载 - 这是大多数人忘记的事情。我的期望是，当我卸载一个软件时，我希望我的环境能够反映该软件已完全消失，因为如果我重新安装它应该就好像该软件从未存在过一样。如果这是您的要求，由于试用/购买版本，某些应用程序确实希望保留一些内容，并希望确保您不会一遍又一遍地重新安装试用版以避免购买它。因此，除了 alexandrul 的注释之外，我还会检查：

• 卸载，删除所有预期的项目（代码、目录和/或注册表项）
• 重新安装
• 维护（修复安装），通常是在出现问题时修复软件安装的一种