首页 >编程 >正文

一次性能测试复盘

这是一次比较仓促的性能测试,由于性能测试人员不足,紧急调动我们业务测试进行性能测试。当然了,这也是一次宝贵的经验。下面来详细说一下这次性能测试的过程。

获取信息

这次性能测试的业务不属于我们日常测试的范围,是业务组需要在我们的平台上发布。我们对这些接口并不熟悉,因此,需要获取相关的文档来熟悉项目以及我们要压测的接口。主要包括:环境信息、接口文档、相关的业务流程以及一份以前的性能测试报告。

调试接口

我们的性能测试工具统一用Jmeter。调试接口分为两步:一是保证接口调通,二是进行业务串联。根据接口文档以及业务流程进行接口组合。这一步主要进行接口的调试,主要包括:接口入参的类型是否正确;入参与输出是否一致。

业务串联主要是对接口进行业务层面的删减、参数化、试跑。业务串联主要分为三类接口:注册、查询以及操作类。这期间遇到了一个问题:有一个注册接口需要用到身份证,一直注册就需要源源不断的身份证。这时候,我们想到了两个解决方案。一个是直接写在Jmeter的beanshell里面;一个是我们有身份证生成工具,可以生成后放在Execl或者txt文件里面读取。我们用beanshell完成封装,并且可以顺利获取。经过讨论,后一种的生成是一位大佬写的,暂时用后一种。

进行测试

我们根据现场反馈的数据进行换算。算出我们需要压测的最大并发数以及最小并发数。这中间有一个插曲,就是之前说的注册用户数。我们是按半小时跑,但是注册用户按照半小时跑,总用户数将远远超过现场最大用户数,在生产环境这样搞,可能会造成不必要的麻烦。经过讨论,我们改为轮次,注册接口每个并发跑30轮。

注册类接口改为了按轮次执行,但是还有其他查询接口,只能按时间来跑。这时候问题又出现了:注册接口产生的数据,查询和执行接口是要用到的。这时候的解决方案是把注册生成的数据提取出来,放在txt里面,跑查询和执行接口的时候,再读取txt。

在进行现场压测的时候,还有一个问题,就是生成的txt文件,身份证号生成过多时会大量重复。就临时换个我们自己写的beanshell,虽然也有重复,但是不超过0.1%,就一直用着跑了。

期间脚本没有再出现什么问题,一直到压测结束。

收获

这次压测,是一次理论知识实战的宝贵经验。主要感触有两点:一是要有足够的准备。这次好的一点就是,调试接口初期,业务开发能进行很好的配合,对接口问题进行积极处理,需要的文档、环境也能及时提供;二是在问题出来时,要有足够的预案:在身份证号生成这一个环节,如果没有足够的预案,好不容易申请的压测机会就要流逝,阻碍测试的正常进行。

这次的分享到这里就结束了,如果对于我们遇到的问题有更好的解决办法或者建议,可以私信或者留言哦!

END

网友评论

验证码 换一张
取 消
暂无评论...
三日内热门评论文章
关键词
为您推荐
  • 相关阅读
  • 业界资讯
  • 手机通讯
  • 电脑办公
  • 新奇数码
  • 软件游戏
  • 科学探索