性能测试常见问题

889 553
发布提问
  • 全部
最热 | 最新
  • 软件测试 | 如何用Jmeter找出最大并发用户数?
    00:00
    00:00
    视频播放已结束
  • 项目明天就要上线了,今天晚上还发现一个bug。。。。。你们怎么处理,延期上线吗 首先和开发、产品一起评估下这个 bug 的严重程度和影响范围。 如果是比较轻微的 bug, 可以考虑先上线,在后续迭代版本中修复; 如果是比较严重的 bug,找开发沟通下,看看 能不能快速修复,并且有足够的时间去做下测试 如果时间不足了,那就得跟相关人员沟通 下,是不是先延期上线,毕竟强行上线后可能会造成严重的后果 你们怎么办?
  • 上班过程中遇到问题,你们怎么跟开发去沟通的呢,有没有人比较害怕跟开发沟通呀,分享一些沟通心得 1、就事论事,跟开发沟通时不要携带任何情绪,客观真实的进行沟通 2、不要过渡依赖开发,遇到问题先自己尝试分析下,有一个基本判断后,再去找开发 3、描述问题要简洁、清晰,比如现在在做什么事情,遇到了什么问题,需要开发提供什么 帮助 4、测试要有自己的原则和立场,自己认为是正确的事情,要坚定立场和自我判断,不能完 全听信开发 5、尽量集中式沟通问题,避免碎片化沟通,导致开发工作频频被中断 6、提升自己的技术能力和认知,用更专业的语言和开发沟通 7、遇到非常难沟通的开发,有必要时,要及时向上反馈,寻求帮助 你们工作中遇到过什么奇葩的开发吗
  • 分享一个我面试别人必问的问题:性能测试的时候TPS比较低,可能是哪些原因造成的呢 a)压力机本身性能瓶颈 b)网络IO瓶颈 c)中间件(tomcat/nginx/mysql)连接数限制 b)应用程序:内存、线程的阻塞、等待 e)数据库性能问题 f)本系统资源的瓶颈(cpu、内存、磁盘、网络等) g)其他外部系统响应时间过长,造成本系统的time-wait 这个是我总结的一些关注点,欢迎留言评论交流
  • 软件测试 | 面试官问你能独立完成项目测试吗,你是怎么回答的呢?
    00:00
    00:00
    视频播放已结束
  • 软件测试 | 内存溢出和内存泄露的区别
    00:00
    00:00
    视频播放已结束
  • 软件测试 | 工作中什么样的系统需要做性能测试呢?
    00:00
    00:00
    视频播放已结束
  • 软件测试 | 性能测试怎么构造数据?
    00:00
    00:00
    视频播放已结束
  • hhhhhh
  • hhhhhh
  • 根据需求规格说明书和性能指标输出性能测试方案,根据性能测试方案,将方案细化成用例,根据方案搭建性能测试环境。
  • 1、需求明确并发数或者用户量情况下,首先看最基本的:用户响应时间(95%用户响应时间、99%用户响应时间、最大响应时间具体根据需求或者现实定) 其他性能指标 tps、rps、CPU、内存、硬盘、网络、数据库以及代码问题都是用户时间响应长才会去监控排查的。在需求规定用户数下(压测时候是大于需求用户量的,具体大多少要根据实际情况了,有些翻倍,有些更多倍)用户响应时间正常,基本上其他问题都不大,如果你还要继续性能测试只是进一步优化而已,个人觉得没必要把时间花在这里了。 2、需求不明确情况下,就正常用户响应时间内找最大并发数、吞吐量估计用户量与实际中用户量对比了(一般理论要大于实际中的量,才有保障),其实这个与上面的也是反过来 3、上面两个前提是正式环境配置接近测试环境配置,包括软件配置硬件配置。
  • 个人理解:功能测试是验证产品的功能好使不好使,性能测试是产品的功能在好使的情况下,能有多好使。举个栗子,给你个锤子,功能测试就是这个锤子能不能捶东西,性能测试就是这个锤子一直锤会不会有问题,锤石头会不会有问题等等问题
  • 15K 我给你做功能测试,给我安排性能测试的活,不干😂20K 我可以给你做性能测试…… 功能测试简单点点点就差不多结束了…… 性能测试出现问题得看代码……很麻烦……也是建立在一个功能测试完成,稳定性,可靠性等的基础上去实现的
  • 如果你没有从事过专业的性能测试,如果有面试官问到,建议简单说一下,会用 jemter 或者 loadrunner 写脚本,之前项目有做过一些业务接口的并发测试,其他的不是太深入,不要展开讲太多,小心给自己挖坑,以前面试过几百个测试,真正会做性能且有实践项目经验的只碰到一个,其他都是外行。
  • 首先呢,肯定是先熟悉业务咯,业务不熟怎么测的好? 再次,要了解项目架构,能更好的写方案和分析问题。 上面两个属于加分项,不是主要答案,你答了更好。 以下性能测试本身 1.时机 要知道什么时候做性能测试,包括但不限于替换接口,接口响应变慢,观察服务器情况考虑增减配置,C 端项目上升期日常性能压测等。 2.方案 怎么做,评估是否需要压测,书写测试方案(包含),评审,然后找时间做性能测试,同时最好压测时,开发和运维在关注机器情况,避免压挂了。 不同场景侧重点不同,如新接口没有现成参照指标只能根据需求提出方提出的内容结合经验评估,如旧接口替换成新接口那简单拉最近几天平均访问量,压到比这个访问量多一些的情况,并且查看平均响应时间,成功率,负载情况,数据库读写,java 内存释放等,跟旧接口去比较。 3.实践 找时间压测了,查看日志,查看监控,避开客户使用的高峰期。在配置比较好的设备或者服务器上压,有条件的,还可以搭建专门的压测平台,分布式,压测数据报告等都做归档。 4.总结 写性能测试的报告了,给出结论,比如接口性能满足可上线,比如 xxx 性能到瓶颈需要加配置,xxx 服务器使用率较低减配等。 给出测试过程,数据,以及分析。
  • 第一 从常用工具学起 jmeter 等你学会了 有需求了  就用性能需求往工具并发上套 这样你就是一个初级的性能测试了  第二 你可以自己做性能需求分析了  给你一些模糊的性能需求或者要求 你可以推断出一个测试并发 就是中级了 第三你可以找出系统的压力点 并且可以在开发设计过程中进行性能方面的指导 你已经很可以了
  • 一些人做性能测试,都是在“耍流氓”! 举个例子: 我拿到了一份“流氓”的性能测试报告,上面只写了响应时间、TPS 是多少,然后罗列了一下压力机基本配置情况,比如 40 个并发相应时间是 5 秒,TPS 是 260。 那么,我该怎么判断这次性能测试的有效性: 1.场景是否合理? 2.压力是否传递均匀或者传递到指定目标? 3.是否有干扰因素,或者说那些数据是否有效? 4.有没有一些可信的判断方法? 这些问题的出现,其实就是反映出了目前在做性能测试的一些误区: 只测不调,无法给出研发和运维人员执行建议 无法定位问题,缺乏清晰的逻辑和数据证明价值 性能测试工具≠性能测试 性能测试技术体系落后(loadrunner),急需拥抱开源软件
  • 功能测试,基于界面,简单说就是验证是否实现了需求点,顺带测试是否易用;深一点,包括各种端的弱网等专项测试。 性能测试,分服务端和客户端; 服务端性能,通过接口并发响应,找出sql,算法,服务器配置的瓶颈; 客户端性能,主要测试移动客户端的CPU,内存耗用,卡顿,帧率,电量电压等指标。 纯手打
  • 带宽 在压力测试中,有时候要模拟大量的用户请求,如果单位时间内传递的数据包过大,超过了带宽的传输能力,那么就会造成网络资源竞争,间接导致服务端接收到的请求数达不到服务端的处理能力上限。 2、连接池 可用的连接数太少,造成请求等待。连接池一般分为服务器连接池(比如 Tomcat)和数据库连接池(或者理解为最大允许连接数也行)。 (关于连接池的具体内容,可参考之前的博客:性能测试:连接池和线程)