假设有一个OApȝQ该pȝ?000个用用?#8213;―q就是说Q可能用该OApȝ的用hL?000名,q个概念是“pȝ用户?#8221;Q该pȝ有一?#8220;在线l计”功能Q系l用一个全局变量记数所有已d的用PQ从在线l计功能中可以得刎ͼ最高峰时有500人在U(q个500是一般所说的“同时在线人数”Q,那么Q系l的q发用户数是多少呢?
Ҏ(gu)我们对业务ƈ发用h的定义,q?00是整个pȝ使用时最大的业务q发用户数。当Ӟ500q个数值只是表明在最高峰时刻?00个用L(fng)录了pȝQƈ不表C实际服务器承受的压力。因为服务器承受的压力还与具体的用户讉K模式相关。例如,在这500?#8220;同时使用pȝ”的用户中Q考察某一个时间点Q在q个旉上,假设其中40%的用户在较有兴致地看pȝ公告Q注意:(x)“?#8221;q个动作是不?x)对服务端生Q何负担的Q,20%的用户在填写复杂的表|对用户填写的表格来说Q只有在“提交”的时L?x)向服务端发送请求,填写q程是不Ҏ(gu)务端构成压力的)Q?0%部分用户在发呆(也就是什么也没有做)Q剩下的20%用户在不停地从一个页面蟩转到另一个页?#8213;―在这U场景下Q可以说Q只?0%的用L(fng)正对服务器构成了压力。因此,从上面的例子中可以看出,服务器实际承受的压力不只取决于业务ƈ发用hQ还取决于用L(fng)业务场景?/p>
在实际的性能试工作中,试人员一般比较关心的是业务ƈ发用hQ也是从业务角度关注究竟应该设|多个q发数比较合理,因此Q在后面的讨ZQ也是主要针对业务ƈ发用hq行讨论Q而且Qؓ(f)了方便,直接业务ƈ发用hUCؓ(f)q发用户数?/p>
Q?Q?计算q_的ƈ发用hQ?C = nL/T
Q?Q?q发用户数峰|(x) C’ ≈ C+3根号C
公式Q?Q中QC是^均的q发用户敎ͼn是login session的数量;L是login session的^均长度;T指考察的时间段长度?/p>
公式Q?Q则l出了ƈ发用h峰值的计算方式中,其中QC’指ƈ发用h的峰|C是公式Q?Q中得到的^均的q发用户数。该公式的得出是假设用户的login session产生W合泊松分布而估得到的?/p>
实例Q?/p>
假设有一个OApȝQ该pȝ?000个用Pq_每天大约?00个用戯讉K该系l,对一个典型用h_(d)一天之内用户从d到退pȝ的^均时间ؓ(f)4时Q在一天的旉内,用户只在8时内用该pȝ?/p>
则根据公式(1Q和公式Q?Q,可以得到Q?/p>
C = 400*4/8 = 200
C’≈200+3*根号200 = 242
F=VU * R / T
其中F为吞吐量QVU表示虚拟用户个数QR表示每个虚拟用户发出的请求数QT表示性能试所用的旉
R = T / TS
TS为用h考时?/p>
计算思考时间的一般步骤:(x)
A?首先计算出系l的q发用户?/p>
C=nL / T F=R×C
B?l计出系l^均的吞吐?/p>
F=VU * R / T R×C = VU * R / T
C?l计出^均每个用户发出的h数量
R=u*C*T/VU
D、根据公式计出思考时?/p>
TS=T/R
~陷有效性百分比DDE=TDFT/(TDFC+TDFT)×100%
其中:TDFT=试q程中发现的全部~陷(即由试l发现的),TDFC=客户发现的全部缺?在版本交付后一个标准点开始测??半年以后)
~陷排除有效性百分比DRE=(TDCT/TDFT)×100%
其中:TDCT=试中改正的全部~陷,TDFT=试q程中发现的全部~陷
试用例设计效率癑ֈ比TDE=(TDFT/NTC)×100%
其中:TDFT=试q程中发现的全部~陷,NTC=q行的测试用例数
以下公式较适用于白盒测?/p>
功能覆盖? 臛_被执行一ơ的试功能Ҏ(gu)/ 试功能Ҏ(gu)L Q功能点Q?/p>
需求覆盖率= 被验证到的需求数?/ȝ需求数?Q需求)
覆盖? 臛_被执行一ơ的试用例? 应执行的试用例L Q测试用例)
语句覆盖? 臛_被执行一ơ的语句数量/ 有效的程序代码行?/p>
判定覆盖? 判定l果被评L(fng)ơ数 / 判定l果L
条g覆盖? 条g操作数D被评h(hun)一ơ的数量 / 条g操作数值的L
判定条g覆盖? 条g操作数值或判定l果臛_被评价一ơ的数量/(条g操作数值L+判定l果L)
上下文判定覆盖率= 上下文内已执行的判定分支数和/(上下文数*上下文内的判定分支L)
Z状态的上下文入口覆盖率= 累加每个状态内执行到的Ҏ(gu)?(状态数*cdҎ(gu)L)
分支条gl合覆盖? 被评到的分支条件组合数/分支条gl合?/p>
路径覆盖? 臛_被执行一ơ的路径?E序总\径数