性能测试--好文章多学学
【关键词】性能测试性能优化 DBA
随着项目越来越大，性能问题层出不穷。如何做好性能测试成为测试人员经常讨论的话题。很多时候，大家都在疑惑性能测试如何来做，性能标准从那里来，有没有通用的标准，性能测试由谁来做，如何规划。首先我们了解一下，什么是性能测试。性能测试的目的：通过性能测试了解系统的性能有没有满足需求，对于不满足需求的模块则通过测试发现可能的性能瓶颈，并进行相应的性能调优，从而达到最终用户的要求。由于项目巨大，所以性能测试不仅仅是测试人员的事情，可能需要整个项目组的参与，而测试人员则更需要清晰的了解到性能测试分几个阶段，每个阶段如何来做，需要协调那些资源？
在性能测试的每一个阶段，性能测试的参与人是不一样的，下面的图就是不同阶段的人员参与表。
性能测试人员图
从上图中可以看出，其实性能测试不是一个人可以搞定的事情，在需求阶段，制定性能初步的标准则需要需求人员的协助，了解那些场景是重要的，大约有多少人用，有多大数据量；而在设计场景时不仅要从需求中设计出必需要测试的场景，有时候需要通过功能测试人员了解，他们在测试过程中那些场景运行的比较慢。而运行脚本时，则需要SA（System Administrator系统管理员，编者注）,程序员帮你增加分析所需要的性能指标，而DBA（DataBaseAdministrator数据库管理员，编者注）则增加数据库监控的参数。在分析结果的阶段则需要三者相互灵活的配合，当发现性能问题时，可能会根据程序员或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多次的重复对事务的构建，众所周知分布式事务的构建是最消耗性能的，所以一般不要放在循环的里面。对于第三种情况可能性就更多了，调用次数多不代表错误，但如果性能因此大受影响，则是不被提倡的。第四种情况，就可能是一些什么不合理的异常出现所导致的，可能就是缺陷。在这个阶段由于要阅读成千上万的代码，即使你的能力超强，也是不可能完全了解了，所以当发现可疑的代码时，应与当事人一起去剖析这段代码，要耐心的分析每一种可能。有时候，这个活比技术还难做，如何在不伤到别人情感的情况下给别人指出错误，这可是测试人员最大的挑战，从技术上，到人的心理都要有所把握。虽然这一阶段难度比较高，但看到产品经过自己的努力，越来越快时，你会感到无限的成就感。
最后只想再说一下，性能测试是一个团队的事情，不是某一种角色可以完全承担的，测试人员在每一个阶段要善于借用团队的力量，协调着做，同时也要不断提升自己的技术，只有不断的努力，帮助研发成功，才能得到在大家的尊重。
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
TAG:
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | ||||||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
| 26 | 27 | 28 | 29 | 30 | 31 | ||||
数据统计
- 访问量: 6281
- 日志数: 12
- 建立时间: 2007-11-20
- 更新时间: 2007-12-20
