软件性能测试过程详解与案例分析(段念 编著) 学习笔记二
1.响应时间
对请求做出响应所需用的时间;
①应用系统从发出请求开始到客户端接收到响应所消耗的时间;
②应用系统从请求发出开始到客户端接收到最后一个字节数据所消耗的时间;(一般使用此种方式描述响应时间)
③页面响应时间=网络传输时间+应用延迟时间
④对一个电子商务网站来说,在美国和欧洲,一个普遍被接受的响应时间标准为2/5/10秒,也就是说,在2秒之内给客户响应被认为是“非常有吸引力的”,在5秒之内响应客户被认为是“比较不错的”,而10秒时客户能接受的响应的上限;
⑤在进行测试时,“合理的响应时间”取决于实际的用户需求,而不能依据测试人员自己的设想来决定;如,税务报账系统,该系统的用户每月使用一次该系统,一次花费2小时以上进行数据的录入,当用户单击“提交”按钮后,即使系统在20分钟后才给出“处理成功”的消息,用户仍然不会认为该系统的响应时间不能接受;
2.并发用户数
①业务并发用户数
对服务端来说,每个用户和服务器端的交互都是离散的。如果仅考虑一个单独的用户对系统的使用,过程大致如下:用户每隔一段时间向服务器发送一个请求或是命令,服务端按照用户的请求执行某些操作,然后将结果返回给用户。
从用户的角度来说,在一个相当长的时间段内(例如1天),都会有基本固定数量的使用者使用该系统,虽然每个使用者的行为不同,但从业务的角度来说,如果所有这些用户的操作都没有遇到性能障碍,则可以说该系统能够承受该数量的并发用户访问。
②如果考虑整个系统运行过程中服务器所承受的压力:在该系统的运行过程中,把整个运行过程划分为离散的时间点,在每个点上,都有一个“同时向服务端发送请求的客户数”,这个就是所称的服务端承受的最大并发访问数。如果能找到运行过程中可能出现的最大可能的服务端承受的最大并发访问数,则在该用户数下,服务器承受的压力最大,资源承受的压力也最大,在这种状态下, 可以考虑通过并发测试(Concurrency Testing)发现系统中存在的并发引用的资源争用等问题。
③并发用户数,系统用户数,同时在线用户人数
假设有一个OA系统,该系统有2000个使用用户—这就是说,可能使用该OA系统的用户总数是2000,这个概念就是“系统用户数”,该系统有一个“在线统计”功能,从在线统计功能中可以得到,最高峰时有500人在线(这个500就是一般所说的“同时在线人数”);
根据我们对业务并发用户数的定义,这500就是整个系统使用时最大的业务并发用户数。当然,500这个数值只是表明在最高峰时刻有500个用户登录了系统,并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式有关。例如,在这500个“同时使用系统”的用户中,考察某一个时间点,在这个时间点上,假设其中40%的用户在饶有兴致的看系统公告,20%的用户在填写复杂的表格,20%的用户在发呆,剩下的20%用户在不停地从一个页面跳转到另一个页面—在这种场景下,可以说,只有20%的用户真正对服务器构成了压力。因此,从上面的例子可以看出,服务器实际承受的压力不只取决于业务并发用户数,还取决于用户的业务场景。
④如何确定一个系统的并发用户数?
a.以更细的时间粒度进行考察:例如,可以设计1个小时为考察时间的粒度,对一个典型的OA系统,将一天的上班时间划分为8个区间,这样可以解决业务操作存在的时间集中性的问题;
b.考虑典型的业务模式:不同的应用有不同的业务模式,例如,一个内部系统一般在上班开始后的30分钟至1个小时集中出现用户的登录;一个账务系统在每月的结账日前几天会比较繁忙;一个门户网站在重大消息发布的前后会有访问高峰;一个旅游的网站在节假日前夕会有大量用户的访问。。。因此,在考虑计算并发用户数时,可以结合应用的业务模式,多考虑一些可能发生的场景,基于这些场景进行估算;
⑤C=n/10,C^=rxC
用每天访问系统用户数的10%作为平均的并发用户数,并发用户数的最大值由并发用户数乘上一个调整因子r得到,r的取值一般为2-3。
⑥日志分析
“日志分析”方法是指通过对应用服务器的日志进行分析,从而了解系统用户的使用状态,从日志中计算出“服务器承受的最大并发用户访问数”数据,这种方式得到的数据准确度和可信度都比较高,对于Internet应用等无法估计用户数量和用户行为模式的应用,这种方式最为可信;
“日志分析”的方法需要日志分析工具的支持,如AWStats开源工具。
3.吞吐量
①单位时间内系统处理的客户请求的数量,直接体现软件系统的性能承载能力。吞吐量用请求数/秒或是页面数/秒来衡量,从网络的角度来说,也可以用字节数/秒来考察网络流量。
②吞吐量指标可以在两个方面发挥作用:
a.可以协助设计性能测试场景,以及衡量性能测试场景是否达到了预期的设计目标;在设计性能测试场景时,吞吐量可被用于协助设计性能测试场景,根据估算的吞吐量数据,可以对应到测试场景的事务发生频率、事务发生次数等;另外,在测试完成后,根据实际的吞吐量可以衡量测试是否达到了预期的目标。
b.用于协助分析性能瓶颈:吞吐量的限制是性能瓶颈的一种重要表现形式;例如,RBI(Rapid Bottleneck Identify)方法就主要通过吞吐量测试发现性能瓶颈。
③以不同方式表达的吞吐量可以说明不同层次的问题。例如,以字节数/秒方式表示的吞吐量主要受网络基础设施、服务器架构、应用服务器制约;以单击数/秒表示的吞吐量主要受应用服务器和应用代码的制约。
④吞吐量和并发用户数之间的关系:
在没有遇到性能瓶颈的时候,吞吐量的公式 F=Nvu x R/T
F表示吞吐量,Nuv表示VU(虚拟用户)的个数,R表示每个VU发出的请求数量,T表示性能测试所用的时间;
4.性能计数器
①是描述服务器或操作系统性能的一些数据指标;
②计数器在性能测试中发挥着“监控和分析”的关键作用,尤其是在分析系统的可扩展性、进行性能瓶颈的定位时,对计数器取值的分析非常关键;
③资源利用率:系统各种资源的使用状况,一般用“资源的实际使用/总的资源可用量”形成资源利用率的数据,用以进行各种资源使用的比较;
5.思考时间
思考时间(Think time),也被称为“休眠时间”,从业务的角度来说,这个时间指的是用户在进行操作时,每个请求之间的间隔时间;