軟件性能測試的重要性及策略發表于：2010-12-22來源：作者：點擊數：1351

標簽：軟件性能測試的重要性及策略【IT168技術文檔】目前軟件性能測試是發現軟件性能問題最有效的手段，而完備有效的性能測試是最關鍵的，在本節中我們將從流程和技術的角度解析如何構建一個高效的性能測試模型。1.2.1性能測試在軟件測試的周期位置首先，軟軟件性能測試的重要性及策略【IT168技術文檔】目前軟件性能測試是發現軟件性能問題最有效的手段，而完備有效的性能測試是最關鍵的，在本節中我們將從流程和技術的角度解析如何構建一個高效的性能測試模型。

1.2.1性能測試在軟件測試的周期位置

首先，軟件性能測試屬于軟件測試范疇，存在于軟件測試的生命周期中。一個軟件的生產過程通常遵循V型圖，如圖1-3所示。

圖1-3軟件開發-測試V型圖

在通常的軟件生產周期中，先由用戶提出用戶需求或經系統分析核定以后提出系統需求，開發人員再經過需求分析提出軟件需求規格說明，進行概要設計，提出概要設計說明，進行詳細設計，提出詳細設計說明，最后就是對每個模塊進行編碼。到測試階段，測試按照開發過程逐階段進行驗證并分步實施，體現了從局部到整體、從低層到高層逐層驗證系統的思想。對應軟件開發過程，軟件測試步驟分為代碼審查、單元測試、集成測試、系統測試。

而性能測試就屬于軟件系統級測試，其最終目的是驗證用戶的性能需求是否達到，在這個目標下，性能測試還常常用來做：

(1)識別系統瓶頸和產生瓶頸的原因;

(2)最優化和調整平臺的配置(包括硬件和軟件)來達到最高的性能;

(3)判斷一個新的模塊是否對整個系統的性能有影響。

系統瓶頸：

瓶頸本來是指玻璃瓶中直徑較小并影響流水速度的一段，用它來比喻軟件系統中出現性能問題的節點是很形象的，比如一個典型的分布式系統架構如圖1-4所示。

圖1-4軟件系統壓力流動圖

如果把軟件系統看做是交通系統，那么網絡就是一條條大道，客戶端、防火墻、負載均衡器、Web服務器、應用服務器(中間件)、數據庫等各個系統節點就是交通要塞，客戶的請求和數據就像在道路上行駛的車輛，如果在某處發生堵車，那么整個交通系統都會不暢。在這個時候，我們就要分析是哪里出了問題，是道路不夠寬，還是某處立交橋設計不合理而引起堵塞等。找到問題的關鍵點，那么此關鍵點就是本系統的瓶頸。軟件系統也是如此，我們做性能測試的大部分工作都是為了尋找這個瓶頸到底在何處。

需要注意的是，軟件的性能瓶頸可能不止一處。

作為軟件測試的一種，軟件測試的規則同樣適用于性能測試中：

(1)確定預期輸出是測試必不可少的一部分

如果事先無法肯定預期的測試結果，往往會把看起來似是而非的東西當作正確結果。必須提倡用事先精確對應的輸入和輸出結果來詳細檢查所有的輸出。對于性能測試來說，預期輸出就是用戶的性能需求，一份明確的性能需求是成功性能測試的先決條件。

(2)必須徹底檢查每一個測試結果

事實上，在最終發現的錯誤，有相當一部分在前面的測試中已經暴露出來了，然而由于人們未能細心檢查先前的測試結果而遺漏了。

一段程序中存在的錯誤概率與在這段程序中發現的錯誤數呈正比。

這是pareto原則應用于軟件測試，也包括性能測試，即性能測試發現的錯誤中的80%很可能集中在20%的程序模塊中。

(3)窮舉測試是不可能的

在性能測試中不可能覆蓋每一個功能部分，這也意味著有性能問題的模塊可能被忽略掉，這樣的話，我們在設計性能測試案例時，應該采取一些策略和技巧，使用盡可能少的性能測試用例，發現盡可能多的bug。這方面內容我們將在本書的第10章中介紹。

在具有軟件測試共性的同時，性能測試也有自身的一些特點。

1.性能測試不是功能測試

性能測試不要求也無法做到覆蓋軟件所有的功能，通常我們只是對系統中某些功能或模塊做性能測試。一般的，我們在選擇性能測試案例時需要遵循以下的原則：

(1)基本且常用的

比如，一個E-mail系統，基本且常用的功能有注冊、登錄、收郵件、查詢郵件，用戶使用這些功能的頻率較高，要做性能測試。而高級查詢、過濾器、郵件列表等功能被使用的次數較少，就可以不做性能測試，或者進行性能測試的優先級低一些。

(2)對響應時間要求苛刻的

這樣的要求經常出現在金融和電信等對實時性要求比較高的系統中。比如，從手機呼叫開始，經過基站、核心網，再到被叫手機響鈴，整個系統的處理時間應該在用戶能接受的范圍內。另外，一個負責和手機通信的基站在發生故障或掉電后，要能很快地恢復工作狀態。這些功能都對時間有著嚴格的要求，一定要做性能測試，當然實際運作時，電信系統上線時所做的性能測試不僅僅限于這些功能。

將這些功能細分就是性能測試中的事務(Transaction)。關于事務這個概念我們在后面的章節中將詳細闡述。

2.性能測試屬于系統級測試

從V型圖可以看到，性能測試屬于系統級測試。那么性能測試是基于單元測試、集成測試、功能測試等都已經完成的基礎上，站在用戶的角度去測試整個系統的。這包含兩個含義：

第一，性能測試是“兩頭在外”，軟件性能需求不僅直接來自用戶，最終目的也是服務于用戶。通過性能測試這個過程，從上面我們講到用戶的需求和性能測試指標的對應關系，就可以看出。

第二，性能測試開始的必要條件是軟件系統已經處于一個比較穩定的狀態，系統架構、主要代碼、中間件等都不再有大的變化，否則會給性能測試帶來很大的風險。

思考

基于以上事實，我們應該在軟件流程什么階段開始性能測試?結合自己的實際工作進行分析。

1.2.2性能測試策略揭秘

談到“策略”，這是如今很火、使用較多的一個詞。不光在IT領域，其他各個行業中也都有各種各樣的策略，如營銷策略、風險規避策略等。策略即謀略、手段、方法，表現為權宜的行動路線、指導原則或過程。

做事情講策略，這是一種智慧，是人們聰明起來的表現，但當越來越多的策略“概念化”的時候，我們不得不去思考我們到底要達到什么樣的目標，什么樣的策略才是我們需要的。

案例

引用網上一位哲人說的話：“概念只是為了方便人們理解和研究世界萬物事物而制造的工具，而最終結果將使概念不再需要，就如同莊子所說的得意而忘言”。語言就是一種包裝材料，它包裝的是某種含義。因為人類傳遞信息必須使用語言，所以我們在研究的時候不得不借助于這種包裝，但是當人的思維能力具備了打開包裝直接取得內部的含義的時候，語言就變得多余了。這時候再關注于語言和概念本身就成了買櫝還珠的現代版了。

因此，我們應該關注的不是概念本身，而是概念背后的含義。理解了含義，再冠予它什么樣的名詞頭銜，如“攻略“，對于我們都無關緊要了。而理解一個概念，我們可以靠WWH方法，即對概念的三個問題：Why、What、How。

好，言歸正傳，回到軟件性能測試策略中來。在性能測試過程中，只要有事情做，就會有策略，如設計用例有設計策略，執行時有執行策略，調優時還有調優策略。為了不產生混淆，我們要說明的是，在本節中討論的策略是性能測試設計策略。

Why(為什么會有不同的策略)

在軟件性能一節中，我們看到軟件的性能來自軟件對空間和時間的綜合方案，這種組合是很多的，因此用戶的軟件性能需求可能會多種多樣。對于軟件人員，我們做性能測試也要因地制宜，根據不同的性能需求，選擇不同的測試策略。

What(什么是性能測試設計策略)

驗證性能需求是測試目的，測試策略即已經被證明是行之有效的測試方法。

How(怎樣實施)

常見的性能測試方法有以下幾種：

1.負載測試

在這里，負載測試指的是最常見的驗證一般性能需求而進行的性能測試，在上面我們提到了用戶最常見的性能需求就是“既要馬兒跑，又要馬兒少吃草”。因此負載測試主要是考察軟件系統在既定負載下的性能表現。我們對負載測試可以有如下理解：

(1)負載測試是站在用戶的角度去觀察在一定條件下軟件系統的性能表現。

(2)負載測試的預期結果是用戶的性能需求得到滿足。此指標一般體現為響應時間、交易容量、并發容量、資源使用率等。

2.壓力測試

壓力測試是為了考察系統在極端條件下的表現，極端條件可以是超負荷的交易量和并發用戶數。注意，這個極端條件并不一定是用戶的性能需求，可能要遠遠高于用戶的性能需求?？梢赃@樣理解，壓力測試和負載測試不同的是，壓力測試的預期結果就是系統出現問題，而我們要考察的是系統處理問題的方式。比如說，我們期待一個系統在面臨壓力的情況下能夠保持穩定，處理速度可以變慢，但不能系統崩潰。因此，壓力測試是能讓我們識別系統的弱點和在極限負載下程序將如何運行。

例子：負載測試關心的是用戶規則和需求，壓力測試關心的是軟件系統本身。對于它們的區別，我們可以用華山論劍的例子來更加形象地描述一下。如果把郭靖看做被測試對象，那么壓力測試就像是郭靖和已經走火入魔的歐陽峰過招，歐陽鋒蠻打亂來，毫無套路，盡可能地去打倒對方。郭靖要能應對住，并且不能丟進小命。而常規性能測試就好比郭靖和黃藥師、洪七公三人約定，只要郭靖能分別接兩位高手一百招，郭靖就算勝。至于三百招后哪怕郭靖會輸掉那也不用管了。他只要能做到接下一百招，就算通過。

思考

我們在做軟件壓力測試時，往往要增加比負載測試更多的并發用戶和交易，這是為什么?

3.并發測試

驗證系統的并發處理能力。一般是和服務器端建立大量的并發連接，通過客戶端的響應時間和服務器端的性能監測情況來判斷系統是否達到了既定的并發能力指標。負載測試往往就會使用并發來創造負載，之所以把并發測試單獨提出來，是因為并發測試往往涉及服務器的并發容量，以及多進程/多線程協調同步可能帶來的問題。這是要特別注意，必須測試的。

4.基準測試

當軟件系統中增加一個新的模塊的時候，需要做基準測試，以判斷新模塊對整個軟件系統的性能影響。按照基準測試的方法，需要打開/關閉新模塊至少各做一次測試。關閉模塊之前的系統各個性能指標記下來作為基準(Benchmark)，然后與打開模塊狀態下的系統性能指標作比較，以判斷模塊對系統性能的影響。

5.穩定性測試

“路遙知馬力”，在這里我們要說的是和性能測試有關的穩定性測試，即測試系統在一定負載下運行長時間后是否會發生問題。軟件系統的有些問題是不能一下子就暴露出來的，或者說是需要時間積累才能達到能夠度量的程度。為什么會需要這樣的測試呢?因為有些軟件的問題只有在運行一天或一個星期甚至更長的時間才會暴露。這種問題一般是程序占用資源卻不能及時釋放而引起的。比