性能测试二八原则,响应时间2/5/8原则

所谓响应时间的“2-5-8原则”,简单说,就是

  • 当用户能够在2秒以内得到响应时,会感觉系统的响应很快;
  • 当用户在2-5秒之间得到响应时,会感觉系统的响应速度还可以;
  • 当用户在5-8秒以内得到响应时,会感觉系统的响应速度很慢,但是还可以接受;
  • 而当用户在超过8秒后仍然无法得到响应时,会感觉系统糟透了,或者认为系统已经失去响应,而选择离开这个Web站点,或者发起第二次请求。

软件测试理论中,常提到2-8原则

所谓2-8原则,即80%的bug多发生在软件的20%的模块。所以,在回归测试的时候,这20%的高发地带是关注的重点!

二八原则还指:80%的业务量在20%的时间里完成。

如何理解,下面我们来个例子吧

用户登录场景:早高峰时段,8:50---9:10,5000坐席上线登陆。

      业务量:5000个 

      时间:20x60=1200秒

    吞吐量=80%x业务量/(20%*时间)=4000/240=16.7/秒

而并非5000/1200=4.1/秒

实际上,登录请求数分布是一个正态分布,最高峰时肯定比4.1/秒更高,高峰段实际上完成了80%的业务量,却只花了20%的时间。

温馨提示:

1.二八原则计算的结果并非在线并发用户数,是系统要达到的处理能力(吞吐量),初学者容易被误导,那这这个数据就去设置并发数,这是错误滴。

2.如果你的系统性能要求更高,也可以选择一九原则或更严格的算法,二八原则比较通用,一般系统性能比较接近这个算法而已,大家应该活用。

二八原则还指:

1、80%的错误是由20%的模块引起的

-----> 站在用户角度,并非研发实现的角度,正确地选择重要模块作为测试重点,从而不偏离方向。

2、80%的测试成本花在20%的软件模块中

-----> 设计用例时需要将时间花倾斜在复杂的20%核心模块上,从而设计更高效的测试用例。

3、80%的测试时间花在20%的软件模块中

------> 软件测试执行过程中需要将时间倾斜在重要模块的测试用例中,从而使测试更加有效,发现bug。

原文地址:https://www.cnblogs.com/PeterZhang1520389703/p/8571139.html

时间: 2024-11-13 06:41:39

性能测试二八原则,响应时间2/5/8原则的相关文章

【我的《冒号课堂》学习笔记】设计原则(3)内聚原则

内聚原则 “高内聚,低耦合”原则是软件模块设计的通用原则.实际上,该原则最早出现在结构化设计(structured design)中,后被引入对象式设计.耦合和内聚是衡量软件设计质量的两个重要指标,是检验模块设计是否合理的主要标准.其中,耦合(coupling)反映模块之间的关联程度,内聚(cohesion)反映模块内部的关联强度. 以上是常见的耦合类型和内聚类型.模块化的目的是把一个复杂的系统分解成几个相对独立简单.具有特定功能的软件组件,以便分开管理.模块职责单一而明确,关系简单清晰就是遵循

面向对象五大原则之一:单一职责原则(自我理解)

http://www.cnblogs.com/seacryfly/archive/2011/12/29/2305965.html 只有类对应的(唯一)职责(需求)的变更才会引起代码的重构. The single responsibility principle states that every module or class should have responsibility over a single part of the functionality provided by the so

C#软件设计——小话设计模式原则之:开闭原则OCP

前言:这篇继续来看看开闭原则.废话少说,直接入正题. 软件设计原则系列文章索引 C#软件设计——小话设计模式原则之:依赖倒置原则DIP C#软件设计——小话设计模式原则之:单一职责原则SRP C#软件设计——小话设计模式原则之:接口隔离原则ISP C#软件设计——小话设计模式原则之:开闭原则OCP 一.原理介绍 1.官方定义 开闭原则,英文缩写OCP,全称Open Closed Principle. 原始定义:Software entities (classes, modules, functi

设计模式六大原则之一:单一职责原则

设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 说到单一职责原则,很多人都会不屑一顾

设计模式六大原则(一):单一职责原则

单一职责定义: 不要存在多于一个导致类变更的原因,通俗的说,即一个类只负责一项职责. 问题由来: 类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案: 遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. ps: 说到单一职责原则,很多人都会不屑一顾.因为它太简单了

[转]设计模式六大原则[1]:单一职责原则

定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 说到单一职责原则,很多人都会不屑一顾.因为它太简单了.稍有经验的程序员即使

【我的《冒号课堂》学习笔记】设计原则(1)间接原则

间接原则 All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections. ——David Wheeler 这是一句计算机界的名言.在计算机领域中这样的例子数不胜数,像文件系统中的路径path,HTTP中的URI.数据库中的外键foreign key.程序中的变量均具有间接指代作业. 先

面向对象设计原则七:接口隔离原则

接口隔离原则(ISP) 定义:使用多个专门的接口比使用单一的总接口要好.即不要把鸡蛋都放到一个篮子里. 好处:比较灵活.方便,不想实现的或不用实现的可以不实现.解释说明: 大部分人都喜欢用一个接口把需要用到的方法全部声明出来,但是ISP建议我们使用多个专门的接口比使用单一的总接口要好,也就是一个接口里的方法多的话,实现起来不是很方便. 示例1: 1 using System; 2 using System.Collections.Generic; 3 using System.Linq; 4 u

面向对象设计原则之四:依赖倒置原则

依赖倒置原则 所谓依赖倒置原则(Dependence Inversion Principle )就是要依赖于抽象,不要依赖于具体.简单的说就是对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合. 面向过程的开发,上层调用下层,上层依赖于下层,当下层剧烈变化时,上层也要跟着变化,这就会导致模块的复用性降低而且大大提高了开发的成本. 面向对象的开发很好的解决了这个问题,一般的情况下抽象的变化概率很小,让用户程序依赖于抽象,实现的细节也依赖于抽象.即使实现细节不断变化,只要抽象不变