本节书摘来自华章计算机《LoadRunner性能测试巧匠训练营》一书中的第1章，第1.1节,作者：赵 强 邹伟伟 任健勇 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
第1章 与性能测试的亲密触碰
性能测试的挑战性和趣味性小白早有耳闻，也会经常听到各个公司因为系统性能而引发的一系列严重问题，所以性能测试会越来越受到重视，只是时间的问题。下面就让我们和小白先来了解下性能测试的趣事，再一同学习性能测试的基本知识。
1.1 性能测试的作用以及重要性
随着社会的发展，用户对产品的要求也越来越高，以前可能看重功能方面，现在正在逐步转变为性能方面，同时各大公司也加强了产品的性能测试，因为从这几年发生的事件来看，性能带来的严重问题以及损失不容忽视，而性能测试的重要性也不言而喻。
1.1.1 由性能引发的严重问题
小白印象中由性能引发的严重问题历历在目，大部分都是由于没有做性能测试、性能测试做得不充足或者对并发以及流量的预估不正确导致。
【案例1】2008年的奥运会票务系统，由于庞大的订票人数超出预期，奥运票务系统“开工”后不久便陷入“瘫痪”状态，当时对外公布的是奥运票务系统每小时能处理15万张门票的销售，以及承担每小时100万次以上的网上浏览量，但10月30日系统死机前每小时的网上浏览量达到800万，1小时售出的票也达到了20万张。由于预估工作的缺陷，导致很多人无法通过网络订到自己想要的票，影响了很多人的热情，也损害了国家形象。
【案例2】作为电商的代表，2009年11月22日，eBay网站出现死机，导致卖家至少损失了当日销售额的80%，原因是那年圣诞临近时，eBay网站上有超过2亿件待售商品，这个数字比上一年同期多出33%，正是这激增的33%的待售商品导致eBay网站不堪重负而死机，80%的销售额对于eBay来说不可谓不严重。
【案例3】魔兽世界在中国的代理商由九城变更为网易，与九城服务器经常死机不无关系，但是换作网易后，服务器也经常死机。2010年10月11日，魔兽世界服务器故障时，官网论坛上的游戏玩家纷纷发“贺词”表示不满，从这可以看出网易公司对魔兽世界的性能预估存在不足。也正是因为对性能严重忽视间接导致了九城在失去魔兽世界之后，从一家土豪公司成了一家几乎被人遗忘的公司。
【案例4】视频网站优酷网也在2010年发生死机事件，超过3小时无法访问。优酷对外宣称的原因是：此次死机事件起源于“地球一小时”活动，优酷网为响应这次活动，全站采用关灯模式，意在借此提醒网民注重环保与节约。但此举令网友一时无法适应，大量网友频繁刷新页面导致优酷网服务器崩溃。
【案例5】2010年，中国最大的微博平台新浪微博死机4小时，新浪官方解释说：之所以掉线几小时，是因为用户增长超出预期，服务器备感压力。自上午10点起，用户无法登录，新浪的报错页面几次更改，最初的“微博正在升级，将于11:30恢复”，然后改为“12:00恢复”，过了一段时间，干脆改为“稍后恢复”，然而，估计是看不到恢复希望，提示信息又改为“微博系统压力过大正在抢修，我们深表歉意”。悲剧的是“歉意”竟然写成了“谦意”，这件事遭到网友的大量恶搞，小白也是参与者之一。
1.1.2 性能测试的重要性以及必要性
根据2008年Aberdeen Group的研究报告表明，Web网站1s的页面加载延迟相当于少了11%的PV，相当于降低了16%的顾客满意度。如果从金钱的角度计算，就意味着：如果一个网站每天挣10万元，那么一年下来，由于页面加载速度比竞争对手慢1s，可能导致总共损失25万元的销售额。
Compuware公司分析了超过150个网站和150万个浏览页面，发现页面响应时间从2s增长到10s，会导致38%的页面浏览放弃率。
Radware也曾发布一份题为“行业现状：2013年春季电商页面速度与Web性能”的调查报告。报告指出，仅一年时间内，美国前2000家领先的在线零售商网站的加载时间较去年同期减慢了22%，网站性能急剧下降，用户体验质量大幅下降。对网站回访率、跳出率、客户满意度及在线收入等多个关键业务指标的影响越来越大，对在线零售商而言，网站加载速度已经成为制约其发展的重要因素，提升Web性能已经刻不容缓。
2014年中国电子商务研究中心发布对电商网站的调查报告，报告中指出用户对网站响应时间的要求很严苛，期望立刻做出响应的占90%，期望5min内做出响应的占10%。
从上面的研究分析再结合小白印象中列举的例子可以看出，性能测试非常重要也非常必要，因为性能问题不仅仅会损害公司的形象，也会造成公司资金方面的损失。
1.1.3 什么系统需要做性能测试
小白刚接触到“什么系统需要做性能测试”这个问题的时候，心里在想应该是大型的系统、软件才需要做性能测试，如果只是几个人用就没有必要了。可仔细想想，小白觉得应该是所有系统、软件都应该做性能测试，关键是要思考应该做到什么程度，而不是做不做的问题。因为就算是一个人在使用某个系统，但该系统的查询性能极差，一次查询需要50多秒钟，这绝对是任何人都难以接受的。
接着小白对现有的系统进行了分类，大致分为单机系统、C/S、B/S。这3类系统都应该进行性能测试，只是每个分类有各自特点，在实际测试中应该有不同策略进行应对。
一般C/S架构的应用程序更关注于系统资源使用情况、数据库性能以及运行的配置要求等。例如，内存、用户连接数、数据库死锁、数据库cache命中率、运行的最低配置等。
而对于B/S架构的应用程序，会关注Web服务器的相关指标，如每秒点击数、吞吐量、尝试连接数、事务成功率等。
如下几个案例分别针对典型的系统进行了说明。
【案例1】假设使用Word来编辑一个1 000多页的文档，该文档包含了丰富的图表、图片，需要等待系统花多少秒的时间进行处理。这时需要关注性能响应。
【案例2】某业务系统属于二次开发，之前没有做过性能测试，当并发100个用户时就会造成数据库服务器崩溃。这是很明显的性能问题。
【案例3】某企业内部信息系统，使用人比较少，但并发时会出现重复的相同记录。这种场景很难在功能测试时出现，所以有时候性能测试并不是只能发现性能问题。
【案例4】面向广大互联网人群的网站，每天都需要接受大量的访问请求，服务器压力大，对这样的系统进行性能测试是十分必要的。
其中B/S架构的系统会比较复杂，小白接到的正好是B/S的项目，看来这下需要学习一番了。
1.1.4 性能测试的目的
很多第一次接触性能测试的人都会把功能测试的思想带入，造成思维的局限。其实性能测试还是与功能测试有所不同的。性能测试更加关注系统的性能表现，也就是How fast和How much。而做性能测试就是排除系统瓶颈，使得它表现得更好、更霸气。可以从以下几个方面来理解。
1）评估当前系统。系统未做过任何性能测试，对系统的当前性能情况不了解，就好像没有体检过就不知道自己的身体状况一样。而此前说到的一系列性能引发的严重问题也正是由于缺少了必要的性能评估而导致。
2）寻找瓶颈，优化性能。常见的现象为，某业务操作响应时间很长、某系统上线一段时间后运行越来越慢，这些都需要逐步分析定位并调优。
3）预测未来性能。当用户数和业务量增加时能否及时应对？如何调整？是增加应用服务器，还是数据库服务器？还是要优化代码逻辑？这一系列问题都值得我们深思，这也是性能测试的目的所在。回想1.1.1节中的eBay不就是最好的例子吗。
