jmeter压测怎么才算通过测试_性能测试之一个完整的性能测试涉及内容

jmeter会使用了,接口调试、参数化也能搞定了,那我们怎么设计场景进行日常接口压测呢?之前文章中提到过,当前团队对接的所有项目接口都是需要进行性能测试,测不测是我们性能测试人员说的算,测试的接口我们会给出评估,给出具体不测试的理由。其实每个接口都测,性能测试工作量还是很大的。我们也是想通过高并发的手段暴露出程序存在的一些性能相关的缺陷问题(比如:内存溢出、线程死锁、慢sql等)。本文主要介绍下当前我们公司在日常迭代过程中拿到一个接口后怎么开展性能测试呢?

在实际工作,一般我们会从这么几个方面开展性能测试。

1.环境

开始性能测试前首先需要有个独立的压测环境,各服务调用尽量走内网(排查网络环境),尽量不要使用测试环境,一般公司测试环境从节约成本角度,配置较低或者混着部署(一台机器上部署了N多个服务),压测的时候几个并发就可能把资源消耗完,根本压不起来,间接掩盖了程序存在的性能缺陷。我当前的公司有独立的线上内测环境、测试环境、压测环境,压测环境的机器配置(硬件、软件参数)是根据线上服务器配置保持一致,基本配置(4C8G)。环境这一步还是较关键的,机器不给力或者配置有差异,后面得出的压测结果可信度可想而知,研发也不会认的

2.测试确认

确认测试范围,了解被测接口内部逻辑、是否存在特别需要关注的点、测试数据量等。一些重要信息需要同产品、研发、业务测试人员讨论确认,如用户最常常用是哪些场景(是必填居多还是非必填居多)、最关注哪的性能,哪些数据需要模拟到真实的量级等。

3.设计测试

包括根据实际业务场景设计测试用例、准备测试数据。这就涉及到上面提到的测试确认信息,用户的使用习惯、工作时间段、系统各模块压力分布等等。只有场景设计到位,压力结果才有意义(比如:一个接口所有参数是非必填的,压测的时候如果都按照必填去测试,场景就和实际不一致,测试是没有意义的),更能暴露出系统存在的瓶颈。同时,测试数据准备也是很关键的一步,生成测试数据量达到未来预期数量只是最基础的一步,更需要考虑的是数据的分布是否合理,需要仔细的确认程序中使用到的各种查询条件,这些重点列的数值要尽可能的模拟真实的数据分布,否则测试的结果可能是无效的。

4.执行测试、监控

准备测试脚本,执行之前设计好的各个用例,监控并收集需要的数据。由于日常主要是迭代版本优化测试,这里简单介绍下压测场景:针对设计好的测试用例,每一种情况,我们会进行4组测试,比如:基准测试(单用户迭代100次)、50并发一次、100并发一次、100并发持续5分钟这四种情况。在这个过程中,我们会对每一种情况收集相应的测试数据和监控数据,若有问题出现时,会结合这些数据对问题进行分析定位。

5.通过标准

性能测试前提还需要有个标准,这个是衡量性能好坏的关键指标。由于是日常迭代版本压测(主要是单接口压测),我们内部考虑到用户可接受的业务指标和资源指标定了个标准:

164eb57151da40700cdabac50bfe0126.png

这也是很多刚接触性能测试时比较迷茫的地方,不知道压到多大压力才算满足自己需求的。这个需求通常不是自己想当然,而是需要在压测前多方讨论实际需求或者实现目标后拟定的。

6.测试报告

将测试过程中各种数据(业务数据、资源数据)收集起来汇总成报告,展示给各方人员看。这里我附上我们日常单接口压测的一个报告。

52599a7f26ca3498e54c3ed7ce8812f9.png

有了标准,我们就能确定哪些接口是通过性能标准,哪些是不通过标准的。至于不通过标准是什么原因导致的这个就牵涉到分析、定位问题。这属于一定的技术能力,牵涉的知识面较广,后续介绍。

走过路过,点个在看再走吧~

作为一个对测试有情怀的人,希望本公众号的文章对大家有一定的帮助,每时每刻转载或者编辑日常工作中自己对测试的认知,希望喜欢!

3f7d4d9637094e0cf6a41bfb11fcf73e.png

测试交流,加我备注【测试交流】拉入交流群~~~

792f0a76aadfc7528d8a3916aebc2a5c.png

声明:本文转自【性能测试践行】

dfa4c29fbedd5699d08cd8365e75c954.png

福利来一波~~~

关注公众号回复以下信息送免费资料
Jenkins Jenkins学习资料
Jmeter Jmeter学习资料

Java   Java学习资料

Python python入门资料

RobotFramework   RobotFramework 框架搭建资料

表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
相关推荐
©️2020 CSDN 皮肤主题: 深蓝海洋 设计师:CSDN官方博客 返回首页