性能测试是一项综合性的工作，致力于暴露性能问题，评估系统性能趋势。性能测试工作实质上是利用工具去模拟大量用户操作来验证系统能够承受的负载情况，找出潜在的性能问题，分析并解决；找出系统性能变化趋势，为后续的扩展提供参考。测试显然不是录制脚本那么简单的事情（而且现在很多系统还无法录制脚本）。本章带您进入性能的领域，阐述性能测试涉及的IT知识、角色、视角、流程及面临的挑战。
性能测试的价值
随着互联网的发展，单机软件的逐渐减少，系统从单机步入“云”时代，软件系统功能和规模也越来越庞大，盗版也越来越难，用户规模也越来越大，企业盈利随之爆发式地增长。随着用户数量的增多，系统稳定就成为企业的首要技术保障，稳定才能带来流量，才能赚钱。
下面我们回顾一下著名的性能事件（这些事件内容来自于百度）。
[案例1]2012.11.11
“11月11日凌晨零时起，某企业11.11正式启动，激增的流量瞬间险些让系统陷入瘫痪状态。随后某宝出现短时间内无法付款，多家品牌商系统崩溃……”。这损失的都是钱啊！
某宝和某东为首的电商赚足了眼球。某宝双十一网络瘫痪遭诟病，某宝被“抢瘫”，好不容易进入支付过程，某宝提示系统繁忙，经过反复尝试，用户花费很长时间才能实现支付。
破1000万用户访问时，部分某宝官网打开时间需要15~23分钟，对于一般用户是绝对不能接受的，某宝开始瘫痪无法响应，部分页面无法显示等。在关键的时刻各种性能问题到底给我们上了一节什么样的课程？
来看看2012年优化性能后的数据：
2012某宝双11销售额191亿
2013某宝双11销售额350亿
2014某宝双11销售额571亿
2015某宝双11销售额912亿
没错直接损失了100多亿，如果性能测试做足能够把好关，提前做好预案，一天就可以营收100多亿，要知道好多传统百货集团一年也营收不了这么多。
来看看某东2012年因某宝瘫痪后流量暴涨，大量用户登录。结果某东的服务器被大流量冲垮，服务器也瘫痪。无论如何2012年11月11日某宝和某东的瘫痪，引人深思，性能测试的价值也随之体现。
[案例2]12306订票网站（内容来自于百度）
12306网站创建初期的几年每逢春节就瘫痪，2014年1月9日，当日开始出售1月28日的火车票，是当年的售票高峰日。这一天的网页浏览量高达88亿次，88亿次/12小时=20W/秒+的点击。这个网站的多次瘫痪证明了，性能测试的重要性，也证明了不是用硬件就能解决软件性能。
[案例3]2008年奥运会票务系统
由于订票人数远远超出预期（性能需求没做到位，设计也没有到位，无排队等设计）刚开放后不久就瘫痪，造成了部分人无法从网络获得门票。
[案例4]亚马逊网站瘫痪
2014年11月6日因华为手机P6在欧美销售太过火爆，电商国际巨头亚马逊网站（当地）瘫痪。造成的损失不仅仅只是活动损失，还有声誉。
要应对大规模的用户共同使用一套系统，那必须有相对应的强壮性能的系统，性能测试是对这套系统的一个质量保障，如果性能测试有漏洞，那么就会引发非常惨烈的后果，因此上线前的性能测试必不可少。
软件测试分类
从上图可以看到性能测试在整个软件测试环节占了50%的内容，如测试内容中，负载测试、压力测试、性能测试、大数据量测试、恢复测试、内存泄露测试、竞品测试（比较测试）和可靠性测试。一共14个测试内容，性能的测试占领8个，可想而知性能测试在软件测试中的重要程度。
软件业大部分软件开发之初一般考虑的是软件功能的市场需求契合度，是否能被市场认可。这个前提成立之后，才会有较大的用户群体去使用，从而出现性能问题。然而根据金字塔理论，到了后期再进行修改，投入和产出不成比例。一般公司在做出确定可以盈利的产品后，会对产品进行再次开发，来达到这个性能要求。所以第一个产品（试验）的性能要求和真正的推广产品（成熟）的性能要求不是一个量级，企业发展到一定程度就得关注性能，重视性能。
性能测试的价值就是保障系统的性能，提供良好的用户体验；尽可能地找出系统性能薄弱环节，帮助进行性能优化。
性能测试流程
做事情我们讲究方法，注重效益，例如生产企业会有流水线。做性能测试也一样，我们也有规范的流程，完全符合项目管理流程。
- 业务学习
通过查看文档，手工操作系统来了解系统功能。 - 需求分析
分析系统非功能需求，圈定性能测试的范围，了解系统性能指标。 - 工作评估
工作量分解，评估工作量，计划资源投入（即需要多少人力，多少工作日来完成性能测试工作）。 - 设计模型
圈定性能测试范围后，把业务模型映射成测试模型。
什么是测试模型呢？比如一个支付系统需要与银行的系统要进行交互（充值或者转出），由于银行不能够提供支持，我们会开发程序去代替银行系统功能（这就是挡板程序，Mock程序），保证此功能的性能测试能够开展；这个过程就是设计测试模型。
再比如，后面要讲到的实例项目Jforum论坛，根据需求我们了解到一般大家发帖或回贴前都会先登录，那么我们在开发脚本时就要把登录与发帖或回贴场景绑定在一起进行测试；这就是测试模型。通俗点说就是性能测试用例设计加性能测试实现方案，用例只关注业务，模型还需关注如何实现，是否具有可操作性，可验证性等问题最后我们还得根据不同的测试目的组合成不同的测试场景。 - 计划编写
计划测试工作，在文档中明确列出测试范围、人力投入、持续时间、工作内容、风险评估、风险应对策略等。 - 脚本开发
录制或者编写性能测试脚本（现在很多被测系统都是无法录制脚本的，我们需要手工开发脚本），开发测试挡板程序，开发测试程序等。有时候如果没有第三方工具可用，甚至需要开发测试程序或者工具。 - 测试环境准备
性能测试环境准备包括服务器与负载机两部分，服务器是被测系统的运行平台（包括硬件与软件，比如应用服务器需要8Core，32G内存，中间件是Jboss7等），负载机是我们用来产生负载的机器，用来安装负载工具，运行测试脚本。 - 测试数据准备
根据数据模型来准备被测系统的主数据与业务数据（主数据是保证业务能够运行畅通的基础，比如菜单、用户等数据；业务数据是运行业务产生的数据，比如订单；订单出库需要库存数据，库存数据也是业务数据。我们知道数据量变会引起性能的变化，在测试的时候往往要准备一些存量/历史业务数据，这些数据需要考虑数量与分布）。 - 测试执行
测试执行是性能测试成败关键，同样脚本不同执行人员得出的结果可能差异较大。这些差异主要体现在场景设计与测试执行上。 - 缺陷管理
对性能测试过程中发现的缺陷进行管理。 - 性能分析
对性能测试过程中暴露出来的问题进行分析，找出原因。 - 性能调优
性能测试工程师与开发人员一起来解决性能问题。 - 测试报告
测试工作的重要交付件，对测试结果进行报告，主要包括常见的性能指标说明（TPS、RT、CPU Using……），发现的问题等。
性能测试主要交付件：测试计划、测试脚本、测试程序、测试报告或者阶段性测试报告
如果性能测试执行过程比较长，换句话说性能测试过程中性能问题比较多，经过了多轮的性能调优，需要执行多次回归测试，那么在这个过程中需要提交阶段性测试报告。 - 评审
对性能报告中的内容进行评审，确认问题、评估上线风险。有些系统虽然测试结果不理想，但基于成本及时间的考虑也会在评审会议中通过从而上线。
性能测试成功与失败要素
性能测试上手难度比较高，是一门融合测试、开发、运维、需求调研、架构、协调管理等综合技能的学科，掌握一门技能测试工具对于性能测试来说只是万里长征的第一步，没有一定的需求，开发和运维专业能力，往往会吃一些苦头。
性能测试有几大难点：
1.需求分析
2.场景设计
3.性能诊断调优
4.环境搭建和模拟
往往很多性能测试从业者在需求分析方面没有做到位，不能准确地预估用户行为；在场景上不能复现用户操作，无法把需求体现在脚本和场景设计上，无法模拟真实的系统负载；这种状态下做出的性能测试往往结果良好，上线出问题，导致整个项目团队狼狈不堪，整个公司手忙脚乱。
性能诊断调优是一门有效利用和协调硬件软件的“艺术”，从Oracle Exadata诞生之初在软件层面的优化就可以有200倍至10000倍之多。
但是性能诊断和调优是有时间和经济成本的，也是需要全面的IT知识体系的专家或者团队才能比较 全面地挖掘出系统的性能问题并给出调优方案。
很多性能测试初学者总觉得性能测试就是写个脚本，弄几台机器应付，出个报告就行了。通常关注并发多少，响应时间多少，能跑通吗等问题认为并发越大，响应时间越快，那性能一定就越好，实际上我们需要对系统进行一系列复杂精密的工作才能开始性能测试执行，经过N次回归，找到瓶颈的具体原因，优化再验证。
下面讲解性能测试重要关注点。
- 评估系统，需求分析
对性能测试进行需求分析，通常情况下我们很多功能测试人员会直接依赖需求人员或者项目经理的口述或者有缺陷的文档。实际上，大多数情况下我们需要自己来引导相关的运维人员和需求人员给出具体的需求数据，并对这些数据进行二次分析，得出我们真实的性能需求。
对于初次上线的系统，我们需要用同行的系统数据，进行用户行为分析和商业数据结构的估算为前提，利用性能估算法推算。得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。
对于已经上线的系统，我们可以通过运维人员获取TPS和时间的比例分布图、用户数和时间的分布图、数据库ER关系图、容量数据等，直接精确得出目前的系统的用户行为和业务数据关系，进而得出我们需要的性能需求。 - 场景设计、用例设计
充足的需求调研与分析之后，我们要在测试场景中尽可能真实地复原系统负载。
通过需要我们要决定哪些功能要参与性能执行，如何参与？这就是用例设计。
如何有效地组织测试用例就是场景要做的事，按业务分布、业务量、业务时段、业务角色来综合分配用户数、执行时间、执行比例等。看似简单，实际操作起来还是比较麻烦的。 - 测试执行、是否通过
模拟不同负载执行测试场景来识别系统弱点：做好各种监控，甄别各种问题；验证系统的稳定性。下面是我们在执行时常见的需要关注的指标。
- 性能诊断优化
性能诊断知识面要求甚广，系统日益复杂，单打独斗的日子已经远去，依靠团队力量才能够高效完成诊断任务。性能测试从业者要具备良好、敏感的性能意识，能够把遇到的问题初步分类，协助各开发团队完成问题定位、分析调优。所以首先要是一个好的协调者，还是一个技术面广的技术人员，具备跨领域知识，如开发、运维、数据库、缓存等。
不同角色看性能
上图是当前典型的系统性能涉及的方面，需要多个工种（有架构师、开发、系统管理员、DBA、测试等）一起协调才能完成工作，每个环节都可能是瓶颈，造成阻塞。相对于目前国内的IT部门环境，因为需要协调多部门，所以性能测试工作人员必须是一个复合型人才，对于各工作的知识有所了解也要求有一定的项目协调能力，来引导大家同心协力地完成此项复合任务，靠单人是不太可能完成如此具有挑战的工作。
技术部门一般有以下几种常见的角色，开发、测试、架构师、运维人员-（系统管理员、DBA等）。下面我们看看不同角度对于系统的要求。
1、黑盒测试的角度
黑盒测试操作应用界面——数据请求经过网络发送——服务器前端接收处理——在DB server获取相关数据——前端处理后返回数据——应用界面收到数据响应下一步。
黑盒测试只关心应用程序的单步响应时间，性能好坏就看应用时间多少，也就是数据流经过服务器/服务器集群经过网络传输后往返的时间总和。
2、开发角度
1.架构合理性
2.数据库设计合理性
3.代码
4.系统里内存的使用方式
5.系统里线程使用方式
6.系统资源是否有恶性，不合理竞争
7.作为一个开发人员，只关注功能的代码实现，很少有精力去关注数据库的设计，框架的设计是否合理，系统里内存的使用方式是否合理、系统里线程使用方式是否合理、系统资源会不会有可能存在不合理竞争。他们通常认为这些是架构师去考虑的问题，但是在我国普遍的中小软件公司，很少有去考虑这些事情。
3、系统管理员角度
1.硬件资源利用率
2.JVM
3.DB
4.换哪些硬件能提高系统性能
5.系统能否支持7*24的服务
6.扩展性，兼容性，最大容量，可能的瓶颈
7.作为运维人员通常关注这套系统所有服务器是否正常运行，一般关注这些服务器（数据库、中间件等服务器）的硬件资源利用率情况，如内存是否有可用空间，CPU是否超过70%，网络是否畅通、I/O是否存在瓶颈。这些服务器和配置是否能支撑几个月甚至几年稳定无问题地运行这套系统。除此之外还考虑，随着公司业务的增大，吞吐量需求加大，是否增加服务器就可以等比例地提高系统的综合吞吐量。
4、性能测试的角度
1.服务器硬件性能
2.根据需求和历史数据制定性能目标
3.建立性能通过模型
4.对开发代码框架和硬件框架进行性能分析
5.针对开发发布版本的基准测试
6.执行软件性能验收及稳定性测试
7.生产环境的配置和优化
8.制定性能测试的测试用例
9.制定性能测试的场景设计
10.协调各部分配合
11.特定的性能分析
性能测试工具选择
工欲善其事必先利其器，性能测试时模拟大量负载需要工具帮忙，市面上可供使用的负载工具繁多，如何选择呢？
首先我们要明白负载工具是帮助我们来模拟负载的，对于性能测试来说，工具并不是核心，分析、评估、找出性能问题才是核心，这些是主观因素；工具是客户因素，自然要降低其对结果的影响，所以工具选择时我们有几个方面要考虑。
1.专业、稳定、高效，比如Loadrunner，工业级性能负载工具。
2.简单易上手，在测试脚本上不用花太多时间。
3.有技术支持，文档完善，不用在疑难问题上花费时间，集中精力在性能分析上。
4.要考虑投入产出比，比如我们可以选择免费开源的JMeter。当然有时候自研或者使用开源不一定比商业工具更省钱，因为要做技术上的投资，时间上的投资。
常见的性能工具：
1.HP公司的LoadRunner；
2.Apache JMeter(开源)；
3.Grinder(开源)；
4.Compu Ware公司的QALoad；
5.Microsoft公司的WAS；
6.RadView公司的WebLoad；
7.IBM公司的RPT；
8.OPENSTA等。
下面比较下选择商业工具与自研及开源工具
总之我们要认清性能测试的核心是性能分析，重要的是思想，实现方式，不在意工具；大家本着简单、稳定、专业、高效、省钱的原则来选择工具。
性能测试相关术语
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）：性能测试过程中为了模拟真实用户的业务处理过程，在LoadRunner中构建的基于事务、脚本、虚拟用户、运行设置、运行计划、监控、分析等的一系列动作的集合，称之为性能测试场景。场景中包含了待执行脚本、脚本组、并发用户数、负载生成器、测试目标、测试执行时的配置条件等。
13、思考时间（Think Time）：模拟正是用户在实际操作时的停顿间隔时间。从业务的角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间。在测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔时间。
14、标准差（Std. Deviation）：该标准差根据数理统计的概念得来，标准差越小，说明标动越小，系统越稳定，反之，标准差越大，说明波动越大，系统越不稳定。包括响应时间标准差、TPS标准差、Running Vuser标准差、Load标准差、CPU资源利用率标准差、Web Resource标准差等。举例响应时间标准差。
性能测试通过标准
性能测试从需求、设计、准备、执行到分析，最后需要判断性能测试是否通过，性能测试工程师最终需要考虑很多因素，判断的标准相应也会有多个维度。
性能测试通过标准包括服务端性能、前端性能和用户体验性能，常规通过标准如下图所示。
性能测试趋势
“云”计算已经来到我们身边，测试也已经向云计算在发展，性能测试也将深度“云”计算化。
提高工作效率是人类一直的追求，性能测试将会在自动化的道路上越走越快，持续集成也将更好的集成性能测试部分。已经有公司在用docker来做持续集成。
另外，最近几年开始流行devops（当然devops也会基于云计算），开发与运维，开发与测试的边界越来越窄，很多运维及测试的事情都在开发的考虑范围内，自动化测试工作，性能测试工作都会有一部分并入devops中，测试的技术门槛一方面更低，专注功能的测试门槛更低；另一方面更高，专注于性能测试的技术要求更高，我们面临的系统复杂度越来越高，分析问题难度加大，自然价值更高。
小结
本章讲解了一些性能测试的基本理论，相信大家对性能测试已经有了一个初步认识。性能测试工作是一个综合学科；对技术要求高、广，也要求具备一定沟通能力，能够胜任这项工作。
性能测试的工作过程中要注意的关键点也比较多，首先要做好性能需要分析；不充足的性能需要分析直接导致性能测试工作失败。接着要做好用例及场景设计，尽可能复现实际负载，这样的执行工作才是可信赖的，可参考的。执行过程中要做好性能监控工作，为问题分析提供数据支撑。