转自：http://www.cnblogs.com/kongzhongqijing/articles/4135060.html
如何理解性能测试在软件生命周期中的位置？
宗刚：性能测试应该贯穿整个软件的生命周期，从需求到架构到迭代到上线再到运维都和性能测试息息相关。下图为借鉴了敏捷性能工程的思路整理出来的一个全生命周期性能管理图。
主要分成4个大阶段：
A. 计划阶段：
编写可测试的性能需求：详细说明可落地可测试的需求，而不是笼统的写着一天支持1.5亿的交易，支持1亿的用户。
性能测试策略：需要提前考虑怎么进行性能测试，用什么工具？需要哪些培训等等 在产品代办列表里增加性能活动：由于性能测试一般实施周期比较长，建议单独成为一个列表项。
B. 架构评估：
在系统架构阶段，在实现部分关键功能的情况下评估系统性能、容量、安全、可扩展性、稳定性等等是否满足系统设计的需要，我们常常缺少这个阶段的实践，等系统开发结束才进行，常常为时已晚。在系统规划时常常在缺少实际测试数据的时候拍脑袋规划硬件，出现“大马拉小车”的局面，架构评估的另一个作用是通过架构阶段的评估为规划提供数据支持。
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%等等，所以在测试之前需要清楚这些约束。除了上面的通用指标，各个应用系统会依据技术特点有一些特殊的指标。更全面的指标应该是分层的，从终端用户的体验—>业务流程—>中间件数据库的响应—>基础架构的利用。
如何进行性能测试建模？在性能测试过程中要建立哪些模型？
宗刚：性能测试过程需要考虑的模型有：业务模型、测试模型、用户模型TPS模型、数据模型、失效模型、性能模型
业务模型：依据应用系统特点分析出来的不同的业务场景和业务配比。性能测试常常会通过历史数据分析业务的重要性、交易频率、易耗资源的交易以及未来的发展趋势，最后确定一种业务配比。依据这个业务配比设计测试场景。这往往是不够的，一个线上系统往往有多个业务模型，需要考虑时间驱动的如：白天、晚上、月末、过年过节，事件驱动的如：本拉登去世黄金业务突发变化、业务部门促销等，第三方驱动：永远不要相信第三方的内容，所以需要考虑第三方接口的业务突变，延时等等。
测试模型：如何将业务模型的内容转化为可以测试的内容，就是测试建模需要解决的问题。通过业务建模分析出来的业务需要过滤，剔除一些不易执行的、相互包含的等等业务。最后落地为各种可执行的业务配比，业务配比完成后，需要考虑的是如何和测试工具映射起来，这个就牵涉到用户模型和TPS模型。用户模型是指按照业务配比设置发起压力的用户比例，这种方法存在一定的局限性，因为不同的交易响应时间是不同的，长交易完成1笔交易，短交易可能是5笔，特别是在较大压力时，测试结果的业务配比会和真实的业务配比差距很大。所以一般情况下需要考虑TPS模型，这个是和业务模型相同的配比，这个模型的一个劣势就是需要不断调整并发用户数。
数据模型：一个系统的大多数性能问题是数据库问题，所以垫底数据或参数化数据是否和实际相符将直接影响性能测试的有效性。一般建议性能测试使用清洗后的生产数据，参数化数据尽量采集生产系统一天的交易数据。以前见过一个项目，说有的数据都是通过loadrunner压进去的，所有数据都集中在一块，测试结果和实际生产差距巨大，整个测试无效。
失效模型：主要是总结了大量以往生产系统经常出错的模式，在设计测试案例的时候需要着重考虑。这部分要依据实际情况来定，如果能够从运维部门获得更多的事故数据就更有价值。
性能模型：不同的交易对系统的性能要求是不同的，依据测试的数据以及生产环境的数据建立模型，主要解决以下问题：测试环境中测试的数据如何映射到生产环境？生产环境中出现性能问题应该如何预测预防和优雅降级？生产环境应该如何扩容等等。
这次QCon测试专题中，您的专题讲座会给听众带来哪些收获？
宗刚：这次演讲我会分享如何进行大型交易系统性能测试与分析，并讨论有哪些需要注意的地方。在内容中我会以一个大型案例为主线，并通过多个成功与失败案例为辅系统解决性能问题。 这里面大家将会了解到：
A. 风险驱动的性能测试与分析计划
B. 历史数据与未来业务并重的业务模型分析
C. 注重实效的场景设计
D. 符合实际的测试数据
E. 被测系统和压力系统并重的性能监控
F. 快速的性能瓶颈定位
G. What-IF分析与优雅降级