赞
踩
1、性能测试常用8个步骤
1)获取最常用场景
已有面向广大用户的系统,只要使用就能提取到性能测试点。
最直接的方式:自己可以去操作下。如:视频网站,首页(访问量占总访问量的50-70),内容详情页,各子导航等。
已有面向少数客户的系统,最快速的方式看下数据库表量,找出数据量大的表去问项目经理 数据是怎么产生的,也能获取到性能测试点。
如果不能访问数据库,则可以找使用系统的客户聊聊(找聊的人数不少于角色人数),听听他们是如何使用的 也能知道最常用的功能是什么。
如果是未上线的,就更好办啦,找项目经理/产品经理/技术负责人聊聊呗,听听他们对系统的规划、设想和设计。
2)获取最终性能目标
方式一:客户有明确要求。
先恭喜你,遇到一个有预期的客户。但也得提醒你注意,客户预期是否合理。
方式二:现有资源限制,想知道最大承载量。
方式三:啥都没有的。
从我目前的经历来看,这个最常见来着。(是不是也可以证明我经历少呢,无从得知,欢迎讨论)
这样的情况,只要自己用客户提供环境/公司环境,自己搭建一套最小系统,看最小系统的承载量啦。
3)设计性能测试用例
主写:测什么场景,用什么测,收集什么信息,用例执行达标的方式是什么。
其次:规划下用例执行顺序。
好吧,规划执行顺序像测试策略啦,但个人总觉得一提到测试策略就是高大上、繁琐的赶脚(请原谅我的浅薄),不适合我的笨脑瓜,还是直接简洁方式适合我,就放在测试用例设计中吧。
4)搭建测试环境和造数据
在很多公司这个都是研发或运维的事情,我个人意见:测试人员自己做来的好。
好处:等需要调整环境时自己可以直接上手,不需要去请教研发和运维呀,大大节省了沟通成本和缩短修改的时间。
建议使用Jenkins得到系统部署包,最好能用docker 直接得到测试镜像(如有兴趣可以看我的部署专题)
存储过程、shell脚本可以实现造数据。
能自己搞定的,尽量自己搞定,不依赖他人,才是活的更好,工作也是如此的。
5)将word形式的测试用例改成可执行的用例
怎么写脚本需要看你选的是什么工具来做性能测试。
如一个URL页面的性能测试,我通常就用开源ab,webench。(关于市面上云性能测试服务,但有去验证下,再来发表意见)
6)执行用例
这里有一点要提醒,常见的就是1个用例执行2小时,4个用例就是执行8小时,然后就认为自己一天能完成性能测试的执行,可往往第1个用例要花费双倍以上的时间(环境配置的微调)
7)收集结果
不是测试执行后才考虑这个问题,是在测试用例设计时就考虑好的,到执行时确认收集的结果是正确即可。
8)编写性能报告
在网上只有一搜索性能测试报告模版查到的就会是一个很多页数的模版。
个人不建议用这样的模版来汇报性能测试结果,我一般只有测试项对应着的性能测试指标,且用图表的直观地表达出性能上升期、峰值、稳定期。
2、性能测试关注点总结
性能测试关注点:how much 与 how fast
1)性能测试的分类
极限测试:
在各种边界压力情况下,如电池、存储、网速,验证APP是否能正确响应,内存满时安装APP—运行APP时手机断电—运行APP时断网
响应能力测试:
APP中各类操作是否满足用户响应时间要求,APP安装—APP卸载—APP各类功能性操作的响应时间
压力测试:
反复/长期操作下、系统资源的占用情况
2)性能的评估
评估典型用户应用场景下,系统资源的使用情况(可测试方面:安装与启动时间—CPU的占用—内存的占用—流量的耗用—电量的耗用—-网速–后端(并发连接数),测试APP中的各类操作是否满足用户响应时间要求)
3)性能测试的指标
性能测试指标的来源:用户对各项指标提出的明确需求,如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项指标(需求+经验)
可用性(可用时长);
响应时间(用户发起请求到应用响应完全到达用户客户端所消耗的时间);
吞吐率(某些面向应用的时间的发生概率);
资源利用率(对某种资源理论容量的使用百分比);
4)性能测试的目的
测试系统的性能指标;
检查系统的性能瓶颈;
给出较合适的软硬件配置方案;
检验硬件配置是否能够满足客户需求;
最终起到优化系统的目的
| 下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |








不论身处何地,只要心怀梦想,坚持努力,你就能超越极限,创造奇迹。相信自己的力量,迎接挑战,成就非凡的人生!
永不言败,永不放弃。无论遭遇多少挫折,只要保持勇气和信念,坚韧不拔地前行,成功的道路便会越来越近!
心怀信念,迈出坚定的步伐,勇往直前。无论前方有多少艰难险阻,只要不放弃,成功的光芒终将照耀你的人生征程!
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。