整体性能测试剖析
【摘要】性能测试不只是测试人员的事情，只有通过不同阶段不同参与人的通力合作才能把性能测试做好。
【关键词】性能测试性能优化 DBA
随着项目越来越大，性能问题层出不穷。如何做好性能测试成为测试人员经常讨论的话题。很多时候，大家都在疑惑性能测试如何来做，性能标准从那里来，有没有通用的标准，性能测试由谁来做，如何规划。首先我们了解一下，什么是性能测试。性能测试的目的：通过性能测试了解系统的性能有没有满足需求，对于不满足需求的模块则通过测试发现可能的性能瓶颈，并进行相应的性能调优，从而达到最终用户的要求。由于项目巨大，所以性能测试不仅仅是测试人员的事情，可能需要整个项目组的参与，而测试人员则更需要清晰的了解到性能测试分几个阶段，每个阶段如何来做，需要协调那些资源？
在性能测试的每一个阶段，性能测试的参与人是不一样的，下面的图就是不同阶段的人员参与表。
性能测试人员图
从上图中可以看出，其实性能测试不是一个人可以搞定的事情，在需求阶段，制定性能初步的标准则需要需求人员的协助，了解那些场景是重要的，大约有多少人用，有多大数据量；而在设计场景时不仅要从需求中设计出必需要测试的场景，有时候需要通过功能测试人员了解，他们在测试过程中那些场景运行的比较慢。而运行脚本时，则需要SA（System Administrator系统管理员，编者注）,程序员帮你增加分析所需要的性能指标，而DBA（DataBase Administrator数据库管理员，编者注）则增加数据库监控的参数。在分析结果的阶段则需要三者相互灵活的配合，当发现性能问题时，可能会根据程序员或DBA的要求，不断的调整监控的参数，以便更精确的定位问题。而在优化阶段，则是找出性能的瓶颈并优化，更需要多方的配合，不仅仅是测试。
在性能测试前期，也就是上图的前三个阶段，重点需要了解，系统有那一些重要的功能模块，大约的用户是多少，用户的行为是如何分布的，每个模块的使用频度，大约的数据量，使用什么样的硬件，系统稳定性的要求等等。当然需求人员不是专业的测试人员，这时专业性能测试人员就是跟据需求人员大致的描述或是文档，提取出这些重要信息，建立系统模型。下面的一份表就是某个大型系统邮件模块的数据模型：
|
序号 |
分类 |
项目 |
数据 |
单位 |
|
1 |
统计数据及经验数据 |
A:总用户数 |
5,000,000 |
个 |
|
2 |
B:激活用户比例，每天访问用户数点总用户数的比例 |
60% |
||
|
3 |
C:每个激活用户邮件数 |
50 |
封 |
|
|
4 |
D:每个用户每天收到信数 |
8 |
封 |
|
|
5 |
E:每个用户每天发送信数 |
6 |
封 |
|
|
6 |
F:系统高峰时间(小时) |
4 |
小时 |
|
|
7 |
G:高峰时间内收发的邮件数占一天总邮件数 |
50% |
||
|
8 |
H:每个用户每天收发件次数 |
6 |
次 |
|
|
9 |
J:每封邮件大小平均为(K) |
30 |
Kbyte |
|
|
10 |
K1:据统计，使用WEBMAIL的用户数百分比： |
70% |
||
|
11 |
K2:使用邮件客户端软件的用户数百分比： |
28% |
||
|
12 |
K3:使用IMAP用户数百分比： |
2% |
||
|
13 |
L:平均每通过web访问一封信，大约要访问页面数为: |
4 |
个 |
|
|
14 |
M:假定每个页面大小约为 |
30 |
Kbyte |
|
|
15 |
N:通过本系统向外转送百分比 |
75% |
||
|
16 |
O:发送给本系统的邮件百比分 |
25% |
||
|
17 |
Q:系统峰值时CPU利用率 |
60% |
||
|
18 |
||||
|
19 |
处理能力计算 |
POP的处理能力=A*K2*B*D*G/(F*3600) |
52.78 |
封/秒 |
|
20 |
POP流出系统量＝（POP的处理能力*J) |
1.58 |
Mbyte/s |
|
|
21 |
HTTP的收信件处理能力=A*K1*B*D*G/(F*3600) |
83 |
封/秒 |
|
|
22 |
HTTP的发信件处理能力=A*K1*B*D*G/(F*3600) |
62.5 |
封/秒 |
|
|
23 |
HTTP流出系统量（平均页面大小*页面数* HTTP处理能力) |
9.96 |
Mbyte/s |
|
|
24 |
HTTP流入系统量（HTTP发信数*J) |
1.88 |
Mbyte/s |
|
|
25 |
SMTPIN(从其它系统收到邮件）=A*K2*B*D*G/(F*3600) |
52.78 |
封/秒 |
|
|
26 |
SMTPCLIENT(客户端发送系统)=A*B*E*G/(F*3600) |
104.17 |
封/秒 |
|
|
27 |
SMTPOUT(发送到其它系统）=A*B*E*G*N/(F*3600) |
78 |
封/秒 |
|
|
28 |
SMTP平均发信（SMTPIN+SMTPCLIENT+SMTPOUT) |
134 |
封/秒 |
|
|
29 |
SMTP流入量=(SMTPIN+SMTPCLIENT)*J |
4.68 |
Mbyte/s |
|
|
30 |
SMTP流出量=(SMTPOUT*J) |
2.03 |
Mbyte/s |
|
|
31 |
高峰时期邮件平均流入量 |
6.56 |
Mbyte/s |
|
|
32 |
高峰时期邮件平均流出量 |
13.57 |
Mbyte/s |
|
|
33 |
高峰时期邮件平均总流量 |
20.13 |
Mbyte/s |
|
|
34 |
系统带宽要求（流量×8(含协议数据)) |
160 |
Mbit/s |
|
|
35 |
|
|
|
|
|
36 |
并发数计算 |
POP高峰并发数目=A*K2 * B*H*G/(F*3600) 次/秒 |
39.58 |
次/秒 |
|
37 |
SMTP高峰并发数目=A*B*(D+E)*G/(F*3600) 次/秒 |
183.06 |
次/秒 |
|
|
38 |
HTTP高峰并发数目=A*B* (D+E)*K*L*G*O/(F*3600)次/秒 |
145 |
次/秒 |
|
|
39 |
IMAP高峰并发数目=A*D*K3*B*I*G/(F*3600)次/秒 |
0.35 |
次/秒 |
|
某模块数据模型图
上表中可以分析出此邮件系统中最主要的应用是webmail,smtp,pop，其中webmail方式大约为活跃用户的70%,而其它方式则占30%,同时它还给出了平时的参数指标，与峰值的时间与指标。这样你后面的场景设计则重点会很清楚，三种方式是测试的重点，用户的分布也很清晰。从上表中还可以看出，此场景的需求人员做了大量的细致的性能分析工作，在国内这样专业的需求人员不是很多，有时候只能靠性能测试人员不断的沟通来获得必要的性能信息，同时在这个阶段也最好与有经验的架构师多沟通，了解系统可能存在的性能瓶颈，以便使自己设计的场景更有针对性。
场景设计完成之后就进入了脚本的编写，在这个阶段，主要是性能测试人员的程序能力。在这一方面，测试工具是比较多的，我所熟知的就有ACT，WAS，LoadRunner等工具。从原理看，其实都是一样的，不过如果是测试复合协议的应用，LoadRunner 则是首选，特别是在几个协议同时使用的应用，比如类似于QQ这样的应用可能会用到多个协议来进行录制。其实在录制脚本的第三个阶段也是需要跟程序员配合的，比如在录制web应用程序中，对session,cookie的处理，对业务上一些请求的处理,这些都需要程序员协助，同时他们也能够帮你确认某一阶段，用什么样的技术，选什么样的协议，从而帮助你更好的编写模拟应用场景的脚本，在这里测试人员经常会认为只要掌握了工具就行了，其实在这里需要很好的编程功底,希望大家多多关注这些脚本的编程，而不是用一两个工具。
脚本的运行与监控，还有分析结果也是重中之重，在运行时，可能会跟据不同的应用选择监控的参数，比如在程序运行中，是否有大量的IO读写，网络交互，或是线程切换，在数据库，是不是有大量的逻辑读写的操作，或是执行频度特别高的SQL执行，这些有可能你是了解的，但是如果身边有DBA的专家，与架构师，他们会更了解应用程序的性能瓶颈，会需要一些有效的监控指标，这时你在选择性能监控指标时，要多听他们的意见。特别是发现性能问题时，可能需要程序员与DBA参与进来时，再次运行场景时，更需要增加一些他们认为可能出问题的监控指标。当然作为测试人员也要了解，这些指标的异常，可能是由于应用程序那一方面不合理的，为研发提出合理的意见。
发现问题后就是tuning ,这也是性能测试最终的目的，发现性能问题，并进行解决。前面的几个阶段，可能是只定性的发现问题，而如可精准的发现问题，则需要扎实的编程功底。对于代码的tuning有如下原则，发现占用时间最长的函数，而不是优化性能不合理的函数。在对代码的tuning中，你可以借助代码分析工具，下面就是IBM-Quantify执行后的图：
Purify的分析图
可能大家使用这个工具时会觉的晕，其实我第一次用时也晕的N次，其实用多了很简单的，工具都是相通的，在这里只要把握程序的脉络，就好像庖丁解牛，最主要是关注程序占用时间最长的函数和调用次数最多的函数，只有对这样的函数进行优化才能事半功倍，而一些程序员往往喜欢优化算法不合理的函数，费了九牛二虎之力，却发现效果并不是很好。在这一阶段经常会碰到以下一些情况：
- 程序调用数据库接口函数时发现时间过长；
- 初始化一些事务的次数过多；
- 某一些函数调用次数过多；
- 有一些不应当出现的异常函数出现。
对于上面的第一种情况，一般是数据库可能是某一些SQL的效率不高，你可以与有经验的DBA把这段应用的SQL取出来，进行分析，确认一下是不是数据库的问题。其实在优化的过程中，数据库的优化是最简单的，不需要修改任何程序，而且效果往往是最好的。第二种情况，一般最大的可能是程序员把事务写在了循环的里面，造成了N多次的重复对事务的构建，众所周知分布式事务的构建是最消耗性能的，所以一般不要放在循环的里面。对于第三种情况可能性就更多了，调用次数多不代表错误，但如果性能因此大受影响，则是不被提倡的。第四种情况，就可能是一些什么不合理的异常出现所导致的，可能就是缺陷。在这个阶段由于要阅读成千上万的代码，即使你的能力超强，也是不可能完全了解了，所以当发现可疑的代码时，应与当事人一起去剖析这段代码，要耐心的分析每一种可能。有时候，这个活比技术还难做，如何在不伤到别人情感的情况下给别人指出错误，这可是测试人员最大的挑战，从技术上，到人的心理都要有所把握。虽然这一阶段难度比较高，但看到产品经过自己的努力，越来越快时，你会感到无限的成就感。
最后只想再说一下，性能测试是一个团队的事情，不是某一种角色可以完全承担的，测试人员在每一个阶段要善于借用团队的力量，协调着做，同时也要不断提升自己的技术，只有不断的努力，帮助研发成功，才能得到在大家的尊重。
转载：http://www.51testing.com/html/13/n-8713.html
