性能测试经验总结

时间:2024.3.10

第一步:计划测试

1、明确压力点,根据压力点设计多少种场景组合

2、把文档(包括多少种场景组合、场景与场景组合条件的对应表)写好

3、如果监测UNIX机器,在被监测的机器需要安装监测Unix的进程

4、让开发人员帮助我们准备测试数据或他们写相关的文档我们来准备数据

5、让开发人员做一个恢复数据的脚本,以便我们每次测试的时候都能有一个相同的环境

6、针对每一个模块包括四个子文件夹:如模块A下包括“脚本”“场景”“结果”“图表” 四个子文件夹,每个子文件夹储存对应的文件,如下表所示

其中:结果名“1场景”是在场景中的“Results Setting”中设置的,具体的设置见“建立场景”部分,这里也可以有另外一种方法:在打开模板设置,如下:

选中“Automatically save the session as:”并且在“%ResultDir%”后面填写你想保存的文件名,当你打开某个lrr文件时,系统自动在当前目录中生成一个文件保存分析图表,如下图所示:

第二步:生成测试脚本

1、把登陆部分放到“vuser_init”部分,把需要测试的内容部分放到“Action”部

分执行;但是如果是模拟多个用户登陆系统,则要把登陆部分放到Action部分来实现

2、录制脚本后,想查询某个函数的原型,按“F1”键

3、确认脚本中哪些参数是需要进行参数化的(最好能可以和开发人员一起确认)

4、在脚本参数化时把函数web_submit_data()中的ITEMDATA后面的数据参数

化,因为这些数据是传递给服务器的,当然也可以把一个函数中的所有相同变量都替换掉

5、脚本中无用的部分用“/*”“*/”“//”注释掉,但最好不要删除

6、调试脚本遵循以下原则:

确认在VU里SUSI(单用户单循环次数single user & single iteration)

确认在VU里SUMI(单用户多循环次数single user & multi iteration)

确认在controller中MUSI(多用户单循环次数multi user & single iteration) 确认在controller中MUMI(多用户多循环次数 multi user & multi iteration)

7、事务的名称取的有意义便于事务之间的区分,把所有的事务名都记录在一起,

便于在测试结果概要中区分它们,这要写成一个表:某次测试有哪些模块,每个模块中有哪些事务(见对应的“关系表”)

8、在“Parameter List”中可以选择参数类型“Random Number”,

使某一个参数取设定的范围内的随机值

第三步:建立场景

1、 把场景名称编号,并制定出一份场景名称和场景条件组合的对应表。比如,场景m对应

于“某一模块_xx个vu _分z台machine”(见“关系表”中的例子)

2、 根据上面的对应表把场景设置好,需要设置的要素如下:总体多少个用户、分多少个组、

每个组有多少个用户、分几台机器运行、每个脚本迭代多少次、是否回放think time时间、检查Parameter List中每个参数设置是否正确、参数从表中取值间隔是否正确、是否选中“Initialize all Vusers before Run”

3、 测试结果应该保存为“m场景0,m场景1,…”

4、 把虚拟用户分散到几台机器上和在一台机器上面都要进行测试,因为有可以效果不同

5、 场景中如果有需要改动的地方,必须新建一个场景(建议使用“另存为”,然后再修改结

果文件名,再选择相应的脚本),并把场景按顺序编号,先维护好场景与场景组合条件的对应表,以便以后的查找,并且在结果“Results Setting”中设置的结果名与场景名相同。建议在“Results Setting”中选中“Automatically create a results directory for each scenario execution”让它每次自动累加,不建议选中“Automatically overwrite existing results directory without prompting for confirmation”,因为我们不要覆盖掉以前的测试结果,把它保存下来以便有个根据。

6、 需要注意的地方:当在“Parameter List”中的“Select next row”选中“Unique”时,如

果再在“Edit Schedule\Schedule by Scenario\Duration”中选中第二项“Run for XX after the ramp up has been completed”时系统就会报错,提示“Unique”类型不相符。

7、 在“Run-time Setting”设置中,“General”中的“Pacing”非常有用,可以设置每次迭代

之间相隔多少时间,也可以是随机的取值

8、 建议:把“Parameter List”和“Run-time Setting”中的所有设置都搞熟悉,这样便于以

后对脚本和场景进行设置

9、 设计“Parameter List”时的小技巧:即在“Allocate X values for each Vuser”时,尽量

把它的间隔在数据容许的范围内取大些,这样可以做从一次迭代到最大值迭代,而且对脚本没有什么影响

10、当一个脚本中有多个事务,在事务前面增加集合点时需要一点技巧。或者我们把脚本复

制几个,或者我这样做:测试前面的事务的压力时,把后面的事务前的集合点设置为不激活状态;在测试后面的事务的压力时,把前面的事务的集合点设置为不激活状态,另外最好不选中Initialize all Vusers before Run,具体参见Controller中的“Scenario/Rendezvous”,及用户手册(按F1)

11、把持续时间从最后60秒改为整个场景的时间,右键单击某个图,选择“Configue”,修 改Graph Time即可

12、每次从一个场景修改后保存为另一个场景时别忘记把结果保存文件名修改相对应的文件名。在设置结果保存文件名时有一个技巧:如果你打开这个窗口时,点击确定则系统会

默认以“4场景2”为基点向后加“4场景20”“4场景21”等等,但是如果你把结果文件名后面的数据去掉,改为“4场景”,点击确定后,系统会自动搜索是以“4场景”开头的文件名,并在它的后面继续增加,比如把它改为“4场景”时,下次结果保存在“4场景3”中。而且他在搜索的时候搜索以“4场景”开头的文件名,从0开始,有的话就不取代而跳过,没有的话就取代。

第四步:运行场景

1、 运行场景前需要注意的事项:每个组的虚拟用户数、迭代次数、think time、参数化时的

取值间隔、执行恢复数据的脚本、确认虚拟机的LoadRunner Agent Service打开

2、 如果监测Unix,运行场景前需要启动监测Unix进程,启动的命令“rpc.rstatd”、查看这

个进程是否启动的命令“rpcinfo –p”

3、 运行前使Generator机器处理Ready状态

4、 确认被监测的机器已经连接上去,并且添加自己所需要的计数器

5、 运行之前一定要确认系统中压力点的数据量是多少

6、 确认以上都正确时再运行测试场景

第五步:监视场景

1

、打开

Transactions”,可以随时观察到事务的运行状态 “Passed Transactions”或“Failed

第六步:分析测试结果

1、 打开Analysis后,把经过数据处理的结果图表保存到“图表”文件夹,并且文件名和场

景名、结果名相同,这样便于以后的查阅。也可以省去每次进行数据处理的时间。

2、 可以通过点击界面上的“View Run Time Setting”可以看到此场景运行时的一些场景

设置

3、 在关联图表时可以自动调节每个元素的比例,点击右键,选

即可

4、 每次测试结束后确认所做的操作是正确的,确认正确后再分析结果

5、 在结果文件夹中为每个场景建立一个文档,把每次运行时的情况记录下来以便于写测试

报告,尤其运行错误的原因记录下来,并把开发人员所做的修改也记录下来以便知道开发人员做了些什么修改

6、 在分析运行结果时可以把几个结果合在一起进行比较,打开如下“Cross with Result…”

即可,然后增加一个运行结果,这样就可以把你所需要的结果放到一起比较了


第二篇:测试经验总结


1.测试人员和用户的联系与区别

黑盒测试人员和用户,都是站在实际应用层进行操作,因此他们对应用层的可用性、实用性非常关注。用户不懂的是软件的使用,而相对用户来说,测试人员对软件比较了解,但不熟悉业务本身。

八个字归纳:用户是用,测试是测。

用户不懂使用就需要技术支持人员去培训,而测试人员在测试初期经过开发人员和项目负责人的简单培训后,就应该通过所学的理论知识和相关的业务知识独立去了解、深入到软件的功能点中。

应该做到:由测试人员培训技术支持人员,由技术支持人员实施时给用户培训。

2.带着问题去测试

阿猪工作守则第一条:带着问题去测试

测试中会遇到很多问题,没关系,没有脑子里面的一个个问号,是不能很好的发现问题的。往往发现一些藏的很深的bug都是在测试人员一步步解决这些问号的过程中,切忌遇到问题就问,不仅因为增加不必要的与开发人员、负责人等的交流时间可能延误项目进度,而且自己对问题的印象也不会很深刻,毕竟在相对较短的测试时间内,听不如记,记不如自己去发现规律。

3.测试期间提问题和交流的时机

什么时候应该提问题?

我们都知道,作为测试人员,并不是测试期间什么时候遇到问题就要马上问,那什么时候是提问的时间?

培训

培训时,一般在讲解内容的间歇允许打断,由培训人员解答测试人员的疑惑。培训的过程其实就是一个传输新知识并答疑的时间,这个期间的提问是欢迎的,也可以增加参与性和调动积极性。所以希望大部分的问题能在这个阶段提出来。受时间、环境等条件制约,有时培训的人讲的也不一定细致和全面,这时就需要自己多想,想想这个功能是干什么的,为什么这么做,对应的业务是什么。

阿猪工作守则第二条:培训时脑子灵活转动,多想多问

以前大家可能有过参加辩论会的经历,就算没有其实和人聊天也是一个交互的过程。参加辩论会要求快速思考,然后放慢语速说出自己的观点,因为不能说错。我们在参加培训时前者相同,后者相反。脑子嘴巴都要快,说错了也没有关系,自己的想法被纠正的过程中也是加深印象和理解的过程。

计划评审

提出对于软件不理解、安排的任务不明白的地方。

测试期间

这个时期最主要的问题应该集中在影响测试流程和进度的问题,而不是说明书或其它文档上已有的内容,或者与自己负责模块无关的内容。开发人员和其他测试人员都有自己的进度安排,因此,

影响测试流程和进度的问题,马上问!

不影响流程的问题,记下来统一问!

不必要的问题(说明书或其它文档上已有的内容、讲过三遍以上的问题、今晚去哪里吃饭的问题),不问!

好处:避免不必要的时间支出,不打乱自己的测试思路,一气呵成,并且使项目成本得到控制

坏处(?):脑子里、笔记本上留下一堆待解决的问号吧,浪费脑细胞和公司的笔和纸

张等资源

阿猪工作守则第三条:先做事,后学习

在有限的时间内先完成该做的事,有空闲的时间再去补充自己的知识。

要很好的把握上述内容,也要求提高培训期间培训人员培训内容的完善性,要求前期培训人员强调出软件的重点、难点和注意事项。这个期间适合于上面提到的“带着问题去测试”的方法。

但有一点需要注意:不要为了一个地方的卡壳在那耗上一天半天的,这就不值得了。 测试中期评审测试问题

答疑解惑的时间。

测试报告评审

对一些结论有疑惑和不解的地方,提!

4.记笔记

一个老生常谈的话题。

阿猪工作守则第四条:好记性不如烂笔头

测试培训的时候对于一些重点应该记下来,即使当时听懂了;没听明白的更应该记下来,到测试软件的时候去验证自己的疑问。如果培训时特别强调的地方,测试时再去问,这就不好了。

养成一个良好的习惯,会使以后的工作更加顺利。

5.在公司和学校的学习的区别

学校是专门学习的地方,公司就是工作的地方,因此,它们的性质决定了其学习内容和方法的不同。

学校 公司 备注

内容上 主要是系统的理论知识 主要是和项目相关的业务知识 如果在测试中感到自己部分理论知识欠缺时,就应该回家多补充了

时间上 大块时间的连续学习 相对邻散 在公司一般不会拿出大块时间来学习和讲解 形式上 老师授课+自学 培训+交流+测试过程中自学

个人觉得,一个高效的测试流程应该如下:

a.花几个小时至多半天时间快速阅读浏览软件说明书、设计文档;

这个阶段要让脑子里面形成对软件的整体印象感,能够让自己把握全局,因此,测试负责人安排时间看文档时,决不能忽视它的重要性,否则就会出现后续阶段磕磕碰碰的情况。注重速读,把握软件说明,忽略具体的数据库设计、功能点设计、计算、规则和辅助工具(相关软件)说明文档,囫囵吞枣的方法在这里就显得很有效。

如果项目时间紧或没有文档,这个步骤所做的事可以在下面完成。

b.利用培训时间消化吸收的知识

c.软件上手

几个小时至多半天时间,熟悉软件框架和基本功能,不要求所有功能都会操作,自己负责的模块可以多侧重一些。

d.细测

主要症对计划中安排给自己做的模块,这时就要相对放慢节奏,每一步操作、每个对话框(操作界面)都要深究,别放过任何情况。这时会遇到一些错误或不理解的地方,明显的如报错就提到开发过程论坛,不明显的就先记下来,等这个功能点测完再回头去看,你会发现:

50%的问题可以自己分析出来和解决,有的问题不是问题,只是开始还没有完全理解。 阿猪工作守则第五条:软件不是一次能测透的

Rome is not built in one day.

工期、人力、环境资料等,都制约着测试的深度和广度,因为不要期望一次能完全把握某个软件。

综合测试的优势在于,我们负责公司产品的把关,而项目由产品延伸而来;测试产品会不断出新的版本,一次没有理解,可以在下一次中弥补,温故而知新。

一口吃不成一个胖子,看我这么瘦又这么能吃就知道了^^

要结合自己的实际情况决定本次测试的深度,不要看着别人进度快了就打乱自己的节奏,只要安排合理,应该按照计划来。特别忌讳认为自己这块没问题了就马上去看看别人负责的功能,期望全能。这样一般来说除了ljl这种全能性人物外都会造成最后自己的问题留了一堆,别人的也没搞懂。

新人特别注意,踏踏实实的搞懂每个自己负责的模块,打阵地站,这种方法很有效。 评价自己是否可以转入下个模块的几个因素:自我提问与别人提问、测试进度

如果大多数相关人员(主要是测试负责人、其他部分相关测试人员特别是开发组集成测试人员和技术支持人员)对于自己负责模块的问题都能解答,搞定!NEXT-->转入下个模块。

否则,还是再回头想想思路和遗漏的地方。当然,要综合考虑测试进度。请组长对自己提几个软件的问题,他会很乐意的。

e.小结

一个阶段就进行一次小结,这个小结可以是书面的,比如测试问题记录、测试用例补充、测试模块设计等,但大多是自己分析,为了方便接下来模块的测试.

f.性能测试

性能测试不仅是测试性能,同时也加深自己对软件应用的理解,因为性能测试往往和实际应用或用户需求结合的很紧密,避免造成软件功能都会用,但不知用来干麻的尴尬情况。 g.安装盘测试

安装盘程序测试,简单过一下软件功能有无错误。

安装盘程序文件、库文件、组件等的完整性、正确性,这个非常重要,要不返工就浪费时间了。这个阶段要积极与开发负责人和GJ沟通,确保最后的胜利。

h.测试总结

测试接近尾声,总结自己对软件的掌握情况,得出测试结论、归纳测试方法、提出修改建议,为软件以后版本的修改提供依据,也为以后再测类似软件提供捷径。

5.小结

? 用户用软件,测试测软件

培训时多想多问?

好记性不如烂笔头?

带着问题去测试,在测试中解决问题?

? 先做事,后学习,争取双赢

软件不是一次能测透的?

更多相关推荐:
软件测试经验总结

软件生命周期(SDLC)的六个阶段1、问题的定义及规划此阶段是软件开发方与需求方共同讨论,主要确定软件的开发目标及其可行性。2、需求分析在确定软件开发可行的情况下,对软件需要实现的各个功能进行详细分析。需求分析…

手机软件测试经验总结

手机软件测试总结沙晶晶一个合格的手机软件测试工程师要掌握的东西是很多很多的。在我个人理解中,一个合格的高级手机软件测试工程师应该具有最基本的两点知识:软件测试理论知识和一定的开发技能。1.软件测试理论知识这个不…

软件异常测试经验总结

软件异常测试从业务需求方面:特殊业务流程测试:测试软件不按照正规的流程,而是按照可能的但非正规的业务流程运行,是否会生成错误数据,或者造成原有数据的错误,甚至造成系统的瘫痪;主要是检查系统某些关键业务在极限情况…

手机测试经验总结--SMS

手机测试经验总结--SMS手机测试经验总结--SMS短消息uGSM中唯一不要求建立端-端业务路径的业务就是短消息(亦称为短信),即使移动台已处于通话状态下仍可进行消息传输。?SMS:ShortMessageSe…

测试经验总结1

一、测试用例是软件测试的核心软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入,在最短的时间内完成测试,发现软件系统的缺陷,保证软件的优良品质,则是软件公司探索和追求的目标。每个软件产品或软件开发项目都…

Oracle的性能测试经验总结

前段时间,在阿里妈妈新机房压力测试过程中用到了LR测试ORACLE,跟DBA一起在杭州网通新机房进行1000用户的压力模拟测试。整个压力测试耗时两天。以下是一些经验:1)压力测试过程中发现一些SQL脚本执行非常…

使用Loadrunner性能测试经验总结

教程贴士:明确压力点,根据压力点设计多少种场景组合第一步:计划测试1、明确压力点,根据压力点设计多少种场景组合2、把文档(包括多少种场景组合、场景与场景组合条件的对应表)写好3、如果监测UNIX机器,在被监测的…

测试部年终总结

测试部年终工作总结光阴似箭,岁月如梭,一转眼,我来到英特华已经九个月了,在这段时间里,我们公司从没有测试人员,到测试部的建立;从没有测试环境到测试服务器的建立,测试工具QC、性能测试软件LoadRnner的安装…

测试工程师工作总结

总体来说,XX年我主要完成了以下几方面的工作:l项目测试工作l知识与经验分享l完成所需知识的积累l工具学习及研究具体来说,如下:1.项目测试工作这段时间,我主要是协助c.y.x进行cmbp项目测试,主要工作内容…

测试员工作总结

20xx年个人工作总结光阴似箭,岁月如梭,一转眼,我来到华源已经有近两个月了,在这段时间里,使我从一个测试新手逐步向一个掌握一定测试技巧、对测试有着浓厚兴趣测试人员转变。在这近两个月工作中,我们苦过、累过、紧张…

软件测试半年工作汇报总结

年工作总结工作刚满三个月,在这三个月的时间内,我主要做了以下几个方面的工作:1.对软件的熟悉与理解2.跟随开发人员对软件的改进进行了跟踪测试,利用功能组合的方法,对各种工具进行了测试,提交Bug共计405个,已…

测试实验总结报告

软件测试学习总结姓名:王化强学号:20xx011260从对软件测试没有什么经验的我初步掌握了软件测试的方法和技能,收获颇多。经过这次理论学习,了解到要做好软件测试,要求掌握的知识并不仅仅是测方面的,网络、数据库…

测试经验总结(56篇)