相信本文会对处于下面两种状态的测试工程师朋友会有所启发和帮助：
1. 正要但还没开始做性能测试的朋友，除了loadrunner，不知道从哪里下手？
2. 已经开始做性能测试，正在被一堆问题困扰得焦头烂额的朋友。
听说过有的工程师运行几轮性能测试，就能迅速定位性能bug；更多地是听到某工程师运行N多次，就是不能复现问题，甚至整个研发部门开发人员测试人员齐上阵，都无法找到性能问题所在。这是为什么呢？是运气不好么？还是技术能力不强？
说说我看过的一个真实的案例：某大型外企的产品上线后，当用户数超过某个值的时候，在线的软件系统就会重启。这是一个严重的bug，但非常糟糕的是，在测试环境里，测试人员无论如何，都复现不出这个bug，研发部门的老总调用了精兵强将，包括众多开发骨干，苦苦搜索一个多月，也都无终而归，最后的结果是企业最终失去了这个大客户。其实这样一个大型系统，面对这种问题，别说开发人员，就是比尔盖茨来了，也无济于事。
显然这不是技术能力范畴内能解决的困境，怎样使得性能诊断变得更加容易和方便？这其实是一个软件开发要考虑的可测试性问题。
对于性能测试来说，有必要在软件设计开发阶段遵守规范，建立一整套性能度量体系。体系包括：
1. 性能诊断日志
2. 在应用系统层次上建立性能度量
3. 数据库系统性能度量
性能诊断log包括一系列log等级设置和log格式，使得性能问题能够在log层次上被捕捉到，比如下面是一个SMPP协议网关实现的log：
TimeStatistic -------- Statistic name : EnquireLength Description : Time taken for a round trip ENQUIRE_LINK PDU. Measurement unit : MILLISECOND Measurement start time : 1224214074885 Last measurement time : 1224219511193 # times the operation was invoked : 3 max time : 19 min time : 12 total time : 46 |
在性能诊断模式开启后，软件程序就会每隔10秒钟打印如上信息，从以上信息可以很清楚地看到SMPP网管处理多少个PDU，每个PDU花了多长时间。这样会第一时间内捕获网管的性能处理效率。
在应用层次上的度量多种多样，根据应用的不同，也有不同的度量方法。比如我们最常见的web 处理能力一般用每秒请求数（requests/second),每秒吞吐量（throughoutputs/second)。其实针对每一个应用，开发人员都应该建立相应的度量。
比如一个email 的IMAP server，我们为其建立如下度量：
APPEND Average Time (milliseconds)
APPEND Failure Rate (Failures/minute)
APPEND Rate (Requests/minute)
AUTHENTICATE Average Time (milliseconds)
AUTHENTICATE Failure Rate (Failures/minute)
……
等等。
一般地，度量要分为度量名，采集频率，预警值设置，预警信息等等。
开发人员则遵循规范，在开发过程中实现以上度量信息的采集。
在建立一个完善的性能度量体系后，性能的诊断和定位就变得更加容易，也完成了定性分析到定量分析的转变。
（有兴趣的朋友可以参看oracle的AWR报告，这是一个典型的基于度量的report）
版权声明：原创作品，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。本文出自sunshinelius的51Testing软件测试博客：http://www.51testing.com/?2382
sunshinelius的书籍：《性能测试从零开始——LoadRunner入门》
