性能测试报告范例.docxVIP

测试目的： 考虑到各地区的用户数量和单据量的增加会给服务器造成的压力不可估计，为确保TMS系统顺利在各地区推广上线，决定对TMS系统进行性能测试，重点为监控服务器在并发操作是的资源使用情况和请求响应时间。 测试内容 场景并发用户数运行场景设置测试点300托运单点击生成派车单1单次循环服务器稳定性及响应时间900托运单点击生成派车单5单次循环服务器稳定性及响应时间共1000箱，20000个商品的单据上传匹配1单次循环服务器稳定性及响应时间共2500箱，40000个商品的单据上传匹配5单次循环服务器稳定性及响应时间RF自由派车单据下载（单线路）1单次服务器稳定性及响应时间RF自由派车单据下载（多线路）5单次服务器稳定性及响应时间 测试工具 主要测试工具为：LoadRunner11 辅助软件：截图工具、Word  测试结果及分析 5个用户同时生成派车单的测试结果如下： Transaction Summary（事务摘要） 从上面的结果我们可以看到该脚本运行47秒，当5个用户同时点击生成派车单时，系统的响应时间为41.45秒，因为没有设置持续运行时间，所以这里我们取的响应时间为90percent –time，且运行的事物已经全部通过 事务概论图，该图表示本次场景共5个事务（每个用户点击一次生成派车单为1个事务），且5个事务均已pass，绿色表色pass，如出现红色则表示产生error  系统资源 从上图可以看到服务器的CPU平均值为14.419% ，离最大参考值90%相差甚远；且趋势基本成一直线状，表示服务器响应较为稳定，5个用户操作5个900托运单的单据对服务器并没有产生过大的压力。  每秒点击数 　“Hits per Second（每秒点击数）”反映了客户端每秒钟向服务器端提交的请求数量，这里服务器每秒响应9,771次请求；如果客户端发出的请求数量越多，与之相对的“Average Throughput (吞吐量)”也应该越大。图中可以看出，两种图形的曲线都正常并且几乎重合，说明服务器能及时的接受客户端的请求，并能够返回结果。 按照上述策略，我们得出的最终测试结果为： 生成派车单: 1个用户，300个托运单点击生成派车单，响应时间7.34秒 5个用户，900个托运单点击生成派车单，响应时间41.45秒 单据匹配： 单用户1000箱，20000个商品，上传匹配时间8秒 五个用户2500箱，40000个商品，同时上传匹配耗时2分25秒 自由派车： 单条线路917个托运单下载，响应时间1分40秒 上述结果是在公司内网，测试环境上进行的测试，可能与实际会有偏差  同时本次压测过程发现了3个bug BUG#25680 【测试环境-1.0.5】五个用户，每个用户同时上传500个单据时，系统报异常（提示用户请求取消当前操作） --待修复 BUG#25519 【1.0.5】RF装车界面，当待装车明细过大（超过20000箱）时，点击明细按钮会导致RF崩溃，且明细数量也不正确！--已发版待验证 BUG#25545 【测试环境-1.0.4】PC创建派车计划，多个用户同时选择同条线路，可以选到同样的托运单并审核成功。 --待修复 结论 本次性能测试得出的结果具有一定参考价值，用户数量和数据量也比较切进现场实际情况，所得的各项响应时间在用户可接受的范围，因此本次性能测试通过。