功能和性能測試經驗談(2)

　　5.分析測試結果

　　分析測試結果在整個測試過程中最重要，通過分析可以發現應用程序的各種功能性缺陷。當運行完某個測試腳本后，會產生一個測試報告，從這個測試報告中我們能發現應用程序的功能性缺陷，能看到實際結果和期望結果之間的差異，以及在測試過程中產生的各類對話框等。

　　6.回報缺陷(defect)

　　在分析完測試報告后，按照測試流程要回報應用程序的各種缺陷，然后將這些缺陷發給指定人，以便進行修改和維護。

　　性能測試的三大步驟

　　第一步 準備和組織是性能測試過程的第一步，在這個階段，需要明確性能測試的目標和需求，并組織起合適的人員，制訂性能測試計劃。

　　一般來說，性能測試的應用領域分為能力驗證、能力規劃、性能調優和缺陷修復四個方面。其中能力驗證表明測試的目的是驗證系統能力是否達到預期的性能標準; 能力規劃是要考察系統的可擴展性; 性能調優則是為了找到系統的性能瓶頸，為性能調優提供依據; 缺陷修復是為了找出系統中存在的并發等方面的缺陷。

　　明確目標也就是要把性能測試的目的歸到相應的應用領域，而確定需求則是要更詳細地確定性能測試的基準。對產品的性能測試需求的來源是軟件需求、設計文檔或是用戶備忘錄等設計和需求相關的文檔。當然，并非所有的性能測試需求都在這些文檔中以明確的方式標識出來，此時就需要根據不十分明確的文檔描述進行進一步的細化。我們的經驗是在文檔評審時高度關注所有與性能相關的描述，例如“要求操作響應時間小于……”、“要求……能夠快速……”、“要求……能夠支持……用戶訪問”、“要求……能快速穩定運行”等，然后進行進一步的細化，從而作為測試的依據。

　　性能測試涉及的設備、環境、技術、工具較多，性能測試人員的組織也必須兼顧這些方面。一個性能測試組最好包括系統工程師(負責測試環境搭建、服務器和應用服務器的配置)、網絡工程師(負責網絡環境的維護和驗證)、性能分析工程師(負責測試計劃的擬定，對性能測試結果進行分析，給出性能測試報告)、自動化工程師(負責測試腳本的編寫和測試工具實施)、數據庫工程師(負責對數據庫層進行性能問題定位)。在條件允許的情況下，還可以包括開發工程師和客戶代表，輔助對性能測試結果進行分析和確認。

　　性能測試計劃是用來指導性能測試過程的主要文檔，在測試計劃中除了要寫明本次測試的測試目標、測試需求外，還需要在測試計劃中給出明確的測試退出條件和測試的時間和資源計劃。

　　第二步 第二步測試設計，也是性能測試的主要內容。測試設計一般基于測試場景進行，一個測試場景就是一個用戶的實際使用系統的剖面。

　　在性能測試過程中，明確每個場景的參與者人數、比例和具體行為是非常重要的，這些都是構成性能測試腳本的基礎。根據經驗，可以從應用服務器的日志中分析用戶行為。例如，對于一個OA系統，我們從日志中分析出在上午9:00～9:30時段內有200個查看郵件頁面的page view，且查看時間基本集中在前10分鐘; 而在9:00～9:30時間段內對BUG顯示頁面的查看量是300個page view，對頁面的訪問基本平均分配在整個時間段，則我們可以建立兩個腳本，前一個腳本模擬查看郵件操作(腳本1)，后一個腳本模擬查看BUG操作(腳本 2)，考慮運行15分鐘的測試場景，則只需在前5分鐘運行腳本1，在整個過程中運行腳本2，通過調整think time使得page view達到實際的數值即可。

　　當然，并不是每個不同的用戶應用剖面都需要作為測試場景來設計，在多數情況下，可以通過對測試場景出現的幾率、重要性、風險等進行分析，從而最終確定需要設計的測試場景。明確了場景之后，根據性能測試應用領域的不同，可以采用不同的性能測試方法來達到性能測試的目標。另外需要提醒的是，性能測試設計還應該包括測試環境、測試數據等的設計，因為影響系統性能的因素很多，保持測試過程中環境和數據的可控性是非常重要的。

　　第三步 第三步性能測試結果分析，是性能測試過程中最困難，也是最重要的步驟。它需要分析人員對測試結果中的各項數據有準確的認識，明確各指標之間的關系。如果各項數據指標間沒有明顯聯系，在多數情況下需要綜合考慮各種因素，才能得出最終結論。

原文轉自：http://www.uml.org.cn/Test/200608151.htm