即最后结论：
X=(0.252Y+8.64y-0.36yY)*m
根据经验值，Y=3，y=30%时，m/X=0.33。而m是平台最大有效并发数，即用来服务于广告物料显示的并发数，而对于每次广告物料的显示，客户端还有访问其它资源如JS代码等，假设每一次广告物料的访问会有伴随另外2个资源的访问。
那么平台支撑的总的并发数与需要达到的日均PV的比大约为0.33*3=1。
(b)实际测试模型设计中结果：
对广告链接页面的并发用户数只需要达到N1=0.33*40000000*0.7/24*0.3*3600=356个
对于流媒体服务器并发用户数：N2=10000000*0.7/24*0.3*3600/2=135个
对于图片服务器并发用户数：N3=30000000*0.7/24*0.3*3600/2=405个
2、集团邮箱：
(1)具体的业务参数要求：集团邮箱支持支持2000万用户，对性能有要求的操作有邮箱登录，读信，翻页，发邮件(分别是8秒内，2秒内，2秒内，5秒内)。所有的操作均返回 HTTP200的状态代码。其中服务器资源分别是登录5台机器(连接PASSPORT)，收发邮件5台(不包括POP收发信)，其它邮件处理服务器5 台，pop/smtp服务器5台。
(2)具体的测试设计方法：具体的设计2000万个用户登录时间大概在会在8点到下午18点前操作，而该类业务模型满足80~20原则，比如80%的业务会在20%的时间内处理。则登录的并发用户数设计成多少好呢? VUlogin=20000000*80%/(10*20%*3600*5) 其它事物可以以此类推。
(3)当然如果业务在要求吞吐量的时候，就要更根据吞吐量来设计性能瓶颈所需要的并发用户数这在我们21CN网站和电子商务网站中经常出现。这里引进一个公式VU=F /R*T(VU并发虚拟用户数,F吞吐量,T性能测试时间,R每个VU的请求数量)举例说明(某网站的吞吐量为90亿KB，每个用户每秒50万kb，运行时间30分钟设计出来的每秒用户数VU=9000000000/(500000*30*30))
(4)如办公系统(业务比较频繁的系统)：每天内的一些典型用户固定可以考虑采用一种更准确的计算并发用户数的的方法。公式引进：C=N*L/T,C1=C+ (C是平均并发用户数，N是login session的数量，L是login session的时长，T是考察的时间长度，C1是最高峰值)(*这里的用户是指明确每天都要使用的系统的大概数量来自需求，而这里的用户都是当做一个典型的用户来分析就是登录后会进行正常的流程操作)如21CNEIP每天有320个典型用户访问，系统平均时间为4小时，在一天内用户使用该系统的时间都在 8小时内。得出C=320*4/8,C1=C+3 (5)针对这几种模式做一些归纳无论那种模型都是来源于需求根据需求的实际模型是最真实的也是最有效的性能测试模型，在没有典型用户的前提下选择2-8原则(在测试环境中要考虑到等价这个概念就是测试环境服务器数量没有实际环境哪么多的时候要折算过来)，有典型用户的情况下选择最大并发数的计算方法，在要求有吞吐量的情况下用吞吐量的计算方法(但是吞吐量的数据要采用上一次测试或者经验值中没有突破系统瓶颈的部分数据要不结果不准确，其中每秒事物数取的是平均值)
三、其它值得注意部分
1、设置测试场景中并发用户为每隔一段时间增加X个虚拟用户(预热，RAMP UP设置)，与同时加载所有的并发用户的测试结果不同，实际的测试中要根据具体业务情况设计。另外实际的数据库记录数和网络环境等都会影响到测试结果。
2、建议在实际的测试过程中能多次测试取平均值。
3、性能测试的”拐点论”:产生拐点的情况是性能测试产生某种瓶颈，主要原因是某种资源达到了极限。此时表现为随着压力的增大，系统性能出现急剧下降。
4、性能测试的系统能力验证: (a)是系统稳定性的一个基本要求，通常表现为系统在要求的平均并发用户下服务器的CPU平均使用率不高于75%，内存的使用率不高于75%。(b)系统在要求的并发用户数达到峰值情况下服务器的CPU平均使用率不高于95%，内存的使用率不高于90%。(c)系统能在高于实际系统运行压力1倍的情况下，稳定的运行72小时。
5、为分清各个不同事物的响应时间请务必在多事物的脚本中添加事物以便区分，请在要用到多个帐户或者多个用户的迭代或者循环操作的时候请务必进行参数化 (很多系统都限制了同一帐户在多长时间的操作，或者防止数据冲突)。
文章来源于领测软件测试网 https://www.ltesting.net/
