性能测试分层及规格
性能测试目标
性能测试主要是两个目标：能力验证和能力规划。
- 能力验证：评估系统的能力，衡量系统的性能指标。系统的能力可以是容纳的并发用户数，也可能是系统的吞吐率；系统的性能指标可以是响应时间，也可以选择 CPU、内存、磁盘、网络的使用情况。
- 能力规划：评估某系统能否支持未来一段时间内的用户增长或是应该如何调整系统配置，使得系统能够满足增长的用户数的需要。
测试阶段分层
任何系统都可以粗略地分成客户端、网络和服务器端，相应的，性能测试分层模型也可以分为三层：前端、网络、后端。
前端
前端主要是指用户看到的页面。比如，web 页面、移动 APP 的各个页面，这些是用户最关心的。但前端的性能大多是因为后端服务的响应快慢导致的。当然，前端性能也是比较重要的一块内容，此处我们暂不讨论。
网络
网络是连接前后端的命脉，网络质量的好坏也有很大的影响。在性能测试中可能遇到的情况大致分为两种，一种是测试不同网络状况下的大流量的表现，另一种则是压力机和服务器最好在同一网段，不然压力无法完整的到达后端，会在网络层拖垮，这样就没法较为准确地评测服务器端的性能情况了；即一般会在内网下进行性能测试，在相对优的性能表现下，反推进行网络带宽等的设置。
后端
后端的性能测试一直是性能测试的重点。这里被分为三层：混合场景、单场景、单接口；有的也有分为四层的，多了一层单元性能测试（即单元级的性能测试，如某个核心算法函数的性能。需要说明的是，这个层级，大多数公司都是有心无力）。
后端性能展开
后端性能测试一直是性能测试工作的重心，也是受益最大的部分：若后端出现故障，影响几乎所有前端的请求。
对于后端性能测试，一般根据不同的需求制定对应的策略：
自上而下：有明确目标或指标，目标达成则测试通过，否则进行业务拆分后，找到具体瓶颈点，联系开发进行调优；
如果在性能需求分析时，已经明确了性能需求点、规格、数据量、网络拓扑等信息，可以直接从单场景进行压测；若测试通过，则就不需要拆分到单接口进行，节约资源；
若测试不通过（比如响应时间不达标），则需要将业务进行拆分，拆解成各个单接口，逐一进行性能测试，找到最影响性能瓶颈点的那个接口，重点优化；
自下而上：无明确目标，测试底层模块，并做基本的分析、调优，测出最优指标，然后一步一步向上层扩展。
在大多数情况下，性能需求分析很难全面获取到你需要的性能规格等信息，有时开发甚至只有一句话需求 “ 测一下这个系统的性能表现 “。
此时，需要我们首先进行单接口性能验证、分析，并将各接口按照性能表现排序，优先优化性能表现差的 TOP N（若资源充裕的话，可以进行全接口优化）。
单接口优化过性能，并不意味着单场景、混合场景就一定不会有问题了：可能存在接口间的系统资源争用、线程锁等问题，需要平衡考虑。
有时候可能还会出现这类情况：某接口进行了性能优化、调整了资源使用，在进行单场景或混合场景测试时，为平衡资源使用，该接口还需要减少某些资源开销，导致该接口的响应时间被略微拉长。
需要注意的是，不管是自上而下还是自下而上，都有各自的优缺点，但如果时间充裕的话，还是建议自下而上的进行性能测试，优先测试单接口，然后单场景、混合场景。
性能分析分层
分层分析是指按照系统模型、系统架构以及调用链分层进行监控分析和问题排查。
- 分层分析一般需要对系统的应用架构以及部署架构的层次非常熟悉，需要熟悉请求的处理链过程；
- 分层分析需要对各层的技术有一定了解，如网络、后端、消息队列、缓存、数据库等；
- 分层分析来排查问题的效率虽然较低，但是往往能发现更多的性能问题；
- 分层分析可以自上而下，也可以自下而上。
性能规格约束
- 单个场景压力持续时间不低于 30min；
- DFX 测试 10 次，且最长响应不超指标；
- CPU 使用率不超过 80%
- 单核 CPU 负载不超过 1；
- 内存使用率不超过 80%；
- 稳定性场景使用驼峰式请求；
- 稳定性中，数据并发量最高值超过规格的 1.3 倍；
- 稳定性中，业务并发量最高值超过规格的 1.5 倍；
- 稳定性测试时长，公有云相关产品，稳定性测试周期最短 3 天；
- 稳定性测试时长，其他产品稳定性测试周期最短 7 天；
附内存占用解析
- used=total - free - buffer –cache
- 空闲内存统计，主要看 free 命令中的 available 指标
对性能测试的定义
性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下并发执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。