性能测试面面观——HP性能测试专家宗刚访谈(2)

　　C、迭代阶段：

　　系统不断的增加新特性、新需求，需要迭代验证系统的性能与容量

　　D、运维阶段：

　　研发人员常常觉得系统交给运维就可以了，由于运维人员对应用本身不够清楚，所以常常是盲人摸象，抓不住根本。见过业务高峰期，运维人员就看着CPU在往上涨，不知道应该怎么办，不清楚系统的容量点会在哪里出现，系统宕掉一台服务器会怎么样?多长时间能够恢复?到底能够支持多少的业务量?什么业务比较消耗时间?怎么优雅降级?在研发环境中，获得这些数据和手段都是比较容易的，运维人员是研发的第一个客户，应该多为他们考虑。

　　上面介绍了整个生命周期性能的管理，从广度角度讲。那么从深度角度讲，性能管理应该包括：性能测试、性能优化和性能建模容量规划。

　　性能测试：验证系统性能是否满足需求。

　　性能优化：优化性能瓶颈，提升系统处理能力，测试和优化会有若干次的迭代。性能建模容量规划：生产环境可能出现各种场景，应该怎么预测与预防。

　　如果比喻整个过程为病人看病，那么性能测试就是体检，性能优化就是对病下药，性能建模容量规划就是保健。

　　由于系统总在变化，新业务、扩容、软硬件版本升级等等，所以需要不断的迭代，如下图：

　　问题：你如何判断性能测试在项目或产品中的实际价值?

　　宗刚：实际价值：

　　A、业务部门：支持业务决策和促销，提高客户满意度

　　B、运维部门：清楚系统容量，提升系统可用性、稳定定，降低硬件采购成本，提前预测预防提高响应速度，睡觉可以安心

　　C、规划部门：有理有据进行规划

　　D、研发部门：减少运维部门给研发部门的压力

　　问题：你觉得高级性能测试专家需要什么样的个人能力和素质?

　　宗刚：高级性能测试专家需要的能力模型，如下图所示，成为博学的专家。

　　精通于性能测试分析建模，熟悉系统各层的监控与优化。同时需要较强的沟通能力，为了实施好项目需要有过程领域的知识如敏捷、CMMI等。性能测试技术发展路线参考如下：

　　成为一个高级性能测试人员需要掌握的东西非常多，如何学习这些知识。通过多年的实践归纳，我的一点学习方法和大家分享：

　　成长=3本书+领域专家+实验+实战+持续提升。

　　3本书：1本基础书籍+1本全面的理论书籍+1本实战书籍。所有的书一定要经典书籍，我们常常开始学习知识的时候通过论坛的方法，这种方法入门比较容易，但是很难系统，也会占据非常多的时间。为什么要经典书?读书的最大成本不是买书的钱，而是读书的时间，所以看书一定要看最经典的书，怎么找经典书?可以到豆瓣、专业论坛、当当上看看评论。每个领域有每个领域的书籍，学习Oracle优化有oracle的书籍，学习loadrunner有loadrunner的书籍，千万不要以为做性能测试就学3本性能测试的书籍就够了。

　　领域专家：成长过程中如果有领域专家的支持，就会少走不少弯路。当我开始学习Oracle性能调优的时候，刚好认识一位Oracle调优同事，和他沟通请他推荐一些资料，讲讲实操的技巧。这里需要注意的一点是不要所有毛皮小事都去找专家，人家也有自己的工作。一些问题可以通过google搜索、或专业论坛就可以解决。前段时间有项目需要用informix数据库，就请一位informix专家给我指导，大多数技术小问题在技术论坛上都有。如果大家不认识专家，那也没有关系，通过微博、论坛认识他们，大多数人还是愿意帮忙的。

　　实验：性能项目不是那么多，所以自己要找一些实验的内容。技术书籍一般都会有一些实战的内容，如果不去实际操作一遍往往过一段时间就忘了。当我学习Tuxedo调优的时候，在自己的虚拟机上搭建Tuxedo环境，使用修改后的Demo应用进行压力测试，设计不同的压力场景，测试过程不断去调优应用，这个学习过程成长会很快。我的好多同事为了学习好hp-ux，自己购买退役的小机搭环境，进行实验调优。很多时候不是技术难，而是没有机会接触这样的环境。有过实验的经历，在就职面试的时候也算是经验啊。

　　实战：通过实验之后，基本有经验了，如果再通过几个实战项目，不断总结归纳，基本就成为一个中级的性能测试人员了。以战养战，没有一个人开始就会所有的东西，每个项目都会用一些新的技术，所以在不同的项目中需要有很强的学习能力，能够快速学习新的技术并用于实战。

　　持续提升：想成为高级性能测试人员或专家，就需要不断更新学习新的知识和技术。通过论坛、活动、微博、读书等方式不断提升，也要常常和大家一起分享，分享是非常好的学习手段，还可以提高自己的知名度。

　　问题：如何从业务目标分析得到性能测试需求、性能指标?

　　宗刚：常见的业务需求如下：日交易量支持1.4亿，响应时间小于2秒，支持用户2亿。我们需要把这些指标转化为可以测试的指标和场景。通过分析历史交易的波峰波谷，把1.4亿的交易量折换为每秒钟的交易量;响应时间也可以分类，比如本地业务多长时间，跨省业务多长时间，跨行业务多长时间等等;我们常常把支持多少用户作为衡量指标，这是一个误区，大量用户导致产生大量的业务才会消耗系统的利用率，所以关键是业务量。这里有个例外，如果要验证支持多少在线用户，以及长连接的系统就需要考虑支持的用户数量更精确的说法应该是支持的Session。从业务需求到性能测试需要一般要经历这些过程：评估性能风险、确定关键用例、选择关键性能场景、建立可测试性能目标。

　　性能指标一般会有：交易响应时间、交易成功率、资源利用率、每秒钟的交易量(TPS)。这几个指标是相互约束的，如果低成功率下的TPS是没有意义的。多数运维部门对资源利用率都会有一些硬规定，比如CPU不能高于85%，内存不能高于90%等等，所以在测试之前需要清楚这些约束。除了上面的通用指标，各个应用系统会依据技术特点有一些特殊的指标。更全面的指标应该是分层的，从终端用户的体验—>业务流程—>中间件数据库的响应—>基础架构的利用。

原文转自：http://www.blogjava.net/qileilove/archive/2013/04/16/397896.html