• 欢迎光临~

1.性能测试概念

开发技术 开发技术 2022-06-08 次浏览

性能测试概念

    我们经常看到的性能测试概念,有人或称之为性能策略,或称之为性能方法,或称之为性能场景分类

    大概可以看到性能测试、负载测试、压力测试、强度测试等一堆专有名词的解释

    针对这些概念的一个感觉很乱,延伸出了这么多的概念,并且概念之间的界限又非常模糊

    性能测试应该是针对系统的性能指标,建立性能测试模型,制定性能测试方案,制定监控策略,在场景条件之下执行性能场景,

    分析判断性能瓶颈并调优,最终得出性能结果来评估系统的性能指标是否满足既定值。

 

 

性能测试需要指标

   如果没有指标,老板只说一句,系统压死为止。听起来很儿戏,但这样的场景不在少数。

   如果把系统压死也算是一种指标。至于你用什么手段把系统“压死”,那就是实现的问题了。你可以采用很多种手段

  指标 这个定义来说,理论上合理的,并且应该有的指标是:时间指标、容量指标和资源利用率指标

 

性能测试需要有模型

    模型是什么?它是真实场景的抽象,可以告诉性能测试人员,业务模型是什么样子。

    比如说,我们有 100 种业务,但不是每个业务都需要有并发量,可能只有 50 个业务有,那就要把这些有并发的业务统计出来,

    哪个业务并发多,哪个业务并发少,做压力时就要控制好这样的比例。

    随着互联网中零售业、云基础架构的全面发展,有些企业直接在线上导流来做性能测试,

    这种思路上的转变来源于架构的发展及行业的真实需要。

     但这并不能说明性能测试不需要模型了,因为这个模型已经从生产流量中导过来了

    性能测试也要选择适合自己系统业务逻辑的方式,用最低的成本、最快的时间来做事情

 

性能测试要有方案 

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

     建议用项目管理工具单独画测试计划,比如用 Project 或 OmniPlan 之类的工具。

     这是因为在方案中,写测试计划,基本上只能写一个里程碑,再细化一点,就是在里面再加几个大阶段的条目。

     但是用项目管理工具做计划就不同了,它不仅可以细分条目,还能跟踪各个工作的动态进度,可以设置前后依赖关系,填入资源和成本以便计算项目偏差

 

性能测试中要有监控

   这个部分的监控,要有分层、分段的能力,要有全局监控、定向监控的能力

 

性能测试要有预定的条件

    这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容。

    要是展开来说,在场景执行之前,这些条件应该是确定的。有人说,我们压力中也会动态扩展。

    但是动态扩展的条件或者判断条件,也是有确定的策略的,比如说,我们判断 CPU 使用率达到 80% 或 I/O 响应时间达到 10ms 时,就做动态扩展。

    这些也是预定的条件。关于这一点,如果对软硬件资源、测试数据和执行策略分不清楚,甚至都不明白为什么要几分钟加几个线程。在这种情况之下,就不能指望这个场景是有效的了。

 

 

性能测试中要有场景

  “性能场景”这个词在性能测试中占据着举足轻重的地位

   对性能场景中的“场景”比较正宗的描述是:在既定的环境(包括动态扩展等策略)、既定的数据(包括场景执行中的数据变化)、既定的执行策略、既定的监控之下,

   执行性能脚本,同时  观察系统各层级的性能状态参数变化,并实时判断分析场景是否符合预期

   性能场景也要有分类

   1.基准性能场景:这里要做的是单交易的容量,为混合容量做准备                                       

                              几个线程跑三五遍脚本不叫基准测试,那只是场景执行之前的预执行,用来确定有没有基本的脚本和场景设计问题,不能称之为一个分类

 

    2.容量性能场景:这一环节必然是最核心的性能执行部分。根据业务复杂度的不同,这部分的场景会设计出很多个

 

    3.稳定性性能场景:稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中,稳定性测试基本没和生产一致过。

                                  在稳定性测试中,显然最核心的元素是时间(业务模型已经在容量场景中确定了),

                                   而时间的设置应该来自于运维周期,而不是来自于老板、产品和架构等这些人的心理安全感

 

     4.异常性能场景:要做异常性能场景,前提就是要有压力。在压力流量之下,模拟异常。这个异常的定义是很宽泛的

 

    5.测试场景不等同于用例:如果只是叫法不同,是可以的,关键是内容也出现了很大的偏差,

                                          这个偏差就是,把用例限定在了描述测试脚本和测试数据上,

                                          并没有描述需要实时的判断和动态的分析。这就严重影响了下一个概念:性能结果

 

性能测试中要有分析调优

  需不需要在性能测试项目中调优,或者说是不是性能测试工程师做调优,人们有不同的争论。

  从性能市场的整体状态来看,在性能测试工程师中,可以做瓶颈判断、性能分析、优化的人并不多,

      所以很多其他职位上的人对性能测试的定位也就是性能验证,并不包括调优的部分。

  于是有很多性能项目都定义在一两周之内。这类项目基本上也就是个性能验证,并不能称之为完整的性能项目。

  而加入了调优部分之后,性能项目就会变得复杂。对于大部分团队来说,分析瓶颈都可能需要很长时间,这里会涉及到相关性分析、趋势分析、证据链查找等等手段

 

  性能项目分为如下几类:

  1. 新系统性能测试类:这样的项目一般都会要求测试出系统的最大容量,不然上线心里没底。
  2. 旧系统新版本性能测试类:这样的项目一般都是和旧版本对比,只要性能不下降就可以根据历史数据推算容量,对调优要求一般都不大。
  3. 新系统性能测试优化类:这类的系统不仅要测试出最大容量,还要求调优到最好

 

  性能团队的职责定位有如下几种:

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

 

 

性能测试肯定要有结果报告

  有了前面监控的定义,有了场景执行的过程,产生的数据就要整理到结果报告中

  这个文档工作也是很重要的,是体现性能团队是否专业的一个重要方面。并不是整理一个 Word,美化一下格式就可以了。

  测试报告是需要汇报或者归档的,大部分老板或者上司关心的是测试的结果,而不是用了多少人,花了多少时间这些没有意义的数字。

  我们更应该在报告中写上调优前后的 TPS、响应时间以及资源对比图,性能测试需要对系统上线后的性能负责

 

总结

  在性能测试的概念中,性能指标、性能模型、性能场景、性能监控、性能实施、性能报告,这些既是概念中的关键词,也可以说是性能测试的方法和流程

  这些概念我们在实际的工作中,都是非常重要的。因为它们要抹平沟通的误解。让不同层级,不同角色的人,可以在同样的知识背景下沟通,

      也可以让做事情的人有清晰的逻辑思路,同时对同行间的交流,也有正向的促进作用

      1.性能测试概念

 

程序员灯塔
转载请注明原文链接:1.性能测试概念
喜欢 (0)