性能测试学习笔记(一)

1.性能测试概念

性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。

1.1性能测试指标

时间指标
容量指标
资源利用率指标

1.2性能测试模型

模型是是真实场景的抽象，可以告诉性能测试人员，业务模型是什么样子。比如说，我们有 100 种业务，但不是每个业务都需要有并发量，可能只有 50 个业务有，那就要把这些有并发的业务统计出来，哪个业务并发多，哪个业务并发少，做压力时就要控制好这样的比例。

1.3性能测试方案

方案里的关键点要有测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险。基本上有这些内容就够了，当然这些内容具体的信息还需要精准。

1.4性能测试监控

监控要有分层，分段的能力，要有全局监控、定向监控的能力。

1.5性能测试预定条件

预定条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容。在场景执行之前，这些条件应该是确定的。

1.6性能测试场景

性能场景描述：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。

性能场景分类：

基准性能场景：这里要做的是单交易的容量，为混合容量做准备。
容量性能场景：这一环节是最核心的性能执行部分。根据业务复杂度的不同，这部分的场景会设计出很多个。
稳定性性能场景：稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中，稳定性测试基本没和生产一致过。在稳定性测试中，显然最核心的元素是时间（业务模型已经在容量场景中确定了），而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人的心理安全感。
异常性能场景：要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常。

1.7性能测试分析调优

性能场景完成后得到测试结果，需要对结果进行分析，同时如果条件运行还可以做瓶颈判断、性能分析、性能优化。

1.8性能测试报告

场景执行的过程，产生的数据要整到结果报告中，性能结论也要写入报告。同时可以加入性能整体分析与优化建议。

2.TPS与响应时间

上图中蓝线表示TPS，黄色表示响应时间。

在TPS增加的过程中，响应时间一开始会处在较低的状态，也就是在A点之前。接着响应时间开始有些增加，直到业务可以承受的时间点B，这时TPS仍然有增长的空间。再接着增加压力，达到C点时，达到最大TPS。再接着增加压力，响应时间接着增加，但TPS会有下降（请注意，这里并不是必然的，有些系统在队列上处理得很好，会保持稳定的TPS，然后多出来的请求都被友好拒绝）。最后，响应时间过长，达到了超时的程度。

3.性能测试场景综述

场景	作用	替换的概念
基准性能场景	也可称为单交易容量，即将每一个业务都压到最大TPS，从而为后续场景做数据对比
容量性能场景	也可称为混合容量性能场景，即将所有业务根据比例加到一个场景中，在数据、软硬件环境、监控等配合之下，分析瓶颈并调优的过程	性能测试、负载测试、压力测试、强度测试、容量测试、极限测试、并发测试、综合场景测试、极限测试
稳定性性能场景	核心就是时长，在长时间的运行之下，观察系统的性能表现，分析瓶颈并调优的过程	疲劳强度测试、稳定性压力测试
异常性能场景	显然就是异常的定义最为重要，常用的手段就是宕主机、宕应用、宕网卡。还有宕容器、宕缓存、宕虚机、宕队列、宕缓存。实际的场景中要模拟什么杨的异常，一定是根据系统的业务架构和部署架构分析而来的。	破环性压力测试