第一章 性能測試基礎
------在交流群中很多測試同道都比較偏向性能測試，在公司質量測試部門收集到的學習方向大多數同事也集中在性能測試的方向上；也有很多人問“我要搞性能測試，沒有基礎，應該從哪開始”。
------其實這個問題，既簡單有復雜。
第一節(jié) 簡單又復雜
首先問一個問題:
---我們?yōu)槭裁匆鲂阅軠y試？
很多人會回答“項目需要”，可是有沒有想過項目為什么需要做性能測試？
簡單點說:是因為系統(tǒng)的訪問量和操作量比較頻繁，大量用戶的頻繁操作必然會產生一些用戶在同時（Same Time）操作一些功能，這就需要系統(tǒng)能夠處理這些Same Time操作或者處理速度非常快行，而我們的項目需要節(jié)約成本，就需要采用合適的方案來滿足這些方面的要求。
我們平時做功能測試實際上是模擬一個用戶在對系統(tǒng)的功能進行操作。如果系統(tǒng)有大量的用戶訪問、有比較頻繁的操作量或者說比較大的業(yè)務量，那我們需要驗證一下大數據量的、頻繁的操作等我們系統(tǒng)是否能夠處理好。
所以，性能測試實際上就是功能測試的延伸，只不過需要模擬大量的用戶或者大量的、頻繁的對系統(tǒng)進行實際功能操作；同時我們需要判斷這些這樣的操作下系統(tǒng)是否滿足業(yè)務的實際要求。
---模擬用戶的大量頻繁操作，監(jiān)控系統(tǒng)中各個節(jié)點的資源耗用情況，找到系統(tǒng)的處理極限或者瓶頸所在，評估系統(tǒng)整體是否能夠滿足要求或者是否優(yōu)化系統(tǒng)以及制定優(yōu)化方案；這，就是性能測試。
OK，那么系統(tǒng)為什么會出現瓶頸呢？
因為：
1） 系統(tǒng)有大量的頻繁的訪問需求；
2） 系統(tǒng)的固有資源有限（處理速度有限）；
3） 我們在開發(fā)系統(tǒng)的時候往往收到各種業(yè)務上的限制，并且我們的技術可能并不是足夠完美；
等等，各種因素造就了我們開發(fā)出來的軟件系統(tǒng)會存在運行速度不夠快、不能夠滿足用戶的大量的頻繁的操作需求。
大多數的性能指導書籍都是從性能需求或者性能指標開始講起，我個人開始看這方面的書籍的時候已經從事性能測試有一段時間了，對性能基本上有一個大概的印象，所以看這些書的時候還是能很快弄明白的；但是，多年以后我再重溫這些書籍的時候，卻在想：如果我是一個“小白”，我能理解么?大多數回答都是“NO”。所以我就在想我應該從哪個點入手來跟大家聊一聊“一個小白應該怎么辦呢？”
多年以后，再次回首之前的性能測試之路，總結了一下個人經驗，性能測試的基礎可以總結為五個字：簡單又復雜。
從簡單開始
首先，我們來看一張圖
這實際就是我們一般系統(tǒng)的整體運行流程，也可以說是所有系統(tǒng)的基本運行圖，如果說這就是性能測試的基礎，大家會是什么反應？
可能有人會說“開玩笑吧，這不是功能測試的一般原型么？”
沒錯，在我看來所有的測試都是這樣的（也還包括單元測試、接口測試等等都是這樣）。
性能測試原本就是功能測試內容的擴展，只是它的目的不一樣而已。
前面說到了我們?yōu)槭裁匆鲂阅軠y試，其實性能測試的基礎原理就包含在里面:利用一些技術手段，模擬用戶的大量頻繁（功能）操作，找到系統(tǒng)的瓶頸所在，對系統(tǒng)進行一定的優(yōu)化和改進，并驗證系統(tǒng)是否能夠滿足用戶需求，提高用戶滿意度。
漸入復雜
“利用一些技術手段，模擬用戶的大量頻繁（功能）操作，找到系統(tǒng)的瓶頸所在，對系統(tǒng)進行一定的優(yōu)化和改進，并驗證系統(tǒng)是否能夠滿足用戶需求，提高用戶滿意度?！?/p>
再來對照上面的性能測試基礎原理，逐漸提一些問題：
(1) 利用一些技術手段---有哪些技術手段？怎么利用？
(2) 模擬用戶大量頻繁操作---怎么模擬？頻繁程度怎么控制？
(3) 找到系統(tǒng)瓶頸所在---怎么找？
(4) 對系統(tǒng)進行一定的優(yōu)化和改進？---怎么優(yōu)化、改進？
(5) 驗證系統(tǒng)是否滿足用戶需求，提高用戶滿意度---用戶需求怎么確定和判斷？怎么提高用戶滿意度？
OK，這些都是需要解決的問題。
原來簡單的原理，應用起來逐漸復雜起來了。
問題多了，我們從哪兒入手呢？
做事情總有一個目的和目標，同樣的，性能測試首先需要確認目標和目的，也就是用戶需求是什么或者系統(tǒng)要達到什么樣的性能目標。
然后，就是我們需要去驗證這個目標是否達到，我們需要一些度量策略和標準來確認目標是否達到，是否需要優(yōu)化。
度量的過程需要有數據支撐，需要對比系統(tǒng)的實際運行數據和目標標準的差異，最終來進行判斷是否滿足標準或者需求。
這些數據就需要我們來采集，采集系統(tǒng)運行過程中的數據。
度量結果出來后，我們需要對存在瓶頸的節(jié)點進行優(yōu)化處理。
回歸到最后了，我們需要了解系統(tǒng)怎么運行的才能決定在哪些點進行數據采集；并且我們需要了解系統(tǒng)怎么運行的才能對存在的瓶頸進行優(yōu)化，如果對系統(tǒng)本身都不了解又從哪里入手進行優(yōu)化呢？
所以，下面這張圖來了
圖看起來復雜了，我們面對的問題也逐漸復雜了起來。
簡單又復雜
面對上節(jié)漸入復雜的系統(tǒng)流向圖，我們還是要慢慢分析:
每一個app的運行都離不開一個操作系統(tǒng)環(huán)境，這個環(huán)境可能是一個或者多個操作系統(tǒng)組成，對多個操作系統(tǒng)我們可以分解成單個的操作系統(tǒng)來分析。
將上面的復雜流程圖分解開來就是下面這樣
所以，我們最后的基礎就在需要了解一個應用在操作系統(tǒng)中是怎么運行的。
哦，終于到了基礎中的基礎：就是操作系統(tǒng)的運行原理。
每一個app應用都會有自己所要實現的功能，它們最終都是需要依靠操作系統(tǒng)來支撐來實現其功能的實現。
每一個app要么通過DISK的code、要么通過RAM里面的code、要么通過NET里面的code向操作系統(tǒng)發(fā)出指令，操作系統(tǒng)處理后，返回相應的響應給操作系統(tǒng)或者DISK、RAM、NET等；就如下圖。
然而，對于一個操縱系統(tǒng)來說，它所有的（app）應用程序最后都直接或者間接的由操作系統(tǒng)轉化成CPU指令集來實現，所以，我們追逐到根本就是需要了解CPU以怎樣的流程來執(zhí)行操作系統(tǒng)的指令。
那么CPU是怎么工作的呢？
首先，我們要明確的知道一點，單個CPU在同一時刻只能執(zhí)行或者處理一條指令，從CPU的角度來說不存在“并發(fā)”執(zhí)行的概念。
其次，性能測試有并發(fā)的概念，而且我們實際操作也存在并發(fā)（同一時刻同時執(zhí)行一些操作），那么服務器的CPU是怎么來處理這個需求的呢？
其實，CPU它“不能處理”，它對我們進行了欺騙，它不能處理，但是卻讓我們以為它在同一時刻處理這些事情。
那我們就需要了解一下CPU是怎么欺騙我們的。（這里有個非常重要的概念---“時間片”）
因為，我們（人類）無論是視覺還是感覺都會存在延遲。
舉例說個大家基本都了解的“視覺延遲”，一般正常的人類視覺延遲（更多的時候會說成是視覺暫留，產生原因是神經反應速度，詳細大家可以下去了解下）是0.02~0.1之間(正常在二十四分之一秒左右，部分人反應迅速，有可能達到0.03，也有部分遲鈍些，可能達到0.06)。
CPU正是利用了這些延遲，把1秒（或者更短）的時間分成了很多更加短小的時間片，在每一個更小的時間片段中執(zhí)行一個指令，這樣在我們能夠感知的時間內就可以執(zhí)行多個指令，讓我們覺著它是在并行處理。
正是有了時間片的概念，才有了“并發(fā)”。從極限的思想出發(fā)是不存在并發(fā)的。
OK，接下來，我們看看CPU的基本工作原理，還是一張圖:
沒錯，單個CPU就是這樣永不休止的執(zhí)行著，直到斷電關機。
拋開應用程序實際就是下圖的關系:
總結起來就是CPU指令和RAM、DISK、NET的交互。
那我們就需要從CPU，RAM，DISK，NET這些最基本的開始了解起來。
而CPU是最基礎的應該了解的內容。
CPU的工作原理：由RAM、DISK、NET等發(fā)送一些code命令、數據、指令到CPU的存儲單元，CPU的調度控制單元對這些指令進行排序控制，發(fā)送到運行單元進行運行，當運行時間片到時間時不管指令是否完成，都將結束當前的指令運行，進行下一個指令的運行，將前一個指令的運行結果反饋回來，并在此時對指令隊列進行重新排序和調度（時間片內未執(zhí)行完的指令會進行重新排序，有可能將不再是排在第一位），進入新的一輪調度運行；反復進行這個流程運行，知道斷電關機。
------------aceaoh
