1.3 如何做效能測試
乙個專案要取得成功是困難的，因為成功的專案需要多個因素和條件來支援；而乙個專案失敗卻很容易，只要若干因素之中的乙個出現問題，就有可能導致專案失敗。比如中途測試人員發生變化，效能指標未和使用者達成統一理解等。筆者還曾看過乙個例子，因為測試報告的格式與使用者要求的格式不一致，而不得不重新再執行一次所有的效能場景，來採集使用者要的資料。
實際上，當我們做過的效能測試專案越多，就會發現越多的因素可能會影響效能測試專案的成敗，甚至可以是千奇百怪的。
在本節中，我們主要是尋找出不同效能測試專案的共性，而總結出乙個具有普遍意義的效能測試過程。遵循過程做效能測試，在大多數情況下可以有效地規避風險，並能取得比較好的效能測試結果。這當然不是意味著我們有了這個過程，就不考慮其他因素了，只是說每個專案都會有自己的獨特因素要考慮，儘管這些因素可能很重要，但它們並不在本節的討論範圍內。
在給出此過程模型之前，我們要澄清兩點事實：
第一，效能測試過程從何時開始，又在何時結束？
這是乙個基本而重要的問題。
在各種書籍和資料中，有關效能測試過程的描述不盡一樣：
比如loadrunner手冊中提供的過程是：計畫測試→測試設計→建立vu指令碼→建立測試場景→執行測試場景→分析結果。
而在segue中提供的效能測試過程，是乙個try-check過程，即：評估需求→開發測試→建立基線→執行測試→分析結果→回歸測試→測試結束。
上面loadrunner和segue描述各自的效能測試過程最大的區別不在於工具部分，而是在於兩者過程的入口和出口條件不一致。這使得它們其實在描述兩件事情，或者說是在描述乙個事情的兩個部分。
在cmm中，軟體測試和軟體設計、編碼一樣，隸屬於軟體工程過程，而需求分析過程在軟體工程過程之前。這就隱含著乙個預設的先決條件：在cmm這個體系下，產品在進入軟體測試階段的時候，軟體需求是已經明確下來並文件化了的。
實際情況卻經常並非如此，同樣是軟體需求，軟體功能需求在進入測試階段就已經產生了各種文件，包括需求文件和設計文件，確保功能需求是詳細、明確、無二義性的；而軟體效能需求往往進入了效能測試階段還不明確（可參見controller一章開篇的例子）。這會給效能測試專案帶來很大的風險。
因此，我們應該突破已有的理論束縛，尋找更合適的效能測試過程模型。經過對多個效能測試專案的實踐經驗總結，我們在本節提出game（a）效能測試過程模型，其開始於軟體需求分析階段，非常符合目前國內的效能測試實踐。
第二，效能測試本身有沒有質量？
以前我們總是討論軟體產品的質量、開發**的質量，但對軟體測試的質量卻鮮有提及。我們知道「乙個好的測試用例是發現了乙個原先未發現的bug」，這其實是對用例質量的度量。軟體效能測試專案也有質量，並可以度量。下面是部分度量的方法：
（1）效能測試耗費的資源，包括時間、人力、物力。
（2）效能測試中發現的bug數目，以及各自的級別。
（3）軟體系統交付使用者，在生產環境執行後發現的效能bug數目、級別。
而乙個好的效能測試過程模型對提高效能測試質量是很有幫助的。
game（a）效能測試過程模型：
g：goal，目標
a：analysis，分析
m：metrics，度量
e：execution，執行
（a）：adjust，調整。e執行失敗後才進入a階段，並且涉及的大多是有關開發和系統管理工作，因此a設為隱式。
效能測試過程模型如圖1-5所示。
（2）定義最優的硬體配置
檢測各項系統配置（記憶體、cpu速度、快取、介面卡、數據機）對效能的影響。了解系統體系結構並測試了應用程式響應時間後，您可以度量不同系統配置下的應用程式響應時間，從而確定哪一種設定能夠提供理想的效能級別。
例如，您可以設定三種不同的伺服器配置，並針對各個配置執行相同的測試，以確定效能上的差異：
配置1：1.2ghz、1gb ram
配置2：1.2ghz、2gb ram
配置3：2.4ghz、1gb ram
（3）檢查可靠性
確定系統在連續的高工作負載下的穩定性級別。強制系統在短時間內處理大量任務，以模擬系統在數週或數月的時間內通常會遇到的活動型別。
（4）檢視硬體或軟體公升級
執行回歸測試，以便對新舊版本的硬體或軟體進行比較。您可以檢視軟體或硬體公升級對響應時間（基準）和可靠性的影響。注意：此回歸測試的目的不是驗證公升級版的新功能，而是檢視新版本的效率和可靠性是否與舊版本相同。
（5）確定瓶頸
您可以執行測試以確定系統的瓶頸，並確定哪些因素導致效能下降，例如，檔案鎖定、資源爭用和網路過載。將loadrunner與新的網路和計算機監視工具結合使用以生成負載，並度量系統中不同點的效能，最終找出瓶頸所在的位置。
（6）度量系統容量
度量系統容量，並確定系統在不降低效能的前提下能提供多少額外容量。如圖1-7所示，要檢視容量，您可以檢視現有系統中效能與負載間的關係，並確定出現響應時間顯著延長的位置。該處通常稱為響應時間曲線的「拐點」。
我們根據不同的測試目標去選擇合適的效能測試設計策略。比如，「度量終端使用者響應時間」可以採用負載測試策略，「檢查可靠性」就可以用壓力測試策略，等等。
七 效能測試從零開始 LoadRunner入門
1.4 效能測試 工具的評估和選擇 我們可以看到，效能測試和一般 功能測試 不同的是，效能測試的執行是基本功能的重複和併發，因此我們在效能開始之前需要模擬多使用者，在效能測試進行時要監控指標引數，同時效能測試的結果不是那麼顯而易見，需要對資料進行分析。這些特點決定了效能測試更適合通過工具來完成。市場...
從零開始介面測試
介面測試現在已經是每個測試從業人員必須掌握的知識，介面測試實施在多系統多平台的構架下，有著極為高效的投入產出比，所以介面測試也在各大網際網路公司中越來越受到重視。但是很多測試人員一開始都是從功能測試開始的，可能很多人並沒有接觸過介面測試，那如何快速對介面測試上手呢，我們來看看吧。介面測試是測試系統元...
效能測試從零開始實施指南 測試報告篇
效能測試的目的，是通過模擬真實的業務場景和海量的使用者請求及資料對業務系統進行多種場景的測試，來驗證各個服務的效能表現是否滿足實際的業務需要。長期來看，效能測試最終的目標是為生產環境容量規劃提供可靠地參考資料，使生產服務的可用性 擴充套件性和穩定性更高，讓技術更好的服務業務，創造更多的價值。從整個效...