Windows服务器中自带的性能监控工具叫做Performance Monitor;
在开始-运行中输入‘perfmon’,然后回车即可运行。
Monitor本身也是一个进程,运行起来也要占用一定的系统资源。所以你看到的资源的使用量应该比实际的要稍微高一点。这个工具在帮助管理员判断系统性能瓶颈时非常有用;
举个列子来说,今天有个用户抱怨说他们项目组的服务器(这是一台虚拟机)运行起来非常慢,但也不知道具体问题出在什么地方。任务管理器里显示CPU和内存的使用量都不算高,但服务器的相应就是非常慢;
Monitor,让其运行一段时间后(因为参考平均值会比较准确),发现average disk queue的值比较高,这就说明物理服务器的硬盘负荷太重,I/O操作的速度跟不上系统的要求。关掉虚拟机,将其转移到另一台硬盘负载比较小的主机上,再打开虚拟机。
分析性能情况
1、内存泄露判断
虚拟内存字节数(VirtualBytes)应该远大于工作集字节数(Workingset),如果两者变化规律相反,比如说工作集增长较快,虚拟内存增长较少,则可能说明出现了内存泄露的情况。
对于Workingset、Private Bytes、Available bytes这些计数器,如果在测试期间内数值持续增长,而且测试停止后位置在高水平,则也说明存在内存泄露。
Windows资源监控中,如果Process\PrivateBytes计数器和Process\WorkingSet计数器的值在长时间内持续升高,同时Memory\Available
bytes计数器的值持续降低,则很可能存在内存泄漏。
2、CPU使用情况
一般平均不要超过70%,最大不要超过90%(好:70% 、坏:85%、 很差:90%)。
3、tps(每秒处理事务的数量,在SOAPUI中进行统计)
一般在10-100,不同应用程序具体值不同。
问题一:软件测试中性能测试需要关注什么 性能测试需要关注的第3件事,就是被测系统所处的操作系统环境。要破译它,必须要学会凌驾它的命令,不论是windows,unix,还是liunx,皆如此。淘宝用的是liunx,于是我们自然要学会活用liunx命令。在性能测试过程中,我们往往要查询服务器资源使用情况,例如cpu,load,i/o等。此时,top命令、uptime命令、iostat命令就显得尤为重要。在性能测试过程中,我们往往要查询服务器的log信息。此时,cd命令、vi/vim命令、cat命令、grep命令、tail命令就能大显身手。在性能测试过程中,我们往往要查看某个进程使用的虚拟内存和物理内存。此时,cat /proc/pid/status就十分有用。在性能测试过程中,我们往往要查看某个文件占用了大量的空间。此时,find命令派上用场。此处不一一列举。上述这些命令,均可以根据实际情况,配以对应的参数,进行更好的跟踪来采集所需要的数据。liunx命令的灵活应用,配合shell的语法规则,能写出许多非常使用的小脚本。这些东西,对于性能测试,及性能测试结果分析,都有相当重要的意义。
问题二:软件性能测试需要会什么 这个你算问对人了。给你说几点吧,为什么性能测试在软件测试里面算是吃香的,因为他的要求也比较多,需要掌握:网络方面、数据库方面(Oracle、SQLserver、mysql)、操作系统(如Linux方面)、脚本(如shell)、性能测试工具、资源监控工具、瓶颈定位工具,以及分析问题的能力。除此在外要对Java或要有一定了解。尤其是内存机制方面。如果你想成为一名合格的性能测试工程师的话 ,慢慢学吧
问题三:性能测试应该做哪些准备 环境搭建:这个根据实际规划,我在企业内做过的性能测试搭建的环境都是和用户上线使用的实际环境一样的。
数据准备:个人感觉是整个工作里第二耗时的,需要真实模拟用户数据,这个不是单单的创建几个帐号就完事的,每个用户基本都会有不太一样的配置,实际操作的时候部署数据的脚本都写到手软。
脚本编译:选择性能工具编译性能脚本,你需要跑什么业务流程就编译什么样的脚本。
脚本执行:用规划好的用户数执行脚本,这个一般持续很长时间,时间太短不足以暴露服务器等的性能瓶颈,性能测试中最耗时的就是这个步骤。
收集日志:在执行脚本完成后收集到的能客观反应系统性能的日志、报表文件,比如LR的报告、数据库的AWR日志等等。
分析结果:分析收集到的日志、报表,找出性能瓶颈或是得出性能指标结果。这个一般需要对数据库或者底层非常了解的专业人士来分析,一般测试人员只需要提供收集到的报告就差不多了。
生成报告:将上面所有的性能测试活动整理总结,输出测试报告。
问题四:要做好性能测试,该掌握些什么? 这类问题之前也被问到很多次了,所以这次干脆整理一下,发个主题供同行们参考。如果需要补充,也欢迎大家留言一起讨论。 如果想真的做好性能测试,需要学习的东西还是比较多的。简单列一下吧。 1. 精通性能测试的基本概念,过程,方法论,了解性能工程;
3. 扎实的计算机专业基础知识,包括计算机组成原理、操作系统、数据库原理、计算机网络原理;
4. 熟悉至少1个常用的数据库产品,例如SQL Server或者 Oracle,能进行一般的数据库管理操作,熟悉SQL脚本的使用,熟悉常用的数据调优工具和常用的counter;
5. 熟悉至少一个操作系统的原理,Windows或者Linux都可以,熟悉操作系统的体系架构、操作系统的重要基础概念,以及内存管理、存储/文件系统、驱动/硬件的管理、网络协议的实现及构成、性能的监控方法和原理,熟悉常用的counter;
6. 熟悉至少一个web server 产品,例如apache,了解一般的配置和常用的counter;
7. 熟悉至少一个应用服务器产品,例如tomcat,了解一般的配置,熟悉常用的服务器性能监控方法和原理,熟悉常用的counter;
8. 至少熟悉TCP/IP协议,熟悉HTTP协议,至少见过并了解三层、四层交换或者路由器的使用和配置。了解常用的与网络性能相关的counter;
9. 了解一般的大型企业应用的部署架构和应用架构;
10. 了解知名大型web应用、高并发量、高流量、实时响应要求高的超大规模网站的架构和优化历程;
11. 熟悉统计学的基础知识、常用分析方法以及实验设计方法,了解数学建模相关的知识;
12. 熟悉专属行业的业务知识和用户场景,例如电信行业的OSS系统所涉及的业务知识和用户场景,证券交易系统所涉及的业务知识和用户场景;
13. 大量的实际性能测试及优化经验;
14. 积极的参与到各类圈子、社团的讨论和交流、分享中。 暂时先想到了这么多,有兴趣的朋友可以一起讨论一下,相信每个人都有自己不同的经历和感想,可以跟其他人分享一下,提供参考。
另外,我之前也整理发布过不少性能测试方面的资料,从入门级的文章到 升级的必读都有一些,有兴趣可以参考。
问题五:性能测试的内容 性能测试 在软件的质量保证中起着重要的作用,它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面:应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下,三方面有效、合理的结合,可以达到对系统性能全面的分析和瓶颈的预测。 应用在客户端性能测试的目的是考察客户端应用的性能,测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等,其中并发性能测试是重点。并发性能测试是重点并发性能测试的过程是一个负载测试和压力测试的过程,即逐渐增加负载,直到系统的瓶颈或者不能接收的性能点,通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试(Load Testing)是确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统组成部分的相应输出项,例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用,从而来确定能够接收的性能过程。压力测试(Stress Testing)是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。并发性能测试的目的主要体现在三个方面:以真实的业务为依据,选择有代表性的、关键的业务操作设计测试案例,以评价系统的当前性能;当扩展应用程序的功能或者新的应用程序将要被部署时,负载测试会帮助确定系统是否还能够处理期望的用户负载,以预测系统的未来性能;通过模拟成百上千个用户,重复执行和运行测试,可以确认性能瓶颈并优化和调整应用,目的在于寻找到瓶颈问题。当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候,尤其是以后在生产环境中实际使用起来,用户往往会产生疑问,这套系统能不能承受大量的并发用户同时访问? 这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。举例说明:电信计费软件众所周知,每月20日左右是市话交费的高峰期,全市几千个收费网点同时启动。收费过程一般分为两步,首先要根据用户提出的电话号码来查询出其当月产生费用,然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤,但当成百上千的终端,同时执行这样的操作时,情况就大不一样了,如此众多的交易同时发生,对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统的承受力,预见软件的并发承受力,这是在软件测试阶段就应该解决的问题。大多数公司企业需要支持成百上千名用户,各类应用环境以及由不同供应商提供的元件组装起来的复杂产品,难以预知的用户负载和愈来愈复杂的应用程序,使公司担忧会发生投放性能差、用户遭受反应慢、系统失灵等问题。其结果就是导致公司收益的损失。如何模拟实际情况呢? 找若干台电脑和同样数目的操作人员在同一时刻进行操作,然后拿秒表记录下反应时间? 这样的手工作坊式的测试方法不切实际,且无法捕捉程序内部变化情况,这样就需要压力测试工具的辅助。测试的基本策略是自动负载测试,通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景,对应用程序进行测试,同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能,确定问题所在以及优化系统性能。预先知道了系统的承受力,就为最终用户规划整个运行环境的配置提供了有力的依据。并发性能测试前的准备工作测试环境:配置......>>
问题六:软件性能测试的目的 为了验证系统是否达到用户提出的性能指标,同时发现系统中存在的性能瓶颈,起到优化系统的目的。
问题七:软件测试一般都用到哪些工具 测试工具分为很多种,主要如下:
测试管理工具:MQC,TestManager,QACenter,其中缺陷跟踪还可以使用:变更管理工具
功能测试自动化:QTP,RFP,QARun,Silk
性能测试工具:Loadrunner,Robot,QAload,WAS,Silk Performance
单元、白盒测试工具:Junit,Jmeter,devpartner,骸probe,Purify Plus
安全测试: Appscan,Fortify
问题八:手机软件的测试主要有哪些方面去测试,性能测试用什么去测试好? 罗列几个比较有代表性的方向:
功能测试
性能测试
稳定性测试
安全测试
兼容性测试
网络环境测试
位置定位测试等
如何做性能测试:
明确测试目标,了解性能测试需求
编写性能测试计划
分析性能测试需求
编写性能测试方案、设计测试场景
相关资源准备(人力资源、硬件资源、软件资源)
测试程序开发,脚本维护、测试数据准备、测试监控准备
执行性能测试并收集测试结果
分析结果
系统调优及再测试
现今的安卓开发环境,碎片化现象十分严重。安卓机型铺天盖地,很多中小型研发团队缺少测试环境,也没有资金和精力购全机型,这时就引入了一个云真机测试的概念。WeTest平台的云真机测试 wetest.qq/...zhidao 平台提供上千台真实的安卓主流机型,随时随地进行测试,提供截图、实时日志和各种性能数据。
如果以上回答能帮助到你那就最好不过了~
问题九:测试主板性能的软件有哪些 WinBench 99可以用来测试各个部件的性能的。你可以用3DMARK测试一下电脑各个部件的性能,一般上3DMARK所有项目都通过的话,就说明主板和其他部分没有什么冲突的问题了。
问题十:app的性能测试到底是测什么意思 app的性能测试要关注
包体大小、CPU 占用率、图片处理器每秒刷新的帧数、内存使用、电量、流量等等
作为一名开发者,我们最长听到的就是编程界的三高:
高性能、高并发、高可用。
听起来非常高大上,但是性能到底如何呢?又该如何评定呢?
这次我们谈一谈性能测试,看一看到底什么样才叫做高性能。
本文主要从以下几个方面进行讨论。
(1)性能测试是什么?
(2)为什么需要性能测试?
(3)性能测试如何做?
(4)有哪些性能测试的工具
老马曾经说过,你想理解一件事物,首先必须先定义它。
这里直接引用一下百科中的定义:
性能测试的定义也不难理解,往往定义本身阐述了性能测试的作用。
如果你是一名开发、测试,平时接手过不少需求,可能性能测试接触的也不多。
每一个需求,都有对应的功能性需求和肺功能性需求。
功能性需求是产品需求文档中最直接的,需要实现的功能目标。简称,能用就行。
非功能性需求则要宽泛的多,架构设计是否合理?是否便于后期拓展?是否便于监控?代码实现是否优雅?文档注释是否完整?
就像你写了一只鸟,鸟头做螺旋桨非能飞起来,但是在架构设计上可能是不合理的。
飞起来
一个查询功能,用户点击查询,10S 种才返回数据,功能上是满足的,但是性能上是不能接受的。
线上的交易功能平时各方面都很棒,节假日高峰期直接系统就瘫痪了。
那如何避免这些问题出现在生产上呢?
这就需要上线之前,首先做好对应的性能测试,避免再生产上出现问题,带来严重的生产事故。
性能要高,性能要硬,性能测试,又高又硬!
又高又硬
做一件事情之前,我们首先要确定好自己的目标。
性能测试,到底要测试什么?
有些类似于开发过程中的需求分析,常见的测试指标如下。
响应时间是指某个请求或操作从发出到接收到反馈所消耗的时间,包括应用服务器(客户端)处理时间、网络传输时间以及数据库服务器处理时间。
作为用户而言,在页面点击查询,等待了多久才能获取结果,这个就是响应时间。
用户不关心你后端经过了多少个服务,慢就是原罪。
对于微服务系统,链路监控就显得比较重要。可以帮助我们快速定位到底慢在哪里。
TPS(Transaction Per Second)是指单位时间(每秒)系统处理的事务量。
我看网上还有很多类似的概念:点击量/点击率、吞吐量/吞吐率、PV/UV,这里不做赘述。
个人看来本质上 TPS/QPS 就是去压测你应用的极限,当访问量较大的时候,程序能否活下来?
这里主要涉及到两个概念:高性能和高可用。
我们后面会简单讨论下这两点。
明确了测试指标之后,就需要进行测试的准备。
环境准备:比如你想压测数据库,那就需要准备对应配置的数据库资源。
脚本的准备:数据初始化脚本,调用脚本等。
这个可以类比开发过程中的代码开发。
ps: 性能压测一般不是很常用,所以环境准备流程会比较长,这一点需要注意。
当进行测试之后,测试的结果一定要给出一份报告出来。
是否通过压测要求?
最高的 QPS 是多少?
这样开发可以根据这份报告进行相应的优化。
提升性能的内容写一本书也不为过,这里简单罗列一些最常用的几点:
(1)慢 SQL
一般程序如果响应时间较长,可以首先看一下慢 SQL。
看下是否需要增加索引,或者进行 SQL 优化。
(2)缓存
针对查询,性能提升最显著的就是引入缓存。
当然,引入缓存会使架构变得复杂,这一点要结合自己的实际业务。
(3)硬件升级
如果程序优化的空间比较小,可以考虑升级一下硬件资源。
比如服务器配置翻倍,数据库配置翻倍。
什么?你说公司没钱升级?
没钱升级做什么压测?
这个时候测试报告的作用就显露了,直接用数据说话。
直接说 QPS 达不到生产要求,程序优化的空间很小,推荐硬件升级配置,升级到多少。
做人,要以德服人。
做测试,要用数据说话。
以德服人
测试最常用的工具当属 jmeter。
除此之外,还有一些其他的工具:
LoadRunner、QALoad、SilkPerformer和Rational Performance Tester。
下面对几个工具做下简单介绍
Apache JMeter 可以用于测试静态和动态资源(Web动态应用程序)的性能。
它可以用于模拟服务器、服务器组、网络或对象上的负载,以测试其强度或分析不同负载类型下的总体性能。
将负载测试集成到开发工具中:IDE、jUnit、nUnit、Jenkins、Selenium和Microsoft Visual Studio。
从12.55版本开始,您可以运行您的JMeter脚本,并在任何性能测试中集成JMeter和附加的脚本类型。
ps: 这个设计理念就非常好,可以和成熟的工具进行整合。站在巨人的肩膀上。
QALoad是客户/服务器系统、企业资源配置(ERP)和电子商务应用的自动化负载测试工具。
QALoad可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试,并针对所发现问题对系统性能进行优化,确保应用的成功部署。
ps: 这个工具本人没有接触过。
SilkPerformerV可以让你在使用前,就能够预测企业电子商务环境的行为—不受电子商务应用规模和复杂性影响。
可视化的用户化、负载条件下可视化的内容校验、实时的性能监视和强大的管理报告可以帮助您迅速将问题隔离,这样,通过最小化测试周期、优化性能以及确保可伸缩性,加快了投入市场的时间,并保证了系统的可靠性。
作为 DevOps 方法的一部分,IBM Rational Performance Tester 帮助软件测试团队更早、更频繁地进行测试。
它验证 Web 和服务器应用程序的可扩展性,确定系统性能瓶颈的存在和原因,并减少负载测试。
您的软件测试团队可以快速执行性能测试,分析负载对应用程序的影响。
ps: 这一款工具有 IBM 提供,质量值得信赖。
这么多工具可供使用,相信读到这里的小伙伴已经找到了自己心仪的测试工具。
别急,下面专门为做 java 开发的小伙伴们推荐一款性能测试工具。
男人有男人的浪漫,开发者当然也要有开发者的浪漫。
【男人的浪.jpg】
作为一名开发者,老马平时单元测试使用 junit 最多。
所以一直希望找到一款基于 junit 的性能压测工具,后来也确实找到了。
@JunitPerfConfig 指定测试时的属性配置。(必填项)
使用如下:
@JunitPerfRequire 指定测试时需要达到的要求。(选填项)
使用如下:
对应的测试报告生成方式也是多样的,也允许用户自定义。
基于控台日志:
或者基于 HTML:
junitperf
本文对性能测试做了最基本的介绍,让小伙伴们对性能压测有一个最基本的理解。
测试和开发一样,都是一件费时费力,而且需要认真做才能做好的事情,其中的学问不是一篇就能说清的。
性能测试工具也比较多,本文重点介绍了专门为 java 开发者打造的 junitperf 工具。
下一节我们将从源码角度,讲解一下 junitperf 的实现原理。
我是老马,期待与你的下次重逢。
开源地址:https://github.com/houbb/junitperf
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)