1、性能调优
开发人员对系统调优后,需要测试人员配合去做性能测试,验证这次优化是否有效果。如果性能指标相比较之前的性能指标更好了,说明系统优化的有效果。反之说明调优不理想
2、新业务、新接口上线
系统从无到上线,验证新系统的能力是否能够满足某段时间系统使用要求,否则当高峰期来临,系统可能会崩溃。
3、验证系统稳定性
做性能测试经常跑一两个小时或者几十分钟就可以了,但系统的稳定性,系统能否长期稳定的工作,这个是不够的。系统出现的稳定性问题,一般有内存泄漏、连接数泄漏、死锁、游标不够用等,这些问题短时间内可能不会暴露出来。为了验证系统稳定性,一般用性能峰值并发数(即系统支持的最大并发数)7天24小时,系统的吞吐量,平均响应时间等各项性能指标均正常则认为系统稳定性是ok的。根据系统的重要程度,可以适当调整运行的时间,但至少要压测一个晚上的时间。
4、验证系统架构是否存在瓶颈
同一系统,架构师会提供不同的架构方案。那么不同的设计方案到底哪个好,我们可以通过性能测试验证不同方案的性能,其次了解系统大概达到什么量级的并发后系统就会出现问题,了解系统架构在达到性能峰值时哪块会出现瓶颈,帮助开发针对性地进行系统调优工作。
一般考虑的点有如下几点:
系统中被频繁使用的功能、调用的接口等
系统中涉及大量数据库读、写的功能
大量读写系统缓存部分的功能,验证缓存是否生效
总得来说应该将用户访问量大的,频繁操作数据库的,系统核心功能这些地方考虑到性能测试范围内。
3+1原则(指量、全、深+快)
主要对性能测试设计、测试执行以及数据分析。
量:包括业务量(业务类型),负荷量(系统处理的流量),配置量(软件配置和硬件配置),用户量(静态用户和动态用户),时间量(测试的时间)。
全:主要是针对测试用例而言。测试用例理你包括预置条件,测试步骤和预期结果三部分,这个“全”重点针对预置条件和测试步骤的测试结果观察和数据而言。
深:一是对系统地了解要深,二是对缺陷的分析要深。
快:一是测试经验的固化,避免测试设计,观察等遗漏。将经验固化成模板或工具便于经验的传承,减少测试的重复和遗漏;二是性能测试的自动化,包括性能测试环境构建和测试执行以及测试分析的自动化,自动化对性能测试效率的提升价值更大。
2-5-10原则
主要针对响应时间。简单说,就是当用户能够在2秒以内得到响应时,会感觉系统的响应很快;当用户在2-5秒之间得到响应时,会感觉系统的响应速度还可以;当用户在5-10秒以内得到响应时,会感觉系统的响应速度很慢,但是还可以接受;而当用户在超过10秒后仍然无法得到响应时,会感觉系统糟透了,或者认为系统已经失去响应,而选择离开这个Web站点,或者发起第二次请求。
80/20原则
用于减少风险,抓住重点进行更多的测试:80/20原则即帕累托法则(Pareto Principle),用户80%的时间在使用软件产品中20%的功能。“重点测试”就是测试这20%的功能,而其他80%的功能属于优先级低的测试范围,占测试20%的资源。
实例:对测试强度估算
基本概念:每个工作日80%的业务在20%的时间内完成。
例如:每天工作8个小时,那么每天80%的业务在8*20%=1.6小时内完成。
例如:去年全年处理业务约100万笔,其中,15%的业务处理中,每笔业务需对应用服务器提交7次请求;70%的业务处理中,每笔业务需对应用服务器提交5次请求;其余15%的业务处理中,每笔业务对应用服务器提交3次请求。根据以往的统计结果,每年的业务增量为15%,考虑到今后3年业务发展的需要,测试需按现有业务量的两倍进行。
强度估算如下:
每年的总请求数为:
(100*15%7+10070%5+10015%*3)*2=1000万次/年
每天的请求数为:
1000/160=6.25万/天<备注:每个月为20个工作日,所以1年为160天>
每秒请求数:(62500×80%)/(8*20%*3600)=8.68次/秒
保证性能测试与真实生产环境的一致性,具体从以下三方面看:
1、硬件环境
如服务器的型号,是否与其它应用程序共享此服务器,是否在集群环境下,是否通过BIGIP进行负载均衡,客户使用的硬件配置情况,使用的交换机型号,网络传输速率。
2、软件环境
版本一致性
包括操作系统、数据库、中间件的版本,被测系统的版本。
配置一致性
系统(操作系统/数据库/中间件/被测试系统)参数的配置一致,这些系统参数的配置有可能对系统造成巨大的影响。所以,除了保证测试环境与真实环境所使用的软件版本一致,也要关注其参数的配置是否一致。
3、使用场景的一致性
基础数据的一致性
包括预测的业务数据量,以及数据类型的分配。很简单的一个列子,一个系统的数据库只有10条数据和一条数据库里几千万条数据,我们在对其进行性能测试时,得到的性能指标可能会有非常大的差别。
为了保证每次测试环境的更加一致性,磁盘的使用情况以及磁盘的碎片情况也会或多或少地影响的性能。
使用模式的一致性
尽量模拟真实场景下用户的使用情况,其实,我们在做性能测试前期的需求分析,其主要目的也就是为了更真实的模拟用户的使用情况。
最后,我收集和整理了一份资料,有需要可以关注微信公众号:程序员二黑,免费获取!
公司新来的阿里p8,看了我做的APP和接口测试,甩给了我这份文档…
腾讯二面:web测试问题被虐哭了,直到学长给了我这些知识点…
面试滴滴科技,被按在地上摩擦,鬼知道我经历了什么?