注:本文并不百分百是原创,参考资料已经列在文章最下方。
对压力测试一无所知、但需要了解比较系统的压测知识的新手人群。
软件测试如果按照是否查看代码分类,则可分为白盒测试、黑盒测试以及灰盒测试三类,其中黑盒测试又可分为功能测试与性能测试。我们这里主要探讨性能测试中的压力测试,而性能测试的具体分类如下:
负载测试与压力测试的区别: 在负载测试中需要不断变化系统的负载,以测试系统在不同负载下的性能表现;在压力测试中则是让系统在极高的负载下测试系统的运行情况。
压测一般用于新系统上线支持、技术升级验证、业务峰值稳定性保障、站点容量规划以及性能瓶颈探测等。
举个例子,2012年11月11日零点,阿里各种系统报错、立刻下单报错、购物车支付报错、支付系统报错、购物车的东西丢失,系统显示交易成功率不到50%,产生了大量超卖,给阿里带来很大的损失。这是因为错误预估了可能会达到的流量,没有明晰整个购物链路上每个系统的承受能力,也没有完善的预案,说明了压测的重要性。
我们可以对各种服务对象进行压力测试,例如接口、系统、后台服务等。
接口测试是测试系统组件间接口的测试,主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点;测试原理是通过测试程序模拟客户端向服务器发送请求报文,服务器接收并处理报文然后发送应答报文,客户端再接收服务器相应发出的应答报文这一过程。
实现接口测试的方法
一般当需要测试大量并发,一台机器满足不了需求时会采用分布式压力测试。通俗解释就是由一台中控机(master)去调度其他多台机器(slave)执行对目标对象(target)的测试脚本,然后返回测试结果给中控机(master)。
ab(Apache Benchmark)是Apache公司提供的一款简单易上手的测试工具,一般用于测试web服务。它是一个命令行工具,对发起负载的本机要求很低,不会占用很多CPU或内存,但是会可能给目标服务器造成巨大的负载,其原理类似于CC攻击
。它适用于本地对支持HTTP协议的单一地址进行性能压测。
CC攻击(Challenge Collapsar)是针对web服务器或应用程序的攻击。原理是通过代理服务器或者大量肉鸡模拟多个用户访问目标网站的动态页面,制造大量的后台数据库查询动作,消耗目标CPU资源,造成拒绝服务。CC攻击的请求本身是正常的请求。
它可以根据命令创建很多并发访问线程,模拟多个访问者同时对某一个URL地址进行访问,以此测试目标服务器的负载压力。
它的扩展性比较低,用来测试post get接口请求非常便捷,但只能提供基本性能指标,没有图形化结果,无法监控。
LoadRunner是HP公司提供的一款预测系统行为和性能的工业标准级测试工具,通过模拟成千上万个用户实施并发操作,测试系统的性能,并且提供详细的测试结果分析,协助用户查找问题。
它的工作原理是用虚拟用户脚本生成器用代理方式接收客户端发送的数据包进行处理并转发给服务器端,再接收从服务器端返回的数据流进行处理并返回客户端,通过这种方式来模拟真实运行环境;在整个过程中实时监控采集控制台上的所有资源并捕获性能数据,最后将结果存储在数据库的储存库中。
它基本包括了JMeter的常用功能,支持IP欺骗,优点是专业、稳定、高效,缺点是非开源免费,售价高,扩展性比较差。
IP欺骗是指利用带有假的源IP地址的IP协议分组来冒充另一个计算机系统身份,使发送方可以保持匿名的技术。在压力测试中,如果某一个IP访问过于频繁或者访问量过大时,服务器会拒绝访问请求,此时可以通过IP欺骗增加访问频率和访问量;还有某些服务器配置了负载均衡,使用同一个IP无法测出系统的实际性能;又或是一些网站会限制IP登录等等,为了真实模拟现实情况,都需要用到IP欺骗。
JMeter是Apache公司组织开发的基于Java的测试工具,最初被设计用于web应用测试,但后来扩展到了其他测试领域。它的功能与LoadRunner比较相似,工作原理也基本一致——JMeter通过线程组来模拟真实用户对服务器的访问压力,可以作为服务器与客户端之间的代理网关以捕获请求和响应。另外,JMeter能够对应用程序做功能/回归测试,通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性,JMeter允许使用正则表达式创建断言。
它是一款开源的免费软件,具有强大的开源社区支持,社区内开发者活跃程度高。它使用了图形界面,用户可以通过图形界面来编写测试用例,操作简单易上手;并且它体积小巧,不需要安装即可使用。
它相比于LoadRunner的缺点是结果分析能力没有LR强,且不支持IP欺骗。并且JMeter的性能不太稳定,在高并发下观测结果集时容易遭成界面卡死或崩溃。
这里只比较详细地介绍了三种最常见的压测工具,还有一些其他工具简单介绍如下:
可以通过历史监控数据(已经上线的服务,存在历史数据),类比(新服务/线上未监控的服务,但存在类似功能服务的历史数据)或者估算(不存在历史数据、不存在类似功能服务数据,使用8/2原则
)去预估压测中期望服务能达到的性能预期。
8/2原则:指一天内80%的请求会在20%的时间内到达。
在压测前应明确需要压测的场景是什么,应有压测的优先级,高优先级场景有:
梳理完场景后,确认压测哪些服务,可能还需要对链路上相关的业务进行改造等。
部署压测环境,需要模拟用户(业务)与系统的交互。常见的方法是使用线上环境压测,在负载低的时间段发起压测。
前期工作是根据场景设计或者文本用例编写测试脚本以及对脚本进行调优等。在压测过程中一般从细粒度开始慢慢集成到整个大系统,如单接口单机->单接口1/4资源->场景化1/4资源->全量资源压测->拨测
。
单接口单机 在单核(或物理资源少)机器上部署单个服务,排除外部链路、网络等因素,得出自身服务的单核性能情况(单位QPS/core),后续根据此单核性能指标结合压测目标值进行扩容。另外由于是压的单接口单机,无其他接口请求影响,上下游在足够资源的情况下也不会造成瓶颈,所以能确保服务的性能真实值。 单接口单机可以在正式开始大规模压测前提前发现问题,方便RD做针对的性能优化并快速检验优化效果。一部分问题会先在单接口单机压测环节中发现,而一些隐藏得更深的问题,需要延后到全链路大流量压测才能暴露。 单接口1/4资源 单接口单机压测环节,服务端已经完成了部分性能优化,接下来可以进入单接口1/4资源压测,这样是为了验证在单接口单机压测中得到的单核性能数据,在扩容1/4资源下性能是否会线性增长,是否存在性能损耗以及定位损耗源。 场景化1/4资源 单接口压测局限很明显,场景化压测由于引入了上下游服务的其他接口的因素,可以发现单接口压测无法发现的问题,更接近线上用户场景。 全量资源全链路 全部资源到位后,预估的线上压力是否能承受,这一步也是内网压测过程的最后一步。 拨测 除了做内网压测,还要进行拨测验证用户从客户端到服务端的整个带宽资源是否满足预期,内网压测已经确认了业务性能是否达标,因此拨测可以只选择了一个场景进行验证即可。(简单来说拨测相当于压测cdn,检查各地cdn节点资源是否充足)来源:服务端压测怎么做
确认监控体系是否完整,对服务器、系统的资源指标和系统指标进行监控,一般监控项有:压测常用的性能指标指标。
压测最终应该输出一份报告总结,其实也就是把整个压测方案、过程、结论记录下来,写明压测目标、压测接口、压测数据、压测结论,给出发现的问题并提供优化方案。往往在压测报告完成时,性能问题已经基本被解决了,报告的意义在于梳理前面的整个流程,给后续的压测提供经验指导。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。