2.2 性能测试的开始（WHAT）
2.2.1 什么是性能测试
很少能见到性能测试的标准定义，Lucy在网上查了很多资料，最后归纳出来性能测试主要包含如下3个方面：
（1）在给定环境和场景中进行的测试活动；
（2）根据测试结果评判是否存在性能问题；
（3）如果存在性能问题，需定位性能瓶颈，并提出改进建议。
从本质上讲和功能测试有诸多相同之处，都是为了找出问题，但在解决问题的能力上的要求更高。
而在ISO9126的软件质量模型中也有关于性能测试部分的介绍，它提供了一组衡量软件质量好还是不好的基础指标，如图2-2所示。
图2-2 ISO软件质量模型
在软件外部和内部质量的六大特性（功能性、可靠性、易用性、效率、维护性、可移植性）中的效率和性能有着密切的联系，效率是指在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。其中资源可能包括其他软件产品、系统的软件和硬件配置，以及物质材料（如打印机、扫描仪等）。
衡量一个软件的性能，需要从软件效率的以下3点考虑。
时间特性：在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的能力。即完成用户的某个功能需要的响应时间。
资源利用性：在规定条件下，软件产品执行其功能时，使用合适的资源数量和类别的 能力。
效率依从性：软件产品遵循与效率相关的标准或约定的能力。
举例：我们想知道http://www.51testing.com网站的性能，我们就需要了解1个用户打开网站需要多少时间，N个用户打开网站的时间又是多少？用户打开网站是在Windows 7的机器上还是在Windows 10的设备上？系统的CPU是单核还是多核？如有100万用户访问网站，那么我们可以预测在多核CPU下使用Windows 7打开网站的速度要比单核CPU下使用Windows 98打开网站要快，反之我们则怀疑系统可能存在性能问题。
学习笔记
软件性能是软件质量特性的重要组成部分，一般来说，我们会把性能测试看作是外部质量特性的一部分，而外部质量特性指的是我们最为熟悉的系统测试，所以我们可以得出一个简单的结论，性能测试是系统测试的一种测试类型。
2.2.2 性能测试的分类
性能测试的概念并不难理解，但分类就有点绕来绕去的感觉，Lucy有点摸不着头脑，于是决定打电话求教从事性能测试工作的朋友Mary。Mary和Lucy从小在一个大院长大，听闻Lucy要学习性能测试非常乐意帮助她。以下是Mary的基本资料，让我们认识一下这位性能测试工程师。
个人基本资料 姓名：Mary 性别：女 年龄：28岁 毕业院校：××大学计算机专业 工作年限：6年（含性能测试1.5年） 就职公司：B技术有限公司 当前职位：技术部 / 性能组 / 性能测试工程师 |
Lucy拿着准备好的问题，给Mary打了第一通电话，寒暄后开始进入性能测试的讨论。
Lucy：关于性能测试类型到底有哪些？很多书上讲的都不太一致，我有点懵。 Mary：性能测试类型有很多种，你可以先从常用的开始了解。 Lucy：嗯，我也是这样想的，但不清楚哪些是常用的。 Mary：好的，常见的有性能测试（狭义）、负载测试、压力测试、并发测试…… Lucy：等等，我记录一下，那它们各有什么特点呢？ Mary：别着急，我给你举例说明一下，所谓性能测试（狭义）就好比是体育比赛中我们知道比赛的规则…… Lucy：听你这么一说我们好像明白些了，回头我整理一下各种测试类型的资料，你再帮我看看如何？ Mary：没问题。 |
电话结束后Lucy开始整理相关测试类型的资料，并E-mail给Mary确认，经过几次的调整和修改基本符合Mary的要求。以下是整理后的记录。
1．性能测试（狭义）
性能测试方法是在特定的运行环境下，通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。
这种性能测试方法主要目的是为了验证系统是否具有自己所宣称的能力，这种方法是对系统性能已经有了解的前提，并对需求有明确的目标，在已经确定的环境下进行的。
举例：中考体育考试评分标准，该标准在考试前就已经提前确定好了，各位考试的同学只需要按照考试项目在相同的环境完成考试，评分人员就可以给出分数，这就是典型的根据指标给出结果的测试。
2．基准测试
在一定的软件、硬件和网络环境下，模拟一定数量的用户运行一种或多种业务，将测试结果作为基线数据，供后续测试活动参考。
这种性能测试方法的主要目的是找出系统的基本性能情况，为后续调优做准备。
举例：中学体育考试的评分标准肯定是经过大量中学生的数据积累得来的，如果性能测试（狭义）是用该指标进行后续考试的评分，那么基准测试则是在不知道该指标的情况下让学生完成考评，从得到的数据中求平均。
【特别说明】：性能测试（狭义）在有的公司也被看作是基准测试，但在概念上其实是不同的，前者是知晓性能指标，对比实际和预期的差异，而后者则是通过度量得到性能指标，为调优提供依据。
3．负载测试
通过在被测系统上不断加压，直到性能指标达到极限，例如“响应时间”超过预定指标或某种资源已经达到饱和状态。
这种性能测试方法主要目的是找出系统处理能力的极限，这种方法是在不了解系统能力的前提下，在给定的测试环境中进行，看系统在什么时候已经超出“我的要求”或系统崩溃。
举例：找一位同学进行爬楼梯测验，最先要求同学从1楼爬到10楼扛5斤米，发现同学没有问题后接着要求从1楼爬到10楼扛10斤米，逐次增加扛大米的斤数，直至扛不动为止。假设该同学扛40斤米爬楼梯的时候脸已经憋得通红（已经尽全力了），但还是顺利地扛到了10楼，而增加到46斤米的时候彻底累垮，没能到达10楼，我们就可以说扛45斤米爬10层就是该同学的极限了。
4．压力测试
压力测试也称为强度测试，主要测试系统在一定饱和状态下，例如CPU、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。
这种性能测试方法主要目的是检查系统处于压力性能下时，应用的表现。这种性能测试一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。一般用于测试系统的稳定性检查。
举例：我们还是以负载测试中爬楼梯的同学为例，如果扛45斤是该同学的极限，那么扛40斤从1楼到10楼，持续一段时间（4小时），看该同学能不能坚持住，这就是所谓压力性能下的表现。
5．并发测试
并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
这种性能测试方法主要目的是发现系统中可能隐藏的并发访问时的问题。主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。
举例：我们以马拉松为例，经常有千人马拉松赛跑的盛况，但在比赛中赛道是有限的，大家拥挤在赛道上，一声枪响开跑，结果有人在一开始就被拥挤的人群绊倒退出了比赛。而后续的比赛中抢占边缘赛道的竞争更是激烈。如果在该赛道上增加额外的比赛项目，混乱的场面将难以控制。
6．配置测试
配置测试方法通过对被测系统的软/硬件环境的调整，了解各种不同配置对系统的性能影响的程度，从而找到系统各项资源的最优分配原则。
这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。适合对系统性能状况有初步了解后进行，一般用于性能调优和规划能力。
举例：某同学跑1000米取10次的平均成绩为4分8秒，教练为了在短期内提高该同学的成绩采取了如下办法：更换更轻便的跑鞋，换上专业的运动服，调整了跑步姿势等，经过一系列的调整发现该同学的平均成绩提升了2秒钟。
也就是说，这种测试关注点是“微调”，通过对软硬件的不断调整，找出其最佳状态，使系统达到一个最强的状态。
7．可靠性测试
在系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。
这种性能测试方法的主要目的是验证是否支持长期稳定的运行，需要在压力下持续一段时间，在测试过程中关注系统的运行状况。
举例：我们继续以负载测试中爬楼梯的同学为例，如果扛45斤是该同学的极限，扛40斤是该同学较大压力的负载，那么可靠性就是扛25斤左右的大米，从1楼到10楼持续很长一段时间（2~3天），关注该同学在持续过程中的表现。
也就是说，这种测试的关注点是“稳定”，不需要给系统太大的压力，只要系统能够长期处于一个稳定的状态。
Lucy把总结好的相关测试类型E-mail交给了Mary，并电话询问总结的情况，Mary回复了电话。
Mary：Lucy同学，你总结得不错嘛。 Lucy：谢谢，现在我对各种测试类型区分起来也容易多了。 Mary：好的，现在要告诉你一个关键信息，请“忘记”分类。 Lucy：什么，我没听错吧？ Mary：是的，没有听错，在性能测试中我们很少会单独考虑一种测试类型，往往是综合考虑的。 Lucy： 能解释一下吗？ Mary：我举个例子，如体操全能赛，如果爆发力好在鞍马项目上的表现应该不错，但在单杠上耐力的要求会更胜一筹，而平衡木则是整理协调性的体现，一个选手要拿到全能金牌哪个方面都需要表现出色。 Lucy：嗯，有点明白了，这就好比“木桶原理”（最短的木板决定了装水的容量）。一个软件的性能表现是从各个方面考虑的，综合起来表现出色才能说明软件性能优良。 Mary：对，可以这么理解，今后在实践中多应用就能找到选择测试类型的规律。 |
学习笔记
笔记一：负载测试是压力测试和可靠性测试的基础，只有找到极限值才能确定压力状态和常规状态下的取值。
笔记二：性能测试是由若干种测试类型组成的，在实际工作中往往需要多种测试类型一并考虑，而不是只关注某一种类型。
2.3 项目组成员介绍（WHO）
2.3.1 性能测试团队的组建
Lucy所在的公司以前并没有专业的性能测试团队，当前组建该团队的办法主要是从现有人员中选拔合适的人员（Lucy就是备选对象之一），性能测试经理采用外聘的方式。
性能测试团队初级预计规模是4~6人，为了保证外包团队的人员利用率，该团队初期需要承担部分功能测试任务，组织结构如图2-3所示。
图2-3 组织结构图
Lucy本次争取的是内推的性能测试工程师名额，在一个月后进行考核。从组织结构关系可以看出公司本次对性能测试团队是非常重视的，性能测试经理的工作直接汇报给IT总监。而在以前的工作模式中项目经理是开发和测试负责人的直属上级。
这意味着什么？其实Lucy非常清楚，过去的工作经验告诉她，决定权发生了变化，在项目团队中做测试并不需要承担来自客户的直接压力，项目经理会把测试当“自己人”来看待，同开发同事的沟通和相处都比较愉快，大家是一个战壕的，可以说是有福同享有难同当，但在话语权上自然是唯项目经理马首是瞻。
而新的测试团队是独立于项目组之外的，没有人会保护你，需要独立承担性能压力，甚至独立面对最终客户，主要任务是配合各项目组开展性能测试工作，项目组成员会把你当“外人”来看待，需要你体现出更专业的技术水准才能得到团队的认可。当然在话语权上是相对独立的，可以给出自己的判断，不受项目经理的约束。
学习笔记
多数公司的性能测试团队都是独立的，负责多个项目组的性能测试任务，了解公司的组织结构，你会更清楚你的工作职责和重要性。
2.3.2 鱼和熊掌可以兼得
其实从规划来看，今后Lucy很长一段时间将告别现有的管理岗位，进入全新的角色学习新技能，对此Lucy还有一些困惑的地方，于是再次联系了Mary。
Lucy：Mary你好，我们公司有意培养我成为性能测试工程师，这你是知道的，但我现在的管理工作刚刚顺手，突然离开管理岗位，有点不习惯呢。 Mary：哈哈，这你就多虑啦，现在公司都讲求复合型人才，纯粹的管理其实已经不吃香了，拥有一定技术的管理人员才更有竞争力。 Lucy：我知道你的意思，可是管理的积累还不足，突然又转向技术上积累会不会两头都做不好？ Mary：其实这是职业规划的范畴，最理想的状态肯定是按自己的步调积累，但在现实工作中往往有机会和运气的成分，技术和管理的积累完全可以交叉进行，并不会彼此耽误，反而是相互促进的。 Lucy：那我心里就踏实了，作为女生我的目标依然是管理为主的。 Mary：（笑）我以前也是这样想的，结果从事性能测试后才发现自己原来更适合走技术路线，所以你也别着急为自己下定论，做了再说。 Lucy：好的，我会努力的。 |
学习笔记
笔记一：不要害怕承担压力，压力状态下往往能更快提升个人能力，专业表现是你得到认可的关键。
笔记二：学会站在不同视角下看待测试工作，管理和技术是相互促进的，没有先后之分，把握住当下的机会才是最重要的。
2.6 性能测试过程（HOW）
2.6.1 性能测试规划
对性能测试的规划是为了得到时间、人力、工具等相关活动的安排，所以最终的产物就是性能测试计划，我们可以从以下3个方面去考虑。
1．系统级别的分析
（1）被测系统的类型
① 业务处理型系统。强调系统和用户交互的行为，性能问题集中在业务交互过程，通俗来讲可以理解为业务流程，如果被测系统可以站在用户的角度明确先做什么，再做什么，画出流程图，那么这类系统的性能测试我们可以通过脚本模拟用户操作的方式验证。例如，ATM机的取款流程，电子商务网站的购物流程。
② 数据处理型系统。强调数据的收集、整理和处理的过程，性能问题集中在数据库处理能力上，可以直接针对数据库层面进行性能优化。例如，财务报表中的信息查询，银行系统的数据分析。
（2）分析被测系统的架构和部署情况
① 分析定位时间花在了哪里。主要看架构设计图，分析时间可能消耗在哪里，性能瓶颈可能在哪些地方。例如，一位员工经常上班迟到，我们要分析他为什么迟到，就会把他起床到上班打卡这段时间进行细分，是起床洗漱太慢？还是交通方式的选择不当？亦或是步行速度不够快？通过分析我们才能知道问题出在哪里（可参考2.1.2章节“测试人员眼中的性能”，“响应时间”部分）。
② 部署问题。尝试差异化部署，找到最优部署方案。明确监控对象，准备监控工具，并了解需要监控的指标。例如，教练想要了解运动员的体能情况，就需要借助一些工具进行实时测量，包括心跳、脉搏、呼吸等，通过监控得到的指标调整运动员的训练方式，以求达到更理想的竞技状态。
（3）分析系统的技术实现
分析系统的通信协议，系统用到的编程语言以及采用的技术架构。例如，某B/S结构的电子商务软件用到了HTTP协议，编程语言用的是PHP。这些信息可以让我们更精准地选择性能测试工具。
（4）分析被测系统和其他系统的联系
采用直接隔离或者间接隔离的方式，被调用的部分需要我们利用模块和桩的调用关系来解决，俗称挡板程序，该程序运用单元测试的技巧，只给出反馈结果，不做复杂的逻辑处理。主要分为如下两种情况。
① 被测系统是否与其他系统存在关联，例如，在某宝购物选择银行卡付款，那么该系统就会调用银行系统进行付款确认。
② 被测系统内部的子系统之间的关联，例如，某公司办公系统需要统计考勤，就会调用公司内部的HR系统数据库，确定旷工的人员名单。
2．业务级别的分析
（1）确定待测业务和不测业务
① 参考业务的重要级别。通常来讲业务都有所谓的重要级别，例如，某公司的重要级别分为3类：必须有的、重要的、最好有的。
我们可以将“必须有的”理解为，如果没有这类功能就不能称之为某类系统，也就是系统所具备的基本特征。假设我们测试的对象是一个电子商务网站，那么该网站一定可以完成浏览商品、加入购物车、下订单等基本操作，这就是所谓的“必须有的”。
而“最好有的”是指如果有这些功能系统表现会更好或者用户会更满意，继续假设我们测试的对象是一个电子商务网站，那么优惠券码、积分兑换礼品、帮助中心等模块就是“最好有的”。
所谓“重要的”就是介于两者之间的其他模块。
② 业务是否会出现性能瓶颈。这一点往往容易被新人忽略，许多入门级的性能测试工程师总是希望做更多的脚本，覆盖每个服务器请求，但事实上测试总是基于业务的，在业务量较小的模块或者系统中我们大可不必花费过多经历。例如，在某电子商务网站中，我们不需要对个人信息维护部分进行过度关注，同时修改个人信息的用户数量是极少的。
③ 2/8原则。当下的系统业务越来越复杂，我们要学会在众多的测试点中进行取舍，我们遵循2/8原则，80%的用在一个系统中使用的功能约为20%。
④ 项目时间。真正决定项目裁剪的关键所在，性能测试的时间安排往往是非常紧张的，在有效的时间内我们需要做出精准的判断，对系统最可能出现问题的部分进行测试。这就好比是一个受伤的运动员，医生会先止血再考虑是否骨折的问题。
（2）分析待测业务
① 对操作流程进行分析。确定待测业务后，业务流程的分解往往可以用先做什么，再做什么来理解，例如A->B->C->D。
② 对特征和类型的分析。测试前需要明确这是什么类型的系统，系统模块有哪些特殊之处。例如，下载功能，用户对哪些类型的数据下载更多，文件大小如何，我们需要对该功能做区间分析。
3．需求层面的分析
性能测试应尽早介入，清楚这点后我们不难从需求中找到性能测试方面的描述，很可惜许多公司在性能需求的描述上都非常糟糕。
那么什么是有效的性能需求？简单来说就是可度量的需求，例如，某网站首页打开时间要求在2秒之内，系统支持50个用户同时登录，服务器CPU使用率小于等于60%等。
如何获得有效的性能需求？以上信息都很难在软件需求规格说明书中找到准确的反馈，我们经常看到的性能需求是这样描述的：系统能够快速地查询出结果；多人同时下订单不会导致系统崩溃；页面数据的刷新越快越好……总之需求总是希望我们能有多快就有多快，而给到的“指标”往往让人苦笑，只能进一步挖掘具体的需求点，列出可度量的性能指标。
① 响应时间。根据实际业务进行判断，例如，网站页面响应时间一般遵循2-5-8原则（2秒以内表示完全可以接受，2~5秒表示大部分可以接受，5~8秒表示大多数不能接受，大于8秒表示几乎接受不了），我们看响应时间不能一刀切，要求网站所有页面或者任何处理事件都控制在2秒之内。像下载文件这类业务的时间往往和文件大小有关，在2秒之内不一定完成。
② 吞吐量TPS。如果被测对象已经在线上运行，那么吞吐量可以通过历史数据估算未来的增长情况。如果被测对象从未对外发布，我们可以从今后系统的业务量反向推导。
③ 资源利用率。主要考虑CPU、内存、I/O的使用情况，系统上线前应避免因资源不足而导致的系统瓶颈。
④ 负载用户定义。明确在线用户不等于并发用户，通常取在线用户数的10%（按业务特点来确定）作为并发用户。
学习笔记
笔记一： 性能测试规划部分需要积累大量的实战经验，要想了解公司的技术架构、业务特点以及用户要求等性能测试计划相关内容，需要在公司有一定的积累，并非是一朝一夕就能马上掌握的。
笔记二：尽早介入性能测试项目，在需求层面提出性能要求，明确性能测试的关键指标，这对后期性能测试工作的开展至关重要。
2.6.2 测试场景设计
测试场景的设计主要还是依托对性能测试需求的理解，主要包括模拟真实场景和搭建仿真环境两个部分。
1．模拟真实场景
性能测试一直强调仿真，但为了达到一些极限下的状态我们需要对脚本进行一些规划，设计脚本的性能测试策略。
单一场景（单脚本场景），依据性能需求的不同，一般会从如下测试类型考虑：负载测试、并发测试、压力测试、容量测试等。
混合场景（多脚本场景），不仅依据性能需求，还会尽量站在用户视角考虑性能测试类型：压力测试、配置测试、可靠性测试等。
2．搭建仿真环境
性能测试往往需要独立的测试环境，除了测试环境本身的重要性外，其他方面的好处是显而易见的。
（1）避免不必要的因素成为“瓶颈”，测试环境相对纯净，便于排查系统问题。
（2）模拟实际用户很难重现的问题，部分测试要在特定情况下才会出现问题，该环境便于重现此类问题。
搭建性能测试环境需要确认的事项除了包括硬件环境、网络结构、网络带宽方面的基本配置，还应该包括操作系统、数据库服务器、Web服务器、应用服务器等其他软件的配置。此外，历史数据量在场景设计中也需要考虑，一般包括基础数据和业务数据两个部分。
（1）基础数据：是指系统运行前必须提前准备的数据，例如，某医院的挂号系统，如果没有医生姓名、科室、在岗时间、当前可挂号数等数据，我们就没有办法挂号。所以需要提前在系统中录入相关数据。
（2）业务数据：是指用户通过对系统进行流程化操作而产生的数据，该数据我们可以通过工具进行模拟，主要目的是考虑数据量对系统性能产生的影响。
学习笔记
笔记一：仿真才能更好地模拟用户实际操作，所以性能测试的场景设计是要站在用户视角理解业务实现过程，并根据实际或预估的业务量进行测试。
笔记二：测试环境搭建需要同服务器打交道，对于服务器不熟悉的测试人员可以请公司IT团队协助。
笔记三：测试数据最佳来源是生产环境，如果数据需要从生产环境导出，那么相关人员一定要做好数据的脱敏处理。例如，客户真实姓名、电话、身份证等企业及用户安全方面的信息处理后测试环境方能使用。
2.6.3 测试套件开发
开发测试套件，这一步算是进入了实现阶段，可以利用工具创建测试脚本实现大部分的测试工作，然后按基础数据和业务数据要求，准备垫底数据和测试数据。具体操作流程如图2-5所示。
图2-5 测试套件开发流程
创建脚本：纯手工编写代码是不现实的，我们需要借助工具来完成脚本的创建。
录制脚本：录制是工具的一种模拟用户行为的手段，主要通过录制协议来识别交互过程。
修改脚本：录制的脚本往往不能够直接使用，需要我们读懂脚本，并对脚本进行修改，以达到场景设计的要求。例如，登录脚本。录制脚本的时候使用的用户名是tester001，测试场景要求实现5个不同用户同时登录的情况，于是我们需要把用户名设置为tester001、tester002、tester003、tester004、tester005，系统执行可以同时选择不同的用户名。
模拟用户行为：性能测试的本质就是“欺骗”服务器模拟用户行为，为了防止各类“欺骗”服务器会做很多限制和判断。例如，在同一时间段内，来自同一个IP地址的请求只会被执行一次，那么我们就需要模拟多个IP地址向服务器发起请求才能达到并发的目的。
添加监控：系统分析依赖于收集到的监控数据，这些数据包括服务器和客户端所消耗的时间，网络传递话费的时间，甚至测试工具本身所用的时间。
调试脚本：脚本修改后我们需要实际运行，确保协议传递的正确性和可靠性。
学习笔记
笔记一：很多工具都可以实现套件开发，并非只有LoadRunner一种，甚至有些公司会针对自有产品的特点研发性能测试工具。
笔记二：性能测试脚本是基于协议的脚本，通过对协议请求的捕获向服务器发起请求，因此是不依赖于界面的测试。例如，在Lucy机器上录制的脚本，在Mary的机器上也可以被运行，甚至在Windows下录制的脚本，在Linux操作系统下同样可以运行。
本文选自《性能测试学习笔记之 LoadRunner实战》第二章，本站经人民邮电出版社和作者的授权。
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
