1.为什么要进行性能测试?
业务需求
· 大量用户下,系统能否稳定运行(比较多的)
· 用于硬件服务器的选型
· 用于软件技术的选型
招聘需求
· 面试:会性能测试吗?
· 招聘信息:要求会使用性能测试工具Jmeter、LoadRunner
性能测试:通常意义上都是说的服务器的性能
2.性能测试的概念
2.1:什么是性能?
性能(即效率)
· 时间特性:服务器处理用户请求的响应时间(卡不卡)
· 资源特性:软件在运行时,对于服务器资源的消耗情况
· CPU、内存、磁盘等等
2.2什么是性能测试?
概念:使用自动化的工具,模拟不同的业务场景,对软件的各项性能指标进行测试和评估。
软件的范围包括:
· 后台处理程序(代码)
· 中间件(应用服务器)、数据库、程序架构等等
· 服务器资源的消耗
2.3性能测试的目的:
1、评估当前的系统能力
· 验收第三方提供的软件
· 获取关键的性能指标,与同类型的软件对比(例如:跑分)
2、发现性能问题后,寻找性能瓶颈,优化性能(例如:12306春运时服务故障)
3、评估软件能否满足未来的性能需要(例如:淘宝11在2020年的销售额)
性能测试和功能测试:
焦点:
· 功能:关注系统对用户需求规则的满足程度。关注点(正向、逆向)
· 性能:关注系统对用户业务场景的满足程度。关注点(时间、资源)
关系:
· 在一个项目中,功能测试和性能测试一般都有
· 功能测试通过后,才进行性能测试
1.性能测试分类:
1.基准测试
2.负载测试
3.稳定性测试
4.其他:并发测试、压力测试、容量测试等
1.1基准测试:
狭义上讲:单个用户进行业务场景的测试,并统计性能的各项指标(为后续多用户性能测试做参考对比)
广义上讲:在某一个时刻进行性能测试建立一个已知的性能水平,当软硬件发生变化时再测试,观察变化对于性能产生的影响
基准测试数据的用途:
1.为多用户并发测试和综合场景测试等性能分析提供参考依据
2.识别系统或环境的配置变更对性能响应带来的影响
3.为系统优化前后的性能提升/下降提供参考指标
1.2负载测试:
说明:通过逐步增加系统负载,测试系统性能的变化,在满足性能指标的前提下,系统所能够承受的最大负载量的测试。
通过负载测试,一般能找到系统的最优负载和最大负载。
最大负载一股项目组内部知晓,不会对外公布。
普通用户看到的系统的最大能力,一般都是测试得到的最优负载。
负载:指向服务器发送的请求数量,请求越多,负载越高
注意:负载测试关注的重点是逐步增加压力
负载测试曲线图
(1)在(A-B)范围内,增加系统的在线用户数,系统的处理能力(负载量)会增强(最小负载范围内)
(2)在(B-C)范围内,增加系统的在线用户数,系统的处理能力(负载量)不变(负载压力基本饱和)
(3)在(C-D)范围内,增加系统的在线用户数,系统的处理能力(负载量)会减小(超过负载极限)
(4)系统能处理的最大用户数量为?
(5)系统长时间稳定运行时的推荐用户数量为(B)
(6)需求要求:系统在正常使用(长时间使用)时的用户量为(B-C)区间(接近C),考虑是否有性能问题
1.3稳定性测试
在服务器稳定运行(业务正常的负载量)的情况下,进行长时间的测试,保证服务器能够正常运行。时长一般为1天,一周。
其他测试策略
性能测试中,测试策略其实有很多种,但是掌握基础用法后,其他不同名称的测试策略只是基础用法的一个变形用法
1.4并发测试
系统在短时间内同时处理大量需求,查看系统的并发处理能力。
1.5压力测试
测试系统在强负载的情况下,测试系统在峰值情况下的操作,是否具有良好的容错能力及错误的恢复能力。
稳定性压力测试:在系统高负载的情况下(接近C点),长时间运行(24小时),查看系统的处理能力,
破坏性压力测试:在系统极限负载的情况下(C-D点),对系统进行压力测试,查看系统容错能力和错误恢复能
力。
1.6容量测试
关注系统在极限情况下的各种极限参数值
1.性能测试的指标
指标:在性能测试的过程中,记录的一系列的数据值。用这些实际记录的数据值与需求中的性能要求做对比,达成需求要求则无问题;未达到需求要求则说明是性能bug。
常见的性能指标:
响应时间,并发数,吞吐量,错误率,点击数,资源利用率
2.常用性能指标
2.1响应时间
客户端发送请求,到客户端收到服务器返回的响应,过程中所经历的全部时间,都是响应时间
响应时间=应用程序处理时(A1+A2+A3)+网络传输时间(N1+N2+N3+N4)
2.2并发数
说明:并发测试的用户数
扩展:
· 系统用户数:系统注册的总用户数据
· 在线用户数:某段时间内访问系统的用户数,这些用户并不一定同时向系统提交请求
· 并发用户数:某一物理时刻同时向系统提交请求的用户数
2.3吞吐量
英文为Throughput,.单位时间内,系统处理客户端请求的数量。,衡量服务器性能好坏的直接指标,从不同维度来描述:
· 业务维度:业务数/秒,业务数/小时,业务数天
· 网络维度:字节数/秒,字节数/小时,字节数/天
· 技术维度:TPS(每秒事务数)、QPS(每秒请求数)
QPS
服务器每秒钟处理的接口请求数量。(一个服务器中有多个接口,QPS指的是所有接口在同一单位时间内的接口处理数量之和)
TPS
服务器每秒种处理的事务请求数量。
一个事务通常指的是界面上的一个操作。一个事务可以包含一个或者多个接口请求。
对于登录事务而言,当TPS为10时,服务器的QPS也是10
对于支付事务而言,当TPS为10时,服务器的QPS就是30
2.4点击数
点击数不是指在页面上的一次点击。
指的是页面(html代码、图片、js。。。)加载时,向服务器发送的请求数量
可以用每秒点击数来衡量web服务器的处理能力。
2.5错误率
错误率不是功能有错误或者bug
指的是系统在高负载的情况下业务失败的次数/业务总次数?100%
2.6资源利用率
说明:是指系统各种资源的使用情况,一般用“资源的使用总量?100%”形成资源利用率的数据
1.1性能需求分析
· 熟悉被测系统
。熟悉系统的业务功能
。熟悉系统的技术架构
· 明确性能测试内容
。从业务角度,挑选核心业务进行测试
。从技术角度,挑选逻辑复杂度高、数据量大的业务进行测试
· 确定测试策略
。负载测试、稳定性等
· 确定性能测试指标
。有需求:按照需求来测试
。没有需求:同类型软件对比,对未来数据进行预估
1.2性能测试计划:
从模板内容来说,与功能测试基本一致,主要就是写清楚谁来做、怎么做。
主要内容:
1、项目背景一一简介
2、测试目的
3、测试范围一一对于需求分析中的性能测试内容
4、测试策略一一对应于需求分析中的测试策略
5、风险控制一一技术风险、人力风险
6、交付清单一一每个阶段的产出物
7、进度和分工一一谁在什么时候做什么事
1.3性能测试用例
要素:用例标题、用例编号、用例预制条件、用例步骤、用例预期结果、用例实际结果
(实际结果:需要监控的各项性能指标)
1.4性能测试执行
测试脚本的编写/录制
建立测试环境一一尽可能与用户的环境一致
执行测试脚本
性能测试监控一一与测试脚本执行同时进行
性能分析和调优
。测试人员只需要确定是否存在性能bug,有ug则提缺陷报告
。问题分析和调优由开发人员来完成,测试人员配合验证调优结果(可能需要经过多轮验证)
1.5性能测试报告
1、性能测试的过程记录,性能测试发现的问题、分析
2、性能测试过程中的风险,当前是否存在风险
3、给出性能测试结论(通过/不通过),经验和教训。
xpath元素属性定位
//* 或者//tag_name(文件名)
//*[@attribute]=‘value’
attribute表示的是元素属性名
value表示的是元素对应属性值
案例:
需求:打开注册A.html页面,完成以下操作
1).利用元素的属性信息精确定位用户名输入框,并输入:admin