Ⅰ概念
from 《持续交付》
非功能需求(NFR)测试：关于容量、吞吐量、性能等的测试
代表着软件项目的交付风险
性能——处理单一事务所花时间的一种度量，既可以单独衡量，也可以在一定的负载下衡量。
吞吐量——系统在一定时间内处理事务的数量，通常它受限于系统中的某个瓶颈。
容量——当每个单独请求的响应时间维持在可接受的范围内时，该系统所能承受的最大吞吐量
Ⅱ管理
在项目开始就识别出哪些是重要的非功能需求，这一点至关重要。
管理非功能需求：
1. 创建一些具体任务来管理非功能需求
2. 如有必要，向其他功能需求加入非功能需求的验收条件
分析非功能需求时，提供适当的细节是至关重要的：“两秒内作出反应”——>1. 所有情况下都需要 2. 某数据中心出现问题时，依然需要 3. 边缘应用也需要，还是只针对常用应用 4. 两秒是指两秒内结束交互，还是指能得到某种反馈即可 5. 某个地方出现问题，需要在两秒内返回错误信息给用户，还是只针对成功交互 6. 较大压力下是否也需要 7. 峰值下也需要，还是平均响应时间
容量测试的关键在于，它要告诉我们是否存在问题，以便我们可以修复它。不要妄自猜测，而要先进行度量。
Ⅲ分类
相对度量：
1.扩展性测试 随着服务器数、服务或线程的增加，单个请求的RT和并发用户数的支持如何变化
2. 持久性测试 长时间运行程序，是否会有性能上的变化，这类测试能捕获内存泄露或稳定性问题
绝对度量：
3. 吞吐量测试 系统每秒能处理多少事务
4. 负载测试 当系统负载增加到类似生产环境大小或超过它时，系统的容量如何？
Ⅳ实践
容量测试的一个重要方面是能够为给定的应用程序模拟真实的使用场景。
另外一种方法是找出系统中具体操作的技术基准。
基准式容量测试(benchmark-style) ——> 整个视图的一部分
需要测试断言来判断系统能够满足业务需求 ——>
基于场景的测试，根据业务上对真实环境中的预测值进行评估
基于场景的测试能够与包含其他交互操作的容量测试同时进行。可以将容量测试组成多个大范围的测试套件，并行执行。
定义容量测试的成功与失败条件：
能够产生度量数据，产生成功或失败报告，提供一些系统中所发生的信息，趋势图。
容量测试环境：
1. 尽可能与生产环境相似
2. 缩放范围进行测试 找出两个环境的对比基准；对于集群应用，仅复制一小部分的服务器
自动化容量测试套件
容量测试的目标：
1. 测试具体的现实场景
2. 预先设定成功的门槛
3. 尽可能让测试运行时间短一些
4. 在变更面前要更强壮一些
5. 组合成大规模的复杂场景
6. 可重复，既能串行，又能并行
既满足上述目标，又不过分设计：
使用已有的验收测试——>缺少承受较大负载的扩展能力，度量成功的规范
1. 创建比较现实的类生产环境的负载
2. 选择并实现那些具有实际代表性且现实生产中非正常负载状态的场景
è系统的可扩展性测试，Nygard说：“识别出系统中代价最高的事务，然后在系统中把它变成两到三倍的数量”