性能测试从0开始笔记

脚本编辑和编译
1 确定生成脚本策略
∵系统采用的是Socket Client和Soctet Server建立链接∴可将此部分Java Socket登陆程序编入脚本，生成登陆和交易脚本，用lr执行。
这样的好处是绕过终端IE页面复杂的处理，直接施压到前置机；不好是，会和现实环境有些偏差，在执行场景时可使用一些其他方法得到弥补。ps：但看完了也不知道怎么弥补。

2 完善脚本
脚本除建立链接，业务发送等外，还要建立用户信息数据池、设置监测点和异常退出点。
  1 设置Transation。通过事物获得登陆时间、查询时间和交易时间
    lr中定义事物(Transation)主要为了度量服务器的性能，每个事物度量服务器响应指定的Vuser请求所用的时间。在脚本事务的操作需要插入Vuser函数已标记事物的开始和结束。在脚本使用事物的方法有两种1使用lr_start_transaction和lr_end_transaction直接插入2使用Run-settings中的Miscellaneous选下卡的Automatic Transactions定制自动事物，设置Vuser中的每个Action(init、Action和end三大函数)和step(lr执行的每个函数)...这些都主要是第5章内容
  2 参数化数据
     参数化username、password和各种报文消息内容等数据，使用Data Wizard从数据库直接导入(参数化主要为了多数据多循环时使用脚本，维护时可以直接修改数据文件来构造不同的测试环境进行测试)...第五章主要有讲
  3 设置检查点，对服务器的回应进行分析，找出不同的状态。
     检查点主要验证程序运行结果是否与预期结果相符。对于web Vuser类型，有两种设置检查点的方法1Run-time setting中ContentCheck中设置，可定义检测服务器返回的页面是否包含预定义的字符，进而判断页面是否错误2在请求页面的函数完成后，使用检查函数web_find和web_image_check来搜索结果页面中是否包含既定的图片、关键字。类似函数还有一个web_reg_find...也是第五章主要讲


定义用户行为
用户使用该系统的行为包括 登陆--交易--查询--退出，用户在次过程中应抛出异常，进行合适的处理。

场景的设置和运行
1 并发登陆测试场景
场景分析：
因为已经知道登陆的需求是750用户/分钟，登陆响应在30秒之内
得出需要两种测试方法1递增测试方法：每分钟750用户，即需13用户/s，并保Socket连接，知道1分钟结束。系统响应或者平均时间大于30秒，都不算通过。2瞬时测试，为了更深的了解系统能力，我们对系统的瞬时并发能力也要进行测试，测试系统所能承受的最大瞬时并发用户登陆连接请求个数。
场景设置：
    1 采用手工场景方案，设置用户数750
    2 递增登陆测试，在Controller的Edit Schedule中，选择"Start 13 user every 1 senconds"
    3 瞬时并发测试，在VU脚本中加入同步点(不知是否为集合点)，在Controller中设置开启同步点，并选择策略“100%运行用户到达同步点后再释放”
2 交易流程和查询流程测试
场景分析:
已400笔/秒为目标，响应时间不超过10s(已设置了事务)
场景设置:

Goal type选择"Transaction per second”，Goal是400Transaction/s
Transaction选择trade(自定义事物名称，表示交易)
设置最小用户数为50，最大用户数为1000   //51testing系列的图书这样的点从来没有具体原因为什么这么设置
如果目标没有达到，即场景退出
3 综合测试
即交易和查询一起测试
场景设置:
建立2个Vuser组，分别执行查询脚本和交易脚本
在Controller的运行是设置中设置"浏览器仿真"，选中"下载非HTML资源"和"每次迭代模拟一个新用户"

计数器的设置和性能数据的收集
在lr的Controller中开启UNIX系统资源计数器、WebLogic计数器、DB2计数器、检测系统资源消耗情况，并和测试结果数据合并。

ps.这一章还有运行场景、分析瓶颈两个小节，就不在写上来了，没什么参考的意义，不过在运行场景时交易的负载能力测试未通过(400笔/s)，原因是系统响应时间延长，界面显示和刷新明显变慢，到了业务量高峰时期，界面已经不能显示任何信息，处于不能工作状态，并定位为终端界面程序问题...