所谓响应时间的“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。