性能测试流程

性能测试流程

性能测试思路：

信息：你是有经验的，你所说的都应该是做过的

性能角度：

用户 -快-响应时间--Response Time

客户 -多--业务处理能力--吞吐量--TPS--HPS--PV(打开页面数) --Throughtput

开发商（软件） -算法+DB是否优化

运维/管理员（硬件） -资源利用率

调研：

1、目的：    1、最大处理能力

2、最大用户数

3、有没有瓶颈

4、调优

2、环境：      1、系统架构（为什么了解系统架构）

2、网络拓扑图

3、服务器环境（软件、硬件的配置）

4、开发（语言）、中间件技术

5、数据库

6、压力机环境（10000个并发用户，每个负载机上压500个）

3、业务：1、业务规则

2、业务限制（验证码、加密）

3、业务范围（哪些业务需要做压力测试）

搭建测试环境：Linux、中间件（weblogic,运维做的）

验证功能（功能是否正确）

业务分析--为脚本开发做准备

脚本开发：

1、web（思考时间、并发用户和在线用户的区别）

2、接口：1、API-java

2、HTTP -java

3、socket

思考时间: 一般思考时间选择录制时的0.5倍到1.5倍，接近于真实场景

关联（为什么要做关联：请求和请求之间数据是有联系的，脚本开发过程中，生成的脚本中某一个函数与函数之间默认是没有联系的，假设前一个请求执行成功

之后，它返回来一些数据，而这些数据恰好是下面请求要用到的，后续的请求用到了上面请求返回的数据，那它怎么去用前面的请求返回的数据呢？就需要通过

关联函数，把前面的请求返回的数据保存下来，传给下一个请求，这就是关联）

关联函数：web_reg_save_param()要能说出关联函数的几个基本参数，如果关联出来的数据是多个呢：需要加上ord=all参数

如果关联函数的左右边界是变化的怎么办：使用web_reg_save_param_ex()关联函数，左右边界可以使用正则表达式，可以再问点正则表达式的知识（可以让

开发的讲解一下正则表达式的基本用法）

怎么快速找出哪些地方需要做关联：脚本回放，定位到报错处，确定是哪个请求报错，出现动态数据的地方一般有三个：1、如果是web_submit_data函数，action=

后面地址可能会有动态数据，2、itemdata后面的数据也有可能是动态需要关联的。3、extrares（额外资源）后面的数据也有可能会出现动态数据

具体找关联的方法：1、利用loadrunner的wdiff对比2个脚本，找出脚本不同之处（确保每次提交的数据一致），一般像数字加字符的乱码是动态数据的可能性很大

2、打开扩展日志，接受服务器返回的数据，在回放日志里面找处怀疑是需要关联出来的动态数据

3、在tree试图下，在报错函数之前的请求，去查找服务器返回的数据里（response），动态数据可能会出现在头信息header里而不是body里

，一般头信息里，那些不常见key，就有可能是需要关联的数据

如果需要关联的数据是在web_custom_request请求的body里以json格式的键值对加上类似&、""的分隔符出现的，需要把关联出来的数据用strtok给切割后再使用

参数化（data factory造数据）为什么要使用参数化:1、脚本与数据分离，类似与QTP里面的数据驱动或者关键字驱动。2、模拟真实使用场景：不同用户每次提交的数据不应该是一样的

常用的参数化的类型：file、date日期类型、随机数

参数化里select next row和update value on的9中搭配方式常用的组合：顺序取值+迭代更新、随机取值+只要出现、unique+once（只要用在注册）

检查点：检查点的作用：loadrunenr是以状态码来判断请求是否发送成功，并不关心页面。所以需要添加检查点来检验页面元素是否出现来判断请求是否真的发送成功，一般配合事务使用

文本检查点web_find和web_reg_find的区别：1、前者需要在运行时设置里打开的preference->check勾选enable image and text才生效，后者不需要

2、前者是在服务器端把数据返回后，在页面上查找文本内容，所以要放在请求后面，后者是个注册型的函数，是在服务器返回的缓冲

数据里查找文本内容，效率比较高

3、后者有个参数savecount可以记录文本出现的次数，加上判断语句If(atoi(lr_eval_string("savecount"))>0)来判断事务成功或失败

集合点：在性能测试过程中，需要模拟大量用户在同一时刻，访问系统并同时操作某一任务，可以通过设置集合点实现多个用户同时进行某操作，在controller

里可以设置集合点策略。集合点函数：lr_rendezvous();

事务：衡量系统性能的一个指标，与RT和TPS有关

场景设计：1、根据业务模型或者性能测试的目的画图

2、监控（前期用nmon监控一下操作系统，CPU、内存、硬盘。然后就发现了瓶颈，比如压力上不去，出现这个问题，解决问题的思路，可能会想到

是压力机的资源消耗太多了，代码的问题去监控java栈，CPU没有得到充分的利用，为什么呢？因为很多线程处于非运行状态，通过JSATCK或jvisualVm

直接对线程栈做个dump，然后分析线程状态，看那些线程不是runnable，定位到代码，通过栈跟踪到代码。）

3、设置：a、IP欺骗

b、宽带模拟

c、是否下载资源类文件

4、压力

结果分析：1、前端分析：

HTTPWatch：类似于loadrunner了，它可以把一个请求花的时间给记录下来，它像loadrunner中的一个录制功能（LR测试请）

YSnow：是给整个页面打分，告诉你页面那些元素做的不好，比如css、js放的位置好不好，整个页面做评估，那些地方需要做优化。

dynatrace：分析页面渲染，尤其是js到客户端的基本情况，弥补了loadrunner的缺陷，loadrunner只是请求到数据返回，数据回来的页面展示没有

dynatrace可以做，主要来分析js，

LR页面分解

2、后端分析： a、操作系统（重点）

b、中间件（定位瓶颈和优化)

c、代码（重点）

d、数据库

3、性能指标分析：a、响应时间

b、处理能力

c、资源利用率

4、数据库分析：a、慢查询

b、表设计不合理，索引不合理

c、数据切分

d、读写分离，磁盘阵列技术

e、缓存技术应用（redis、memcache、mongodb）

性能测试报告：

1、启动/分析

1、1：测试前期准备：

系统基础功能验证

性能预备测试

组建性能测试团队：

1、2：性能测试需求调研

1、3:性能测试需求分析

1、4:测试工具引入

商业工具

自行开发

工具应用技能培训

2、测试计划：

2、1：确定性能测试应用领域：

能力验证：目的、目标

规划能力：目的、目标

性能调优：目的、目标

发现缺陷：目的、目标

2、2：确定测试方法以及策略

2、3：业务建模：

确定测试范围

确定业务种类：偏重吞吐量、偏重响应时间

分析系统日志信息

确定并发用户数

画出业务模型图

2、4：用户建模：

确定用户角色类型

调研用户使用习惯

确定参测业务模型

确定业务使用比率

分析系统日志信息

画出用户模型图

2、5：确定性能指标：

响应时间

吞吐量

并发用户数

资源利用率

2、6：评估测试风险：

过程风险

人员风险

技术风险

环境风险

2、7：测试人员以及时间安排

3、测试计划

3、1：测试环境设计

3、1、1、系统部署架构/网络拓扑图

3、1、2、应用服务器

3、1、3、数据库服务器

3、1、4、控制机

3、1、5、负载生机

3、1、6网络环境

3、2：数据设计

3.2.1、基础数据设计

3.2.2、测试数据设计

3.2.3数据构造工具

3、3：测试脚本设计（基于业务/用户模型）

3、4：测试场景设计

3、4、1、基于吞吐量的场景设计

3、4、2、基于并发的场景设计

3、5：测试监控设计

3、5、1：确定监控对象

3、5、2:确定监控指标

3、5、3：确定监控方式以及工具

4、测试实施：

4、1、搭建测试环境

4、2、构建基础数据和测试数据

4、3、开发测试脚本

4、4、基于工具设计测试场景

4、5、场景执行参数设置

4、6、基于监控工具添加相关监控指标

5、结果分析

5、1、前端页面渲染性能分析

5、2、前端页面组件分解分析

5、3、性能测试相关指标分析

5、4、操作系统指标分析

5、5、数据库指标分析

5、6、程序性能分析

5、7、中间件指标分析

5、8、网络指标分析

6、编写测试报告

web前端 云性能测试服务 CPTS

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。