Step1：了解性能测试计划方案

性能测试文档

1. 性能测试的流程

1. 确认需求 2.编写方案 3.配置测试环境 4.执行性能测试 5.分析测试结果 6.性能优化 7.回归分析 8.性能报告

2. 性能测试【时机】

EG:

1）把系统比作一匹马 载人载货

系统——》服务用户

2）想知道这匹马能够载多少货物 负载测试

上线前 - 容量 买服务器

担心系统因为用户量太多而崩溃

3）这匹马载了很多货能走多远 压力测试

系统是否能够支撑长时间高压运行

4）这匹马受伤了，给马看病 性能优化

线上用户反馈 系统比较慢

3. 测试背景：

术语规定：

并发量 模拟业务操作对服务器造成压力的过程，比如模拟100个虚拟用户同时进行操作

负载测试（load Testing）

在一定软硬件环境下，通过不断加大负载（不同虚拟用户数）来确定在满足性能指标的情况下能承受的最大用户数量

简单说，可以帮我们对系统进行定容定量，找出系统性能的拐点，

从而给予生产环境规划建议。这里的性能指标包括TPS(每秒事务数)、RT（事务平均响应时间）

eg：让一匹马站着往上加货物，看到哪个临界值会崩溃

压力测试/强度测试/稳定性测试

通过高负载的手段来是服务器资源（强调服务器资源、硬件资源）处于一个极限的状态，测试系统在极限状态下长时间运行是否稳定

eg：让一匹马载接近临界值的货物，跑一段时间，看是否能跑得顺畅

RT(Response time)响应时间

4.测试范围

1）调研分析：

1.分析用户的行为

2.产品经理的帮助

3.找架构师/技术负责人---提供数据支撑（数据埋点）

4.性能测试角度--思想 测试左移

5.强资源占用的行为

2）范围梳理：

1.打开首页点击推荐的小说，看小说介绍

2.阅读小说章节

3.用户登录后，查看书架

4.用户头像修改

5. 性能需求分析

• 业务模型/预估/技术负责人认可

1）业务流程节点

2）数据流程——涉及到数据库表

3）业务量

首页

日均UV (user用户访问)（独立访客 Unique Visitor） 5k

日均PV （页面的浏览量） 5w

其他页面......

4）数据量

• 性能目标

1）业务指标

响应时间——竞品/产品设计

相对并发量要求

1.生产环境数据统计 比较准确

2.参考自总访问 推导 并发量 （参考2/8原则，百分之20的时间，贡献了百分之80的量）

3.性能测试要针对 后续会增长的并发量

4.技术负责人，项目经理 共同审核

可靠性/错误率

2）资源占用指标

通常服务器资源 保持在百分之85左右

太低 浪费资源

太高 有崩溃的风险

6.性能测试用例

正常的接口都会很快，即使是业务接口，50毫秒的响应速度也是正常，除非是在并发的情况下

基准测试

基准测试能够提供性能指标衡量的一个参考数据

举例：并发为1，每秒业务吞吐量100/s 占用网络带宽1M

假设生产服务器100带宽，请问：业务吞吐量是多少？ 100*100=10000/s

用例1

虚拟用户数1，持续时间30秒，调用多个接口（基准测试的时间不会太长）

首页访问 - 接口的测试呢容（一般系统-静态资源和动态资源分开）

检查响应时间是否符合要求。。。检查cpu占用率

用例2

虚拟用户数1，取100篇小说，循环1000次，对小说介绍页的访问

负载测试

1.线程数 = 绝对并发

线程：一次请求结束，会继续请求

一个请求500ms完成，又发起一个请求500ms完成

此时：1个线程 -- 》2/s --相对并发

2.模拟对首页的访问，总线程数：2000，初始线程数10，每隔5分钟增加50个线程，达到2000个线程，持续5分钟后慢慢停止

压力测试

通过负载测试找到瓶颈之后，才能知道系统极限，然后模拟并发极限数量，进行长时间的测试

性能测试用例结构

1.流程节点----》访问的接口/资源

2.结合测试需要，设定并发量，以及持续时间

3.性能测试预期/判定标准——很多时候 性能测试 统一的判断标准

4.最大的疑惑：以接口作为单独的性能用例设计，还是以流程为用例设计标准？——

1. 不可拆分的场景，多个接口一起测试

2. 可拆分

7.测试策略

执行策略

基准测试开始时间-结束

负载测试开始时间-结束

压力测试开始时间-结束

指标监控测试

业务指标

通过性能测试工具自带的统计进行查看，比如jmeter

资源监控

数据准备

如何生成数据

要生成那些数据

8.完成标准

达到上面要求的性能目标

9.风险分析

例如：本次测试由于没有采用与生产环境相同的硬件配置，可能和实际运行中的性能又一定差距

例如：本次测试数据为人工生成，可能和实际的数据分布有一定的差异