另外，因為原文沒有標題，但為了幫助讀者更容易了解段落，所以通達人替不同段落下了標題。一併在此說明。
以下是原文的完整翻譯
我最近收到一些關於我前陣子發表的文章的意見/問題，許多人還是會對嚴格的效能和負載測試的差異有疑惑，我有想到很多關於它的假設問題以作為區分這兩類測試的石芯試紙：你有對你的應用程式碼執行性能分析（profiling）和/或觀察伺服器在執行你的應用程式時的反應？如果答案是肯定的，那你肯定是在執行效能測試；倘若答案是否定的，那你執行的就是負載測試。
區別測試類型的方法
其他的觀察方式是取決於你相對於黑箱測試是否執行更多的白箱類測試。在白箱測試手法，測試者、開發者、系統管理者和資料庫管理者一起工作以促成應用程式碼和資料庫語法（queries）（例如透過特殊的性能分析器）、和執行應用程式的伺服器硬體/作業系統、和資料庫（透過監控工具，如： vmstat、iostat、top、或Windows PerfMon）。所有這類的活動都屬於效能測試。
黑箱測試的手法是執行 Client 端的負載工具以量測應用程式的回應值，這類工具含括輕量、命令列工具，如：httperf、openload、siege和Apache Flood，一直到重量級的工具，如：OpenSTA、The Grinder 和 JMeter。這類測試不看應用程式的內部行為，也不監測執行應用程式伺服器的硬體/作業系統資源，如果這聽起來像是你所作的測試，那我就稱它為負載測試。
在這兩個名詞的實作上通常互換地使用，我和別人一樣有罪地這樣做，因為我最近稱我的部落格「HTTP performance testing with httperf, autobench and openload」取代成更精準的「HTTP load testing」。我沒有存取應用程式碼、或我測試執行應用程式的那個伺服器，所以我真的不是在做效能測試、而只是負載測試。
易於混淆的原因
我認為有部份的混淆是不論你如何看這兩類測試，它們都有一個共通的部份：負載測試。即使當你性能分析一個應用程式和觀察伺服器（因為執行了效能測試），從執行測試的角來看，你仍然需要對應用程式執行負載測試。
就我所能考慮到的，這些定義本身並沒有多大的價值，最重要的是有一個建構完善的調校應用程式和伺服器的程序以符合你的使用者或是業務客戶的需求，這個程序將使用所有在這提到的測試類型的要素和我之前提到的：負載、效能和壓力測試。
實際的例子
這裏有一些程序的例子，以你開發了一個網頁程式來說：具備支援 100 個在線使用者的資料庫後端、具備3秒以內的回應時間，你將會如何測試你的應用程式以確保符合這些需求？
1. 啟動一個網頁/應用程式伺服器連線到一個資料庫伺服器，如果可以的話，把這兩個伺服器放在一個防火牆後，如果你考慮作線路的負載平衡（ load balancing），把網頁伺服器放在負載平衡器（ load balancer）後，這個方法將使你可以有一個各不相同、可在真實產品環境使用的設備。
2. 以 10 個在線使用者對網頁伺服器開始執行負載測試，每個使用者傳出 1000 個對伺服器的要求（Request），每次設定增加 10 個使用者，直到 100 個使用者。
分析和觀察系統瓶頸
3. 當你在折磨（blasting）網頁伺服器時，性能分析（profile）你的應用程式和資料庫以觀察有任何熱點存在於你需要最佳化的程式碼/SQL語法/儲存程序中，我了解我在這裏掩飾了一些重要細節，但在這個步驟明顯取決於你的特殊應用程式。
也要透過之前提到的命令列工具（top、vmstat、iostat、netstat、Windows PerfMon）觀察這兩個伺服器（網頁/應用程式和資料庫），這些工具將讓你知道就硬體資源而言這些伺服器究竟發生了什麼事，同時觀察防火牆和負載平衡器（在大多數的情況下你可以透過 SNMP）--假設這些問題是基於硬體而非基於軟體，這些設備並不會像是這個階段的瓶頸，因為硬體通常能在遇到限制前處理數上千個連線。
這是整個程序中一個最重要的階段，這些觀察工具的結果不容易有意義的，你需要一些在系統/網路架構和管理上有很多經驗的人。在 Sun/Solaris 平台，有一個叫 SE Performance Toolkit 的工具可以嘗試減輕這個工作，它能透過內建的啟發裝置--當部份門檻到達時告訴你資源的確實使用情形。
重新調校系統
4. 我們假設你的網頁伺服器的回覆率平穩的達到50 個使用者的水準，現在你有一個導致問題的重覆條件，所有在步驟3所作的系統分析和觀察，應該已經提供你一個好的想法：關於在你的應用程式內的熱點、關於尚未正確最佳化的 SQL 語法、關於在硬體/作業系統層的資源狀態。
在這點，開發者需要收回性能分析的量測值、與調整程式碼和資料庫語法，系統管理者也能藉由投入更多的硬體到伺服器以簡易地增加伺服器效能--在我的經驗中尤其是在網頁/應用程式伺服器需要很多記憶體，如果是Java平台則需要更多。
建立/比較基線值（baseline number）
5. 假設應用程式/資料庫程式碼，和硬體/作業系統環境被每個人儘能力調校到最佳值，你重新執行步驟2負載測試並且在效能開始降級前你正在 75 個在線使用者。
在這點，在既有步驟中你沒有太多可以做的事，這正是考慮水平開展系統的時候：在已負載平衡的網頁伺服器農場增加其他網頁伺服器；或增加其他資料庫伺服器；或是做內容快取，例如在 Apache mod_cache；又或者是增加額外如 Squid 的快取伺服器。
在整個程序內一個非常重要的產出是你對目前硬體環境下你的應用程式的一個基線值（baseline number），你可以使用現階段的設定執行稍後的效能測試，就會告訴你應用程式/資料庫程式碼的變化是否會導致效能提昇或衰減。
執行壓力測試
6. 在你實際啟動你的程式前，在一個真實產品環境中重覆上述的步驟
所有的討論假設你要取得你的應用程式的效能/基準值，假如你要實際地發現缺限和看到你的應用程式錯誤和恢復正常，你需要執行壓力測試：使用雙倍數量的使用者折磨你的網頁伺服器，隨機地拔掉網路線（或透過 SNMP 關閉/重啟交換器埠），從 RAID 陣列中拔出一個磁碟，或諸如此類的事。
多方嘗試才是王道
結論？在最後，你怎麼稱呼你的測試不重要，只要你協助團隊的交付能在應用程式功能性和效能上做出保證。效能測試就某部份而言比科學更藝術，很多時候唯一使程序最佳化和調校應用程式和它環境的方法就是藉由嘗試-錯誤法（trial-and-error）、與毅力，有傑出的開源碼工具也將有所助益。
Jose’s Google+ profile
您好，請問[效能/負載/壓力測試的分別]，此篇為何無法閱讀，移除了嗎?
回覆刪除Hi 吉米：
回覆刪除我並未移除可《效能/負載/壓力測試的分別》這篇文章呀，我剛還是可以閱讀這篇文章呀。