效能/負載/壓力測試的分別（Performance vs. load vs. stress ...

效能/負載/壓力測試的分別（Performance vs. load vs. stress testing） http://www.prudentman.idv.tw/2011/01/perform. 立你斯學習記錄 跳到主文 歡迎光臨立你斯在痞客邦的小天地..這裡主要轉貼我工作上有遇過的問題或看過的查過的資料....盡量轉成正體..留存 部落格全站分類：數位生活 相簿 部落格 留言 名片 Mar28Mon201612:00 效能/負載/壓力測試的分別（Performancevs.loadvs.stresstesting） 效能/負載/壓力測試的分別（Performancevs.loadvs.stresstesting） http://www.prudentman.idv.tw/2011/01/performance-vs-load-vs-stress-testing.html  原文   看完下面這篇似乎感覺 效能測試就是正常使用範圍上測試 負載測試 就是規格上開最大的數值測試 壓力測試就是想盡辦法給你測到掛還要會自己保護!不會死要能回來   _----------------------------------------------------------------------------------------------------------------------   效能/負載/壓力測試是三個意義很接近、又容易混淆的名詞，即使是資深的軟體相關從業人員，也不見得能輕易地說出三者的差異。

這篇文章是在Google中以「Performanceloadstresstesting」做關鍵字搜尋後所找到的第一篇文章《Performancevs.loadvs.stresstesting》的翻譯。

如果沒意外，這篇應該也是網路上最人重視、並大量引用（已知12篇）、且有眾多留言（扣除作者的回覆在100則以上）的文章。

從這個部落的名稱「AgileTesting」以及作者的介紹、及發表的文章來看，作者GrigGheorghiu已從事SWTester多年，對多種語言、腳本語言都有涉獵，也對Agile有相當的經驗，以實作的角度提出三者的差異，相當具有參考價值。

因此，通達人就請該作者同意翻釋、轉載該文，以供華文世界的軟體業從業人員參考。

  以下是原文的完整翻譯 這裏有一個對測試者（Tester）的面試問題：你如何定義效能/負載/壓力測試？在大多的時候人們交互地使用這些專有名詞，但他們實際上卻不能分辨有什麼不同。

這篇文章是依照我過去的經驗對這些觀念所做的簡捷探討，但同時使用了以下文獻內對測試的定義： Kaner的《Testingcomputersoftware》 Loveland的《Softwaretestingtechniques》 Nguyen的《TestingapplicationsontheWeb》   July7th,2005更新 從參考記錄（log）中我看到這篇文章在google內被頻繁地搜索，我更新它鏈接到我後來寫的《Moreonperformancevs.loadtesting》一文。

編按：通達人已經翻譯該文，會在下次轉載該文。

  效能測試（Performancetesting） 效能測試的目標不是要找缺陷（bug），而是要消除瓶頸和替未來的回歸測試（regressiontests）建立一個底線，執行效能測試的進行是在一個謹慎控制的量測和分析流程內，理想上軟體是在夠穩定的情況下進行測試，因此測試的過程可以很順利的進行。

更清楚的定義期望組對有意義的效能測試而言是必要的，如果就系統的效能而言你不知道自己要去那裏，那你的方向就有點重要（記得愛麗絲和那隻嘻笑的貓），例如：對網頁程式（Webapplication）而言，你需要知道以下幾件事： 在線的使用者或HTTP連線的期望負荷 允許的回應時間 一旦你知道自己要去那，當你知道要找瓶頸時，你就可以藉由不斷地增加負荷到系統以達到你要去的地方，再舉網頁程式的例子，這些瓶頸會存在於不同層，你可以藉由以下工具準確地確定： 在應用程式層，開發者可以使用profiler在他們的程式碼中spot無效率的地方（例如粗糙的搜尋演算法） 在資料庫層，開發者和DBA可以使用資料庫專屬的profiler和query最佳化工具 在作業系統層，系統工程師可以使用小程式，如：top、vmstat、iostat（在Unix類系統）和PerfMon（在Windows）以觀察硬體資源，如：CPU、記憶體、swap、I/O磁碟；也能使用特殊化的kernel觀察軟體。

在網路層，網路工程師能使用封包探測工具，如：tcpdump；網路協定分析器，如：ethereal；以及不同的小工具，如：netstat、MRTG、ntop、mii-tool。

從測試的觀點來看，上述活動會因為系統「從內部向外」（fromtheinsideout）和不同角度被檢查和觀察而被認為是白箱測試的手法。

然而測試者也可以對測試系統用黑箱測試的手法執行負載測試，對網頁程式而言，測試者將使用模擬在線使用者或HTTP連線、與量測回應時間的工具，以這個目的而言有一些我過去使用過的輕量級開源工具：ab、siege、httperf，有我沒使用過的更重量工具OpenSTA，我也尚未使用Grinder，但它在我的TODO清單中名列前矛。

當負載測試的結果說明系統效能不能滿足它的期望目標時，就是開始調校應用程式和資料庫的時候，你要先確保你的程式碼儘可能有效地執行、同時你的資料庫已在作業系統/硬體設定中最佳化，TDDpractitioners將會非常有效地找出先後順序的框架，如MikeClark的jUnitPerf能提昇負荷測試和定時功能測試的既有單元測試程式碼，一旦一個特定功能或方法被數據表示和調校，開發者就能用jUnitPerf接著包裹它的單元測試和確保它符合負載和時效的效能需求，MikeClark稱這個為「持續效能測試」，我應該提及我曾經在Python下完成一個jUnitPerf的埠起始程式-我稱它為pyUnitPerf。

在調校應用程式和資料庫後，如果系統就效能而言仍不能符合期望目標時，有一個調校步驟的陣列在前述的所有階段皆可利用，這裏有一些在應用程式程式碼之外你可以作的事、以提昇網頁程式效能的例子： 使用網頁快取（cache）機制，例如由Squid所提供的 公開高需求的靜態網頁需求，這樣它們就不會接觸到資料庫 藉由負載平衡度量伺服器農場 按比例度量資料庫伺服器、和切開讀/寫伺服器和唯讀伺服器，接著負載平衡唯讀伺服器 藉由增加硬體資源（CPU、記憶體、磁碟）垂直地度量網頁和資料庫伺服器 增加可用的網路頻寬 效能調校有時比科學更藝術，因為十足複雜的系統糾纏創新的網頁程式，必須更注意修改時間後再作測量，除此之外多種變化微妙的相互作用會很難證明和重複。

在一些如測試試驗室的標準測試環境，將無法總能複製產品伺服器的配置，在這類例子中，將以產品環境分組分段測試環境，因此系統的預期效能需要相應的調低。

這個「執行負荷->量測效能->調校系統」的循環會一直重覆直到系統在測試到達期望效能水準，在這點，測試者會有一個系統處於一般條件下的底線，這個底線可以繼續在回歸測試中使用以衡量一個軟體新版本的效能。

其他效能測試的一般目標是建立系統在測試時的基準（benchmark）值，有非常多的工業標準基準值，例如：發行的TPC和許多硬體/軟體供應商會用各種方式微調他們的系統以獲得TCP前十名，這是每個人對效能宣稱都需要有的普遍知識，特別是提防任何不指明測試所使用硬體和軟體規格細節的宣稱效能。

  負載測試（Loadtesting） 我們已經看到負載測試是效能測試與調校的一部份，在這個前題下，這意味藉由自動工具不斷地增加負載到系統，對網頁程式而言，負載被定義成在線使用者或HTTP連線。

在測試文獻中，「負載測試」一詞經常被定義成提供系統所能執行最大工作量下運作測試的流程，負載測試通常被稱為「容量測試」、或「壽命（longevity）/耐力（endurance）測試」。

容量測試的例子： 藉由修改一個非常大的檔案以測試一個文字處理器 藉由傳出一個非常大的工作以測試一個印表機 藉由上千位使用者的收信匣以測試一個郵件伺服器 一個容量測試的特定案例是0容量測試，以確認系統能接受空的工作 壽命/耐力測試例子： 在Client端執行一個client-server應用程式以考驗伺服器在延長一段時間下的狀況   負載測試的目標   揭露粗略測試的缺陷，如：記憶體控制的缺陷、記憶體洩露（leaks）、緩衝區溢位（bufferoverflows）等 當效能測試時確保應用程式滿足效能建立的底線，這個是藉由執行回歸測試完成以確保應用程式的特定最大負載。

縱然效能測試和負載測試似乎看來一樣，但他們的目標不同。

首先，效能測試使用負載測試技術和工具以量測和基準目標和使用多種負載等級。

另外，負載測試操作一個預先定義的負載等級，通常最高負載下系統依然能運作正常。

注意負載測試並不是要藉由壓倒它來中斷系統，反而是要嘗試維持系統持續運作像情況良好的機器。

在負載測試的內容中，我要強調有一個大資料庫以供測試極為重要，在我的經驗中，許多重要的簡單缺陷不會浮出除非你有像上千使用者的容器般非常大的實體，如：LDAP/NIS/ActiveDirectory、上千封信的mail伺服器、數G（gigabyte）資料表的資料庫、多層的檔案/目錄架構的檔案系統...等，測試者明顯地需要自動化工具產生這些龐大的資料組，但幸運的是任何好的腳本語言（scriptinglanguage）都能勝任這項工作。

  壓力測試（Stresstesting） 壓力測試藉由超出系統資源或拿走系統資源（在這種情況下有時被稱為「負面測試」（negativetesting））的情況下測試以嘗試中斷系統，主要的目的在確保系統失效和正常地回復-這在品質上稱為「可復原性」（Recoverability）。

效能測試需要一個受控制的環境和重覆量測，壓力測試則隨興地引發混亂和不可預測，再舉網頁程式的例子，這裏有許多壓力的方式可以應用於系統： 雙倍於底線數目的在線的使用者/HTTP連線數 隨機地關閉和重啟網路上連接到伺服器的交換機/路由器的埠（例如透過SNMP命令） 關閉資料庫再開啟 在系統執行時重建RAID陣列 執行消耗網頁/資料庫伺服器資源（CPU、記憶體、磁碟、網路）的程序 我確信狡猾的測試者能以他們喜愛中斷系統的方式加強這個清單，然而，壓力測試並不是單純地為了想中斷系統而中斷系統，相反地它卻要求測試者觀察系統如何反應失效，它是否保存其狀態或它突然崩潰？它是否只是凍結（freeze）或者它能和平的失效？在重啟時它有能力重回到上次正常的狀態？它會印出有意義的錯誤訊息給使用者或者它只是顯示一些難以理解的十六進制代碼？因為意外的失效危及到系統的安全？這類案例不勝枚舉。

全站熱搜 創作者介紹 立你斯 立你斯學習記錄 立你斯發表在痞客邦留言(0)人氣() E-mail轉寄 全站分類：數位生活個人分類：程式心得此分類上一篇：指針與int的轉換（warning:casttopointerfromintegerofdifferentsize） 此分類下一篇：warning：deprecatedconversionfromstringconstantto'char*'解决方案 上一篇：LINUX常用的Performance/Monitor工具 下一篇：英文聊天機器人 歷史上的今天 2016:LINUX常用的Performance/Monitor工具 2014:MPEG4码流格式分析 2011:i2c驅動之難點釋疑 ▲top 留言列表 發表留言 熱門文章 文章分類 程式語言(17) 8051(5)openCL(2)C++(1)GPS(4)BarCode(3)多媒體(7)網路相關(23)程式設計(20)ARM(22)u-boot(19)各種規格(41)程式心得(34)程式工具(18)版本控制(13)RTOS(5)uC/OS筆記(12)Objective-C(3) 其他(8) 三國風雲(4)SCRATCH(1)產業消息(2)未分類資料夾(12)娛樂(13)語文學習(8)理財(7)幼教(2) LinuxDriver(9) PCI(6)driver教學(17)driver問題修正(11)嵌入式driver相關(10)USB(8)I2C(7)V4L2(8)Driver其他(29)Alsa(15) Linux(19) WIFI(12)yocto(3)GUI(10)CentOS(4)Linuxsystemprogramming(8)工作使用(2)模擬-VM(3)編譯相關(26)tslib(9)檔案系統(18)嵌入式相關(10)系統相關(20)LINUX(57)模擬-colinux(6)模擬-cygwin(10)Android(21)Mplayer(10)toolchain(6)系統指令(6) 未分類文章(16) 最新文章 文章精選 文章精選 2019十二月(3) 2019十月(7) 2019九月(1) 2019八月(3) 2019七月(1) 2019六月(2) 2019四月(1) 2019三月(12) 2018十月(3) 2018九月(8) 2018八月(3) 2018七月(5) 2018六月(2) 2018五月(6) 2018四月(12) 2018三月(4) 2018一月(3) 2017十一月(4) 2017九月(1) 2017七月(7) 2017六月(1) 2017五月(3) 2017三月(4) 2017二月(3) 2017一月(3) 2016十二月(10) 2016十一月(10) 2016八月(1) 2016七月(5) 2016六月(1) 2016五月(5) 2016三月(11) 2015十月(2) 2015九月(1) 2015七月(1) 2015六月(2) 2015四月(6) 2015三月(4) 2015二月(5) 2015一月(3) 2014十二月(5) 2014十一月(5) 2014十月(1) 2014九月(3) 2014八月(1) 2014七月(5) 2014六月(2) 2014五月(5) 2014四月(5) 2014三月(5) 2014二月(1) 2014一月(5) 2013十二月(11) 2013十一月(6) 2013十月(11) 2013五月(1) 2013四月(1) 2013三月(4) 2013二月(3) 2013一月(1) 2012十一月(4) 2012十月(1) 2012九月(3) 2012八月(6) 2012七月(8) 2012六月(16) 2012五月(4) 2012四月(2) 2012三月(2) 2012二月(2) 2012一月(3) 2011十二月(13) 2011十一月(4) 2011十月(5) 2011九月(1) 2011八月(2) 2011七月(3) 2011六月(4) 2011五月(2) 2011四月(1) 2011三月(13) 2011二月(5) 2011一月(12) 2010十二月(5) 2010十一月(5) 2010十月(5) 2010九月(5) 2010八月(2) 2010七月(8) 2010六月(9) 2010五月(13) 2010四月(7) 2010二月(7) 2010一月(7) 2009十二月(5) 2009十一月(24) 2009十月(6) 2009九月(8) 2009八月(9) 2009七月(12) 2009六月(3) 2009三月(9) 2009二月(22) 2008十二月(8) 2008十一月(2) 2008十月(2) 2008九月(2) 2008五月(3) 2008四月(7) 2008一月(1) 2007十二月(7) 2007十一月(6) 2007十月(20) 2007八月(1) 2007七月(3) 2007六月(15) 2007五月(19) 2007四月(16) 所有文章列表 文章搜尋 最新留言 參觀人氣 本日人氣： 累積人氣： 我的好友 誰來我家 QRCode POWEREDBY (登入) 回到頁首 回到主文 免費註冊 客服中心 痞客邦首頁 ©2003-2022PIXNET 關閉視窗