性能測試從零開始——LoadRunner入門(五)[2] 性能測試工具
需要注意的是，軟件的性能瓶頸可能不止一處。
作為軟件測試的一種，軟件測試的規則同樣適用于性能測試中：
(1)確定預期輸出是測試必不可少的一部分
如果事先無法肯定預期的測試結果，往往會把看起來似是而非的東西當作正確結果。必須提倡用事先精確對應的輸入和輸出結果來詳細檢查所有的輸出。對于性能測試來說，預期輸出就是用戶的性能需求，一份明確的性能需求是成功性能測試的先決條件。
(2)必須徹底檢查每一個測試結果
事實上，在最終發現的錯誤，有相當一部分在前面的測試中已經暴露出來了，然而由于人們未能細心檢查先前的測試結果而遺漏了。
一段程序中存在的錯誤概率與在這段程序中發現的錯誤數呈正比。
這是pareto原則應用于軟件測試，也包括性能測試，即性能測試發現的錯誤中的80%很可能集中在20%的程序模塊中。
(3)窮舉測試是不可能的
在性能測試中不可能覆蓋每一個功能部分，這也意味著有性能問題的模塊可能被忽略掉，這樣的話，我們在設計性能測試案例時，應該采取一些策略和技巧，使用盡可能少的性能測試用例，發現盡可能多的bug。這方面內容我們將在本書的第10章中介紹。
在具有軟件測試共性的同時，性能測試也有自身的一些特點。 軟件測試工具
1.性能測試不是功能測試
性能測試不要求也無法做到覆蓋軟件所有的功能，通常我們只是對系統中某些功能或模塊做性能測試。一般的，我們在選擇性能測試案例時需要遵循以下的原則：
(1)基本且常用的
比如，一個E-mail系統，基本且常用的功能有注冊、登錄、收郵件、查詢郵件，用戶使用這些功能的頻率較高，要做性能測試。而高級查詢、過濾器、郵件列表等功能被使用的次數較少，就可以不做性能測試，或者進行性能測試的優先級低一些。
(2)對響應時間要求苛刻的
這樣的要求經常出現在金融和電信等對實時性要求比較高的系統中。比如，從手機呼叫開始，經過基站、核心網，再到被叫手機響鈴，整個系統的處理時間應該在用戶能接受的范圍內。另外，一個負責和手機通信的基站在發生故障或掉電后，要能很快地恢復工作狀態。這些功能都對時間有著嚴格的要求，一定要做性能測試，當然實際運作時，電信系統上線時所做的性能測試不僅僅限于這些功能。
將這些功能細分就是性能測試中的事務(Transaction)。關于事務這個概念我們在后面的章節中將詳細闡述。
2.性能測試屬于系統級測試
從V型圖可以看到，性能測試屬于系統級測試。那么性能測試是基于單元測試、集成測試、功能測試等都已經完成的基礎上，站在用戶的角度去測試整個系統的。這包含兩個含義：
第一，性能測試是“兩頭在外”，軟件性能需求不僅直接來自用戶，最終目的也是服務于用戶。通過性能測試這個過程，從上面我們講到用戶的需求和性能測試指標的對應關系，就可以看出。
第二，性能測試開始的必要條件是軟件系統已經處于一個比較穩定的狀態，系統架構、主要代碼、中間件等都不再有大的變化，否則會給性能測試帶來很大的風險。
文章來源于領測軟件測試網 http://www.kjueaiud.com/