軟體效能測試見解與總結

入行快兩年了，在這幾年裡，目睹軟體測試得到極大的發展，各企業對於測試的需求大大增加，但據我所瞭解，大部分的企業對測試的需求大多隻是停留在階段，其實這樣的測試是不完整的。對於測試本身，個人認為可以依照物件導向的不同劃分為三種。

1、面向系統：即面對被測系統本身，這類測試主要是驗證被測系統的完善性，健全性。具體的測試目的為驗證方法函式是否正確，功能是否正常，需求是否滿足，即包含著單元測試，、確認測試、系統測試、驗收測試等。

2、面向使用者：指的是站在使用者的角度上測試系統是否存在缺陷，這類測試主要針對使用者體驗度。具體的表現在於介面是否美觀，系統是否易用，能否相容多裝置，能否快速響應等，具體的測試有UI測試，，等。

3、面向企業：考慮更多的是系統是否存在風險，具體表現在於資料洩漏，許可權安全等，常見的測試有安全測試。

對於測試的需求，面向企業可以視情況拋棄或者推遲，但是面向系統與面向使用者是缺一不可的。面向系統就不必多說了，這是最常規的，是系統質量的最基本體現。除了功能的健全完善之外，我們還應該更多的關注使用者的體驗，因為站在使用者的立場上，使用一個系統最為直觀的感受就是介面美觀與響應速度。

鑑於之前所言，在此總結一下個人對的一些見解與總結。

是透過模擬多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試。

通俗的講，就是透過工具模擬使用者作業系統再模擬多使用者併發使用，透過監控過程中的伺服器資源佔用情況以及虛擬使用者使用情況。從而分析資料找出當前系統效能瓶頸，以及造成這個情況的原因。那麼，我們需要弄清楚幾個問題。

工具如何模擬？

當我們開啟瀏覽器訪問一個web系統時，瀏覽器會向這個web系統的伺服器傳送一系列的請求（可以安裝抓包工具進行檢視），當伺服器收到請求之後，會對每個請求做出回答並把資訊返回給瀏覽器。瀏覽器拿到返回來的資料之後，進行處理之後呈現頁面給我們查閱。而在效能測試中，工具就相當於是一個瀏覽器，它可以向伺服器傳送請求，能收到從伺服器返回來的資料，但是它對資料不進行處理，而是直接呈現給我們。我們可以按照操作把需要請求的介面按順序設定好就能模擬出使用者進行了某個動作操作了系統。接著透過設定併發數（虛擬使用者）來進行模擬多使用者同時使用的情景。正因為這樣，所以我們在進行的時候，所設計的指令碼需要儘可能的符合現實情況。否則得到的資料無法反映出伺服器的真實情況。

如何展開？

在瞭解了的工作原理之後，那麼我們該如何展開測試工作呢？ 如果從測試準備階段就開始講的話，那這裡就太長太臭了。所以我在這裡就分階段從簡代入。

1、設計指令碼：不同工具對指令碼的編寫的具體實現方式不同，但是他們做的都是同一件事，就是工具在執行指令碼的時候能按操作順序向伺服器傳送請求。除了按照順序之外，我們的指令碼還需要各種不同的設定，比如引數化，關聯，檢查點，新增思考時間等等，因為Http請求是無狀態的，如果需要登入才能進行的話，還需要注意新增Cookie或者SessionID。在寫好之後，就執行吧，體驗一下成果。

2、資料分析：在執行之後，會得到一個執行的結果概要圖或者詳細資料，資料分析的話，如果是等想要了解系統瓶頸的測試方法，則多關注伺服器的資源。如果想清楚伺服器的處理能力，則多關注響應時間，TPS，吞吐量等資料。

3、情景設計：但是現實中，系統使用過程中不可能出現線上使用者全部都只操作某個模組的某個功能。這時，需要我們透過各種途徑瞭解使用者不同時間段所使用各模組的大概情況。然後再把各種情況融入到指令碼中。

除此之外，還有的就是以及報告等設計編寫了。一份好的用例可能讓測試事半功倍，一份好的報告可以更能體現測試結果。

本文轉自：