系统处理时间
系统得到请求后对请求进行处理并将结果返回。那我进行性能测试主要就是验证系统的处理时间,因为前面的呈现时间和数据传输时间都我们不可控制的,用户使用的电脑及浏览器千差万别,用户的网络状况千差万别。我们唯一能控制的就是将系统的处理请求的时间缩到最短暂。
如果我们对系统的的处理进行分析和讲解的话,它会是一个非常庞大与复杂的过程。语言、语言框架、中间件,数据库、系统架构以及服务器系统。所以,想成为一个优秀的性能测试工程师我们的路还很长。
实际性的能测试
听了上面的分析,貌似每个过程都挺“浪费”时间,那么我们如何只测试系统的处理时间呢?
其实现在的测试工具都屏蔽呈现过程,只是模拟多用户并发请求,计算用户得到响应的时间,页不会将服务器的每个响应都向客户端呈现。
对于数据传输的问题,这也是我要强调的性能测试要在局域网中进行,在局域网中一般不会受到数据带宽的限制。所以,可以对数据的传输时间忽略不计。
响应时间的定义:
响应时间
指的是客户发出请求到得到响应的整个过程的时间。在某些工具中,请求响应时间通常会被称为“TTLB”(Time to laster byte) ,意思是从发起一个请求开始,到客户端收到最后一个字节的响应所耗费的时间。
系统响应时间
应用系统从发出请求开始到客户端接收到响应所消耗的时间。需要注明的是,这样的定义完全是个人喜好。你可以提异议。
我们来看两种情况:
我要访问百度首页,发出了一个请求,百度开始给我返回页面数据,当搜索框与搜索按钮都已经返回到页面上了,但那个图标还在发送中。我不认为这个响应是完整的。必须把页面上的所有信息都返回给我才是完整的,我要的也是所有结果返回给我的时间。这种情况更符合“相应时间”的定义
某系统有一个信息查询功能,当我输入某条件查询时,可能要查询几百万条数据,如果数据库,要查询所有的数据并把所有的数据全部完整的返回给我。可能服务器要查询很久,而我的电脑全部接收这些数据也可能只直接挂掉。那么服务器可能只查询100条数据并把数据返回给我,当我点击“下一页”时,服务器再次查询并将第二页的数据返回给我。这种情况更符合“系统响应时间”的定义。
关于响应时间,要特别说明的一点是,对客户来说,该值是否能够被接受是带有一定的用户主观色彩,也就是说,响应时间的“长”和“短”没有绝对的区别。
合理的响应时间
在互联网上对于用户响应时间,有一个普遍的标准。2/5/10秒原则。
也就是说,在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验,在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应,那么大多用户会认为这次请求是失败的。
这里我们还要考虑一个使用频率的概念。
我最早安装windows系统可能要1个小时,我们为什么觉得这很正常,因为我们要很久才装一次系统,如果系统使用得当,可能一个系统用几年不用重装,假如,我们在系统上装个任何小软件都要这么长时间,那我们一定是无法忍受的。对于软件控来说,他们会时常安装各种新鲜有趣的软件进行使用。
对于一个税务报账系统,该系统的用户每月使用一次,一次花费3小时进行数据的录入,
当用户单击“提交”按钮后,即使系统在10分钟后才给出“处理成功”的消息,我们也觉得是可以接受的。
因此,在进行性能测试时,“合理的响应时间”取决于用户的需求,而不能依据测试人员自己设想来决定。
相关链接: