《持续交付》 - 非功能需求测试
在自动化测试中，相对于功能的测试，我们往往会忽略对非功能需求的测试，这也是很多小的开发团队所忽略的一个问题，当交付软件的时候导致软件的性能较差。事实上，NFR（NonFunctional Requirement，非功能需求）是非常重要的，因为其在很大程度上决定了软件交付的质量。即使是我们知道非功能需求是什么的时候，我们还是很难的去花费合适的精力去满足这些非功能需求，因为我们可能要在低质量代码上去进行维护或是系统变得过于复杂导致开发人员无从下手。所以当项目开始的时候我们就应该提前搞清楚项目的非功能需求是什么，它应该出现在部署流水线的哪个阶段去测试，做到心中又底。一般非功能需求包括：
- 性能：处理单一事务所花费时间的一种度量
- 吞吐量：系统在一定的时间内处理事务的数量
- 容量：在一定的工作负荷下，单独请求所花费的时间在可接受的范围内，该系统所能承受的最大吞度量
一 非功能需求的管理
非功能需求的满足对于项目交付的质量是很重要的，以至于在项目一开始，交付过程中的每一个人都应该去思考本项目的非功能需求。然后为这些非功能需求创建一些具体的用户故事或任务，如果有必要的话可以为这些非功能性需求加一些验收条件。在分析非功能需求时，提供详细的细节是非常重要的，以便于很好的理解验收条件。
二 为容量编程
在为容量编程前，我们应该已经确保很好的分析了非功能需求。容量测试的关键就在于我们它会告诉我们是否存在问题，以便与我们去修复它。这也就是说我们不应该去枉自猜测，而要先去度量。不要去过分的关注应用程序的容量优化，让代码变的过于复杂，最终可能导致无法让项目交付。在项目初始阶段时，就应该意识到容量问题出现的常见原因并设法去避免。一般可以采取下列策略：
- 采用一种合适的架构（注意进程、网络边界、I/O）
- 避免使用影响系统容量和稳定性的反模式
- 不做与容量无关的优化
- 选择与应用程序吻合的数据结构
三 自动化容量测试
代码的修改对系统容量的影响与其对功能的影响是同等重要的，当对代码做了修改后，我们可以知道容量的变化，从而可以更好的去修复。这就是自动化容量测试的目的，一般我们会将自动化容量测试放在部署流水线，也叫容量测试阶段。对于容量测试阶段，应该在通过了提交测试和验收测试（可选 ）后立马进行，，因为容量测试是非常脆弱的，对代码很小的修改都可能会造成容量的变化。容量测试应该达到以下几个目标：
- 测试具体的现实场景
- 预设成功的条件
- 尽可能让测试运行时间短一些
- 是可以重复的
- 保持健壮性
- 可以组成大规模的复杂场景
