第一章 軟體性能測試基本概念和流程
1.1 軟體性能的定義
通常來說，性能首先是一種名額，表明軟體系統或構件對其即時性要求的符合程度；其次是軟體産品的的一種特性，可以用時間來進行衡量。性能的及時性用響應時間或吞吐量來衡量。響應時間是對請求做出的響應所需要的時間。
通常，對軟體的關注是多個層面的。如果按使用者劃分為：使用者、管理者和産品的開發人員。于此還有一個重要的是Web的前端性能。
從使用者的角度來說，軟體性能就是軟體對使用者操作的響應時間。
從管理者的角度來看，軟體系統的性能首先表現在系統的響應時間上，其次管理者還想要知道系統具有多大的可擴充性、處理并發的能力如何、系統可能的最大容量是什麼、系統可能的性能瓶頸在哪裡、通過更換裝置或進行哪些擴充能夠提高系統性能、系統在長時間的運作中是否足夠穩定、是否能夠不間斷地提供業務服務等。管理者關注的部分性能如表1-1所示：
表1-1管理者關注的部分性能相關問題
從開發人員的角度來說，主要關心使用者感受----響應時間；其次，系統的擴充性等管理者關系的内容。圖表1-2開發人員關注的部分性能問題:
表1-2開發人員關注的部分性能問題
Web前端性能考察的主要是浏覽器的展現和腳本執行時間，通常對前端性能的關注主要在浏覽器展現頁面的方式、浏覽器各種執行機制的合理應用及腳本的合理性。如何提高浏覽器下載下傳和執行資源的并發性，如何讓浏覽器盡快渲染頁面，如何讓浏覽器盡可能充分利用緩存等問題是前端性能關注的重點。
1.2 軟體性能的幾個主要術語
1.2.1 響應時間
響應時間是“對請求做出響應所需要的時間”，而且，通常把響應時間作為使用者時間軟體性能的主要展現。
1.2.2 并發使用者數
在實際的性能測試過程中，測試人員一般比較關心業務并發使用者數，也就是從業務的角度關注究竟應該設定多少并發使用者數比較合理，是以性能測試中直接将業務并發使用者數稱為并發使用者數。下面給出一些用于估算并發使用者數的公式：
在公式（1）中，C是指平均的并發使用者數；n是登入 session的數量；L是登入 session的平均時間長度；T指考察的時間段長度。例如，對一個典型的OA應用，考察的時間段長度應該為8h的工作時間。
在公式（2）則給出了并發使用者數峰值的計算方式，其中，Ĉ指并發使用者數的峰值；C是公式（1）中得到的平均并發使用者數。
執行個體：假設一個OA系統，該系統有3000個使用者，平均每天大約有400個使用者要通路該系統，對一個典型使用者來說，一隻隻在8h内使用該系統，且登入到退出該系統的平均時間為4h。根據公式（1）和公式（2）：可以得到:
C=400X4/8=200; Ĉ≈200+3X=242
1.2.3吞吐量
指機關時間内系統處理使用者的請求數
從業務角度看，吞吐量可以用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等機關來衡量；從網絡角度看，吞吐量可以用：位元組/秒來衡量；對于互動式應用來說，吞吐量名額反映的是伺服器承受的壓力，他能夠說明系統的負載能力，以不同方式表達的吞吐量可以說明不同層次的問題，例如，以位元組數/秒方式可以表示數要受網絡基礎設施、伺服器架構、應用伺服器制約等方面的瓶頸；已請求數/秒的方式表示主要是受應用伺服器和應用代碼的制約展現出的瓶頸。
當沒有遇到性能瓶頸的時候，吞吐量與虛拟使用者數之間存在一定的聯系，可以采用以下公式計算：F=VU * R / T
其中F為吞吐量，VU表示虛拟使用者個數，R表示每個虛拟使用者發出的請求數，T表示性能測試所用的時間
1.2.3 性能計數器
是描述伺服器或作業系統性能的一些資料名額，如使用記憶體數、程序時間，在性能測試中發揮着“監控和分析”的作用，尤其是在分析統統可擴充性、進行新能瓶頸定位時有着非常關鍵的作用。
資源使用率：指系統各種資源的使用情況，如cpu占用率為68%，記憶體占用率為55%，一般使用“資源實際使用/總的資源可用量”形成資源使用率。
1.2.4 思考時間
Think Time，從業務角度來看，這個時間指使用者進行操作時每個請求之間的時間間隔，而在做新能測試時，為了模拟這樣的時間間隔，引入了思考時間這個概念，來更加真實的模拟使用者的操作。
在吞吐量這個公式中F=VU * R / T說明吞吐量F是VU數量、每個使用者發出的請求數R和時間T的函數，而其中的R又可以用時間T和使用者思考時間TS來計算：R = T / TS
下面給出一個計算思考時間的一般步驟：
A、首先計算出系統的并發使用者數
C=nL / T F=R×C
B、統計出系統平均的吞吐量
F=VU * R / T R×C = VU * R / T
C、統計出平均每個使用者發出的請求數量
R=u*C*T/VU
D、根據公式計算出思考時間
TS=T/R
1.3 性能測試的流程
該性能測試流程，以loadrunner性能測試設計與實作的。
1.3.1 性能測試需求分析
-
標明測試業務場景
根據使用者需求中所描述的系統架構來分析，性能測試的重點表現在哪幾個方面，如：并發通路的性能、資料交換的性能、批處理業務執行效率、系統處理的穩定性等，同時結合系統架構分析可能存在的性能瓶頸，這個也是選擇測試業務場景的基礎。
根據使用者需求并結合實際，不要做到全部業務覆寫，但盡量做到對不同業務類型和操作類型的覆寫，操作類型的覆寫，如；對資料庫的讀操作（簡單查詢、複雜查詢）、資料庫的寫操作（如：插入、删除和更新），選取一些典型的業務操作作為測試業務場景。
-
分析性能測試名額
1）根據使用者需求和所選取的典型業務場景，首先選取性能名額項，如：并發使用者數、交易響應時間、每秒交易數（TPS）、伺服器資源占用率、網絡吞吐量等；
2）在選取性能名額項後，根據使用者需求或總體設計文檔對性能名額進行分析，獲得各個性能名額項值，如：使用者需求中說明了某個業務使用的使用者數為N，但沒有說明并發使用者數，可以按照10%N~20%N來誰都能夠并發使用者數；有的文檔中會提到一年會處理多少業務量，那麼可以按照28原則計算出每秒交易數（TPS）。
1.3.2準備工作
- 測試環境搭建
測試環境要盡量與系統運作的真實環境大緻一緻，也有一些要求：
1）測試環境時盡可能的模拟系統上線運作環境
搭建測試環境時應充分考慮使用者的使用環境，盡可能模拟使用者實際使用的軟硬體環境，這對性能測試來講尤為重要，如果生産環境和測試環境相差過大，則測試結果沒有參考價值。要求被測系統的硬體配置應與生産部署一緻，所安裝的軟體版本與預期測試的版本号一緻。
2)營造獨立的測試環境
被測系統在預期性能測試執行期間應保證其資源獨占性，即測試過程中要確定我們的測試環境獨立，避免測試環境被占用，影響測試進度及測試結果，比如裝置連網後，如果其他開發組或測試組也在共用，這樣就可能影響我們的測試結果。有時開發人員為确定問題會使用我們的測試環境，這樣會打亂我們的測試活動，更嚴重的是影響測試進度。是以需要為本次測試搭建獨立的測試環境。
3）建構可複用的測試環境
項目實際執行過程中，測試環境是經常變化，比如測試軟體版本更新、測試人員流失等等，需要随時跟蹤和改進，盡量将可控的資源進行分類整理。可控資源包括：測試環境配置手冊、測試硬體資訊、環境變更記錄等等，目的是盡量将測試環境進行備份，友善出現未知問題時快速的還原。當剛搭建好測試環境，安裝測試軟體之前及測試過程中，對作業系統及測試環境進行備份是必要的，這樣一來可以為我們下輪測試時直接恢複測試環境，避免重新搭建測試環境花費時間，二來在當測試環境遭到破壞時，可以恢複測試環境，避免測試資料丢失，重制問題。
- 測試資料準備
在實施性能測試時，需要運作系統相關業務，這時需要一些資料支援才可運作業務，這部分資料即為初始測試資料，資料準備和清理的工作量是非常大的，需要在測試前提前考慮。
為更加真實的模拟現實運作環境，我們在測試過程中，應盡可能準備與真實業務執行相一緻的初始資料，如系統使用者資料、業務資料、輔助資料等。
- 系統使用者資料：登陸系統使用的帳戶名-密碼等，數量與虛拟使用者數一緻；
- 業務資料：每個虛拟使用者模拟真實使用者進行操作時使用到的資料；
-
輔助資料：為保證業務操作的正常進行而設定的基本資訊資料。
此外，測試資料可分可重用和不可重用資料：
- 可重用資料：如客戶資訊等查詢類的資料，此類資料隻需一次準備即可；
- 不可重用資料：此類資料為一次性消耗資料，不可重用，一般應用在資料增加或修改類業務交易，此類資料如增加客戶辨別、帳戶辨別等。
- 測試環境配置
1）RPC服務。監控伺服器資源使用率需要打開系統RPC服務，RPC打開步驟參考詳見《監控配置文檔》。
2）Agent process。該服務是loadrunner的服務，它的作用是實作控制多台機器同時進行并發，安裝了loadrunner的每台機器都會有該服務，隻要打開該服務，然後在loadrunner的控制台的Loadgenerator中加入打開該服務的機器的IP位址即可。
3）監控伺服器資源使用率。在Loadrunnercontroller中加入所要監控伺服器，選擇監控的性能名額。
1.3.3設計并調試腳本
錄制和調試腳本可以具體參見其他的資料，不過要注意靜态關聯和動态關聯的問題。
1.3.4執行腳本
将所錄制和調試好的加入到Loadrunner controller控制台中，設定好測試場景，如：并發使用者數、排程和運作模式（真實運作模式還是經典模式、虛拟使用者加載方式、運作周期）等。