【摘要】性能测试不只是测试人员的事情，只有通过不同阶段不同参与人的通力合作才能把性能测试做好。

【关键词】性能测试性能优化 DBA

随着项目越来越大，性能问题层出不穷。如何做好性能测试成为测试人员经常讨论的话题。很多时候，大家都在疑惑性能测试如何来做，性能标准从那里来，有没有通用的标准，性能测试由谁来做，如何规划。首先我们了解一下，什么是性能测试。性能测试的目的：通过性能测试了解系统的性能有没有满足需求，对于不满足需求的模块则通过测试发现可能的性能瓶颈，并进行相应的性能调优，从而达到最终用户的要求。由于项目巨大，所以性能测试不仅仅是测试人员的事情，可能需要整个项目组的参与，而测试人员则更需要清晰的了解到性能测试分几个阶段，每个阶段如何来做，需要协调那些资源？

在性能测试的每一个阶段，性能测试的参与人是不一样的，下面的图就是不同阶段的人员参与表。

性能测试人员图

从上图中可以看出，其实性能测试不是一个人可以搞定的事情，在需求阶段，制定性能初步的标准则需要需求人员的协助，了解那些场景是重要的，大约有多少人用，有多大数据量；而在设计场景时不仅要从需求中设计出必需要测试的场景，有时候需要通过功能测试人员了解，他们在测试过程中那些场景运行的比较慢。而运行脚本时，则需要SA（System Administrator系统管理员，编者注）,程序员帮你增加分析所需要的性能指标，而DBA（DataBase Administrator数据库管理员，编者注）则增加数据库监控的参数。在分析结果的阶段则需要三者相互灵活的配合，当发现性能问题时，可能会根据程序员或DBA的要求，不断的调整监控的参数，以便更精确的定位问题。而在优化阶段，则是找出性能的瓶颈并优化，更需要多方的配合，不仅仅是测试。

在性能测试前期，也就是上图的前三个阶段，重点需要了解，系统有那一些重要的功能模块，大约的用户是多少，用户的行为是如何分布的，每个模块的使用频度，大约的数据量，使用什么样的硬件，系统稳定性的要求等等。当然需求人员不是专业的测试人员，这时专业性能测试人员就是跟据需求人员大致的描述或是文档，提取出这些重要信息，建立系统模型。下面的一份表就是某个大型系统邮件模块的数据模型：

某模块数据模型图

上表中可以分析出此邮件系统中最主要的应用是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软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。