图片 1

容易混淆的“并发”概念

这篇文章摘自kruny的blog,作者的blog地址为:

如何应用性能测试常用计算公式

常用并发数计算公式
N=[(n*0.8*S*P)/(T*0.2)]*R
n为系统用户数
S为每个用户发生的业务笔数(QPS)
P为每笔业务所需要访问服务器的时间,单位为秒
T为使用业务的时间,单位为秒;
R为调节因子,缺省值为1

昨天读完了段念写的《软件性能测试过程详解与案例剖析》一书的第一章,感觉学到了不少东西,以下将该书中的我认为是精华的一篇复制过来给大家一起看看:

1.问题提出

在实际的性能测试工作中,测试人员一般比较关心的是业务并发用户数,也就是从业务角度关注究竟应该设置多少个并发数比较合理,因此,在后面的讨论中,也是主要针对业务并发用户数进行讨论,而且,为了方便,直接将业务并发用户数称为并发用户数。 
       (1) 计算平均的并发用户数: C =
nL/T 
       (2) 并发用户数峰值: C’ ≈ C+3根号C
        公式(1)中,C是平均的并发用户数;n是login session的数量;L是login session的平均长度;T指考察的时间段长度。
        公式(2)则给出了并发用户数峰值的计算方式中,其中,C’指并发用户数的峰值,C就是公式(1)中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。
实例:
         假设有一个OA系统,该系统有3000个用户,平均每天大约有400个用户要访问该系统,对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。
则根据公式(1)和公式(2),可以得到:
               C = 400*4/8 = 200
               C’≈200+3*根号200 =
242 
           F=VU * R / T
其中F为吞吐量,VU表示虚拟用户个数,R表示每个虚拟用户发出的请求数,T表示性能测试所用的时间
R = T / TS
TS为用户思考时间
计算思考时间的一般步骤:
A、 首先计算出系统的并发用户数
C=nL / T      F=R×C
B、 统计出系统平均的吞吐量
F=VU * R / T R×C = VU * R / T
C、 统计出平均每个用户发出的请求数量
R=u*C*T/VU
D、根据公式计算出思考时间
TS=T/R
缺陷检测有效性百分比DDE=TDFT/(TDFC+TDFT)×100%
其中:TDFT=测试过程中发现的全部缺陷(即由测试组发现的),TDFC=客户发现的全部缺陷(在版本交付后一个标准点开始测量,如,半年以后)

在实际的性能测试中,经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”,下面用一个实际的例子来说明它们之间的差别。

性能测试中有很多非常重要的概念,如吞吐量、最大并发用户数、最大在线用户数等。有很多读者也非常关心,如何针对自身的系统确定当前系统,在什么情况下就可以满足系统吞吐量、并发用户数等指标要求呢?

 

假设有一个OA系统,该系统有2000个使用用户——这就是说,可能使用该OA系统的用户总数是2000名,这个概念就是“系统用户数”,该系统有一个“在线统计”功能系统用一个全局变量记数所有已登录的用户),从在线统计功能中可以得到,最高峰时有500人在线这个500就是一般所说的“同时在线人数”),那么,系统的并发用户数是多少呢?

2.问题解答

缺陷排除有效性百分比DRE=(TDCT/TDFT)×100%
其中:TDCT=测试中改正的全部缺陷,TDFT=测试过程中发现的全部缺陷

根据我们对业务并发用户数的定义,这500就是整个系统使用时最大的业务并发用户数。当然,500这个数值只是表明在最高峰时刻有500个用户登录了系统,并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如,在这500个“同时使用系统”的用户中,考察某一个时间点,在这个时间上,假设其中40%的用户在较有兴致地看系统公告注意:“看”这个动作是不会对服务端产生任何负担的),20%的用户在填写复杂的表格对用户填写的表格来说,只有在“提交”的时刻才会向服务端发送请求,填写过程是不对服务端构成压力的),20%部分用户在发呆也就是什么也没有做),剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下,可以说,只有20%的用户真正对服务器构成了压力。因此,从上面的例子中可以看出,服务器实际承受的压力不只取决于业务并发用户数,还取决于用户的业务场景。

(1)吞吐量计算公式。

测试用例设计效率百分比TDE=(TDFT/NTC)×100%
其中:TDFT=测试过程中发现的全部缺陷,NTC=运行的测试用例数

在实际的性能测试工作中,测试人员一般比较关心的是业务并发用户数,也就是从业务角度关注究竟应该设置多少个并发数比较合理,因此,在后面的讨论中,也是主要针对业务并发用户数进行讨论,而且,为了方便,直接将业务并发用户数称为并发用户数。

吞吐量(Throughput)指的是单位时间内处理的客户端请求数量,直接体现软件系统的性能承载能力。通常情况下,吞吐量用”请求数/s”或者”页面数/s”来衡量。从业务角度来看,吞吐量也可以用”业务数/h”、”业务数/天”、”访问人数/天”、”页面访问量/天”来衡量。从网络角度来看,还可以用”字节数/h”、”字节数/天”等来衡量网络的流量。

以下公式较适用于白盒测试
功能覆盖率= 至少被执行一次的测试功能点数/ 测试功能点总数 (功能点)
需求覆盖率= 被验证到的需求数量 /总的需求数量 (需求)
覆盖率= 至少被执行一次的测试用例数/ 应执行的测试用例总数 (测试用例)
语句覆盖率= 至少被执行一次的语句数量/ 有效的程序代码行数
判定覆盖率= 判定结果被评价的次数 / 判定结果总数
条件覆盖率= 条件操作数值至少被评价一次的数量 / 条件操作数值的总数
判定条件覆盖率= 条件操作数值或判定结果至少被评价一次的数量/(条件操作数值总数+判定结果总数)
上下文判定覆盖率= 上下文内已执行的判定分支数和/(上下文数*上下文内的判定分支总数)
基于状态的上下文入口覆盖率= 累加每个状态内执行到的方法数/(状态数*类内方法总数)
分支条件组合覆盖率= 被评测到的分支条件组合数/分支条件组合数
路径覆盖率= 至少被执行一次的路径数/程序总路径数

1)  计算平均的并发用户数: C = nL/T     

吞吐量是大型门户网站以及各种电子商务网站衡量自身负载能力的一个很重要的指标,一般吞吐量越大,系统单位时间内处理的数据越多,系统的负载能力也越强。

2)  并发用户数峰值: C’ ≈ C+3根号C

吞吐量是衡量服务器承受能力的重要指标。在容量测试中,吞吐量是一个重点关注的指标,因为它能够说明系统的负载能力。而且,在性能调试过程中,吞吐量也具有非常重要的价值,例如,Empirix公司在报告中声称,在他们所发现的性能问题中,有80%是因为吞吐的限制而引起性能问题。

公式1)中,C是平均的并发用户数;n是login session的数量;L是login
session的平均长度;T指考察的时间段长度。

显而易见,吞吐量指标在性能测试中占有着重要地位。那么吞吐量会受到哪些因素影响,该指标和虚拟用户数、用户请求数等指标有何关系呢?吞吐量和很多因素有关,如服务器的硬件配置,网络的拓扑结构,网络传输介质,软件的技术架构等。此外,吞吐量和并发用户数之间存在一定的联系。通常在没有遇到性能瓶颈的时候,吞吐量可以采用下面的公式计算:

公式2)则给出了并发用户数峰值的计算方式中,其中,C’指并发用户数的峰值,C就是公式1)中得到的平均的并发用户数。该公式的得出是假设用户的login
session产生符合泊松分布而估算得到的。

 

实例:

图片 1

假设有一个OA系统,该系统有3000个用户,平均每天大约有400个用户要访问该系统,对一个典型用户来说,一天之内用户从登录到退出该系统的平均时间为4小时,在一天的时间内,用户只在8小时内使用该系统。

这里,F表示吞吐量;
表示并发虚拟用户个数(Concurrency Virtual
User,并发虚拟用户),R表示每个VU发出的请求数量,T表示性能测试所用的时间。但如果遇到了性能瓶颈,此时吞吐量和VU数量之间就不再符合给出公式的关系。