性能测试基础一

性能测试理论

1. 什么是性能测试？

通过一定的手段，在多并发的情况下，获取被检测系统的各项性能指标，验证被测系统在高并发下的处理能力，响应能力，稳定性等，能否满足预期。定位性能瓶颈，排查性能隐患，保障系统的质量，提升用户体验。

• 什么样的系统需要做性能测试

  • 用户量大，PV（浏览量）比较高
  • 系统的核心模块/接口
  • 业务逻辑和算法比较复杂的
  • 促销/活动推广
  • 新系统、新项目
  • 线上性能问题验证和调优
  • 新技术选型
  • 性能容量评估和规划
  • 日常系统性能回归

• 性能测试指标
  TPS/QPS
  Transaction Per Second 每秒处理的事务数
  单位时间处理的业务数量，单位时间通常为1秒
  eg：测试“下单”业务，将“下单”接口定义为事务
  测试“添加购物车-下单”整体业务，将两个接口定义为事务
  平均响应时间
  响应时间=网络传输的总时间+各组件业务处理时间
  平均响应时间：在测试过程中，所有请求的平均耗时 TOP响应时间
  这个值是如何得到的？
  将所有请求的响应时间先从大到小进行排序，计算指定比例请求的时间都是小于某个时间，该指标统计的是大多数请求时间。
  TP90(90%响应时间)：90%的请求耗时低于某个时间
  TP95(95%响应时间)：95%的请求耗时低于某个时间
  TP99(99%响应时间)：99%的请求耗时低于某个时间

  接口一般响应时间：高频接口响应时间低于100ms，一般接口低于200ms
  并发数/虚拟用户(Vuser)
  原理：用并发线程/进程模拟用户
  成功率
  请求的成功率
  PV(Page View)
  页面/接口的访问量
  UV(Unique Visitor)
  页面/接口的每日唯一访客，UV一般按照ip过滤
  比如访问10次淘宝，对淘宝贡献的PV为10，但对淘宝贡献的UV为一，
  吞吐量
  网络中上行和下行的流量总和，吞吐量代表网络的流量，TPS越高，吞吐量越大
  TPS、响应时间和并发数关系
  在系统达到性能瓶颈之前，TPS和并发数成正比，达到瓶颈后，则TPS不变
  响应时间单位为秒的情况下(TPS和响应时间为反比关系)
  TPS = 1/响应时间*并发数
  TPS = 并发数/响应时间
  4、性能测试流程

• 需求调研
  项目背景、测试范围、业务逻辑&数据流向、系统架构、配置信息(尽量与线上硬件信息一致)、测试数据量(量级一致，对于线上数据库为集群的，只模拟单机用户量)、外部依赖、系统使用场景，业务比例、日常业务量、预期指标、上线时间

• 测试计划
  项目描述、业务模型和性能指标(来源于需求调研中的预期指标)、测试环境说明、测试资源、测试方法及场景设计原则(基准测试、单交易负载测试、混合场景测试、高可用性测试、异常场景测试、稳定性测试、其他特殊场景)、测试进度安排及测试准则
  基准测试：为了找到性能基准，以登录为例，用一个并发用户跑脚本，跑3分钟或者5分钟，得到响应时间，可以得到基准值，特点是：使用单并发测试
  单交易负载测试：单业务单接口测试
  高可用性测试(一般针对线上测试，线下一般没集群，不做该测试)：线上环境多为集群，其中一台服务器挂点，整个系统是否受影响。通常测试方法为：挂掉一个集群，看系统能否正常运行。再把挂掉的集群启动起来，看是否可用。
  稳定性测试：一般挑选混合场景跑更长时间
  其他特殊场景：特殊业务场景
  总结：单交易、混合、稳定性一般都会做

• 环境搭建

• 数据准备
  测试数据分为2部分：基础数据和参数化数据
  通常采用以下三种方式进行构造
  业务接口：
  适合数据表关系复杂
  优点：数据完整性比较好
  存储过程：
  适合表数量少，简单
  优点：速度最快
  脚本导入
  适合数据逻辑复杂
  自由度比较高

• 脚本编写
  选择工具(Loadrunner、Jmeter、Locust)
  选择协议(Http、TCP、RCP)
  参数化
  关系
  检查点(断言)
  事务判断

• 压测执行
  分布式执行
  监控
  linux
  jvm
  数据库
  收集测试结果
  数据分析
  瓶颈定位

• 调优回归
  性能调优需要整个团队完成
  反复尝试
  回归验证
  监控工具
  全链路排查
  日志分析
  模块隔离

• 测试报告