軟件性能測試VS負載測試VS壓力測試

　　軟件性能測試VS負載測試VS壓力測試   軟件測試

　　在面試測試人員的時候，這是一個很好的問題：你如何定義性能/負載/壓力測試?在很多時候，人們都是將它們作為可互相替換的相同術語來使用，然而實際上他們之間的差異是比較大的。這個貼子是根據我自己的一些經驗，針對這三個概念寫的一個比較簡單的評論，當然也同時參考了一些測試文獻資料里的定義，比如說：

　　"Testing computer software" by Kaner et al

　　"Software testing techniques" by Loveland et al

　　"Testing applications on the Web" by Nguyen et al

　　Update July 7th, 2005

　　從網站的訪問日志中我可以看到這篇貼子經常會被人們在GOOGLE中搜索到，所以我在這里加上一個我寫的一個后續貼子的地址連接'More on performance vs. load testing'.

　　性能測試

　　性能測試的目的不是去找bugs,而是排除系統的瓶頸，以及為以后的回歸測試建立一個基準。而性能測試的操作，實際上就是一個非常小心受控的測量分析過程。在理想的情況下，被測軟件在這個時候已經是足夠穩定了，所以這個過程得以順利的進行。

　　一組清晰已定義好的預期值是讓一次有意義的性能測試的基本要素。如果連你自己都不知道系統性能有些什么是要測的，那么它對于你要測試的方法手段是沒有指導意義的*。例如，給一個web應用做性能測試，你要知道至少兩樣東西：

　　在不同并發用戶數或者HTTP連接數情況下的負載預期值*

　　可接受的響應時間

　　當你知道你的目標后，你就可以開始使用對系統持續增加負載的方法來觀察系統的瓶頸所在。重新拿web應用系統來做例子，這些瓶頸可存在于多個層次，你可以使用多種工具來查明它們的所在：

　　在應用層，開發人員可以通過profilers來發現低效率的代碼，比如說較差的查找算法

　　在數據庫層，開發人員和數據庫管理員(DBA)可以通過特定的數據庫profilers及事件探查器(query optimizers)

　　在操作系統層，系統工程師可以使用一些工具如在Unix類的操作系統中的top,vmstat,iostat,在Windows系統中的PerfMon來監控CPU，內在，swap,磁盤I/O等硬件資源;專門的內核監控軟件也可以在這一層面上被使用。

　　在網絡層上，網絡工程師可以使用報文探測器(如tcpdump),網絡協議分析器(如ethereal),還有其它的工具(如netstat,MRTG,ntop,mii-tool)

　　從測試的觀點來看，上面所有描述的活動都是一種白盒的方法，它對系統從內到外及多角度進行審查及監控。測度數據*被取得及分析后，對系統的調整則成為理所當然的下一個步驟。

　　然而，(除了上面的方法外)測試人員在給被測系統運行負載試驗*(這里為了不與我們所理解的負載測試-load testing的概念搞混，特譯做負載試驗)的時候，也采取了黑盒的方法。像對于WEB應用來講，測試人員可以使用工具來模擬并發用戶或者HTTP連接及測量響應時間。在我以前使用過的輕量級的負載測試開源工具有ab,siege,httperf。一個更重量級的工具是OpenSTA，但我沒用過。我也還沒有用過The Grinder這個工具，但它在我將要做的事情中排名靠前。

　　當負載試驗*的結果顯示出系統的性能來沒有達到它的預期目標時，這就是要對應用和數據庫的調整的時候了。同時你要確保讓你的代碼運行得盡可能高效，以及數據庫在給定的操作系統和硬件配置的情況下最優化。測試驅動開發(TDD)的實踐者會發現這種上下文結構框架是非常有用的*，如可以通過負載試驗*及時間試驗的函數性*來增強現存單元測試代碼的Mike Clark的jUnitPerf*。當一個特定的函數或者方法被剖析過*和調試過后，開發人員就可以在jUnitPerf中，放入它的單元試驗*來確保它可以達到負載及時間上的性能需求。Mike Clark稱這為“持續性能測試”。我順便也提一下我已經做了一個基于Python的jUnitPerf的初步研究，我稱之為pyUnitPerf.

原文轉自：http://www.anti-gravitydesign.com