性能测试心得系列1:我所理解的性能测试

本文探讨了性能测试的基本思路,从单用户自动化测试到监控请求,分析ART(平均事务响应时间)。面对高ART,文章建议检查服务器日志,排查网络问题,并使用JProfiler诊断代码效率,为新功能上线提供性能保障。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

性能测试的概念,我就不说了,百度一下,会出来一大堆,每一种说法都有一定的道理。什么是性能测试呢? 请不要告诉我是测试一个测试对象的性能:),性能测试,就我目前了解到的来说,很多时候都是很难去定位的,有很多东东可能会绊住我们前进的步伐!现在我们大体讲下,我所理解的大致思路针对于一个要上线的新功能来说,怎么去做。

首先,我们如果有条件最好去做下 单用户下的自动化测试,去daily的check,新功能的性能表现怎样。实在不能自动化完成,也要手动的去完成。

  • 新功能设置成为一个事物,去结合httpwatch,或者其他的开发者工具去监控每一个request,甚至是request的数量。

  • 如果ART(平均事务响应时间)很高,已经被customer,拒绝了,就真的没必要去搭建环境等等,性能测试的准备了。
    如果ART很高,怎么办?
    思路,首先看看后台网络服务器,app服务器等,启动运行时server.log,legacy.log设置是nohup.out是否有异常。再者查看request有没有单个request很高的情况,然后先排除是不是网络原因造成的,曾经碰到过有些request和其他的不在一个网络环境,如果是这样,就简单了,可以配置LB VIP(有些公司权限的限制,可能需要网络部门的帮助),等等来解决(复杂均衡虚拟IP)可以使得使得网段可以被访问。

    如果以上问题都没有怎么办?我们可以去做Jprofiler了,看看是不是有代码的问题,哈哈这个问题就比较复杂了,需要自己去实战的。
    今天暂时写到这里,未完待续

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

测试论道

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值