提及性能测试，总让人有种高深莫测的感觉，对于已经工作在功能测试方面做过1~2年甚至更长时间的朋友来说，性能测试不是不想做，而是无从下手。在企业里有若干理由可以让你放弃性能测试的学习，技术积累多数也是虎头蛇尾，所谓万事开头难，如果能及时调整状态，理清脉络，那么就会诸事顺遂，心想事成。
本章主要包括以下内容：
●拒绝性能测试的理由；
●告别拖延，拥抱变化；
●性能测试招聘要求；
●本章小结。
1.1 拒绝性能测试的理由
在此事上也许你有千百种理由，例如
理由一：公司有专业的性能测试团队，那里不需要没有经验的人（而自己就是那个被认为没经验的人）；
理由二：公司没有性能测试要求，我不需要学习更多；
理由三：公司有性能测试需求，但是没有人会，我也无能为力。
以上3种情况如果非要总结一下，那就是没有人教你如何做性能测试。至于“我不需要学习更多”的说法是明显的自欺欺人，当你拿起这本书的时候，我相信已经证明了我的论证。
那是时候接触下性能测试了，为了能让你不再感到畏惧，能够轻松突破自己，故事就从一个叫Lucy的姑娘说起。相信故事总是吸引人的，故事的主角同你一样并不是工作狂，也不是一个科技极客，请相信作者的介绍，后续的故事将是这位姑娘陪伴您一同学习和成长。
个人基本资料 姓名：Lucy 性别：女 年龄：25岁 毕业院校：××大学计算机专业 工作年限：3年 就职公司：A技术有限公司（主要从事外包业务） 当前职位：技术部 / 某项目组 / 测试负责人 |
Lucy毕业后应聘上了A公司的初级软件测试工程师岗位，在这里工作3年了，主要从事各类外包业务系统的功能测试工作，在繁忙的工作中也算是尽职尽责，目前已经是某个小团队的测试组长。Lucy一直以来都很想接触更有挑战的测试工作，例如性能测试，在半年前就有计划学习性能测试，但繁忙的工作总是让人疲于奔命，重要而不紧急的事项看起来是那么遥遥无期。
什么是重要而不紧急事项？这是个时间分配的问题，我们来看看经典的时间管理象限图，如图1-1所示。
“紧急又重要的事项”和“紧急但不重要的事项”占据了你大部分的时间，也就意味着消耗了你大部分的精力，当你无力面对重要而不紧急的事项，就意味着这件事很难完成，而性能测试恰巧就是Lucy重要而不紧急的事项。
图1-1 时间管理象限
1.2 告别拖延，拥抱变化
日子一天天过去，直到有一天张经理（以下简称PM张）找到Lucy，以下是他们的简短对话。
PM张：Lucy，你来公司有多久了？ Lucy：大概有3年2个月了。 PM张：嗯，时间不短呀，听同事们说你做事认真负责，我也非常欣赏。 Lucy：领导，是有什么新的安排吗？ PM张：公司计划成立性能测试团队，毕竟业务扩展得比较快，用户的期望也就更 高了。 Lucy：领导是希望我去做性能测试吗？（略显兴奋） PM张：正有此意，只是不知道这么长时间你在性能测试方面有无积累？ Lucy：我…… |
有时候真的很难用语言来形容当下的心情，Lucy和PM张经过一番交流，PM张最终决定给Lucy一次机会，要求在一个月内掌握性能测试基本应用（当然现有的工作依然是重点，不会有任何变化），如果一个月无法达到既定目标此事也就作罢。压力到动力的转化就是一墙之隔，请每天抽点时间和Lucy一起在性能测试的世界漫游。
第2章性能测试概述
Lucy翻阅了大量参考资料，将所有内容做了一次整理，但要完全理出头绪还需要借助在HR管理培训时提到的“六何分析法”，即5W1H分析法，这是一种思考方法，可以通过寻找问题和解答问题的思路来学习新技能。
本章主要包括以下内容：
●性能测试的缘由（WHY）；
●性能测试的开始（WHAT）；
●项目组成员介绍（WHO）；
●项目组现有资源（WHERE）；
●关于时间的要求（WHEN）；
●性能测试过程（HOW）；
●本章小结。
2.1 性能测试的缘由（WHY）
2.1.1 性能测试典型案例
我们先来看看WHY的问题，首先我们可以问自己为什么要做性能测试？如果你做过功能测试相信并不会对此有太大的疑惑，Lucy所在的公司做过很多客户项目，其中就有因性能问题而导致出错的典型案例。
案例一：去年A公司承接了一个办公自动化的项目，Lucy是这个项目的主要测试负责人，项目进展还算顺利，直到快交付使用的时候PM张找到开发和测试，征求是否可以模拟多用户使用的情况，以免上线出现问题。因Lucy没有此方面的经验，而开发也只能是对于关键环节做些预防和检查，此事也就作罢。好在客户方算是人品爆发，系统预上线后要求全体成员在指定时间使用该系统至少15分钟，并反馈使用情况。（要知道这件事情的难度是非常大的，客户方公司大约有2000名员工，没有良好的执行力恐怕难以实现。）结果系统在大规模使用的情况下直接崩溃……
案例二：今年初Lucy恰巧接手了一个移动端App项目， 该项目公司测试完成后计划在3天后交付用户，而客户方出于谨慎，为了保证软件质量找来了第三方公司进行验收，通过验收测试发现了部分并发（多用户同时使用某种功能）导致的性能问题……
以上两个案例对于A公司来讲造成了一定损失，这也算是A公司有意组建性能测试团队的重要原因，那么性能测试对我们现实生活又有哪些影响呢？我们来看一些日常生活中的所见所闻：
（1）“双十一”的疯狂，为何抢不到商品的总是自己
某宝拥有强大的服务器，技术上也算是业内数一数二的公司，但在面对上亿用户蜂拥下单的情况下依然是力不从心，经过多年改进，在2015年还是难逃服务器繁忙请等待的尴尬。
（2）12306春运魔咒，为何票刚放出来，还没来得及下单就显示售罄
12306算是业界调侃的主要对象，但凡春运期间买过票的朋友都会吐槽一番，面对整点放票而涌现的巨大抢票压力，2014年让诸多“抢票神器”（利用自动化技术实现购票的一种不正当手段）风起云涌，黄牛手握多张车票，而真正需要火车票的顾客却苦苦守候也只能接受抢不到票的无奈。
（3）大型网游宕机，某大型网络游戏服务器为何频繁发生故障
某大型网游在中国风靡多年，因服务器频繁死机，服务器代理商也出现了易主，2010年因服务器故障导致整个游戏网络瘫痪，甚至部分数据丢失，网络玩家情绪异常激动，集体表示不满。
（4）迪斯尼开园一票难求，又是一次哄抢导致官网出现崩溃
2016年上海迪斯尼官网门票上线即被“秒杀”预售，疑似系统故障，据业内人士分析,官网出现系统故障的原因主要是同一时间集中发送购票请求过多,系统不堪重负。
学习笔记
多数公司想要开展性能测试相关工作，往往是因为业务需要，许多人总说没有机会，但当机会来临的时候自己却没有准备好。
2.1.2 测试人员眼中的性能
在2.1.1小节我们讲了许多案例，无非是想说明以上都和性能测试有关，对用户来讲性能测试最直观的感受就是反应慢或者没有反应，通常我们把这种反应快慢的状况叫作“响应时间”。但作为一名测试人员，我们的理解可以比普通用户更深入些，我们可以看到服务器端的情况，可以了解网络传递的过程，所以我们有更多的视角看待性能问题。
1．响应时间
我们往往用时间的快慢来判断系统当前所处的状态，最直观的感受就是我们向服务器发起了某个请求，在没有缓存的情况下，服务器返回请求所花费的时间总和就等于响应时间。例如，我们向51testing论坛发起登录请求，1秒之后我们进入登录成功页面，那么1秒就是我们所花费的响应时间。
客户感受到的响应时间=客户端响应时间+网络响应时间+服务器响应时间
如图2-1所示，响应时间= CT+（N1+N2+N3）+（N4+N5+N6）+WT+AT+DT。
图2-1 响应时间的组成
（1）客户端响应时间
CT=Client Time对于瘦客户端可以忽略不计，对于胖客户端，例如Ajax，HTML5+ AngularJs+Bootstrap，由于客户端内嵌了大量的逻辑处理，消耗的时间可能很长，需要关注。
（2）网络响应时间
指网络传输交易请求和交易结果所消耗的时间，可以分为以下两个部分。
N1+N2+N3=客户端请求的网络延迟
N4+N5+N6=服务器响应的网络延迟
（3）服务器响应时间
服务器完成交易请求执行的时间，服务器端的响应时间可以度量服务器的处理能力。
WT=Web Server Time
AT=App Server Time
DT=Database Time
2．并发数
我们可以通过有多少用户在使用系统了解系统的承载能力，客户总是希望越多越好，但系统总是有极限的。这里有三个概念需要加以区分。
（1）系统用户数
可以理解为系统注册用户总数。例如，51testing论坛有超过60万的注册用户，有些用户非常活跃，经常登录并留下“足迹”，而有的用户很少访问，甚至自己都忘记曾经注册过的 账号了。
（2）在线用户数
当前统计时正在访问的用户总数。例如，51testing论坛每天有超过12万的在线用户数，但他们不一定会给网站造成巨大的压力，大多数用户只是浏览网页信息，并没有向服务器发起过多请求。
（3）并发用户数
同一时刻让服务器产生压力的用户数。例如，51testing论坛的12万在线用户中有20%正在论坛发帖讨论，那么服务器将承受这部分用户的压力。
3．吞吐量
严格意义上来讲我们可以把吞吐量分为“吞吐量”和“吞吐率”两个概念讲解。
（1）吞吐量
指在一次性能测试过程中网络上传输的数据量的总和，“吞”进去的是请求，“吐”出来的是结果，吞吐量反应的就是服务器的“饭量”，也就是服务器承受的压力。例如，在51testing论坛浏览帖子比发表评论需要更高的网络吞吐量。
（2）吞吐率
通常指单位时间内网络上传输的数据量，也可以指单位时间内处理的客户端请求数量/服务器返回的数据量。它的定义相对灵活，在数据库层面，吞吐率指的是在单位时间内，不同SQL语句的执行数量；从用户层面来讲，吞吐率也可以用“页面数/秒”、“业务数/小时”、“访问人数/天”等指标来衡量。
【特别说明】：吞吐率=吞吐量/传输时间，例如，访问51testing论坛首页，首页大小按2MB计算，如果每秒有1000个首页访问量，那么吞吐率就约等于2GB/s（1GB=1024MB）。
4．每秒通过事务数（TPS：Transaction Per Second）
每秒钟系统能够处理的交易或事务的数量，它是衡量系统处理能力的重要指标。
交易和事务是人为规定的，一个交易或者事务可能包含多个请求，例如，用户注册可以包含多个字段验证请求，而用户注册的TPS等于每秒钟能够注册的用户数量，如果每秒钟能够注册10个用户，那么TPS=10。
【特别说明】：TPS和吞吐率在性能测试中的曲线呈正相关，以吞吐率的案例来看TPS，如果吞吐率指的就是每秒访问论坛首页的次数，那么TPS=1000次。
5．每秒单击数
每秒钟用户向Web服务器提交的HTTP请求数，这是Web应用特有的一个指标。如果把每次单击定义为一次交易，那么单击率和TPS就是一个概念，但事实上一个交易往往由若干请求数组成，请求当中包括页面HTML、css、图片等，甚至可能包括多个页面，也就是说单击数和TPS一般不会一致。
例如，你想在51testing论坛提交一个登录请求，通俗来讲就是你用鼠标的一次“单击”登录按钮的操作，这个单击操作可能向服务器发出了90多个HTTP请求，但我们只能看作是1个事务。
6．资源利用率
指的是对不同系统资源的使用程度，主要针对Web服务器、应用服务器、数据库服务器、网络情况等。
常见的资源有CUP占用率、内存使用率、磁盘I/O、网络。
（1）CPU
CPU就像人的大脑，主要进行各种判断和处理，能反应计算机的繁忙程度，如果CPU占用率达到100%，此时用户就无法做任何操作了。
（2）内存
内存就像人的某个记忆区域，将信息收集和存放起来，此区域能够存放的信息量越多，计算机的反应也就越快，但关机后该区域的信息将被清空。（从内存读取数据要比从硬盘上快得多。）
（3）磁盘I/O
I/O是指磁盘的输入和输出（Input和Output的缩写），读IO，就是发指令，从磁盘读取某段扇区的内容。指令一般是通知磁盘开始扇区位置，然后给出需要从这个初始扇区往后读取的连续扇区个数，同时给出动作是读，还是写。磁盘收到这条指令，就会按照指令的要求，读或者写数据。控制器发出的这种指令＋数据，就是一次IO，读或者写。重点关注的是IO交换频率和磁盘队列长度。
（4）网络
主要指网络流量，看是否是网络带宽的瓶颈。例如，论坛首页2GB的吞吐量将消耗掉16Gbps的带宽。
学习笔记
笔记一：吞吐量、吞吐率、TPS需要加以区分和理解，但实际工作中三者往往可以相互转换，并没有分得太清楚。
笔记二：测试人员眼中的性能关注点，也就是未来性能分析的主要关注指标，指标的具体值就体现了当前系统在特定环境下的工作状态，需要理解并记住它们。
本书读者交流QQ群：425860640，欢迎加入~~
本文选自《性能测试学习笔记之 LoadRunner实战》第一章，本站经人民邮电出版社和作者的授权。
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
