压力测试报告模板

1、.：.；采购订单录入50个用户呼应时间：1最大时间平均时间最小时间90%登录21.37121.37121.37121.371进入订单录入页面0.2120.2120.2120.212保管订单0.4120.4120.4120.41250最大时间平均时间最小时间90%登录30.0527.8521.75929.707进入订单录入页面6.9663.9431.4646.107保管订单5.5442.8330.7994.536网络下载时间细分： 这个页面效力器处置时间过长，阐明在效力器端在处置这个页面的信息时，需求过长的时间。这两个页面客户端接纳时间比较长，阐明这两个页面接纳的数据比较多，可以适当的做一些优化

2、。页面组件分析：这三个页面中的组件平均下载时间比较的长，特别是第一个页面，所以导致登录的时间很长。下载组件大小：这三个页面所含网络分析：绿色：吞吐量紫色：每秒点击率根据每秒点击率与吞吐量的分析，网络不是性能的瓶颈。采购审核50个用户50最大时间平均时间最小时间90%采购审核9.6564.591.9242.092订单生成收货单50个用户50最大时间平均时间最小时间90%生成收货单4.6663.5962.1094.293保管收获单列表3.8022.9540.9993.747提交收货单3.232.4171.562.833查询收货单65条3.6922.5752.2962.781发票生成单50个用户50

3、最大时间平均时间最小时间90%保管发票匹配7.8653.1420.276.756提交发票匹配6.9013.1440.2396.257生成发票匹配7.6963.4620.7466.124网页分析：这两个页面下载的时间最长。下载的组件大小：页面下载时间分析：经过对下载的组件大小与页面下载时间分析可以知道，组件大小是影响这两个页面性能的主要缘由。4个脚本同时运转200用户1、呼应时间最大运转vuer数：57最小时间平均时间 最大时间 规范偏向90%从上图可以看出：登录、保管采购恳求录入单、采购审批这三个模块能够存在性能问题。2、吞吐量与点击率合并图：从这个图可以看出网络不存在性能瓶颈。3、网页分析从

4、上图可以看出：登录、保管采购恳求录入单、采购审批这三个事务下载时间最长。4、页面组件细分这两个组件随着时间的推移，用户量的添加，下载时间急剧上升网页下载细分从这个表中可以看出，随着时间的推移，客户端接纳的时间急剧上升。这两个组件性能瓶颈均在效力器的处置时间上面这个页面的性能瓶颈在客户端接纳数据上面，阐明客户端数据比较的大，导致接受时间比较的长。这个页面的客户端接受时间在HTTP呼应数到达最大值时，开场急剧增大。下载组件大小这几个页面下载的组件是最大的。经过这次的测试，该软件的性能除了登录、保管采购恳求录入单、采购审批这三个事务之外，其他的性能还在可以接受范围之内。这三个模块需求做到优化。大数据

5、量下的测试：生成收货单：1、呼应时间： 最小值平均值最大值规范差 90%2、第一次缓冲时间分析：从上图可以看出，效力器处置时间很大，并且属于上升的趋势，阐明效力器在处置这个事务时，破费了大量的时间，需求看一下程序处置和数据库取数据能否存在算法上的问题。3、下载组件大小这几个页面下载的组件最大。4、页面下载时间细分结合第一次缓冲时间进展分析，可以看出这两个页面是效力器处置的时间过长。在压力测试中，提交收货单不能全部胜利，经过了31个事务，失败了15个事务，阐明这一块的性能存在比较大的问题。生成收货单，经过46个事务，失败4个事务。生成发票匹配单呼应时间：保管发票匹配经过41事务，失败6事务提交发票匹配经过37事务，失败4事务生成发票匹配经过47事务，失败3事务。其中有3个HTTP 500呼应。页面分析这四个页面耗时最长页面下载时间细分从上图可以看