功能和性能測試經驗談

功能和性能測試經驗談


■ 段念 王志平 戴金龍


可以說，誰掌握了功能測試和性能測試的精髓，誰就能在測試外包市場中占據技術制高點。本文正是為這類軟件服務型企業出謀劃策、提供測試技術決策參考。

雖然功能測試是絕大多數軟件都無法回避的，但多數開發企業不諳其中滋味，所以，測試外包市場才會如此繁榮而且規模日益壯大。目前，功能測試已跨越了單靠手工敲敲鍵盤、點點鼠標就可以完成的階段，正朝著自動化和智能化方向發展。自動化是指各類測試工具已經得到日益廣泛的應用; 智能化是指測試人員從腳本編制、運行、調試到結果分析乃至測試方案改進，都需要有深入的了解。

而性能測試的重要性是隨著網絡應用的發展而發展的，由于網絡環境、數據庫環境、應用服務器環境、系統平臺和技術等的復雜性和多樣性，軟件性能非常難于控制。雖然，改善系統性能不是單單依靠性能測試就能完成的，但性能測試至今仍是控制性能的非常有效的手段，在軟件的能力驗證、能力規劃、性能調優、缺陷修復等方面都發揮著重要作用。

功能測試工具的選擇

那么，如何高效地完成功能測試？選擇一款合適的功能測試工具并培訓一支高素質的工具使用隊伍無疑是至關重要的。盡管現階段存在少數不采用任何功能測試工具，從事功能測試外包項目的軟件服務企業。短期來看，這類企業盈利狀況尚可，但長久來看，它們極有可能被自動化程度較高的軟件服務企業取代。

目前，用于功能測試的工具軟件有很多，針對不同架構軟件的工具也不斷推陳出新。這里重點介紹的是其中一個較為典型自動化測試工具，即Mercury公司的WinRunner。

WinRunner是一種用于檢驗應用程序能否如期運行的企業級軟件功能測試工具。通過自動捕獲、檢測和模擬用戶交互操作，WinRunner能識別出絕大多數軟件功能缺陷，從而確保那些跨越了多個功能點和數據庫的應用程序在發布時盡量不出現功能性故障。

WinRunner的特點在于: 與傳統的手工測試相比，它能快速、批量地完成功能點測試; 能針對相同測試腳本，執行相同的動作，從而消除人工測試所帶來的理解上的誤差; 此外，它還能重復執行相同動作，測試工作中最枯燥的部分可交由機器完成; 它支持程序風格的測試腳本，一個高素質的測試工程師能借助它完成流程極為復雜的測試，通過使用通配符、宏、條件語句、循環語句等，還能較好地完成測試腳本的重用; 它針對于大多數編程語言和Windows技術，提供了較好的集成、支持環境，這對基于Windows平臺的應用程序實施功能測試而言帶來了極大的便利。

WinRunner的工作流程大致可以分為以下六個步驟:

1．識別應用程序的GUI

在WinRunner中，我們可以使用GUI Spy來識別各種GUI對象，識別后，WinRunner會將其存儲到GUI Map File中。它提供兩種GUI Map File模式: Global GUI Map File和GUI Map File per Test。其最大區別是后者對每個測試腳本產生一個GUI文件，它能自動建立、存儲、加載，推薦初學者選用這種模式。但是，這種模式不易于描述對象的改變，其效率比較低，因此對于一個有經驗的測試人員來說前者不失為一種更好的選擇，它只產生一個共享的GUI文件，這使得測試腳本更容易維護，且效率更高。

2．建立測試腳本

在建立測試腳本時，一般先進行錄制，然后在錄制形成的腳本中手工加入需要的TSL（與C語言類似的測試腳本語言）。錄制腳本有兩種模式: Context Sensitive和Analog，選擇依據主要在于是否對鼠標軌跡進行模擬，在需要回放時一般選用Analog。在錄制過程中這兩種模式可以通過F2鍵相互切換。

只要看看現代軟件的規模和功能點數就可以明白，功能測試早已跨越了單靠手工敲敲鍵盤、點點鼠標就可以完成的階段。而性能測試則是控制系統性能的有效手段，在軟件的能力驗證、能力規劃、性能調優、缺陷修復等方面都發揮著重要作用。

3．對測試腳本除錯(debug)

在WinRunner中有專門一個Debug Toolbar用于測試腳本除錯?？梢允褂胹tep、pause、breakpoint等來控制和跟蹤測試腳本和查看各種變量值。

4．在新版應用程序執行測試腳本

當應用程序有新版本發布時，我們會對應用程序的各種功能包括新增功能進行測試，這時當然不可能再來重新錄制和編寫所有的測試腳本。我們可以使用已有的腳本，批量運行這些測試腳本測試舊的功能點是否正常工作?？梢允褂靡粋€call命令來加載各測試腳本。還可在call命令中加各種TSL腳本來增加批量能力。

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達到實際的數值即可。

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

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

根據經驗，在性能測試過程中最容易發生的問題是數據庫訪問層問題、應用服務器配置問題以及網絡問題。因此建議一般按照“從簡至繁”的原則，先排除網絡問題，其次對應用服務器配置進行分析，然后在數據庫訪問層進行性能分析，重點是索引、數據庫Cache、死鎖等問題的分析。在確認所有這些因素都不是性能瓶頸的情況下，才對代碼進行分析和檢查，找出導致性能問題的因素。

只要看看現代軟件的規模和功能點數就可以明白，功能測試早已跨越了單靠手工敲敲鍵盤、點點鼠標就可以完成的階段。而性能測試則是控制系統性能的有效手段，在軟件的能力驗證、能力規劃、性能調優、缺陷修復等方面都發揮著重要作用。

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