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

宗刚是 2013 北京 QCon 测试专题的受邀讲师。在 QCon 开始之前，专题出品人高楼对宗刚就性能测试领域内的许多问题做了深入的访谈。以下是访谈内容：

高楼：能否先简单谈谈您在测试领域的工作经验？和您对此领域的理解？

宗刚：我的工作经验主要分成三个阶段：

第一阶段：民企开发 Leader

毕业后做程序员，负责开发维护 6 个产品。解决过多次关键性能问题，其中有一次系统跑批 2 小时后死机，通过我的优化最后只需要 15 分钟完成，协助业务部门打了一个大胜战。06 年开始在项目组自下而上推一些敏捷实践。因为有开发编程以及敏捷工程的基础，为我后期进行大型系统性能测试、优化、规划以及提出全生命周期敏捷性能管理体系打下了坚实的基础。

第二阶段：创业公司负责人

和几位朋友一起创业，负责公司两个产品的运作，测试、开发、需求、业务、销售、人力各种工作都干过。虽然结果不太理想，但这个阶段磨练我从整体去看一个产品，从开发、测试、产品系统看问题，而不会局限于研发。

第三阶段：惠普非功能技术负责人

到惠普后，作为团队非功能技术负责人，推行敏捷软件开发，推行安全测试，提出性能测试优化建模整体服务整体解决系统上线过程中的技术难题，提出全生命周期敏捷性能与容量管理体系解决系统整个生命周期的性能与容量难题，提出交维服务系统解决从研发到运维的技术、流程等问题。主要为国内金融、电信、政府核心系统进行非功能服务。曾在创金融领域全球最高 TPS（HP 开放平台）的项目担任性能技术专家。惠普是一个很大的平台，各种资源都有，性能测试工具、监控工具、刀片、小机、存储、网络、操作系统以及各种领域专家，最重要的是有很多大型应用系统的客户，非常有利于性能技术成长。

对于测试领域的理解：

A. 从测试领域职业发展来看，将来的测试有两条比较好的出路，一条为业务专家，懂得某业务领域知识如金融、电信、建筑等等有行业壁垒的知识；另一条为测试技术专家，会编程是基础，能够做技术含量比较高的测试。原来主要点击几下鼠标的黑盒测试竞争会越来越激烈，由于知识壁垒有限，大量的高校毕业生轻易进入这个领域，很难出高薪。前几年是测试领域的原始积累期，很多技术能力不强的人能成为领导、经理，将来这种可能性越来越小。

B. 性能测试领域现在还缺少标准，市面上的培训以及书籍多数以工具为主，没有系统解决性能问题关注性能测试为主。

高楼：能否简述企业中性能测试现状？

宗刚：从 09 年的淘宝双十一导致多家银行网银系统宕机，到 12306 购票难，再到前不久聚美优品促销活动刚开始就遭秒杀。根据 Google 的统计，如果网站打开慢每 500 毫秒，用户访问量将下降 20%。根据 Amazon 统计，每慢 100 毫秒，交易额下降 1%。这些事件和统计数据为大家敲响了警钟，企业也会越来越重视性能测试。

企业性能测试常见问题：

A. 缺少整体性能与容量管理策略，常常临时抱佛脚，见过用 20 人年开发的系统上线之后系统性能完全无法满足要求，重新开发

B. UAT 阶段才做测试。为时太晚，很多问题这个阶段无法解决或解决成本非常高

C. 运维与研发缺乏互动。没有形成生产与研发的闭环，测试结果脱离实际，见过通过大量性能测试的系统上线之后就宕机

D. 缺少性能优化和规划。只有性能测试报告，定位不了问题，提出不了建议，对于生产系统的容量和性能缺少规划，不清楚系统的容量，无法支持有效的业务决策。

高楼：能否描述一下性能测试人员的现状？

宗刚：11 和 12 年分别在北京、上海、深圳面试了近 100 位性能测试人员，主要的特点如下：

A. 性能测试人员出身比较复杂，有开发经验的人员能力和潜力都强于其他。由于性能测试项目比较少，所以不同角色的人遇到这种项目，就成为性能测试人员。由于性能测试对人员要求的技术比较高，相对之下有开发经验的人员学习速度要快得多。就拿我自己举例，由于有 4 年的开发经验，通过两个项目的实践就可以灵活掌握性能测试，1 年掌握的东西相当于没有开发经验的 3 年。

B. 多数性能测试人员都以工具为主，缺少系统解决性能问题的能力。见过一个项目的性能测试人员只懂通过 loadrunner 设置场景发起压力，根本不会性能监控和瓶颈定位，测试的数据压倒生产库都不知道。

C. 从面试的整体来看北京的技术能力稍强于其它地区，基本上为北京 > 上海 > 深圳。

D. 很多“资深”性能测试的人员由于停留于几年以前会 loadrunner 就是专家的时代，技能没有提升，陷入“上不去，下不来”的尴尬境地。

E. 多数人员习惯于从测试看问题，缺少整体视角解决性能问题。个人建议从产品经理的角度看问题，因为一个产品其实就是一个小型企业，从这个角度看成本、创新、流程、质量就比较有意义，抓住了本质。

F. 性能测试领域非常缺人才，缺少精通性能测试，同时熟悉各层性能优化的人才。见过好几个企业有若干个 OS、中间件、DB 性能优化专家，但是解决不了性能问题，缺少整体贯通的人员。

高楼：你如何理解性能测试在软件生命周期中的位置？

宗刚：性能测试应该贯穿整个软件的生命周期，从需求到架构到迭代到上线再到运维都和性能测试息息相关。下图为借鉴了敏捷性能工程的思路整理出来的一个全生命周期性能管理图。

主要分成 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 分析与优雅降级