中国应用性能管理行业盛宴——2016中国应用性能管理大会(简称APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召开。APMCon由听云、极客邦和InfoQ联合主办的作为国内APM领域最具影响力的技术大会，首次举办的APMCon以“驱动应用架构优化与创新”为主题，致力于推动APM在国内的成长与发展。
中国民生银行信息科技部，高级质量管理经理 陈绍英于服务器端应用监控实践专场发表了题为《银行后台服务智能一体化测试》的演讲，现场解读了另一个视角下探讨如何从开发阶段开始测试与监控银行各个后台服务的性能。
以下为演讲实录：
感谢大家来听我的演讲，在正式开始之前我先给大家热热身，什么样的系统叫一个性能比较好的系统?大家可以聊一聊，就是说怎么评价一个系统?一般情况下评价银行系统性能的好坏是四个方面，评价一般系统，也就是普通系统三个方面就够了。
1、第一个方面是交易的响应时间，也就是你这个系统，无论是完成前台的联机作业还是后台的批量作业响应速度要够快。如果你做一笔交易，比如银行的柜员给客户做存款交易，响应时间是3秒钟，这个是不可以的，所以响应时间是衡量一个系统好坏的标准。
2、第二个方面是业务吞吐量，或者也可以叫处理能力，也可以叫TPS，就是单位时间系统能处理的交易量。这个是很重要的一个指标，第一个是看这个系统运行够不够快。第二个是指在一定时间内，能完成的交易量是不是够，因为任何一个系统必须要支撑一个企业或者一个组织，或者一个互联网公司，它每秒每分钟每天，甚至每个月每年的业务量，任何一个系统它每天至少都要完成一定的业务量，比如有的是一百万笔，像我们行的系统一天都能达到上亿笔的交易量，这个是硬指标。所以在响应时间之后，我们评价一个系统就是看它的业务处理能力。
3、第三个方面是稳定性，就是这个系统是不是足够稳定，足够健壮。这个怎么来评价?就是说你这个系统能不能持续的以这种响应速度，以这种业务处理能力来工作。比如你可以每一百毫秒完成一个事务，每一小时处理一百万笔交易量，那你一天能不能处理八百万笔的交易量?如果一天能完成，一周这个系统能不能持续运行?一周能持续运行，一个月能不能持续运行?所以说评估一个系统的性能是一步一步来看的。
4、第四个方面是银行的系统，尤其是核心系统要求的，就是资源的利用率，也就是说我们任何一个系统的几大资源，也就是CPU、内存、IO这三大资源的利用率必须是合理的。
基本上符合这四大指标的性能都过关了，我们就认为这个系统是满足性能要求的，是性能表现比较好的系统，基本上就可以投产了。
为什么银行系统对资源利用率有特别高的要求?银行基本上大部分系统会用小型机，像四大行基本上会用大型机，但是对资源利用率有非常严格的监控要求。银行的应用系统通常会要求它的资源利用率在30%以内，就是说CPU多数情况下会让它跑到30%左右，一旦跑到 50%就会引起关注，尤其是当CPU利用率或者内存的利用率达到百分之七八十的时候，这个系统性能的监控消息差不多就会发到部门的副总，基本上都有实时短信提醒，目的是什么?就是为了保证系统稳定的运行。
民生银行是从2007年开始做新核心系统，这么多年一直都是按照这个原则来评估每一个系统的性能。然后一个一个系统不断地做测试，尤其是当年做新核心的时候，测试的量非常大，后来新核心上线之后，我们整个团队不断地反知以前的做法，就是想有没有更好的方法，我们能更好的控制这个性能。
大家经常说我们做测试，或者是做性能测试，从设计阶段开始介入，或者是从需求阶段开始介入，按照微模型来开发系统，这种说法见到很多，在课堂上或者是培训班上都这么说。但是，实际当中包括功能测试，从开发阶段介入的很少，性能测试往往介入的就更晚，基本上都是在产品开发差不多了，功能、UAT测试都完成了再做性能测试。如果这个系统比较重要的话，最理想的想法就是性能和UAT并行做，发现问题赶紧解决，但是都没有一个有效的方法真正做到从开发阶段就来管控系统的性能。
今天分享的主题就是我们自己总结之前的经验，然后开发了一个平台，实现对所有后台系统功能、性能从设计阶段开始进行监控。后台系统的任何一个服务和接口，只要代码可以封版了，功能实现了，你只需把它发布到单元测试或者UAT测试环境，不管是什么环境只需要发布到这个环境就可以进行测试，而且测试执行时间可以忽略不计。
下面这个就是前面介绍的那些经验，我们当时的团队加上我们合作公司的团队，光性能测试人员就有30人以上的规模，加上调优人员和开发团队，差不多每个系统都会有1-2个调优人员，所以我们性能测试规模肯定是百人以上的。现在我具体负责的工作是性能测试、移动APP自动化测试、接口自动化测试以及当前平台的设计、开发、推广。
我个人以前也出版过一些图书，我是2009年加入民生银行的，加入民生银行之前差不多保持一年一本的写作速度，这些书现在基本上都买不到了，不过大家不要失望，因为接下来打算再写五本，把以前所有的经验都总结出来。这五本书基本上就是把性能测试相关的主题都写透了，一个是LoadRunner的基本使用，还有基本性能测试的理论，新核心的基本测试就是靠着这本书的理论来完成的。《LoadRunner虚拟用户开发指南》它的升级版就是《LoadRunner虚拟用户高级开发指南》，相当于把我们四五年做新核心的所有经验全都加到这几本书里。还有一本书是关于大型IT系统性能测试的，实际上就是把民生银行的性能测试经验进行总结，主要就是说大型项目怎么管理和规划性能测试。然后，把前面的这些理论融合在一起形成了最终的第五本书，就是大型IT系统的智能一体化测试，就是如何做银行后台系统的功能性能一体化测试。
接下来我们看一看今天的主要内容，主要有三个方面：智能一体化测试基础理论、智能一体化测试平台设计、智能一体化测试实施方案。
一、智能一体化测试基础理论
我们先看一看银行测试的现状。做一个银行系统差不多相当于攀登一个高峰，银行IT系统的测试现状，基本是靠人来堆，而且还都是水平不是很高的人，我们新核心的测试人员有大量刚毕业的学生，我对一些学校没有什么歧视的意思，但是真的是你听都没有听过的学校的毕业生。我们这个项目对人才的培养能达到什么地步?有一个小孩大概是2012年左右进了这个项目组，2015年离开公司，去的是平安财富做性能测试，年薪差不多二三十万，就是说这种项目的难度和人的匹配以及最后的结果，大家想一想就知道项目的挑战会有多大。
银行IT系统自动化测试的现状是什么样的?银行系统的自动化测试是最落后的，和互联网公司简直没办法比，基本上所有系统的自动化都是依托于UI 的测试，而且做自动化的人水平还很高，我们付给外包人员的成本也很高，基本上相当于开个好车往山上冲，其结果是有可能冲上去，也有可能翻车了。
银行IT系统接口自动化测试的现状如何?会做但基本上都是靠开发团队针对具体的项目提供一些工具，然后有工具有自动化，比自行车好一点，摩托车的水平，大家在土里面冲，灰头土脸的，基本上就是这么一个局面。
我们怎么来做银行IT系统的自动化测试?换一个思路就是我们不要再成天盯着那些有界面，有UI的系统，我们应该去走盘山路，绕过UI，做后台系统的自动化测试。为什么?以我们行为例，差不多有两百多套系统，但真正有界面的系统就二三十套，那我们做自动化测试为什么非得盯着这些有界面的?只要需求一变，整个界面相关的脚本全都废掉了。我们最终的目标，也就是今天我们要谈的主题，我们要实现功能性能一起来测试。
这里有一个银行核心系统的业务介绍，基本上做了五轮的性能测试，差不多每轮测试都要做单元测试、性能测试、集成性能测试、渠道端到端、多渠道并行的性能测试，每轮差不多都要测几千个场景。
总结一下，我们在测试过程中都遇到了哪些问题?
• 第一，后台系统只能通过渠道来完成测试。
• 第二，后台系统测试比较晚导致修复成本比较高。
• 第三，严重性能问题发现晚可能较难修复。
• 第四，功能与性能互相影响导致进度落后。
• 第五，后台系统的变更测试不全面会带来运营风险。
我们现有的做法就是挑一些比较关键的交易，比如支付系统挑一个路由，或者挑一些代码，甚至还存在数据库升级之类的，都没有办法做全面的测试。
接下来，我们有一些总结和反思。
最终经过反思总结出智能一体化测试，我们看一看它的方法和目标。
左边是银行系统的大致分层，最里面是核心系统，就是存款、贷款、卡、客户等等，再往外是支付、产品、安全、渠道。最终的目标就是把我们的测试前移到开发阶段，能做到随时测试、同时测试。最终定了五个目标，降低功能和性能测试成本、提高后台系统质量、加快开发与测试进度、降低投产运营风险，为系统升级保驾护航。
然后，我们再看一下功能测试有什么需求。
要对服务进行管理，有数据管理、案例管理等等，还有日常维护，最终是快速形成测试报告，进行问题定位，随时全回归。
重点看一下性能测试的需求有哪些?性能测试的主要种类，一个是常规性能，一个是压力测试，还有峰值、容量、疲劳、极限、异常测试。测试场景的种类有几大类，独立场景，还有混合场景、峰值、容量场景、疲劳、异常、批量作业、基准测试等等，但是实际上做智能一体化测试对于性能比较重要的就是独立场景的测试、混合场景的测试，疲劳场景的测试，基本上做这三类测试大部分性能问题都可以发现了。
下面是基本的核心思想，最下面我们有一个测试平台，一般的功能测试人员，就是说没有任何开发技能的功能测试人员都可以在这个平台上设计测试案例，然后高效来执行。
智能一体化测试主要实现了功能、性能同步测试，实时监控服务性能，大幅提高测试效率，降低升级变更投产风险，改变测试人员工作重心，降低系统整体研发成本。主要应用阶段有三个：开发过程的同步测试;发布版本前的验证测试;针对变更更全面的回归测试。
二、智能一体化测试平台设计
我们再看一下平台的设计，核心部分是一些公共平台，它的设计目标第一个就是做测试不需要开发任何脚本，保证案例长久有效，功能、性能同步，极速运行场景，报告自动生成。再扩展一点，要实现跨系统测试支持，还有异步交易系统的支持，主流协议，程序和案例分离，案例和数据分离，对数据进行智能生成等等，还有关联接口的测试，常规性能的支持，报告生成，而且系统可以实现自动升级。
系统在运行的时候有一个测试工厂，每个测试工厂下面有N个测试车间，每个车间内部会创建N个测试机器人，这些机器人来调用案例对接口发起调用，实际上每运行一条案例就是对接口进行一次调用。之后就生成功能测试结果、性能测试结果、结果分析报告、日志等等，所有的测试结果都会传到我们的云测试中心，这样就可以进行汇总分析。可以看一下工作的主界面，这个实际上跟LoadRunner比较相象。
在我们内部真正测试的时候，像安保系统几百条案例基本上都是在几十秒内把所有的案例执行一遍。
三、智能一体化测试实施流程
智能一体化测试实施流程，基本上就是从系统的概要设计阶段，做测试需求分析或者是做测试技术分析，我们功能需求有哪些，性能需求有哪些，一步一步的，后面这些基本上和一般的功能测试和性能测试就比较接近了。然后比较特殊的一个地方就是这个系统现在的一个基本要求是只要用这个系统，每天或者是上班前下班前，把所有的案例执行一遍。到目前为止投产的这些系统都能做到，每天多数都是上班前对口负责的测试人员花2-3分钟时间运行一遍系统，然后把测试报告发给所有相关人员，有问题就看问题。
实施过程也会遇到一些难点，主要有以下几个方面：
• 现有测试资源投入的限制。我们有个别的开发团队，整个系统一共就一个测试人员，这样的系统推广就慢一些，因为他一直就限于不断地做测试，有测试任务赶紧测试，连把原有案例转到系统的时间都腾不出来。
• 开发与测试团队适应过程。
• 推广过程遇到的技术难题。
• 形成新的测试流程与规范。
当前已经推广起来的系统，有支付系统、银联金卡、人民币跨境支付、安保、分布式新核心系统等。
这是一个统计数据，累计设计场景114个，累计测试案例1389个，累计完成51733次服务调用。在一周之内共有22个测试场景执行了130 多次，通过这个数据能看到对这个系统的调用是非常频繁的，因为基本上每天都在调用。这里有测试场景的名称，每个场景包含的案例数等等，而且在测试过程中基本上每天都会发现一些问题。
