1、需要登录的接口性能测试
在实际业务场景中,很多业务都需要先登录才能正常使用。
在做接口性能测试的时候,需要测试登录后才能访问的接口肯定是无法避免的。
那么,我们怎么才能完成先登录后发出请求的性能脚本呢?
思路:
1)发出登录请求
2)提取响应的认证内容
3)后面的请求引用认证内容
提出问题:
做性能测试,是模拟多个虚拟用户实现并发的,那我们的登录接口也需要重复发起吗?
可以类比一个场景:
做UI自动化的时候肯定也需要登录的,一般我们会将登录放到全局前置来操作,所以整个测试流程下来只需要登录一次。
关键点:
一个用户只需要登录一次,避免重复发起登录请求,造成不必要的资源消耗。
最简单的场景
所有虚拟用户使用同一个用户账户,每次都是先调登录接口,再调登录之后接口请求吗?
如果你的系统,业务上允许一个用户在不退出情况下,反复登录,且没有登录次数限制,这种最理想的情况,你完全可以这么做
做完了,你可能会想,我不用一个账户,100个并发用户数,我就用100个独立账户,每个用户拥有独立账户每个虚拟用户都试用一个独立账户,还是先调登录,再调登录之后接口请求,这样可以吗,要怎么做?
在你的线程组里面用上csv数据文件设置读取出用户账户信息,或者用JDBCrequest从数据库获取出用户信息。
然后再在登录接口中用取出的用户信息来登录。
这样,在性能测试时,就会循环使用你用户总量中的用户来发送请求。
这样,理论上是行的通的,但是,现实有些骨感。
因为做性能测试,使用的是高并发,可能存在竞争关系,可能出现后续接口,使用的关联参数取不到值的情况。
从而导致请求报错,而这种错误,不是性能测试服务器响应报错,而是脚本问题导致报错,影响我们对性能结果的判断。
那么,我们就会问,还有没有其他办法呢?
终极办法:
上面也说了一个关键点:一个用户只需要登录一次。
既然我们一个线程就是一个模拟用户,那我们只需要针对每个线程做到只发出一次登录请求,其他接口可以无限次发起。
具体步骤
1)在线程组下添加一个逻辑控制器【仅一次控制器】
2)在该逻辑控制器下添加登录请求
3)登录请求下添加提取器,提取登录响应内容
4)和逻辑控制器平级下添加需要并发的请求
2、性能测试选择并发用户数
并发用户:指的是现实系统中同时操作业务的用户,在性能测试工具中一般称为虚拟用户(VirutalUser)。
并发用户跟注册用户、在线用户有很大差别,并发用户一定会对服务器产生压力,在线用户数只是”挂”在系统上对服务器不产生压力,注册用户一般指的是数据库中存在的用户。
TPS:TransactionPerSecond,每秒事务数,是衡量系统性能的一个重要指标。
事务靠虚拟用户产生,假如1个虚拟用户在1秒内完成1笔事务,那么TPS就是1,要想达到1000TPS至少需要1000个用户;如果某笔业务响应时间是1毫秒,那么1个用户在1秒内能完成1000笔事务,TPS就是1000。
因此1个用户可以产生1000TPS,1000个用户也可以产生1000TPS,主要看响应时间的快慢。
对于并发用户数的选择,可以选取线上系统在高峰时刻一定周期内使用系统的人数,这些人数可以认为是在线用户数,并发用户数取其10%就可以了。
例如在1小时内使用系统的用户数为10000,那么取10%作为并发用户数基本就够了。
对于TPS的评估,可以通过线上系统在高峰时刻10分钟内完成的业务量在单位时间的处理笔数计算出TPS,即业务笔数/单位时间(10*60)。
对于新上线系统因没有历史数据可供参考,故只能通过业务发展趋势来预判各项指标。
性能测试需要一套标准化流程及测试策略,在进行压测时一般会按照梯度施压的方式增加用户数,以此观察系统在不同压力下的各种反应,如果在没有充分评估的前提下一次加压大量用户会导致系统失败率高响应时间长,最终得到的测试结果没有太大意义。
一般情况下,大型系统(业务量大、机器多)做性能测试5000个并发用户就够了,中小型系统做性能测试1000个并发用户就足够了。
下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
在追求梦想的旅程中,每一次的奋斗都是对自我极限的挑战。让我们以坚韧的毅力和无畏的勇气,破茧成蝶,舞出属于自己的精彩人生!
奋斗是人生的磨刀石,每一次的挫折都是对意志的锤炼。让我们以坚定的信念和不懈的努力,攀登高峰,铸就辉煌的梦想之巅!
梦想的种子在奋斗的土壤中生根发芽,每一次的努力都是对未来的投资。让我们以积极的态度和不屈的精神,勇往直前,收获丰盛的人生果实!