性能测试

LoadRunner的总体架构图,包括各个组件VUGen, Controller和Analysis之间的关系. LoadRunner由四大组件组成：VuGen、控制器、负载发生器和分析器。 1、VuGen发生器：捕捉用户的业务流，并最终将其录制成一个脚本：（1）选择相应的一种协议；（2）在客户端模拟用户使用过程中的业务流程，并录制成一个脚本；（3）编辑脚本和设置Run-Time Settings项；（4）编译脚本生成一个没有错误的可运行的脚本。 2、控制器（Controller）：（1）设计场景，包括手动场景设计和目标场景设计两种方式；（2）场景监控，可以实时监控脚本的运行的情况。可以通过添加计数器来监控Windows资源、应用服务器和数据库使用情况。 场景设计的目的是设计出一个最接近用户实际使用的场景，场景设计越接近用户使用的实际情况，测试出来的数据就越接近真实值。场景设计也设计很多技巧，如IP欺骗、负载均衡等一些手段。 3、负载发生器（Load Generators）：模拟用户对服务器提交请求。 通常，在性能测试过程中会将控制器和负载发生器分开；即控制器使用一台独立的机器（原因是进行脚本编辑时会产生大量的参数化文件，而这些参数化文件会占用系统资源，再者就是运行时会产生大量的日志文件，最主要是因为在模拟成百上千的虚拟用户进行性能测试时，每个虚拟用户都是需要消耗系统资源的

　　当虚拟用户开发完成之后，使用Controller将这个执行脚本的用户从单用户转化为多用户，从而模拟大量用户操作，进而形成负载。（多用户单循环，多用户多循环）我们需要对负载模拟的方式和特征进行配置。 场景（Scenario） 　　用来模拟大量用户操作的技术手段，通过配置和执行场景向服务器产生负载，验证系统各项性能指标是否达到用户要求，而Controller可以帮助我们对场景的设计、执行及监控进行管理。 　　使用Controller管理场景主要分为：场景设计、场景监控。最后通过运行场景完成性能测试的执行。 手工场景（Manual Scenario） 定义： 　　自行设置虚拟用户的变化，通过设计用户的添加和减少的过程，来模拟真实的用户请求模型，完成负载的生成。手工场景是‘定量型’性能测试，掌握负载变化过程中系统各个组件的变化情况，定位性能瓶颈并了解系统的处理能力，一般在负载测试和压力测试中应用。手工场景的核心就是设置‘用户负载方式’ 手工场景-计划方式 　　scenario:多个脚本之间按照设定的场景计划来统一运行。 　　group:多个脚本之间按照独立设置模式跑，各个脚本可以单独设置虚拟用户、运行时间等。 手工场景-运行模式 　　Real-world schedule(实际计划) 　　　　可以通过Add-Action来添加多个用户变化过程，包括多次负载增加用户、持续时间、停止用户

##什么是性能测试 性能测试包含：负载测试、压力测试、配置测试、并发测试、容量测试、可靠性测试、失败测试。 其实就是看看这个产品在高负荷的情况下的一些表现：比如此产品应用场景下 1、最大限度的多人登录，并发进行业务操作数据库是否可行，响应速度是怎样。 2、在cpu资源使用率很高的情况下运行此系统，是否有问题，是否可长时间运行。 3、在产品局部出现问题时，是否影响其他操作，容错是否可行。 来源： CSDN 作者： 安子-心怀光明 链接： https://blog.csdn.net/weixin_43147867/article/details/104131147

最近组内同事针对性能测试LR的脚本部分做了介绍，是个不错的分享。会后反思自己也有很长一段时间没做性能测试了，根据以往的经验，有必要做些整理和补充，本文主要介绍一些Loadrunner性能测试的学习方法、思路、流程以及测试过程中需要注意的点。脚本相关的介绍在这篇文章就不过多描述了，有兴趣的朋友网上进行查找，资料也相对比较丰富。 一、Loadrunner初步了解 关于Loadrunner的学习，初期重点关注Vuser Generator的使用，需掌握以下内容，再去实战操作基本就不难了。 录制脚本的基本步骤； 理解基础函数的含义：lr_start_transaction(),lr_end_transaction(),web_reg_find(),web_url(),web_submit_form(); 会看输出窗口中的Replay log； Vuser-Run Time Setting中Run logic\log\Think Time的设置； 脚本的迭代； 手动写脚本，掌握基本函数； Loadrunner参数的设置； 针对我们目前的项目基本上是做HTTP/HTTPS协议的压测，大家手上有项目时，可以通过录制了解一下整个HTTP请求及响应的情况，学习一下Loadrunner内置的函数。 另外参数设置、迭代、关联函数等等希望大家查一下资料弄懂，实践一下不同方式有什么不同。 二、性能指标

无意之间发现了GT（随身调）这个性能测试工具，该工具是由腾讯出品的开源测试工具，直接运行在手机上的“集成调测环境”。 1.下载：下载地址：开源地址：https://github.com/TencentOpen/GT 下载地址：http://gt.tencent.com/download.html 2.安装在手机上，图标： ，打开GT 3.选择调试的程序 4.点击‘参数’，点击‘编辑’，将需要的参数拖动放置在已关注的参数下，将不需要的参数拖动放置在不需要关注的参数下，也可以将关注的参数放置在浮窗显示的参数下 5.点击右上角的‘running’，开始启动程序，浮窗上会显示设置的参数，参数页面所选择关注的参数已经在获取数据，在运行的过程中，如果不想显示浮窗的参数，不需要停止运行，只要长按GT的图标，就会隐藏浮窗的参数，需要显示时再长按即可 6.如果需要测试电量的损耗，点击底部的‘插件’，选择电量耗时 7.停止测试后，点击图标上的红色按钮，停止采集数据 8.点击参数页面上的每一个参数，可以显示采集数据的折线图，通过折线图可以观察到各项指标的具体情况 9.点击右上角的保存按钮，可以将每一个指标采集到的数据以Excel的格式保存下来 10.打开手机上的文件夹，将Excel文件在电脑上打开方便分析和查看 11.打开的Excel文件中显示的数据有最大值，最小值，平均值以及每个时间段采集到的数据

本节为大家讲述app的专项测试——客户端性能测试。这个我也做了蛮久的了。在这里修改了一下本篇随笔。 首先我们了解一下什么是客户端的性能测试。性能测试相比大家都已经耳熟能详了，这个app的客户端性能测试估计还是有部分同学不甚了解。 客户端性能测试，主要就是针对app在设备上运行时的内存、CPU、GPU、流量、耗电等进行一系列的测试。主要目的就是为了提升产品的竞争力，同时也可以检测出app的内存泄漏、优化点等问题。当然了，这只是我的个人理解了。 确定测试的介入时机，这个我一般是在上线验收测试之前进行的。倒不是说我这个时机就是对的，实在是资源匮乏，人手不足，只有我一个人进行测试，我只能排在这个时间段进行测试。因为在很多公司，实际上这项测试都只是走走过场，并没有发挥它实际的作用。 我觉得真正的介入时机应该实在开始执行测试的时候，与功能测试并行。因为优化是个漫长的过程，所以越早介入越好，首先能够更加完善的针对这些目标进行测试，其次也能够给予开发人员充足的时间进行优化。 然后就是我们的测试范围，这个测试范围呢，我个人觉得主要还是需要针对产品的核心功能进行。每个产品都有自己的核心功能，用户使用的最频繁的，与用户交互最多的功能模块。 那么我们要检测哪些数据呢？又要如何去监测呢？ 我们要检测的数据如下： Ø内存占用 Ø CPU占用 Ø电量消耗 Ø流量消耗 Ø帧数 使用工具 说到工具，现在工具有很多

最近应用出现了一系列的性能问题，之前对性能不太关注，现在得恶补下基本知识了。先从常用的一些性能指标开始了解。 PV PV是 Page View的缩写。用户通过浏览器访问页面，对应用服务器产生的每一次请求， 记为一个 PV。 PV的统计一般可以通过监控埋点或者统计访问日志统计得出， 通过一些监控系统，也可以直观看到统计数据。 ResponseTime响应时间 响应时间(RT)是指从客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间，响应时间由 请求发送时间、网络传输时间和服务器处理时间 三部分组成。 QPS/TPS QPS/TPS原本含义为：系统每秒能处理的请求/事务的数量，或者说吞吐量。在web应用是指web应用每秒能处理的request数量。这个是衡量系统性能的重要指标。 QPS（TPS）= 并发数/平均响应时间。 QPS的统计可以通过访问日志统计对应时间的PV量除以对应时间求得。在性能测试中可以通过工具测试获得。 一般经常统计的是高峰期PV对应的QPS LOAD负载 系统平均负载，被定义为在特定时间间隔内运行队列中的平均进程数。如果一个进程满 足以下条件则其就会位于运行队列中： -它没有在等待 I/O操作的结果 -它没有主动进入等待状态（也就是没有调用'wait'） -没有被停止（例如：等待终止）1 这个负载值比较理想的指标值是cpu个数*核数*0

1 初识自动化测试 如果以前没有做过自动化测试，那么就不了解自动化测试，可能会觉得自动化测试比较神秘，但是，我们在日常的计算机操作中，可能会碰到一些自动化处理的过程，这些过程和自动化测试比较接近。 例如， Windows操作系统的控制面板中，有一项功能： 任务计划向导 。 DOS批处理文件，直到今天的Windows Vista还在使用它。它更接近自动化测试。 上述的自动化处理过程还不是测试，因为 测试的重要一点是须要验证 ，将实际执行的结果和用户期望的结果进行比较。没有这个比较，就不是自动化测试。 2 自动化测试和手工测试有什么不同 亲手做过自动化测试之后，我们对自动化测试就有了一个感性的认识，至少有下列几点感觉： 　　l 机器人从来就不会感觉累 　　l 自动化测试的速度，是手工测试无法比的 　　l 测试结果准确。例如搜索用时即使是0.33秒或0.24秒，系统都会发现问题，不会忽视任何差异。 　　l 一旦脚本完成，可以一劳永逸地运行很多遍，重复使用。 从这里就可以初步体会到自动化测试的优越性―― 高效率、准确可靠 和 复用性 。同时，自动化测试也有不利的一面，即在 创造性、发现新缺陷 等方面能力不足。 有资料显示，即使自动化测试实施良好，也只能发现软件系统中30%的问题，而70%的问题还要靠手工测试发现。所以 自动化测试更适合于负载测试、性能测试和回归测试 。 概括起来

在正式讲解性能测试脚本开发前，有必要在这里详细介绍一下性能测试的常用术语以及jmeter的常用元件。博主认为在学习一门新技术前里面的术语一定要搞清楚，就像学python时如何连属性、方法、类对像、实例对象这行术语都搞不清楚那就会对学习照成很大的障碍，性能测试中的术语要比python中的术语要多很多。我平时在工作过程中也经常会忘记，所以在这里做一个整理归纳。 负载：模拟业务操作对服务器造成压力的过程。 负载测试：在一定软硬件环境下，通过不断加大负载，来确定能满足性能指标的最大用户数。简单来说可以帮助我们对系统定容定量，找出系统的性能拐点。负载测试常用于用户没有给出具体的性能需求，开发团队自行确认系统的最大并发用户数。 配置测试：为了合理的调配资源，提高系统运行效率，通过在各种配置环境下对系统进行测试从而得出不同配置所反映出来的不同性能，从而为设备选择，设备配置提供参考。 压力测试：可能绝大数测试人员用jmeter就是用来做压力测试，压力测试主要是同过高负载的手段来使服务器资源处于极限状态，测试系统在极限状态下是否稳定。 稳定性测试：在一定硬件环境下，长时间运行一定负载，确定系统在满足性能指标的前提下是否运行稳定，与上面的压力测试区别在于负载并不强调在极限状态下（很多测试人员会保守观念，在测试时会验证极限状态下的稳定性），着重是在满足性能要求的前提下，在常时间运行时系统的稳定性

性能测试监控关键指标： Ø 资源指标 CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。 内存利用率：内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%。 磁盘I/O: 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能。 网络带宽：一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。 Ø 系统指标： 并发用户数：某一物理时刻同时向系统提交请求的用户数。 在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求。 平均响应时间：系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。 事务成功率：性能测试中，定义事务用于度量一个或者多个业务流程的性能指标，如用户登录、保存订单、提交订单操作均可定义为事务。单位时间内系统可以成功完成多少个定义的事务