性能测试理论

 

简介

性能测试应该类比为一个真正的产品项目，而不是一个简单的起压和指标收集；性能测试的目的一定是测试出模块或者系统，在线上提供服务时最贴近真实表现的性能收据；
性能测试分为需求分析、流量分析、测试环境、压力工具、压测步骤、性能瓶颈排查（压测报告）6个部分

需求来源

1. 明确的产品需求或者功能需求：比如运营活动，申购赎回满足正常流量/抢购流量
2. 运维部署的性能测试需求：系统的部署方案，模块的参数调整，系统设计漏洞和代码逻辑导致的性能BUG，比如新模块一定要做模块级压测
3. 产品质量标准：这个依赖于日常的数据统计，比如各个接口的流量，响应时间，模块级别的历史压测数据，已知的性能风险，线上服务机器资源分布；QA根据数据的积累来做风险的评估

流量分析

流量分析和环境分析非常重要，否则很可能导致在大量的无用功之后，得出一个不准确的结论；
压测流量要和线上流量或者线上预期承载的流量尽可能贴近，且在压测时无其他流量，这些也往往和代码策略有关；而这个重点也不熟算算术，而且去分析需要收集哪些条件，去哪收集；

外部系统流量分析

• 根据周边信息或者历史数据确认流量入口的请求量

比如：***的抢购系统峰值5000qps

• 用户类型分析

常见比如新老用户，白名单/非白名单用户

• 用户操作路径分析及每步转化率

首页->产品详情->申购->申购结果页->持仓详情

• 细化场景类型

抢购、正常申购

内部系统流量分析

• 内部系统的流量分析通常是很明确的，我们可以通过数据流，拆解出每个模块的请求次数

这个阶段往往手工分析和工具分析相结合，常用的工具：trace

• 缓存往往会影响内部流量拆解

比如用户初次访问往往会击穿缓存

• 对于内部系统不仅仅要关注流量还要关注容量

比如800qps的写，数据库的写入速率是多少，缓存的容量变化等

环境分析

对于性能测试而言，解决了环境就解决了工作的一半，推荐线下机器资源配置尽量贴近线上

线下环境

• 机器性能

物理机vs虚拟机，以及CPU 内存 磁盘 等配置

1. 网络情况

跨机房vs 同机房

• 配置参数

线程数，日志级别，连接池大小

• 服务混部

公共组件版本，比如数据库，redis

线上环境

线上环境的压测结果最贴近真实，但是风险也最高

• 单机房压测

• Fw拉压测BNS

需求分析

以下几点经过对流量和环境做过数据分析，基本有了以下几点：

• How – 怎么压

起多大压力？怎么起压力？压多长时间？

• Who – 要压谁

压测对象是什么，模块？系统？

• What – 压什么请求

压测接口有哪些？
压测请求怎么构造？

• Where – 压什么环境

线上环境？线下环境？
压测环境怎么保证真实？

需求kickoff

• 明确给出此次性能测试的目的、大致时间范围，和peer沟通论证性能测试的必要性，目的达成一致
• 明确压测目的的性能指标：压力，平均响应时间，机器指标，并发数，

压测方案

压测工具和压测词表

工具一：gometer

• 开发环境搭建:
    2>安装go
   3>设置环境变量

  export GOROOT=~/.jumbo/opt/goexport GOPATH= 代码目录(Gotools的大部分功能其实已经不再针对这个目录，而是针对包名，所以如何定位到对应的源代码就落到了GOPATH身上,import 加载绝对路径时 $GOPATH/src)
  4>编译链接 go build main.go 生成可执行文件main

压测复盘