关于【测试计划】
1. 并发数:集合点的设定与否,根据系统实际情况,一般使用并发时有以下几种情况:
1) 重点业务功能的使用
例10个用户并发提交工单,查看提交请求是否被服务器正确响应
2) 可能存在系统瓶颈的事物前
例如使用httpwatch工具查看各个事物请求时间,发现某个请求时间特别长,可以使用loadrunner工具在该事物前设置集合点,查找是否存在瓶颈。
3) 用户有明确要求
多数情况一般不使用集合点,测试场景需要根据被测系统的实际使用情况具体分析,例如分析我们的PASM产品的登录功能,测试系统极限值,可以选择注册用户的80%在上班前XX分钟内完成登录操作,注册用户的20%在XX分钟内完成登录操作(二八在很多地方都适用);根据与客户货研发沟通得出的测试场景,详细写入报告,客户根据符合实际的场景描述,更容易接受测试数据。
2. 如果使用集合点,集合点策略分三种情况,当所有虚拟用户中的X%到达集合点时释放;当所有正在运行的虚拟用户中X%到达集合点时释放;当X个虚拟用户到达集合点时释放;超时时间是每个虚拟用户达到集合点后,等待一下虚拟用户的最长时间,超过这个设定时间则释放所有虚拟用户;具体选择根据实际业务情况设置,以达到强制并发的效果。
3. 创建控制台场景有两种,面向目标的场景和手动场景,如何选择:如果测要求是达到某个性能指标,如每秒多少点击,每秒多少事物通过,多少人同时在线,某事物在某个范围Vuser(500-1000)内的响应时间等等,可以使用面向目标场景。面向目标的场景很多情况下满足不了实际测试需求,这就需要手动建立场景,可以完全按照需要来配置场景,在实际中应用较多,能够更精确地满足测试的需要。
4. think-time和pacing值的使用:一般我们做性能测试,找系统的最佳使用状态,不考虑思考时间和步骤间隔,当用户要求还原系统真实使用情况时,使用这两个值能更接近模拟系统的真实使用,这些值的设置可以研究用户行为取得。
5. 缓存的使用:与客户沟通,根据客户具体要求在录制loadrunner脚本时在Run-time Settings->>Browser->>Browser Emulation中进行相应设置,最后要体现在报告里。
6. 网络带宽:如果再内网进行测试,带宽要求为100mb以上,在测试计划中会有数据提现。
关于【测试报告分析】
需要长时间的积累分析。
必备分析图:“虚拟用户数”与“事物平均响应时间”的叠加。
假如平均响应时间在某一时刻突然上升,很有可能就是最大用户瓶颈。