性能测试案例与经验分享

点击文末小卡片免费获取软件测试全套资料资料在手涨薪更快性能基准测试性能基准测试通常被称为 Performance Benchmark Test是每次对外发布产品版本前必须要完成的测试类型。性能基准测试会基于固定的硬件环境和部署架构比如专用的服务器、固定的专用网络环境、固定大小的集群规模、相同的系统配置、相同的数据库背景数据等通过执行固定的性能测试场景得到系统的性能测试报告然后与上一版本发布时的指标进行对比如果发现指标有“恶化”的趋势就需要进一步排查。典型的“恶化”趋势主要表现在以下几个方面同一事务的响应时间变慢了。比如上一版本中用户登录的响应时间是 2 s但是在最新的被测版本中这个响应时间变成了 4 s系统资源的占用率变高了。比如上一版本中平均 CPU 占用率是 15%但是在最新的被测版本中平均 CPU 占用率变成了 30%网络带宽的使用量变高了。比如上一版本中发送总字节数是 20 MB接收总字节数是 200 MB但是在最新的被测版本中发送总字节数变成了 25 MB接收总字节数变成了 250 MB。这里需要注意的是这些“恶化”趋势的前提是完全相同的环境以及测试负载。不同“恶化”指标的排查有不同的方法。我以最常见的事务响应时间变慢为例和你说明一下排查方法。假设通过性能基准测试的比较结果得知用户登录的响应时间从 2 s 变成了 4 s。那么我们首先要做的是验证在单用户的情况下是否会出现响应时间变长的问题。具体做法是将用户登录的虚拟用户脚本单独拿出来建立一个单用户运行的性能测试场景并执行观察用户登录的响应时间是否变慢。如果变慢了就说明这是单用户登录场景就可重现的性能问题后续的处理也相对简单了。解决方法是分析单用户登录的后端日志文件看看完成登录操作的时间具体都花在了哪些步骤上相比之前哪些步骤花费的时间变长了或者是多出了哪些额外的步骤。如果没有变慢则说明我们必须尝试在有压力的情况下重现这个性能问题。为此我们要基于用户登录的虚拟用户脚本构建并发测试的场景但是我们并不清楚在这个场景设计中到底应该采用多少并发用户、加入多长的思考时间。这时通常的做法是直接采用性能基准测试中的并发用户数和思考时间去尝试重现问题。如果无法重现我们可以适当地逐步加大测试负载并观察响应时间的变化趋势。这里需要注意的是千万不要使用过大的测试负载。因为测试负载过大的话系统资源也会成为性能瓶颈一定会使响应时间变长。但这时响应时间变长主要是由资源瓶颈造成的而不是你开始要找的那个原因。如果此时可以重现问题那就可以进一步去分析并发场景下用户登录操作的时间切片找到具体的原因。如果此时还是不能重现问题的话情况就比较复杂了也就是登录操作的性能可能和其他的业务操作存在依赖或者某种资源竞争关系这就要具体问题具体分析了。一般来说当定位到性能“恶化”的原因并修复后我们还会再执行一轮性能基准测试以确保系统对外发布前的性能基准测试指标没有“变坏”。可以说通过对每个预发布版本的性能基准测试我们可以保证新发布系统的整体性能不会下降这也就是性能基准测试最终要达到的目的。很多大型的传统软件公司都有专门的性能测试团队这个团队会建立标准的性能基准测试场景并把性能基准测试的结果作为产品是否可以发布的依据之一。比如我曾工作过的 HP 软件就由性能测试卓越中心负责维护、执行性能基准测试并分析测试结果。从性能基准测试的设计角度来看你需要特别注意以下三点性能基准测试中虚拟用户脚本的选择以及配比需要尽可能地匹配实际的负载情况总体的负载设计不宜过高通常被测系统的各类占用率指标需要控制在 30% 以内尽量避免由于资源瓶颈引入的操作延时每次性能基准测试前一般需要对系统资源以及网络资源做一轮快速的基准测试以保证每次被测环境的一致性同时也要保证数据库的数据量在同一个级别上。总之你需要采用一切可能的手段来确保多次性能基准测试之间的环境一致性。稳定性测试稳定性测试又称可靠性测试主要是通过长时间7*24 小时模拟被测系统的测试负载来观察系统在长期运行过程中是否有潜在的问题。通过对系统指标的监控稳定性测试可以发现诸如内存泄漏、资源非法占用等问题。很多企业级的服务器端产品在发布前往往都要进行稳定性测试。稳定性测试通常直接采用性能基准测试中的虚拟用户脚本但是性能测试场景的设计和性能基准测试场景会有很大不同一般是采用“波浪式”的测试负载比如先逐渐加大测试负载在高负载情况下持续 10 多个小时然后再逐渐降低负载这样就构成了一个“波浪”整个稳定性测试将由很多个这样的波浪连续组成。稳定性测试成功完成的标志主要有以下三项系统资源的所有监控指标不存在“不可逆转”的上升趋势事务的响应时间不存在逐渐变慢的趋势事务的错误率不超过 1%。实际工程项目中由于稳定性测试执行的时间成本很高往往需要花费 3~7 天的时间所以我们一般是在其他所有测试都已经完成并且所有问题都已经修复之后才开始稳定性测试。另外有些企业为了缩短稳定性测试的执行时间往往还会采用“时间轴压缩”的方法具体的做法就是在加大测试负载的前提下适当缩短每个“波浪”的时间从而减少整体的测试执行时间。最后需要强调的一点是虽然很多时候尤其是产品版本已经逐渐走向成熟期时稳定性测试并不会发现问题但是千万不要小看稳定性测试带来的价值。因为稳定性测试一旦发现问题那么这些问题都是很严重而且非常隐蔽的大问题。所以很多大型的企业级软件企业都会执行严格的稳定性测试并把稳定性测试的结果作为产品是否可以发布的硬性要求。比如我曾经工作过的 HP 软件研发中心它每次产品发布前都会由专门的性能测试团队完成严格的稳定性测试并以此来决定是否要发布这个产品。并发测试并发测试是在高并发情况下验证单一业务功能的正确性以及性能的测试手段。高并发测试一般使用思考时间为零的虚拟用户脚本来发起具有“集合点”的测试。并发测试往往被当作功能测试的补充主要用于发现诸如多线程、资源竞争、资源死锁之类的错误。要执行并发测试就需要加入“集合点”所以往往需要修改虚拟用户脚本。容量规划测试容量规划测试是为了完成容量规划而设计执行的测试。那什么是容量规划呢所谓容量规划是软件产品为满足用户目标负载而调整自身生产能力的过程。所以容量规划的主要目的是解决当系统负载将要达到极限处理能力时我们应该如何通过垂直扩展增加单机的硬件资源和水平扩展增加集群中的机器数量增加系统整体的负载处理能力的问题。目前来讲容量规划的主要方法是基于水平扩展。但是具体应该增加多少机器以及增加后系统的负载处理能力是否会线性增长这些问题都需要通过容量规划测试进行验证。那么容量规划测试具体要怎么做呢我们可以使用性能基准测试中的虚拟用户脚本以及各个业务操作脚本的百分比压测单机部署的被测系统。我们会采用人工的方式不断增加测试负载直到单机系统的吞吐量指标到达临界值由此就可以知道单台机器的处理能力。理论上讲整个集群的处理能力将等于单台机器的处理能力乘以集群的机器数但是实际情况并不是这样。实际的集群整体处理能力一定小于这个值但具体小多少就是要靠实际的测试验证了。理想的状态是集群整体的处理能力能够随着集群机器数量的增长呈线性增长。但是随着机器数量的不断增长总会在达到某个临界值之后集群的整体处理能力不再继续呈线性增长。这个临界值是多少我们也需要通过容量规划测试找出来了。另外容量规划测试的测试结果还可以被用作系统容量设计的依据。比如企业级软件产品的目标用户规模通常是可以预估的那么我们就可以通过这些预估的系统负载计算出软件部署的集群规模并且可以在具体实施后通过容量测试的方式进行验证。最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。