第二章 性能测试初体验

    性能测试是一项综合性的工作,致力于暴露性能问题,评估系统性能趋势。性能测试工作实质上是利用工具去模拟大量用户操作来验证系统承受的负载情况,找出潜在的性能问题,分析并解决;找出系统性能变化趋势,为后续的扩展提供参考。测试显然不是录制脚本那么简单的事情(而且现在很多系统还无法录制脚本),本章主要阐述性能测试涉及的IT知识、角色、视角、流程及面临的挑战。

2.1 性能测试的价值

[案例1]2012年11.11 某宝和某东为首的电商赚足了眼球。某宝双十一网络瘫痪诟病,其宝被"抢瘫",好不容易进入支付过程,某宝提示系统繁忙,经过反复尝试,用户花费很长时间才能实现支付。

[案例2]12306订票网站

[案例3]2008年奥运会票务系统

[案例4]亚马逊网站瘫痪

    下面是软件测试分类,如图2-2所示。

    从图2-2可以看到性能测试在整个软件测试环节占了50%的内容,如测试内容中,负载测试、压力测试、性能测试、大数据量测试、恢复测试、内存泄漏测试、竞品测试(比较测试)和可靠性测试。一共14个测试内容,性能的测试占领8个,可想而知性能测试在软件测试中的重要程度。

    软件业大部分软件开发之初一般考虑的是软件功能的市场需求契合度,是否能被市场认可。这个前提成立之后,才会有较大的用户群体去使用,从而出现性能问题。然而根据金字塔理论,到了后期在进行修改,投入和产出不成比例。一般公司在做出确定可以盈利的产品后,会对产品进行再次开发,来达到这个性能要求。所以第一个产品(试验)的性能要求和真正的推广产品(成熟)的性能要求不是一个量级,企业发展到一定程度就得关注性能,重视性能。

    性能测试的价值就是保障系统的性能,提供良好的用户体验;尽可能地找出性能薄弱环节,帮助进行性能优化。

2.2 性能测试流程

(1)业务学习:通过查看文档,手工操作系统来了解系统功能。

(2)需求分析:分析系统非功能需求,圈定性能测试的范围,了解系统性能指标。

(3)工作评估:工作量分解,评估工作量,计划资源投入(即需要多少人力,多少工作日来完成性能测试工作)。

(4)设计模型:圈定性能测试范围后,把业务模型映射成测试模型。

    什么是测试模型?比如一个支付系统需要与银行的系统要进行交互(充值或者转出),由于银行不能够提供支持,我们会开发程序去代替银行系统功能(这就是挡板程序,Mock程序),保证功能的性能测试能够开展;这个过程就是设计测试模型。

    再比如,后面要讲到的实例项目Jforum论坛,根据需求我们了解到一般大家发帖或回帖前都会登录,那么我们在开发脚本时就要把登录与发帖或回帖场景绑定在一起进行测试;这就是测试模型。通俗点说就是性能测试用例设计家性能测试实现方案,用例只关注业务,模型还需关注如何实现,是否具有可操作性,可验证性等问题最后我们还得根据不同的测试目的组合成不同的测试场景。

(5)计划编写:计划测试工作,在文档中明确列出测试范围、人力投入、持续时间、工作内容、风险评估、风险应对策略等。

(6)脚本开发:录制或者编写性能测试脚本(现在很多被测系统都是无法录制脚本的,我们需要手工开发脚本),开发测试挡板程序,开发测试程序等。有时候如果没有第三方工具可用,甚至需要开发测试程序或者工具。

(7)测试环境准备:性能测试环境准备包括服务器与负载机两部分,服务器是被测系统的运行平台(包括硬件与软件,比如应用服务器需要8Core,32G内存,中间件是Jboss7等),负载机是我们用来产生负载的机器,用来安装负载工具,运行测试脚本。

(8)测试数据准备:根据数据模型来准备被测系统的主数据与业务数据(主数据是保证业务能够运行畅通的基础,比如菜单、用户等数据;业务数据是运行业务产生的数据,比如订单;订单出库需要库存数据,库存数据也是业务数据。我们知道数据量变会引起性能的变化,在测试的时候往往要准备一些存量/历史业务数据,这些数据需要考虑数量与分布)。

(9)测试执行:测试执行时性能测试成败关键,同样脚本不同执行人员得出的结果可能差异较大。这些差异主要体现在场景设计与测试执行上。

(10)缺陷管理:对性能测试过程中发现的缺陷进行管理。

(11)性能分析:对性能测试过程中暴露出来的问题进行分析,找出原因。

(12)性能调优:性能测试工程师与开发人员一起来解决性能问题。

(13)测试报告:测试工作的重要交付件,对测试结果进行报告,主要包括常见的性能指标说明(TPS,RT,CPU Using......),发现的问题等。

性能测试主要交付件:

• 测试计划;
• 测试脚本;
• 测试程序;
• 测试报告或者阶段性测试报告。

如果性能测试执行过程比较长,换句话说性能测试过程中性能问题比较多,经过了多轮的性能调优,需要执行多次回归测试那么在这个过程中需要提交阶段性测试报告。

(14)评审:对性能报告中的内容进行评审,确认问题、评估上线风险。有些系统虽然测试结果不理想,但基于成本及时间的考虑也会在评审会议中通过从而上线。

2.3 性能测试成功与失败要素

    性能测试上手难度比较高,是一门融合测试、开发、运维、需求调研、架构、协调管理等综合技能的学科,掌握一门性能测试工具对于性能测试来说只是万里长征的第一步,没有一定的需求、开发和运维专业能力,往往会吃一些苦头。

    性能测试有几大难点:

    (1)需求分析;

    (2)场景设计;

    (3)性能诊断调优;

    (4)环境搭建和模拟;

    往往很多性能测试从业者在需求分析方面没有做到位,不能准确的预估用户行为;在场景上不能复现用户操作,无法把需求体现在脚本和场景设计上,无法模拟真实的系统负载;这种状态下做出的性能测试往往结果良好,上线出问题,导致整个项目团队狼狈不堪,整个公司手忙脚乱。

    性能诊断调优是一门有效利用和协调硬件软件的"艺术",从Oracle Exadata诞生之初在软件层面的优化就可以有200倍至10000倍之多。

    但是性能诊断和调优是有时间和经济成本的,也是需要全面的IT只是体系的专家或者团队才能比较全面的挖掘出系统的性能问题并给出调优方案。

    下面讲解性能测试重要关注点。

    1.评估系统,需求分析

    对性能测试进行需求分析,通常情况下我们很多测试人员会直接依赖需求人员或者项目经理的口述或者有缺陷的文档。实际上,大多数情况下我们需要自己来引导相关的运维人员和需求人员给出具体的需求数据,并对这些数据进行二次分析,得出我们真实的性能需求。

    对于初次上线的系统,我们需要用同行的系统数据,进行用户行为分析和商业数据结构的估算为前提,利用性能算法推算。得到的负荷和响应时间数据可以被用于验证所计划的模型的能力,并帮助做出决策。

    对于已经上线的系统,我们可以通过运维人员获取TPS和时间的比例分布图、用户数和时间的分布图、数据库ER关系图、容量数据等,直接精确得出目前的系统的用户行为和业务数据关系,进而得出我们需要的性能需求。

    2.场景设计、用例设计

    充足的需求调研与分析之后,我们要在测试场景中尽可能真实地复原系统负载。

    通过需要我们要决定那些功能要参与性能执行,如何参与?这就是用例设计。

    如何有效组织测试用例就是场景要做的事,按业务分布、业务量、业务时段、业务角色来综合分配用户数、执行时间、执行比例等。看似简单,实际操作起来还是比较麻烦的。

    3.测试执行、是否通过

    模拟不同负载执行测试场景来识别系统弱点:做好各种监控,甄别各种问题;验证系统稳定性。下面是我们在执行时常见的需要关注的指标,如图2-4所示。

    4.性能诊断优化

    性能诊断知识面要求甚广,系统日益复杂,单打独斗的日子已经远去,依靠团队力量才能高效完成诊断任务。性能测试从业者要具备良好、敏感的性能意识,能够把遇到的问题初步分类,协助各开发团队完成问题定位、分析调优。所以首先要是一个好的协调者,还是一个技术面广的技术人员,具备跨领域知识,如开发、运维、数据库、缓存等。

2.4 不同角色看性能

    图2-5是当前典型的系统性能涉及的方面,需要多个工种(有架构师、开发、系统管理员、DBA、测试等)一起协调才能完成工作,每个环节都可能是瓶颈,造成阻塞。相对于目前国内的IT软件部门环境,因为需要协调多部门,所以性能测试工作人员必须是一个复合型人才,对于各工作的知识有所了解也要求有一定的项目协调能力,来引导大家同心协力地完成此项复合任务,靠单人是不太可能完成如此具有挑战的工作。

2.5 性能测试工具选择

2.6 性能测试相关术语

    (1)负载:模拟业务操作对服务器造成压力的过程,比如模拟100个用户进行发帖。

    (2)性能测试(Performance Testing):模拟用户负载来测试系统在负载情况下,系统的响应时间、吞吐量等指标是否满足性能要求。

    (3)负载测试(Load Testing):在一定软硬件环境下,通过不断加大负载(不同虚拟用户数)来确定在满足性能指标情况下能够承受的最大用户数。简单说,可以帮我们对系统进行定容定量,找出系统性能的拐点,给予生产环境规划建议。这里的性能测试包括TPS(每秒事物数)、RT(事务平均响应时间)、CPU Using(CPU利用率)、Mem Using(内存使用情况)等软硬件指标。从操作层面上来说,负载测试也是一种性能测试手段,比如下面的配置测试就需要变换不同的负载来进行测试。

    (4)配置测试(Configuration Testing):为了合理地调配资源,提高系统运行效率,通过测试手段来获取、验证、调整配置信息的过程。通过这个过程我们可以收集到不同配置反映出来的不同性能,从而为设备选择、设备配置提供参考。

    (5)压力/强度测试(Stress Testing):在一定软硬件环境下,通过高负载的手段来使服务器资源(强调服务器资源,硬件资源)处于极限状态,测试系统在极限状态下长时间运行是否稳定,确定是否稳定的指标包括TPS、RT、CPU Using、Mem Using等。

    (6)稳定性测试(Endurance Testing):在一定软硬件环境下,长时间运行一定负载,确定系统在满足性能指标的前提下是否运行稳定。与上面的压力/强度测试区别在于负载并不强调是在极限状态下,着重的是满足性能要求的情况下,系统的稳定性、比如响应时间是否稳定、TPS是否稳定。一般我们会在满足性能要求的负载情况下加大1.5到2倍的负载量进行测试。

    (7)TPS:每秒完成的事务数,通常指每秒成功的事务数,性能测试中重要的综合性性能指标。一个事务是一个业务度量单位,有时一个事务会包括多个子操作,但为了方便统计,我们会把这个子操作记为一个事务。

    (8)RT/ART(Response Time/average Response Time):响应时间/平均响应时间,指一个事务花费多长时间完成(多长时间响应客户请求),为了使这个响应时间更具代表性,会统计更多的响应时间然后取平均值,即得到了事务平均响应时间(ART),为了方便大家通常会直接用RT来代替ART,ART与RT代表同一个意思。

    (9)PV(Page View):每秒用户访问页面的次数,此参数用来分析平均每秒有多少用户访问页面。

    (10)Vuser虚拟用户(Virtual user):模拟真实业务逻辑步骤的虚拟用户,虚拟用户模拟的操作步骤都被记录在虚拟用户脚本里。Vuser脚本用于描述Vuser在场景中执行的操作。

    (11)Concurrency并发

    (12)场景(Scenario)

    (13)思考时间(Think Time):模拟正式用户在实际操作时的停顿间隔时间。

    (14)标准差(Std.Deviation)

2.7 性能测试通过标准