vlambda博客
学习文章列表

性能测试的概念到底是什么?

 

网络上比较普遍的说法是负载测试,压力测试,并发测试,极限测试等,甚至一些书籍上都是这样的叫法,但是你仔细看呢,你又会发现这些说法都很相似,难以分辨。

 

其实我比较的认同的一种分法是:单业务基准测试,单业务负载测试,混合交易容量测试。最近也在慢慢的吸收,内化成自己的东西,这些概念在自己的脑子中会逐渐的清晰起来。

 

专栏的作者高楼给出了自己的定义:

 

性能测试针对系统的性能指标,建立性能测试模型,制定性能测试方案,制定监控策略,在场景条件之下执行性能场景,分析判断性能瓶颈并调优,最终得出性能结果来评估系统的性能指标是否满足既定值。

 

性能测试需要有指标

 

指标的话,比较重要的有三个:时间指标、容量指标和资源利用率指标

 

性能测试需要有模型

 

模型的话其实就是根据业务来的,那个业务的并发多,那个业务的并发少。

 

性能测试要有方案

 

方案规定的内容中有几个关键点,分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险。

 

性能测试中要有监控

 

这个肯定是必不可少的部分,有很多的工具,以后会分享一下。

 

性能测试中要有场景

 

场景来源于英文的 scenario,对性能场景中的“场景”比较正宗的描述是:在既定的环境(包括动态扩展等策略)、既定的数据(包括场景执行中的数据变化)、既定的执行策略、既定的监控之下,执行性能脚本,同时观察系统各层级的性能状态参数变化,并实时判断分析场景是否符合预期。这才是真正的场景全貌。

 

这里作者分了三类,摘抄如下:

 

基准性能场景:这里要做的是单交易的容量,为混合容量做准备(不要跟我说上几个线程跑三五遍脚本叫基准测试,在我看来,那只是场景执行之前的预执行,用来确定有没有基本的脚本和场景设计问题,不能称之为一个分类)。

 

容量性能场景:这一环节必然是最核心的性能执行部分。

 

稳定性性能场景:稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中,稳定性测试基本没和生产一致过。在稳定性测试中,显然最核心的元素是时间(业务模型已经在容量场景中确定了),而时间的设置应该来自于运维周期,而不是来自于老板、产品和架构等这些人的心理安全感。


异常性能场景:要做异常性能场景,前提就是要有压力。

 

性能测试中要有分析调优

 

对性能项目分为如下几类。


新系统性能测试类:这样的项目一般都会要求测试出系统的最大容量,不然上线心里没底。

 

旧系统新版本性能测试类:这样的项目一般都是和旧版本对比,只要性能不下降就可以根据历史数据推算容量,对调优要求一般都不大。

 

新系统性能测试优化类:这类的系统不仅要测试出最大容量,还要求调优到最好。对性能团队的职责定位有如下几种。

 

性能验证:针对给定的指标,只做性能验证。第三方测试机构基本上都是这样做的。性能测试:针对给定的系统,做全面的性能测试,可以得到系统最大容量,但不涉及到调优。


性能测试 + 分析调优:针对给定的系统,做全面的性能测试,同时将系统调优到最优状态。

 

最后做一下总结:

 


最近的文章可能都会是总结,因为性能测试这块自己知道的实在是太少了,需要找大量的书籍与专栏来学习消化。

 

学着实践着越来越发现这块是一个无底洞,好像所有的问题都涉及到性能或者说跟性能有点关系。

 

【对自己的说的话】

 

有时候情绪会很低落,有时候又会很容易的兴奋,这样不好。要多传播正能量,做一个乐观的人,还是李笑来的那句话:“永远对未来的自己充满盲目的乐观”。