性能測試從零開始——LoadRunner入門(六)[1]

        性能測試從零開始——LoadRunner入門(六)[1]  性能測試工具

　　1.3 如何做性能測試

　　一個項目要取得成功是困難的，因為成功的項目需要多個因素和條件來支持;而一個項目失敗卻很容易，只要若干因素之中的一個出現問題，就有可能導致項目失敗。比如中途測試人員發生變化，性能指標未和用戶達成統一理解等。筆者還曾看過一個例子，因為測試報告的格式與用戶要求的格式不一致，而不得不重新再執行一次所有的性能場景，來采集用戶要的數據。

　　實際上，當我們做過的性能測試項目越多，就會發現越多的因素可能會影響性能測試項目的成敗，甚至可以是千奇百怪的。

　　在本節中，我們主要是尋找出不同性能測試項目的共性，而總結出一個具有普遍意義的性能測試過程。遵循過程做性能測試，在大多數情況下可以有效地規避風險，并能取得比較好的性能測試結果。這當然不是意味著我們有了這個過程，就不考慮其他因素了，只是說每個項目都會有自己的獨特因素要考慮，盡管這些因素可能很重要，但它們并不在本節的討論范圍內。

　　在給出此過程模型之前，我們要澄清兩點事實：

　　第一，性能測試過程從何時開始，又在何時結束?

　　這是一個基本而重要的問題。

　　在各種書籍和資料中，有關性能測試過程的描述不盡一樣：

　　比如LoadRunner手冊中提供的過程是：計劃測試→測試設計→創建VU腳本→創建測試場景→運行測試場景→分析結果。

　　而在Segue中提供的性能測試過程，是一個try-check過程，即：評估需求→開發測試→建立基線→執行測試→分析結果→回歸測試→測試結束。

　　上面LoadRunner和Segue描述各自的性能測試過程最大的區別不在于工具部分，而是在于兩者過程的入口和出口條件不一致。這使得它們其實在描述兩件事情，或者說是在描述一個事情的兩個部分。

　　在CMM中，軟件測試和軟件設計、編碼一樣，隸屬于軟件工程過程，而需求分析過程在軟件工程過程之前。這就隱含著一個默認的先決條件：在CMM這個體系下，產品在進入軟件測試階段的時候，軟件需求是已經明確下來并文檔化了的。

　　實際情況卻經常并非如此，同樣是軟件需求，軟件功能需求在進入測試階段就已經產生了各種文檔，包括需求文檔和設計文檔，確保功能需求是詳細、明確、無二義性的;而軟件性能需求往往進入了性能測試階段還不明確(可參見Controller一章開篇的例子)。這會給性能測試項目帶來很大的風險。

　　因此，我們應該突破已有的理論束縛，尋找更合適的性能測試過程模型。經過對多個性能測試項目的實踐經驗總結，我們在本節提出GAME(A)性能測試過程模型，其開始于軟件需求分析階段，非常符合目前國內的性能測試實踐。

　　第二，性能測試本身有沒有質量?

　　以前我們總是討論軟件產品的質量、開發代碼的質量，但對軟件測試的質量卻鮮有提及。我們知道“一個好的測試用例是發現了一個原先未發現的bug”，這其實是對用例質量的度量。軟件性能測試項目也有質量，并可以度量。下面是部分度量的方法：

　　(1)性能測試耗費的資源，包括時間、人力、物力。 軟件測試　

    　(2)性能測試中發現的bug數目，以及各自的級別。

　　(3)軟件系統交付用戶，在生產環境運行后發現的性能bug數目、級別。

　　而一個好的性能測試過程模型對提高性能測試質量是很有幫助的。

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