|
第一章 性能测试基础
------在交流群中很多测试同道都比较偏向性能测试，在公司质量测试部门收集到的学习方向大多数同事也集中在性能测试的方向上；也有很多人问“我要搞性能测试，没有基础，应该从哪开始”。
------其实这个问题，既简单有复杂。
第一节 简单又复杂
首先问一个问题:
---我们为什么要做性能测试？
很多人会回答“项目需要”，可是有没有想过项目为什么需要做性能测试？
简单点说:是因为系统的访问量和操作量比较频繁，大量用户的频繁操作必然会产生一些用户在同时（Same Time）操作一些功能，这就需要系统能够处理这些Same
Time操作或者处理速度非常快行，而我们的项目需要节约成本，就需要采用合适的方案来满足这些方面的要求。
我们平时做功能测试实际上是模拟一个用户在对系统的功能进行操作。如果系统有大量的用户访问、有比较频繁的操作量或者说比较大的业务量，那我们需要验证一下大数据量的、频繁的操作等我们系统是否能够处理好。
所以，性能测试实际上就是功能测试的延伸，只不过需要模拟大量的用户或者大量的、频繁的对系统进行实际功能操作；同时我们需要判断这些这样的操作下系统是否满足业务的实际要求。
---模拟用户的大量频繁操作，监控系统中各个节点的资源耗用情况，找到系统的处理极限或者瓶颈所在，评估系统整体是否能够满足要求或者是否优化系统以及制定优化方案；这，就是性能测试。
OK，那么系统为什么会出现瓶颈呢？
因为：
1） 系统有大量的频繁的访问需求；
2） 系统的固有资源有限（处理速度有限）；
3） 我们在开发系统的时候往往收到各种业务上的限制，并且我们的技术可能并不是足够完美；
等等，各种因素造就了我们开发出来的软件系统会存在运行速度不够快、不能够满足用户的大量的频繁的操作需求。
大多数的性能指导书籍都是从性能需求或者性能指标开始讲起，我个人开始看这方面的书籍的时候已经从事性能测试有一段时间了，对性能基本上有一个大概的印象，所以看这些书的时候还是能很快弄明白的；但是，多年以后我再重温这些书籍的时候，却在想：如果我是一个“小白”，我能理解么?大多数回答都是“NO”。所以我就在想我应该从哪个点入手来跟大家聊一聊“一个小白应该怎么办呢？”
多年以后，再次回首之前的性能测试之路，总结了一下个人经验，性能测试的基础可以总结为五个字：简单又复杂。
从简单开始
首先，我们来看一张图
1-1
这实际就是我们一般系统的整体运行流程，也可以说是所有系统的基本运行图，如果说这就是性能测试的基础，大家会是什么反应？
可能有人会说“开玩笑吧，这不是功能测试的一般原型么？”
没错，在我看来所有的测试都是这样的（也还包括单元测试、接口测试等等都是这样）。
性能测试原本就是功能测试内容的扩展，只是它的目的不一样而已。
前面说到了我们为什么要做性能测试，其实性能测试的基础原理就包含在里面:利用一些技术手段，模拟用户的大量频繁（功能）操作，找到系统的瓶颈所在，对系统进行一定的优化和改进，并验证系统是否能够满足用户需求，提高用户满意度。
渐入复杂
“利用一些技术手段，模拟用户的大量频繁（功能）操作，找到系统的瓶颈所在，对系统进行一定的优化和改进，并验证系统是否能够满足用户需求，提高用户满意度。”
再来对照上面的性能测试基础原理，逐渐提一些问题：
(1) 利用一些技术手段---有哪些技术手段？怎么利用？
(2) 模拟用户大量频繁操作---怎么模拟？频繁程度怎么控制？
(3) 找到系统瓶颈所在---怎么找？
(4) 对系统进行一定的优化和改进？---怎么优化、改进？
(5) 验证系统是否满足用户需求，提高用户满意度---用户需求怎么确定和判断？怎么提高用户满意度？
OK，这些都是需要解决的问题。
原来简单的原理，应用起来逐渐复杂起来了。
问题多了，我们从哪儿入手呢？
做事情总有一个目的和目标，同样的，性能测试首先需要确认目标和目的，也就是用户需求是什么或者系统要达到什么样的性能目标。
然后，就是我们需要去验证这个目标是否达到，我们需要一些度量策略和标准来确认目标是否达到，是否需要优化。
度量的过程需要有数据支撑，需要对比系统的实际运行数据和目标标准的差异，最终来进行判断是否满足标准或者需求。
这些数据就需要我们来采集，采集系统运行过程中的数据。
度量结果出来后，我们需要对存在瓶颈的节点进行优化处理。
回归到最后了，我们需要了解系统怎么运行的才能决定在哪些点进行数据采集；并且我们需要了解系统怎么运行的才能对存在的瓶颈进行优化，如果对系统本身都不了解又从哪里入手进行优化呢？
所以，下面这张图来了
1-2
图看起来复杂了，我们面对的问题也逐渐复杂了起来。
简单又复杂
面对上节渐入复杂的系统流向图，我们还是要慢慢分析:
每一个app的运行都离不开一个操作系统环境，这个环境可能是一个或者多个操作系统组成，对多个操作系统我们可以分解成单个的操作系统来分析。
将上面的复杂流程图分解开来就是下面这样
1-3
所以，我们最后的基础就在需要了解一个应用在操作系统中是怎么运行的。
哦，终于到了基础中的基础：就是操作系统的运行原理。
每一个app应用都会有自己所要实现的功能，它们最终都是需要依靠操作系统来支撑来实现其功能的实现。
每一个app要么通过DISK的code、要么通过RAM里面的code、要么通过NET里面的code向操作系统发出指令，操作系统处理后，返回相应的响应给操作系统或者DISK、RAM、NET等；就如下图。
1-4
然而，对于一个操纵系统来说，它所有的（app）应用程序最后都直接或者间接的由操作系统转化成CPU指令集来实现，所以，我们追逐到根本就是需要了解CPU以怎样的流程来执行操作系统的指令。
那么CPU是怎么工作的呢？
首先，我们要明确的知道一点，单个CPU在同一时刻只能执行或者处理一条指令，从CPU的角度来说不存在“并发”执行的概念。
其次，性能测试有并发的概念，而且我们实际操作也存在并发（同一时刻同时执行一些操作），那么服务器的CPU是怎么来处理这个需求的呢？
其实，CPU它“不能处理”，它对我们进行了欺骗，它不能处理，但是却让我们以为它在同一时刻处理这些事情。
那我们就需要了解一下CPU是怎么欺骗我们的。（这里有个非常重要的概念---“时间片”）
因为，我们（人类）无论是视觉还是感觉都会存在延迟。
举例说个大家基本都了解的“视觉延迟”，一般正常的人类视觉延迟（更多的时候会说成是视觉暂留，产生原因是神经反应速度，详细大家可以下去了解下）是0.02~0.1之间(正常在二十四分之一秒左右，部分人反应迅速，有可能达到0.03，也有部分迟钝些，可能达到0.06)。
CPU正是利用了这些延迟，把1秒（或者更短）的时间分成了很多更加短小的时间片，在每一个更小的时间片段中执行一个指令，这样在我们能够感知的时间内就可以执行多个指令，让我们觉着它是在并行处理。
正是有了时间片的概念，才有了“并发”。从极限的思想出发是不存在并发的。
OK，接下来，我们看看CPU的基本工作原理，还是一张图:
1-5
没错，单个CPU就是这样永不休止的执行着，直到断电关机。
抛开应用程序实际就是下图的关系:
1-6
总结起来就是CPU指令和RAM、DISK、NET的交互。
那我们就需要从CPU，RAM，DISK，NET这些最基本的开始了解起来。
而CPU是最基础的应该了解的内容。
CPU的工作原理：由RAM、DISK、NET等发送一些code命令、数据、指令到CPU的存储单元，CPU的调度控制单元对这些指令进行排序控制，发送到运行单元进行运行，当运行时间片到时间时不管指令是否完成，都将结束当前的指令运行，进行下一个指令的运行，将前一个指令的运行结果反馈回来，并在此时对指令队列进行重新排序和调度（时间片内未执行完的指令会进行重新排序，有可能将不再是排在第一位），进入新的一轮调度运行；反复进行这个流程运行，知道断电关机。
| 
