|
重点难点：
需求分析、性能诊断调优
1 测试流程
1.1 需求分析
产品规格：产品经理会告诉做一个什么功能
用户模型：用户数量、用户使用时间段、用户喜欢使用的功能
系统数据：基础数据和业务数据
是因为性能测试需要大量的数据，数据少了，和数据相关的性能问题测不准确，造数据的原则：宁多勿少
系统架构：
web系统：浏览器-nginx-tomcat-redis-mysql
运维日志：进一步确认真实用户的数据和行为
市场计划：帮助我们考虑系统性能的扩展性的
项目管理计划：帮助我们明确测试点的优先级
1.2 方案设计
测试方案和测试有什么区别
需求是源头，方案是关键
压测环境：线下还是线上
工具选择：jmeter/locust
场景设计：单场景还是复杂场景
1.3 测试计划
什么时间、什么人、做什么事、什么时间做完完整版本：项目背景、风险说明、风险应对方案等，通常会用word来一个性能测试计划文档
精简版：project、事情-谁做-时间
1.4 脚本编写
1）了解系统：接口、性能彼此的依赖关系，才开始写脚本
编写脚本常见问题：
1）没有注释
2）写完后没有在场景中跑，直接压测，脚本跑起来就各种报错
1.5 环境搭建
1）搭建环境的资源
2）线下环境模拟线上环境
能在线上做就在线上做
线上分两种情况：
系统没有给用户使用，可以直接在线上测
系统有真实的用户，全链路压测
3）搭建测试环境：测试出测试机器的扩展系数
1.5.1 全链路压测
1）压测的时候会不会影响线上的用户
2）压测的时候会不会影响线上数据库
3）系统比较复杂，协调多个团队
4）日志统计影响
全链路压测通用思路：
1）压测流量要做标识
2）所有的web服务器、应用服务器、缓存服务器、消息队列服务器、数据库服务器都要能识别出压测流量和正常流量的能力。
3）要在所有存储和落地的数据中mysql redis 4）rocketmq中都要有一个影子库或影子表，或缓存区域去存储这些压测的流量
1.6 数据准备
1）准备多少数据，需求分析得出的结果
2）怎么准备：线上数据搜集，工具生成数据
1.7 执行测试
设置好成绩，数据跑出来
1.8 监控和收集数据
监控为了收集数据，为后面的分析和调优做准备
1.9 分析调优
2.0 编写性能测试报告
根据不同人看，写不同的数据
2.1 性能测试指标
用户数
并发用户数，同一时间同时做一件事的用户数
在线用户数：某个时段在线的用户数
注册用户数：从开始到当前一工注册过该系统的用户数
并发用户数是用来压测的：注册用户数是用于造基础数据提供依据的，当然，可能这个不够，实际造的基础数据可能更多
响应时间
用户开始访问系统到用户收到的这段时间称为响应时间
响应时间计算：
响应时间=网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输时间+页面前端解析渲染时间
对外说响应时间是多少时，要说明是在多少TPS下的
TPS
TPS是指服务端每秒处理的事务数
用来衡量系统处理业务的能力，根据实际需要增加
吞吐量
用户反应客户端和服务器之间网络状态的一个指标，其能间接反应服务器承受的系统压力。
吞吐量是衡量网络性能的实际指标（带宽是理论指标）
思考时间
模拟真实用户操作而停顿的时间间隔
思考时间影响系统TPS
资源利用率
cpu、内存、网络、IO
|