圣诞节巨献!在没有明确性能指标的前提下,怎样有效开展性能测试

发布时间:2023年12月25日

理想中的性能测试

用一句歌词形容理想中的性能测试,我站在草原望北京,一望无际国泰安宁。。。

产品经理提供性能测试场景,并发数,以及期望的业务处理能力和响应时间。

研发同学提供详尽的接口文档,配合测试同学生成测试数据。

测试同学很顺利的完成性能测试工作提供测试报告。

研发同学按照测试报告完善产品性能。

真是一片和谐安宁的幸福景象。。。

现实中的性能测试

现实中的很多公司其实都是这样搞性能测试滴。。。

产品经理说,需要对产品进行性能测试,测试人员自己定吧,然后。。。然后就没有然后了!

测试向研发同学要接口文档,其实大多数情况下是没有接口文档的,听到最多的回复是,编码任务太重了,没时间写接口文档;部分幸运的测试同学要到了接口文档,但是按照文档里面的内容,是根本调不通接口的!

这怎么做性能测试呢?

这怎么做性能测试呢?

这怎么做性能测试呢?

很不凑巧的是,老板发现产品很慢,不分青红皂白,对着性能测试同学一顿喷!

tmd,不干了! 不干了? 可是现在工作太难找了,没有收入怎么活?

自救,改变思路

分析产品经理无法提供性能测试的场景,并发数,以及期望的业务处理能力和响应时间的本质原因是什么?很简单!是他真的不知道!!!我们手机里装的应用,那都是app中的翘楚,百分之八十普通小厂的应用(就是你我公司的产品)其实是很少有人问津的,通常打点监控做的也不完善,产品也自然很难获取到用户的真实使用数据信息。

至于研发同学不提供详尽接口文档的原因也很简单,主要有两点:

1.确实忙,没时间写

2.接口变得太快了,维护不过来!

怎么破?

怎么破?

怎么破?

核心就是我们测试人员尽可能少地来打扰研发和产品,我们测试自己干!

简单的说就是,直接从产品页面使用入手,抓住用户体验这个key,从两方面入手:

1.单用户做页面的性能测试,发现页面的资源(如图片、脚本、样式表的加载)以及页面请求的响应时间等性能问题;

2.对某页面中所有的接口进行压力测试。

具体方法如下:

前端性能测试

可以使用google的工具lighthouse,直接发现页面中的资源,如图片、脚本、样式表的加载问题,大家可以参考文章:

从0到1搞定前端性能测试(非常详细)-CSDN博客

页面抓包压测所有接口

实现也非常简单粗暴,通过fiddler等抓包工具,获取产品页面中的所有请求,然后进行压测!

这里有几点注意:

1.不要再生产环境中测试,因为你真的不知道会产生什么影响

2.测试前一定要跟研发打招呼,告诉他们我们要压测了,把抓取的接口发给研发让他们确认(给定反馈时间,不反馈,直接压,出问题了,研发的锅)看看是否会影响生产数据,把有风险的接口屏蔽

3.没有指标的性能测试,在测试报告也没必要明确写哪个接口就是慢,我们可以采取同页面中接口比较的方法,例如一个页面中,我们用10个用户压测时发现,页面的整体响应时间就已经超过5秒了,然后这个页面中有10个接口(1-10),其中,接口5 和接口6 响应时间都在3s 以上,而其他接口都在200ms左右,那么很显然接口5和6是需要被进一步分析的!

4.最后把所有测试接口的处理能力和响应时间进行统计,然后发到业务群里,我们也没必要说接口是否不达标,只表达我们已经进行了测试并展示了结果,至于是否需要优化那就产品经理和研发自行判断把。从我的实践经验来看,还是有一定效果的,因为我们并没有单独对哪个接口进行测试,而是选择了页面中的所有接口,页面响应的快慢是用户直接能够感受到的,而影响页面性能的接口研发是需要处理的(这个无锅可甩),大家也可以在自己的项目中尝试一下

我的每一篇文章都希望帮助读者解决实际工作中遇到的问题!如果文章帮到了您,劳烦点赞、收藏、转发!您的鼓励是我不断更新文章最大的动力!

文章来源:https://blog.csdn.net/liwenxiang629/article/details/135197943
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。