测试技术专题

测试需要关注的那些事儿(七)- 性能测试

2020-03-05  本文已影响0人  唐T唐X

说说性能测试

在如今的大数据时代,性能测试已经是产品出厂前的标配了,否则被服务性能压制了产品的亮点岂不可惜。自然地,测试人员就需要尽可能多的在产品上线前得到服务的各种性能参数,以判断是否能够达到预期。对于UI级别的测试,短期我们还是离不开传统的点点点;但是对于性能测试,光用几只手是不够的,需要用到性能测试工具,比如Jmeter、LoadRunner、AB等等。当然,不能说会用工具就比手工测试高级多少,起码在我看来都是测试的方法,只是在合适的地方用合适的方式罢了,没有高低贵贱之分。所以首先需要声明的是很多人只在意自己是不是用过什么工具,但真正被问起为什么会选择这个工具、为什么这样设置参数和各种思考过程相关的问题后,就没法回答了。这种情况在面试中经常遇到,简历中写的用过的工具天花乱坠,但是一旦被问起上面的问题,大部分就凉凉了。

不好意思,好像跑题了,我们继续回到性能测试这个论题。附上来自百度百科的定义:

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对服务的各项性能指标进行测试。

看了定义,感觉太抽象。举个栗子好了,比如我们的一个产品,给一个人用1分钟,这个人用着数据没问题而且反应还贼快,那下面这些情况还能不能像给一个人用1分钟的时候那样用着数据没问题而且反应还贼快?

不仅要验证预期能否满足,还要验证我们的极限,及出了问题后的展现形式,能不能自动恢复,这些都要有产出的指标数值,这些数值就是性能测试要的结果。

其实,每个公司甚至每个人对于性能测试的理解都是有些许不同的,相对的测试方案也是不很相同,我们会把性能测试分为2种,分别是压力测试、并发测试。我们接下来就分别看看这两种测试的工作内容。

压力测试
Jmeter配置
Jmeter配置

第二步:开始测试,关注聚合报告

聚合报告
由于是样例,我就不跑8个小时了,中断我们截取看下。从报告中我们可以很清楚的看到,这里面包含吞吐量、错误率、平均返回时间、最大最小返回时间、90%返回平均时间这些指标。我们拿吞吐量和错误率来说明下,吞吐量代表每秒我们的服务可以完成多少次请求,图中我们看到吞吐量是210.7/s,也就是说每秒可以完成请求210.7次,但是要注意!我们看到错误率是1.54%,请求错误的原因是因为返回超时了,而这些错误是会被记录到吞吐量中的!所以,吞吐量高并不代表你的服务性能好,只有在错误率很低的情况下吞吐量才有意义。我们这边基本上把错误率的标准设置成1%,也就是说只有ERROR % <= 1% 下的吞吐量值我们认为才有参考意义。在测试的过程中,要做好服务的CPU和内存监控,判断是否有OOM等情况的出现。

第三步:在第二步满足预期的情况下,加大用户数和时长,找到服务的极限指标
找到极限指标主要就是看错误率、吞吐量等值,如果出现了错误率上升,或者吞吐量下降,就要考虑服务到达极限了。这是也同样要结合服务的CPU和内存进行分析。

并发测试

首先,要了解什么是并发,可以看我之前的文章 测试需要关注的那些事儿(四)- 并发
并发测试的目的和压力测试不同,并发测试主要是为了发现数据准确性、死锁等问题。单纯的手工测试很难实现大的并发量,只能依靠工具。

50次这个数值只是我的举例,比如对于微信钱包这种有几亿用户的产品,并发数量就要设置的大得多才行了。

测试人需关注

聊了这么多,相信大家应该对性能测试有了一些认识了。性能测试能力已经是测试人员的标配,而各个公司都有自己的性能测试方案,甚至有些大厂还有自己的性能测试团队,可见其重要!注意!它远不止我们举例的接口压测这般简单,有兴趣的童鞋可以看看滴滴之前的全链路压测方案
,你一定会有种新的感觉!

上一篇 下一篇

猜你喜欢

热点阅读