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

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

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

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

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

　　问题：如何进行性能测试建模？在性能测试过程中要建立哪些模型？

　　宗刚：性能测试过程需要考虑的模型有：业务模型、测试模型、用户模型TPS模型、数据模型、失效模型、性能模型

　　业务模型：依据应用系统特点分析出来的不同的业务场景和业务配比。性能测试常常会通过历史数据分析业务的重要性、交易频率、易耗资源的交易以及未来的发展趋势，后确定一种业务配比。依据这个业务配比设计测试场景。这往往是不够的，一个线上系统往往有多个业务模型，需要考虑时间驱动的如：白天、晚上、月末、过年过节，事件驱动的如：本拉登去世黄金业务突发变化、业务部门促销等，第三方驱动：永远不要相信第三方的内容，所以需要考虑第三方接口的业务突变，延时等等。

　　测试模型：如何将业务模型的内容转化为可以测试的内容，是测试建模需要解决的问题。通过业务建模分析出来的业务需要过滤，剔除一些不易执行的、相互包含的等等业务。后落地为各种可执行的业务配比，业务配比完成后，需要考虑的是如何和测试工具映射起来，这个牵涉到用户模型和TPS模型。用户模型是指按照业务配比设置发起压力的用户比例，这种方法存在一定的局限性，因为不同的交易响应时间是不同的，长交易完成1笔交易，短交易可能是5笔，特别是在较大压力时，测试结果的业务配比会和真实的业务配比差距很大。所以一般情况下需要考虑TPS模型，这个是和业务模型相同的配比，这个模型的一个劣势是需要不断调整并发用户数。

　　数据模型：一个系统的大多数性能问题是数据库问题，所以垫底数据或参数化数据是否和实际相符将直接影响性能测试的有效性。一般建议性能测试使用清洗后的生产数据，参数化数据尽量采集生产系统的交易数据。以前见过一个项目，说有的数据都是通过loadrunner压进去的，所有数据都集中在一块，测试结果和实际生产差距巨大，整个测试无效。

　　失效模型：主要是总结了大量以往生产系统经常出错的模式，在设计测试案例的时候需要着重考虑。这部分要依据实际情况来定，如果能够从运维部门获得更多的事故数据更有价值。

　　性能模型：不同的交易对系统的性能要求是不同的，依据测试的数据以及生产环境的数据建立模型，主要解决以下问题：测试环境中测试的数据如何映射到生产环境？生产环境中出现性能问题应该如何预测预防和优雅降级？生产环境应该如何扩容等等。