软件测试培训
美国上市软件测试培训机构

400-111-8989

热门课程

面向开发的测试技术:性能测试

  • 时间:2017-08-23
  • 发布:软件测试培训
  • 来源:IT职场

引子:自上世纪末Kent Beck提出TDD(Test-Driven Development)开发理念以来,开发和测试的边界变的越来越模糊,从原本上下游的依赖关系,逐步演变成你中有我、我中有你的互赖关系,甚至很多公司设立了新的QE(Quality Engineer)职位。和传统的QA(Quality Assurance)不同,QE的主要职责是通过工程化的手段保证项目质量,这些手段包括但不仅限于编写单元测试、集成测试,搭建自动化测试流程,设计性能测试等。可以说,QE身上兼具了QA的质量意识和开发的工程能力。从这篇开始,我会从开发的角度分三期聊聊QE这个亦测试亦开发的角色所需的基本技能。

1 什么是性能测试?

先来看一下维基百科里对性能测试的定义,

In software engineering, performance testing is in general, a testing practice performed to determine how a system performs in terms of responsiveness and stability under a particular workload. - Wikipedia

注意上述定义中有三个关键词:

responsiveness,即响应时间,请求发出去之后,服务端需要多久才能返回结果,显然响应时间越短,性能越好。

stability,即稳定性,同样的请求,不同时刻发出去,响应时间差别越小,稳定性越好,性能也越好。

workload,即负载,同一时刻服务端收到的请求数量,其中单位时间内成功处理的请求数量即吞吐量,吞吐量越大,性能越好。

响应时间和吞吐量是衡量应用性能好坏最重要的两个指标。对于绝大多数应用,刚开始的时候,响应时间最短;随着负载的增大,吞吐量快速上升,响应时间也逐渐变长;当负载超过某一个值之后,响应时间会突然呈指数级放大,同时吞吐量也应声下跌,应用性能急剧下降,整个过程如下:

图片出处:性能测试应该怎么做?

2 性能测试的目的

了解了应用性能变化的普遍规律,性能测试的目的也就有了答案:针对某一应用,找出响应时间和吞吐量的量化关系,找到应用性能变化的临界点。你可能会问,知道了这些有什么用呢?在我看来,至少有3个层面的好处:

第一,有的放矢,提高资源利用率。性能测试的过程就是量化性能的过程,有了各种性能数据,你才能对应用性能进行定量分析,找到并解决潜在的性能问题,从而提高资源利用率。

第二,科学的进行容量规划。找到了应用性能变化的临界点,也就很容易找到单节点的性能极限,这是进行容量规划的重要决策依据。比如某一应用在单节点下的极限吞吐量是2000 QPS,那么面对10000 QPS的流量,至少需要部署5个节点。

第三,改善QoS(Quality of Service)。很多时候,资源是有限的,面对超出服务能力的流量,为了保证QoS,必须做出取舍(比如限流降级,开关预案等),应用性能数据是设计QoS方案的重要依据。

3 性能测试的三个常见误区

误区1:只看平均值,不懂TP95/TP99

用平均值来衡量响应时间是性能测试中最常见的误区。从第1小节的插图可以看出,随着吞吐量的增大,响应时间会逐渐变长,当达到最大吞吐量之后,响应时间会开始加速上升,尤其是排在后面的请求。在这个时刻,如果只看平均值,你往往察觉不到问题,因为大部分请求的响应时间还是很短的,慢请求只占一个很小的比例,所以平均值变化不大。但实际上,可能已经有超过1%,甚至5%的请求的响应时间已经超出设计的范围了。

更科学、更合理的指标是看TP95或者TP99响应时间。TP是Top Percentile的缩写,是一个统计学术语,用来描述一组数值的分布特征。以TP95为例,假设有100个数字,从小到大排序之后,第95个数字的值就是这组数字的TP95值,表示至少有95%的数字是小于或者等于这个值。

以一次具体的性能测试为例,

总共有1000次请求,平均响应时间是58.9ms,TP95是123.85ms(平均响应时间的2.1倍),TP99是997.99ms(平均响应时间的16.9倍)。假设应用设计的最大响应时间是100ms,单看平均时间是完全符合要求的,但实际上已经有超过50个请求失败了。如果看TP95或者TP99,问题就很清楚了。

误区2:只关注响应时间和吞吐量,忽视请求成功率

虽说衡量应用性能好坏最主要是看响应时间和吞吐量,但这里有个大前提,所有请求(如果做不到所有,至少也要绝大多数请求,比如99.9%)都被成功处理了,而不是返回一堆错误码。如果不能保证这一点,那么再低的响应时间,再高的吞吐量都是没有意义的。

误区3:忘了测试端也存在性能瓶颈

性能测试的第三个误区是只关注服务端,而忽略了测试端本身可能也存在限制。比如测试用例设置了10000并发数,但实际运行用例的机器最大只支持5000并发数,如果只看服务端的数据,你可能会误以为服务端最大就只支持5000并发数。如果遇到这种情况,或者换用更高性能的测试机器,或者增加测试机器的数量。

4 如何进行性能测试?

介绍完性能测试相关的一些概念之后,再来看一下有哪些工具可以进行性能测试。

4.1 JMeter

JMeter可能是最常用的性能测试工具。它既支持图形界面,也支持命令行,属于黑盒测试的范畴,对非开发人员比较友好,上手也非常容易。图形界面一般用于编写、调试测试用例,而实际的性能测试建议还是在命令行下运行。

并发设置

请求参数

结果报表

命令行下的常用命令:

设置JVM参数:JVM_ARGS=”-Xms2g -Xmx2g”

运行测试:jmeter -n -t <jmx_file>

运行测试同时生成报表:jmeter -n -t <jmx_file> -l <log_file> -e -o <report_dir>

除了JMeter,其他常用的性能测试工具还有ab, http_load, wrk以及商用的LoaderRunner。

4.2 JMH

如果测试用例比较复杂,或者负责性能测试的人员具有一定的开发能力,也可以考虑使用一些框架编写单独的性能测试程序。对于Java开发人员而言,JMH是一个推荐的选择。类似于JUnit,JMH提供了一系列注解用于编写测试用例,以及一个运行测试的引擎。事实上,即将发布的JDK 9默认就会包含JMH。

下面是我GitHub上的示例工程里的一个例子,

其中:

@BenchmarkMode: 性能测试模式,支持Throughput,AverageTime,SingleShotTime等多种模式。

@Fork: 设置运行性能测试的Fork进程数,默认是0,表示共用JMH主进程。

@Threads: 并发数,Threads.MAX表示同系统的CPU核数。

@Warmup和@Measurement: 分别设置预热和实际性能测试的运行轮数,每轮持续的时间等

@Setup和@Benchmark: 等同于JUnit里的@BeforeClass和@Test

由于使用JMH框架编写的性能测试程序只能以Jar包的形式运行(Main函数固定为org.openjdk.jmh.Main),一般会针对每个JMH程序单独维护一个项目。如果是Maven项目,可以使用官方提供的jmh-java-benchmark-archetype,如果是Gradle项目,可以使用jmh-gradle-plugin插件。

4 小结

以上就是我对性能测试的一些见解,欢迎你到我的留言板分享,和大家一起过过招。下一篇我将聊一下Web的自动化测试,敬请期待。

上一篇:软件测试(QA)的成就感并不仅仅是你以为的这些!
下一篇:漫谈阿里大数据
选择城市和中心
贵州省

广西省

海南省