性能测试笔记(01)

性能测试笔记

性能测试概念

1、性能测试四要素:
a)环境:能够支撑软件进行性能测试的环境,如开发环境、功能测试环境(硬件环境、软件环境、网络)、性能测试环境
b)工具:是自动化测试中不可缺少的东西
c)模型:衡量实际生产的交易建立模型
d)指标:衡量性能好坏的标准
2、定义:在性能测试环境下(尽量模拟生产环境),运用自动化工具模拟系统平常日和高峰期情况下的性能表现,来获取性能指标(如响应时间、tps。资源使用等)的过程
a)压力测试:通常我们是指对系统分阶段的不断增减压力,监控系统达到一个性能瓶颈或者低于性能指标
b)负载测试:对系统不断增加压力,知道系统一些性能指标达到极限或者出现性能拐点
c)并发测试:该测试是指多个用户,在同一时间段同时访问系统中的某一模块或某个业务,来测试系统是否存在性能瓶颈
d)可靠性测试:该测试给与系统一定业务的负载,并发压力、长时间运行,来监测系统是否稳定
e)大数据量测试:在系统存在大数据情况下进行并发或者压力测试,查看系统在大数据下的性能表现,或者短时间内处理大数据量的性能表现

性能测试作用

1、软件不做性能测试的结果
a)软硬不协调,硬件环境浪费
b)无法评估出系统的支撑能力
c)无法还原出系统问题,来支撑运维。比如高峰点接口反应特别慢,不能找到问题点所在。
d)无法评估出系统的寿命,做出合理的规避。根据使用者的增长量,系统的最大承载量,可以计算出系统的生命周期
2、性能测试作用
a)为新系统上线提供数据参考依据(硬件配置采购、注册用户数量评估、系统运行周期)
b)为已经发生性能问题的系统复现故障并监控分析系统出现的瓶颈点,并进行回归测试
c)为集群部署环境的系统,验证集群软件的可靠性

性能测试常用术语

1、并发:所有用户同一时间做同一件事,这种操作必须针对同一类型的业务
2、并发用户数:同一时间与服务器 进行交互的在线用户数量
3、平均事物响应时间:从客户端发出请求得到响应的整个过程时间。这个过程从客户端发出请求开始计时,到客户端收到从服务端返回响应结束时结束。
4、成功率:性能测试过程中,事物处理成功的交易量
5、TPS:(transaction per second):每秒处理交易或者事物的笔数。衡量系统处理能力的重要标准
6、吞吐量:单位时间内网络上传输的数据量
7、点击率:每秒钟用户向web服务器提交的http请求数
8、服务器资源:内存使用率、CPU使用率,磁盘使用率
a)CPU包括:user%:用户态使用的CPU时间比;sys%系统态使用的CPU时间比;id%:空闲时间的CPU时间比;wa%:CPU等待磁盘写入完成时间
b)内存使用率=(1-空闲内存/总内容大小)*100%。一般至少要有10%可用内存,内存使用率可接受上限为 85%. MemTotal:总内存大小、MemFree:空闲内存大小

c)磁盘I/O:磁盘主要用于存取数据,一般使用%DiskTime度量衡量磁盘读写性能

性能测试整体流程

需求调研确认需求测试准备(测试计划、测试用例、测试环境。测试数据)测试实施(脚本编写、场景设计和执行、测试结果收集)诊断调优测试报告测试总结
1、需求调研:
a)目的:本次测试的重点在哪?属于何种类型的测试?如常规性能测试,测试系统的支撑能力;专项测试;如数据库,视频流测试:测试视频是否流畅
b)范围:本次测试的要点
c)系统架构:B/S还是C/S模式的,开发语言是java还是Python
d)部署架构:软硬件的部署情况(CPU、内存、磁盘等)、是否使用软件进行部署?是否使用中间件?使用哪种数据库以及部署方式?
e)典型交易的选择:
i. 使用频率最高的top5-10个交易;
ii. 选择路径足够长的:登录选择商品确认商品加入购物车立即购买支付
iii. 选择足够重要的:百度贴吧发帖功能
f)环境:尽量模拟生产环境(客户使用时的环境)
g)技术验证:评估系统是否可以用可控的方法进行性能测试;在功能测试所有的版本测试完成后才能做性能测试(前期也可以介入性能测试,越早发现的bug,修复的成本是越低的)
h)指标:衡量被测系统好坏的标准。如tps>=100,响应时间<=3s
iv. 已经上线的系统可以从实际生产环境中获取
v. 新系统需要评估,可以参考同行业的
备注:一般资源利用率的指标值比较固定,cpu使用率<=75%,内存<=80%,IO<=80%
b) 模型调研:如转账、查询、取款
i. 已经上线的系统从实际生产环境中获取,比如三只交易共计1000笔,其中转账有600笔、查询100笔、取款300笔,60%:10%:30%
ii. 新系统需要找相关需求人员确认或产品人员确认,并进行评估
2、 测试准备:
a) 文档准备:
i. 环境确认单(需要哪些机器,每台机器的作用,Web服务器、应用服务器、数据服务器是否单独配置机器,以及每台机器的配置,是否使用相关的软件)
ii. 性能测试方案(包括测试策略、性能测试方法、性能测试统计,需求评审的内容)
iii. 性能测试计划(确认性能测试目的、确认测试的环境、确认测试工具、确认测试用例、确认测试场景、确认测试人员、确认测试准入准出条件、确认测试的交付物、确认测试时间安排)
 确认性能测试目的
 确认测试环境:硬件的配置(CPU、内存、硬盘、网卡等)、网络配置、数据库连接数大小、内存大小,java池的大小、连接池大小
 确认测试工具:LR、jmeter、ab
 确认测试用例:参考测试用例模板
 确认测试场景:
 确认测试人员
 确认测试准入准出条件:这个部分主要限定测试开始、结束条件、如测试开始的版本、结束的版本、结束的标准,以及出现什么测试故障可以暂停测试或终止测试(功能有缺陷或服务不稳定)
 确认测试的交付物:通常会有测试报告、测试脚本、调优脚本、调优后的软件参数列表等
 确认测试时间安排
b) 测试用例准备:一个场景就相当于一个测试用例
c) 测试环境准备:包括被测系统的环境和本地压力测试的环境
d) 测试工具准备:测试工具、监控工具
e) 测试数据准备:
i. 存量数据:数据库中原来就应该有的数据
ii. 测试数据:测试功能点需要用到的数据,测试数据需要从存量数据中获取
f) 人员准备:需求调研人员、测试人员、开发人员
3、 测试实施
a) 脚本编写:用LR工具进行编写
i. 事务:操作步骤、交易步骤
ii. 检查点:唯一标识事务成功或失败的点
iii. 关联:当前请求的数据依赖于上一个请求的返回,需要用到关联
iv. 参数化:将不变的数据已参数传递的方式变为可变的数据,更好的模拟生产操作。

  1. 三种策略
    a) 顺序策略:缺点重复性比较高。比如有ABCD四个数据,用户甲依次去取
    b) 随机策略:比如有ABCD四个数据,用户甲随机去取
    c) 唯一策略:只能用一次,比如有ABCD四个数据,用户甲和用户乙
    b) 场景设计
    i. 单交易基准测试:1-1(1只交易—1个用户)
  2. 目的:验证单只交易在无压力情况下是否有性能问题
  3. 方法:一个用户在一个交易数下运行5分钟
    ii. 单交易负载测试:1-多(1只交易—多个用户)
  4. 目的:验证单只交易的最大处理能力
  5. 方法:使用阶梯型用户轮次执行单只交易5分钟
    iii. 混合测试:多-多(多只交易-多个用户)
  6. 目的:验证整个系统的性能处理能力
  7. 方法:多个交易多个用户按照一定的模型比例执行多个轮次,执行10-30分钟
    iv. 稳定性测试:多-多
  8. 目的:测试系统在长时间运行下的稳定性
  9. 方法:去混合场景中最有阶梯(用户数)的80%进行测试12个小时(724系统)或8小时(58系统)
    v. 可靠性测试:
    c) 场景执行:按照场景设计顺序执行
    d) 结果收集:
    i. 收集性能指标值,只需要在LR中对应的组件中将结果提取出来就可以了
    ii. 输出产物:性能测试执行日志
    e) 诊断调优分析
    i. 根据性能测试执行的结果和调研的需求指标进行对比,是否满足调研指标,如果不满足则需要进行调优
    ii. 调优大部分发生在测试执行过程中,一般会出现严重超标会进行当场诊断分析
    iii. 诊断调优部分一般会交给团队中的高级分析师,调优原则:
  10. 根据测试现象分析可能存在的性能问题
  11. 在问题出现的场景执行过程中,抓取可用信息
  12. 重点分析问题过程信息,找出问题的源头
  13. 给出问题分析建议,有项目开发人员进行修改发布版本
  14. 性能测试执行人员对新版本进行回归验证
    iv. 从哪些方面进行调优?(代码,数据库,硬件等)
    v. 输出产物:性能测试诊断调优建议书
    f) 测试报告:评判系统是否符合指标,主要包括内容:
    i. 测试目的:根据本次测试的需求总结出本次测试的测试目的
    ii. 测试范围:
  15. 测试系统范围
  16. 测试交易范围:本次测试选取的典型交易选择描述
    iii. 测试指标要求:
  17. 总体指标:测试需求中谈论指定的测试指标汇总,来源于性能测试方案
  18. 其他需求:包括单只交易性能指标和高可用性的特殊指标
    iv. 测试环境:详细的体现出实际生产环境和测试环境的差别
    v. 测试执行的记录:参考性能测试执行日志
    vi. 测试结果分析:对本次测试场景进行结果分析记录和描述
    vii. 测试问题及解决方法:清晰记录下本次测试过程中测试的问题以及解决方法
    viii. 测试遗留问题及风险建议:本次测试后是否还有一些问题没有解决,以及系统上线过后是否存在哪些潜在风险,详细描述
    ix. 附件:本次测试中的主要文档,比如:测试用例、测试脚本、bug统计、需求文档等
    g) 测试总结:自己总结测试过程中遇到的问题,对相关的测试文档进行归档;经验共享;总结技术为以后遇到相似的系统性能测试提供合理的方案。
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 数字20 设计师: CSDN官方博客
应支付0元
点击重新获取
扫码支付

支付成功即可阅读