重讀《從菜鳥到測試架構師》-- 模擬客戶的訪問行爲（上）

上一章，咱們跟着剛剛進入性能測試組的小艾一塊兒初識了什麼是性能測試，也知道了客戶在性能上都關注了些什麼，在組長的教導下，小艾明白了，想要讓用戶獲得最好的性能體驗，最簡單有效的方法就是模擬客戶使用產品時遇到的訪問行爲，這一章節就來聊聊如何來模擬客戶的訪問行爲呢？

更真實更高效的模擬——自動化的性能測試

若是說功能測試還有手動測試和自動測試的選擇，那麼，性能測試則不可避免地要用到自動化測試，即經過程序來模擬實際用戶對於網站的訪問行爲。這裏你們能夠思考下爲何性能測試必須使用自動化來測試~

既然說到須要使用自動化，那麼如何作呢？通常咱們會經過一些本身開發的或者現有的測試工具來實現多用戶混合場景的併發訪問。

通常而言，對於功能繁多的大型軟件的測試來說，一般會設計一個比較完備的測試框架，而非簡單錄製腳本加壓進行測試。

測試框架的要求

1. 測試程序的模塊化和可重用性：實際測試中，不一樣的測試分支可能會有相同的步驟，在定義每一個模塊的時候將輸入/輸出定義清楚是關鍵。 

2. 功能分支的可選擇性：爲了模擬實際客戶的訪問，每每將多個測試分支混合在一塊兒進行併發訪問，所以，測試腳本必須是能夠選擇混合哪些分支的。

3. 可定義的輸入數據：腳本必須能夠定製輸入的數據

4. 高可靠性：對同一套腳本，一樣的輸入，一樣的測試環境，屢次運行出的結果應該相同或很是接近，不然測出的結果沒有可信性

5. 可擴展性：如併發用戶數量、測試時間等的擴展

春節大促——壓力測試

如上一篇文章提到的雙十一大促等，是一種短期內將系統負載壓到極限的例子，在測試中，通常經過壓力測試來模擬。

壓力測試

主要考察讓系統運行在比較大的負載條件下的性能表現。通常會採用多個併發用戶進行一段時間高壓力的訪問，壓力測試能夠發現系統工做在多任務併發狀況下可能出現的性能問題。因爲壓力測試下系統工做在很是高的負載情況下，因此衡量的性能運行指標通常爲吞吐率和錯誤率，而不包括響應時間。

壓力測試的目的

發現並解決在併發、長時間運行或大量數據狀況下才出現的系統缺陷。

在指定併發用戶數下可否達到吞吐率目標。

什麼是吞吐率？

吞吐率一般是指應用系統在單位時間內實際處理的交易數量或頁面點擊數量。與系統負載指標相似，吞吐率也隨時間而變化，存在最大值和平均值。

一些重要的組件的吞吐率每每被做爲一個版本的關鍵質量標準，決定軟件版本是否能順利發佈。

新版本的吞吐率每每用來與舊版本的吞吐率進行比較來確保新功能的加入不會引發總體的性能降低。

 

壓力測試根據目的分類

一類壓力測試是找出應用系統的飽和點，即系統的性能瓶頸。一般但願該瓶頸是系統的CPU處理能力，這類壓力測試主要經過標準是系統在CPU運算能力飽和狀態下的吞吐率和錯誤率。

一類壓力測試則是找出應用系統的崩潰點。這類測試一般不關心具體的吞吐率和錯誤率指標，而是考察吞吐率、錯誤率指標與負載的關係曲線。

壓力測試經過的標準

在承受指定負載的前提下，系統的吞吐率是否達標，併發用戶數是否達標，出錯率是否達標。

在併發量很大的狀況下，有的事務可能由於等候資源超時而形成回滾，少許的訪問失敗在所不免，但若是大併發下出錯率很高，就說明系統處理併發的能力不足，有多是併發處理邏輯有問題。

通常來講，吞吐率越高表示系統的性能越好，但值得注意的是，各類交易的複雜程度不一樣，每一個交易頁面的點擊數也可能相差很大，脫離具體交易的內容，片面經過兩個系統的吞吐率來衡量兩個系統的性能好壞是沒有意義的。

而對於同一個交易系統來說，但願吞吐率與併發數能成正比，這是理想的狀況。現實則會在某個點達到CPU使用率飽和，若飽和後繼續增大併發量，則可能致使系統崩潰。

平常的訪問量——正常的響應時間

響應時間是另外一個常見的衡量系統快慢的運行指標。通常來講，響應時間越短越好。

與將系統負載壓到極限的壓力測試相比，響應時間測試測的是再正常負載狀態下，被測系統的服務器端和客戶端響應時間（不考慮外部網絡傳輸影響）。即，響應時間的測試結果更接近一般狀態下的系統真實性能表現。

響應時間測試的目的

在正常負載前提下，保證服務器或者客戶端的操做響應時間不超過規定的標準。

網頁響應時間的構成

用戶的頁面請求從發出到徹底獲得響應有一個過程：在網絡上傳輸數據、在服務器端處理，服務器將響應數據傳回到客戶端，在瀏覽器中顯示，這幾部分是相互獨立的。

在網絡上數據傳輸的時間取決於頁面數據量的大小、網絡速度和網絡上的擁擠程度。

在瀏覽器中顯示的時間取決於客戶端程序的複雜程度，以及運行瀏覽器的客戶計算機的處理速度。

服務器端處理的時間和服務器系統的性能相關，這段時間稱爲頁面處理時間，又可細分爲隊列等待和實際處理兩部分。

 

實際處理

實際處理時間與吞吐率關係較小，主要取決於處理程序的執行效率（算法好壞）和硬件處理速度。

 

隊列等待

隊列等待時間除了與硬件處理速度相關，還跟各類共享資源的參數設置有關。

在設計響應時間這方面的測試用例的時候，會針對服務器端和客戶端分別設計用例，而且分別定義經過標準。

保證長時間的穩定運營——可靠性測試

通常來講，可靠性測試對待測系統施加的負載要小於壓力測試的負載。通常能夠選取系統平常處理的平均負載。

可靠性測試評估的性能指標一般是響應時間、錯誤率和系統資源佔用率。

 

可靠性測試的目的

評估長時間的性能指標是否知足要求，每每考察平均值。

考察性能指標的變化趨勢，以發現系統可能存在的內存泄漏、性能降低等與執行時間有關的性能問題。

考察某些維護性操做是否會對前臺用戶訪問的性能形成大的影響。

可靠性測試是一個版本性能的終極測試，可靠性測試的設計每每須要考慮把藥測試版本最關鍵功能和最基本功能都涉及到。

客戶的成長不比產品慢：想象不到的數據量——可擴展性測試

可擴展性測試是驗證被測系統隨着計算能力的擴展可否承受更大的負載，負載的增大包括數據規模、業務種類、數據複雜度等。

 

可擴展性測試的目的

可擴展性測試每每針對的是系統在某一個負載方向上的可擴展性。

可擴展性測試通常在不一樣的負載下衡量系統響應時間或者吞吐率的變化趨勢。

尾聲

不論是吞吐率、併發用戶數、響應時間仍是可靠性，任何性能指標的好壞，除了與軟件自己的併發性能好壞有關，還在很大程度上取決於硬件系統的處理能力。

在明白了上述的知識以後，下一章，小艾將親身經歷性能測試的工做了，讓咱們一塊兒期待吧~

 

這一系列文章在微信公衆號中已經所有更新完成，你們能夠經過查看歷史消息回顧全部文章，更多精彩內容能夠掃描下面二維碼關注微信公衆號: 倚樓聽風雨的如月