经验交流:性能测试经验总结[1] 性能测试工具
第一步:计划测试
1、明确压力点,根据压力点设计多少种场景组合
2、把文档(包括多少种场景组合、场景与场景组合条件的对应表)写好
3、如果监测UNIX机器,在被监测的机器需要安装监测Unix的进程
4、让开发人员帮助我们准备测试数据或他们写相关的文档我们来准备数据
5、让开发人员做一个恢复数据的脚本,以便于我们每次测试的时候都能够有一个相同的环境 软件测试
6、针对每一个模块包括四个子文件夹:如模块A下包括“脚本”“场景”“结果”“图表” 四个子文件夹,每个子文件夹储存对应的文件,如下表所示:
MILY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">模块名 |
场景名 |
结果名 |
图表名 |
用户层障碍 |
1场景 |
1场景0 |
1场景0 |
1场景1 |
1场景1 | ||
1场景2 |
1场景2 | ||
2场景 |
2场景0 |
2场景0 | |
2场景1 |
2场景1 | ||
2场景2 |
2场景2 |
其中:结果名“1场景”是在场景中的“Results Setting”中设置的,具体的设置见“建立场景”部分,这里也可以有另外一种方法:在打开模板设置,如下图1:
选中“Automatically save the session as:”并且在“%ResultDir%”后面填写你想保存的文件名,当你打开某个lrr文件时,系统自动在当前目录中生成一个文件保存分析图表,如下图2所示:
第二步:生成测试脚本
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”,使某一个参数取设定的范围内的随机值