性能测试报告编写
性能测试报告的编写其实和上面的分析思路一样,只是把关键的图表融入文档并进行语言的组织描述即可,此处不再重复阐述,只给出报告的框架以及关键描述,重点描述结论以及解决方案。
(1)测试目的本报告是为了反映WebTours系统的关键业务的性能表现,检查在多用户并发访问的情况下,系统的表现情况。本次测试从事务响应时间、并发用户数、系统资源使用等多个方面,以专业的性能测试,技术,分析出当前系统的性能并给出解决方案。
(2)测试范围对WebTours的关键业务组合进行性能测试,包括登录、查机票、订机票、退出等业务。
(3)测试环境本章的分析是以WebTours自带报告进行的,所以并不清楚当时的测试环境是什么。一般测试环境的描述需要包括服务器环境、客户端环境以及网络环境。详细列出各自环境中的配置等即可。
(4)业务场景建模本次测试的业务场景为:用户登录→查找机票→预订机票→查看已经预定的机票-退出。本次测试场景的设置策略为:慢增长方式,逐步加压,达到70个Vusers后保持运行,最终整个场景耗时11分钟57秒后结束。
(5)测试结果分析这里就是把分析的关键数据图表以及描述进行整合,不需要的数据图表可不体现在报告中,只分析关键数据图表即可。但需要注意的是,只描述现象是不可行的,也需要写出初步的推理猜想,这样后续才能一步步验证,从而最终确定结论。具体分析请参考4.2节中的内容。
(6)测试结论与解决方案通过上述的分析,本系统可能存在如下问题,并针对每类问题给出了解决方案。
1)服务器硬件方面:随着并发用户的增加,系统CPU使用率逐渐增加,并且出现明显的排队现象,说明硬件存在瓶颈。
解决方案:可增加或替换更好的CPU和磁盘,同时修改Windows系统对于TCP连接数的限制。
2) Web服务方面:每秒连接数一直处于比较低的状态,可能是连接数受到限制,可适当提升连接数。
解决方案:对Xitami服务中的参数进行优化,可以适当调整Max HTTP connections和Allow Keep-Alive connections的值。
3)网络方面:随着并发用户数的增加,向服务器请求增加,网络出现堵塞情况导致图片下载时间增加。
解决方案:优化网络带宽,保证环境的稳定性,减少图片的动态请求。
4)程序代码方面: itinerary.pl程序文件Receive时间太长且下载大小很大。
解决方案:一方面可优化客户端的展现方式;另一方面可优化itinerary.pl中的业务,可考虑对showSummary, removeFlights, showError, printltineraryHeader等方法进行拆分优化。
5)架构方面:本系统部署在Windows下,且数据是存储在文件中的,在大并发下,性能不如在Linux中使用数据库好。
解决方案:迁移程序部署在Linux下,把数据存储到数据库中,并对字段进行适当的索引可以提升效率和性能,同时考虑缓存设计,提升命中率。
(7)测试风险由于该报告为官方提供的测试报告,并未提供测试环境、详细配置等信息,所以在分析上可能存在遗漏或不足,带来了一定的风险,故测试结果分析与调优仅供参考。