某模块数据模型图

上表中可以分析出此邮件系统中主要的应用是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多次的重复对事务的构建，众所周知分布式事务的构建是消耗性能的，所以一般不要放在循环的里面。对于第三种情况可能性更多了，调用次数多不代表错误，但如果性能因此大受影响，则是不被提倡的。第四种情况，可能是一些什么不合理的异常出现所导致的，可能是缺陷。在这个阶段由于要阅读成千上万的代码，即使你的能力超强，也是不可能完全了解了，所以当发现可疑的代码时，应与当事人一起去剖析这段代码，要耐心的分析每一种可能。有时候，这个活比技术还难做，如何在不伤到别人情感的情况下给别人指出错误，这可是测试人员大的挑战，从技术上，到人的心理都要有所把握。虽然这一阶段难度比较高，但看到产品经过自己的努力，越来越快时，你会感到无限的成感。
后只想再说一下，性能测试是一个团队的事情，不是某一种角色可以完全承担的，测试人员在每一个阶段要善于借用团队的力量，协调着做，同时也要不断提升自己的技术，只有不断的努力，帮助研发成功，才能得到在大家的尊重。