效能測試基礎——（CPU）

發表於：2017-8-01 11:12  作者：aceaoh   來源：51Testing軟體測試網採編

字型：大 中 小 | 上一篇 | 下一篇 |我要投稿 | 推薦標籤： 效能測試 軟體測試技術

　　效能測試基礎

　　------在交流群中很多測試同道都比較偏向效能測試，在公司質量測試部門收集到的學習方向大多數同事也集中在效能測試的方向上；也有很多人問“我要搞效能測試，沒有基礎，應該從哪開始”。

　　------其實這個問題，既簡單有複雜。

　　第一節 簡單又複雜

　　首先問一個問題:

　　---我們為什麼要做效能測試？

　　很多人會回答“專案需要”，可是有沒有想過專案為什麼需要做效能測試？

　　簡單點說:是因為系統的訪問量和操作量比較頻繁，大量使用者的頻繁操作必然會產生一些使用者在同時（Same Time）操作一些功能，這就需要系統能夠處理這些Same Time操作或者處理速度非常快行，而我們的專案需要節約成本，就需要採用合適的方案來滿足這些方面的要求。

　　我們平時做功能測試實際上是模擬一個使用者在對系統的功能進行操作。如果系統有大量的使用者訪問、有比較頻繁的操作量或者說比較大的業務量，那我們需要驗證一下大資料量的、頻繁的操作等我們系統是否能夠處理好。

　　所以，效能測試實際上就是功能測試的延伸，只不過需要模擬大量的使用者或者大量的、頻繁的對系統進行實際功能操作；同時我們需要判斷這些這樣的操作下系統是否滿足業務的實際要求。

　　---模擬使用者的大量頻繁操作，監控系統中各個節點的資源耗用情況，找到系統的處理極限或者瓶頸所在，評估系統整體是否能夠滿足要求或者是否優化系統以及制定優化方案；這，就是效能測試。

　　OK，那麼系統為什麼會出現瓶頸呢？

　　因為：

　　1） 系統有大量的頻繁的訪問需求；

　　2） 系統的固有資源有限（處理速度有限）；

　　3） 我們在開發系統的時候往往收到各種業務上的限制，並且我們的技術可能並不是足夠完美；

　　等等，各種因素造就了我們開發出來的軟體系統會存在執行速度不夠快、不能夠滿足使用者的大量的頻繁的操作需求。

　　大多數的效能指導書籍都是從效能需求或者效能指標開始講起，我個人開始看這方面的書籍的時候已經從事效能測試有一段時間了，對效能基本上有一個大概的印象，所以看這些書的時候還是能很快弄明白的；但是，多年以後我再重溫這些書籍的時候，卻在想：如果我是一個“小白”，我能理解麼?大多數回答都是“NO”。所以我就在想我應該從哪個點入手來跟大家聊一聊“一個小白應該怎麼辦呢？”

　　多年以後，再次回首之前的效能測試之路，總結了一下個人經驗，效能測試的基礎可以總結為五個字：簡單又複雜。

　　從簡單開始

　　首先，我們來看一張圖

　　這實際就是我們一般系統的整體執行流程，也可以說是所有系統的基本執行圖，如果說這就是效能測試的基礎，大家會是什麼反應？

　　可能有人會說“開玩笑吧，這不是功能測試的一般原型麼？”

　　沒錯，在我看來所有的測試都是這樣的（也還包括單元測試、介面測試等等都是這樣）。

　　效能測試原本就是功能測試內容的擴充套件，只是它的目的不一樣而已。

　　前面說到了我們為什麼要做效能測試，其實效能測試的基礎原理就包含在裡面:利用一些技術手段，模擬使用者的大量頻繁（功能）操作，找到系統的瓶頸所在，對系統進行一定的優化和改進，並驗證系統是否能夠滿足使用者需求，提高使用者滿意度。

　　漸入複雜

　　“利用一些技術手段，模擬使用者的大量頻繁（功能）操作，找到系統的瓶頸所在，對系統進行一定的優化和改進，並驗證系統是否能夠滿足使用者需求，提高使用者滿意度。”

　　再來對照上面的效能測試基礎原理，逐漸提一些問題：

　　(1) 利用一些技術手段---有哪些技術手段？怎麼利用？

　　(2) 模擬使用者大量頻繁操作---怎麼模擬？頻繁程度怎麼控制？

　　(3) 找到系統瓶頸所在---怎麼找？

　　(4) 對系統進行一定的優化和改進？---怎麼優化、改進？

　　(5) 驗證系統是否滿足使用者需求，提高使用者滿意度---使用者需求怎麼確定和判斷？怎麼提高使用者滿意度？

　　OK，這些都是需要解決的問題。

　　原來簡單的原理，應用起來逐漸複雜起來了。

　　問題多了，我們從哪兒入手呢？

　　做事情總有一個目的和目標，同樣的，效能測試首先需要確認目標和目的，也就是使用者需求是什麼或者系統要達到什麼樣的效能目標。

　　然後，就是我們需要去驗證這個目標是否達到，我們需要一些度量策略和標準來確認目標是否達到，是否需要優化。

　　度量的過程需要有資料支撐，需要對比系統的實際執行資料和目標標準的差異，最終來進行判斷是否滿足標準或者需求。

　　這些資料就需要我們來採集，採集系統執行過程中的資料。

　　度量結果出來後，我們需要對存在瓶頸的節點進行優化處理。

　　迴歸到最後了，我們需要了解系統怎麼執行的才能決定在哪些點進行資料採集；並且我們需要了解系統怎麼執行的才能對存在的瓶頸進行優化，如果對系統本身都不瞭解又從哪裡入手進行優化呢？

　　所以，下面這張圖來了

　　圖看起來複雜了，我們面對的問題也逐漸複雜了起來。

　　簡單又複雜

　　面對上節漸入複雜的系統流向圖，我們還是要慢慢分析:

　　每一個app的執行都離不開一個作業系統環境，這個環境可能是一個或者多個作業系統組成，對多個作業系統我們可以分解成單個的作業系統來分析。

　　將上面的複雜流程圖分解開來就是下面這樣

　　所以，我們最後的基礎就在需要了解一個應用在作業系統中是怎麼執行的。

　　哦，終於到了基礎中的基礎：就是作業系統的執行原理。

　　每一個app應用都會有自己所要實現的功能，它們最終都是需要依靠作業系統來支撐來實現其功能的實現。

　　每一個app要麼通過DISK的code、要麼通過RAM裡面的code、要麼通過NET裡面的code向作業系統發出指令，作業系統處理後，返回相應的響應給作業系統或者DISK、RAM、NET等；就如下圖。

　　然而，對於一個操縱系統來說，它所有的（app）應用程式最後都直接或者間接的由作業系統轉化成CPU指令集來實現，所以，我們追逐到根本就是需要了解CPU以怎樣的流程來執行作業系統的指令。

　　那麼CPU是怎麼工作的呢？

　　首先，我們要明確的知道一點，單個CPU在同一時刻只能執行或者處理一條指令，從CPU的角度來說不存在“併發”執行的概念。

　　其次，效能測試有併發的概念，而且我們實際操作也存在併發（同一時刻同時執行一些操作），那麼伺服器的CPU是怎麼來處理這個需求的呢？

　　其實，CPU它“不能處理”，它對我們進行了欺騙，它不能處理，但是卻讓我們以為它在同一時刻處理這些事情。

　　那我們就需要了解一下CPU是怎麼欺騙我們的。（這裡有個非常重要的概念---“時間片”）

　　因為，我們（人類）無論是視覺還是感覺都會存在延遲。

　　舉例說個大家基本都瞭解的“視覺延遲”，一般正常的人類視覺延遲（更多的時候會說成是視覺暫留，產生原因是神經反應速度，詳細大家可以下去了解下）是0.02~0.1之間(正常在二十四分之一秒左右，部分人反應迅速，有可能達到0.03，也有部分遲鈍些，可能達到0.06)。

　　CPU正是利用了這些延遲，把1秒（或者更短）的時間分成了很多更加短小的時間片，在每一個更小的時間片段中執行一個指令，這樣在我們能夠感知的時間內就可以執行多個指令，讓我們覺著它是在並行處理。

　　正是有了時間片的概念，才有了“併發”。從極限的思想出發是不存在併發的。

　　OK，接下來，我們看看CPU的基本工作原理，還是一張圖:

　　沒錯，單個CPU就是這樣永不休止的執行著，直到斷電關機。

　　拋開應用程式實際就是下圖的關係:

　　總結起來就是CPU指令和RAM、DISK、NET的互動。

　　那我們就需要從CPU，RAM，DISK，NET這些最基本的開始瞭解起來。

　　而CPU是最基礎的應該瞭解的內容。

　　CPU的工作原理：由RAM、DISK、NET等傳送一些code命令、資料、指令到CPU的儲存單元，CPU的排程控制單元對這些指令進行排序控制，傳送到執行單元進行執行，當執行時間片到時間時不管指令是否完成，都將結束當前的指令執行，進行下一個指令的執行，將前一個指令的執行結果反饋回來，並在此時對指令佇列進行重新排序和排程（時間片內未執行完的指令會進行重新排序，有可能將不再是排在第一位），進入新的一輪排程執行；反覆進行這個流程執行，知道斷電關機。