測試用例之性能測試用例

性能測試、壓力測試、負載測試、強度測試、穩定性測試、健壯性測試、功能測試、接口測試……,這么多眼花繚亂的測試類型名稱，估計很少有人能準確的區分并說出定義來，至于對應的測試用例如何編寫和執行，就更不用說了。

如果問測試工程師測試用例如何編寫，就象是問程序員如何編寫代碼得到的答案一樣，每個人都會給出不同的編寫方法，但實用的測試用例卻象優秀的程序一樣難以編寫。

目前國內，測試工程師卻時常要面對“已經延期幾倍計劃時間的項目”，測試用例如何發揮更大的作用，是一個迫切需要解決的問題。事實上，完全可以把測試用例看成是測試工程師編寫的程序：這個“程序”是為了輔助測試工作的進行而開發的，目的是為了發現軟件問題，同時“順便”證明軟件功能是否符合要求。

本文針對上面的問題，以設計性能測試用例為示范，講解在企業實際工作中，如何有效劃分測試種類和編寫對應的測試用例，使測試工作更加合理、高效率的開展。

1測試種類和階段

1.1 測試種類

對于測試種類的說法多種多樣，最多的能達到30多種測試類型。而實際工作中很多測試是互相包含的。按照企業中實際工作需要，通常主要進行下面幾種類型的測試：功能測試、健壯性測試、接口測試、強度測試、壓力測試、性能測試、用戶界面測試、可靠性測試、安裝/反安裝測試、文檔測試。

下面介紹幾種重要的測試種類及其測試的內容：

功能測試：功能測試主要針對產品需求說明書的測試，是驗證功能是否否合需求，包括原定功能的檢驗、是否有冗余功能、遺漏功能。這類測試應由測試員做，這并不意味著程序員在發布前不必檢查他們的代碼能否工作，他們也需要進行基本功能的測試。

接口測試：程序員對各個模塊進行系統聯調的測試，包含程序內接口和程序外接口測試。這個測試，在單元測試階段進行了一部分工作，而大部分都是在集成測試階段完成的。由開發人員進行。

性能測試：在交替進行負荷和強迫測試時常用的術語。性能測試關注的是系統的整體。它和通常所說的強度、壓力/負載測試測試有密切關系。所以壓力和強度測試應該與性能測試一同進行。

用戶界面測試：對系統的界面進行測試，測試用戶界面是否友好、是否方便易用、設計是否合理、位置是否正確等一系列界面問題

安裝/反安裝測試：安裝測試主要檢驗軟件是否可以正確安裝，安裝文件的各項設置是否有效，安裝后能否影響原系統；反安裝是逆過程，測試是否刪除干凈，是否給影響原系統等。

文檔測試：主要測試開發過程中針對用戶的文檔，以需求、用戶手冊、安裝手冊等為主，檢驗文檔是否和實際應用存在差別。文檔測試不需要編寫測試用例。

測試種類的劃分不要拘泥于上面的形式，總體來說應該服從于測試策略，可以根據具體工作的特點進行安排，為了工作更容易開展，完全可以把一些測試合在一起進行。在后面的性能測試用例的編寫上，充分體現了這一思想。

1.2 測試階段

和開發過程相對應，測試過程會依次經歷單元測試、集成測試、系統測試、驗收測試四個主要階段。對應關系如圖1所示：

需求開發

高層設計

詳細設計

編程

單元測試

集成測試

系統測試

驗收測試

圖1 開發與測試的“V”型關系

單元測試：單元測試是針對軟件設計的最小單位––程序模塊甚至代碼段進行正確性檢驗的測試工作，通常由開發人員進行。

集成測試：集成測試是將模塊按照設計要求組裝起來進行測試，主要目的是發現與接口有關的問題。由于在產品提交到測試部門前，產品開發小組都要進行聯合調試，因此在大部分企業中集成測試是由開發人員來完成的。。

系統測試：系統測試是在集成測試通過后進行的，目的是充分運行系統，驗證各子系統是否都能正常工作并完成設計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產品的質量有重大的影響。

驗收測試：驗收測試以需求階段的《需求規格說明書》為驗收標準，測試時要求模擬實際用戶的運行環境。對于實際項目可以和客戶共同進行，對于產品來說就是最后一次的系統測試。測試內容為對功能模塊的全面測試，尤其要進行文檔測試。

盡管測試階段的劃分十分明確，但是在具體的項目和產品的測試中，尤其在執行測試時，會根據實際需要來開展。

1.3 測試種類、階段和用例的關系

為了便于在實際工作中提高效率，同時方便測試用例的編寫和執行，可以把上面提到的各個測試類型與對應的測試用例合并。合并后的測試用例主要有以下幾種：

1． 功能測試用例：包含功能測試、健壯性測試、可靠性測試

2． 性能測試用例：包含性能測試、壓力測試、強度測試

3． 集成測試用例：包含接口測試、健壯性測試、可靠性測試

4． 安全測試用例：安全測試用例

5． 用戶界面測試用例：包含用戶界面測試用例、少量功能測試用例

6． 安裝/反安裝測試用例：安裝/反安裝測試用例

綜合上面的分析，測試種類、測試階段以及執行人員具體的關系如表1所示。

總之，測試的種類應該盡量的少，這樣每次都可以執行更多的測試內容。例如在進行功能測試的同時，完全可以進行健壯性的測試。（當然如果產品健壯性方面要求較高，就可以把健壯性測試作為獨立的測試。）

2性能用例編寫方案

性能測試在軟件測試中占有重要的地位，而性能測試又關聯很多內容。例如壓力和強度測試就與性能測試密切相關：針對一個網站進行測試，模擬10到50個用戶就是在進行常規性能測試，用戶增加到1000乃至上萬就變成了壓力/負載測試，如果同時對系統進行大量的數據查詢操作，就包含了強度測試。

為了便于性能測試工作的實施，這里的性能測試綜合了性能、強度、壓力、負載等多方面的測試內容，主要包含的內容有：預期性能指標測試、用戶并發性能測試、疲勞強度測試、大數據量測試和速度測試、網絡、服務器等方面的內容。

性能測試不同的系統有不同的要求，編寫方法要根據實際要求進行編寫，本文提出一個常見的參考方案，在實際工作中，可以根據需要加入其它例如內存泄露等和性能相關的測試用例。

下面介紹各個部分性能測試用例包含的內容：

2.1預期性能指標測試用例

通常系統在設計前都會提出一些性能指標，這些指標是性能測試要完成的首要工作之一。針對每個指標都要編寫多個測試用例來驗證是否達到要求，并根據測試結果來改進系統的性能。

這類通常以單用戶為主，如果遇到并發用戶的情況，可以歸到并發用戶測試用例中。這類用例通常都是可以通過手工來執行的用例，例如示例中的上傳一份文件，期望的性能為2M/S，完全可以手動上傳文件，同時用秒表計時。這些內容通常在需求說明書中可以顯而易見的查到。不過當看到如支持并發用戶300人，就應該放到后面進行。測試結果也是直接記錄是否達到要求，如果系統沒有達到要求則進行改善。

2.2用戶并發性能測試用例

用戶并發測試是性能測試的最主要部分，包含了負載測試和壓力測試的過程。主要是逐漸增加用戶數量來加重系統負擔，直到出現不能接收的性能點或者瓶頸。一般要測試正常數量的用戶并發和極限數量下用戶并發的情況。

并發用戶測試主要是對系統的核心功能和重要業務進行測試，要以真實的業務數據作為輸入，選擇有代表性和關鍵的業務操作來設計測試用例。主要編寫以下兩個方面的用例：

核心模塊的測試（可以理解為“單元性能測試”）：對核心功能模塊進行并發用戶測試，測試系統是否能夠穩定運行。例如對于互聯網的公用郵件系統，每天早上9點左右可能是收發郵件的高峰，這時候上千的用戶都要在上班后進入郵件系統，系統這個時候需要接收和發送大量的郵件。所以郵件系統這一功能模塊要進行并發測試。通過測試可以知道數據庫服務器、操作系統、網絡設備等是否能夠承受住考驗，同時可以對瓶頸進行分析。

表2列出來一些常見的參數(表格中的數據為示例的測試用例和測試結果)，可以根據實際需要進行增加和刪除，其中磁盤I/O、數據庫相關測試參數要根據實際情況進行選擇，因此沒有列出。

在編寫這類用例時，要進行綜合分析，選出系統中的各個核心模塊，分別設計每個模塊的測試用例：把模塊劃分成小的“事務”進行測試，這樣在測試分析中便于定位問題究竟出現在哪里。例如郵件系統可以劃分成：接收郵件、發送郵件、打開郵件等小的事務進行測試用例的編寫，每個操作做為一個用例來執行。

業務組合性能測試（可以理解為“集成性能測試”）：所有的用戶不會只使用核心模塊，通常每個功能都可能被使用到，所有既要模擬多用戶的“相同”操作，又要模擬多用戶的不同操作，對多個業務進行組合性能測試。

業務組合測試是更接近用戶實際操作系統的測試，因此用例編寫要充分考慮實際情況，選擇最接近實際的場景進行設計。這里的業務組成單位以不同模塊中的“子操作事務”為單位，進行各個模塊的不同業務的組合。例如在辦公自動化系統中就可以選擇“公文模塊中的發送公文、電子公告模塊中的查看公告信息、網上論壇模塊中的上傳文件”等事務作為一組組合業務進行測試，用例設計信息如下：

功能：在線用戶達到高峰時，用戶可以正常使用系統，保證500個以內用戶可以同時在線使用系統。

目的：測試系統500個以內的用戶同時在線能否使用比較常見的模塊：公文系統、電子公告、網上論壇。

方法：采用LoadRunner的錄制工具錄制三個業務：

業務1––在公文系統內，進行打開、修改等操作；

業務2––在電子公告系統內，查看、發布公告；

業務3––在網上論壇系統內發布帖子，查看文章。每個業務分配一定數目的用戶，利用LoadRunner來完成相關參數的測試。

其它部分設計可以參考表2。執行時要分別記錄各個事務的執行情況。

多用戶并發性能測試是性能測試的核心內容，包含了全部與多用戶相關的測試。因此設計時要全面考慮，不要有遺漏。在測試執行時，本部分通常是采用性能測試工具例如LoadRunner來進行測試的，因此更容易執行和提高效率。

2.3疲勞強度與大數據量測試

疲勞強度測試是在系統穩定運行下模擬最大用戶數量、并長時間運行系統，通過綜合分析執行指標和資源監控來確定系統處理最大業務量時的性能。

疲勞強度測試的目的就是檢驗系統長時間運行后的性能，因此設計用例時，需要編寫不同參數或者負載條件下的多個測試用例，對服務器、軟件、網絡進行不同條件下的綜合測試分析，測試時要記錄系統發生故障的信息作為測試結果。疲勞強度測試也是采用測試工具進行的。

大數據量測試分為兩種：一個是針對某些系統存儲、傳輸、統計查詢等業務進行大數據量的測試；另一個是與前面并發測試相結合的綜合數據測試。編寫用例時主要編寫前一部分，后一部分盡量放在并發測試中。

大數據量測試一般是針對那些對數據庫有特殊要求的系統進行測試，例如電信業務系統的手機短信息表，由于有的用戶關機或者不在服務區，每秒鐘需要有大量的短信息保存，同時在用戶聯機后還要及時發送，因此對數據庫性能有極高的要求，需要專門測試。

本部分用例設計表格可以參考用戶并發性能測試部分。

2.4網絡性能測試

網絡性能測試主要是為了準確展示帶寬、延遲、負載和端口的變化是如何影響用戶的響應時間的。在實際的軟件項目中，主要是測試用戶數目與網絡帶寬的關系。

編寫用例的格式如表3(表格中的數據為示例數據)：

本部分可以獨立測試，也可以和用戶并發性能測試、疲勞強度與大數據量性能測試結合起來，在原有的基礎上采用工具來調整網絡設置，從而達到監視網絡性能的目的。通常網絡性能都是采用工具進行性能評估，由系統集成工程師來進行。

2.5服務器性能測試

本部分的測試用例不必獨立編寫，或者根據實際需要編寫少量的測試用例，建議這部分的用例編寫和前兩部分結合起來，在用戶并發性能測試、疲勞強度與大數據量性能測試時完成對服務器性能的監控，完成對服務器性能的評估。

2.6性能分析基本策略

在上面的用例執行完成后，接下來要進行性能分析。性能分析是性能測試的最終目的，否則測試出的指標就不會有實際意義，這里主要介紹一下性能分析的基本思路。性能分析通常要圍繞三個方面進行：軟件、服務器、網絡。

軟件主要是分析具體事務執行時間，尤其并發用戶部分，根據測試工具測試出的結果分析那些事務執行的慢，然后可以分析執行較慢的代碼，針對網頁可以分析具體的頁面元素執行情況。

服務器的分析要結合軟件的運行情況進行分析，著重分析硬件的執行參數，CPU、硬盤、內存、中斷、內存等情況，分析尤其要注意對這些參數進行綜合分析，往往各個參數之間會互相影響，最后在調查、分析整體系統的基礎上，找出影響服務器整體性能的瓶頸，確定相應的升級需求：

1. 服務器硬盤負載較重，需增加硬盤。

2. CPU整體性能偏低，需增加或更新CPU。

3. 網卡性能偏低，需更換光纖網卡。

4. 硬盤I/O負載任務繁重，需使用高轉速硬盤或采用RAID卡。

5. 內存資源短缺，需增大內存。

6. 其他方面，需要升級軟件系統、合理進行子網劃分、加強管理等。

網絡性能分析要結合結合服務器和測試目標軟件，通常網絡傳輸慢會有軟件和服務器方面的原因，甚至有時候會有客戶端方面的原因。不過目前網絡的環境普遍可以，不管是局域網還是廣域網，網絡的環境越來越好。

3用例管理

測試用例的管理我們可以借鑒開發過程中對程序的管理方法，我們可以把測試用例看成程序––測試工程師編寫的程序，這個程序也要經過“設計”、“開發”、“測試”、“版本管理”、“發布”、“維護”等一系列操作，然后按照管理軟件程序的方法來管理測試用例。

用例管理主要包含評審、修改、執行用例、用例版本維護、用例升級方面的內容。

3.1 用例評審

測試用例評審是測試用例不可缺少的一個環節，這是對“測試部門開發出的產品”進行的“測試”?；舅悸肥菍y試準備階段的成果進行分期評審，依次評審系統/驗收測試用例、集成測試用例、單元測試用例。

評審用例在比較正規的公司更容易實施，要求相應的軟件開發團隊必須在實際工作中對測試給予足夠的重視，才可以把這項工作做好，否則只是走走形式。有效的用例評審通常由下面兩種形式組成：

測試部門外部評審––主要是由開發部、項目實施部、甚至銷售人員參加的評審，目的主要是查找測試工程師編寫的用例是否缺少內容。建議采用非正式評審的形式進行，因為我們很難把開發人員組織在一起，一般來說他們的開發進度壓力很大，能夠抽出時間看文檔已經是“很給面子了”。當然不統一進行評審會耽誤工程的進度，所以在實際工作中如果時間緊迫，可以提前啟動測試實施工作，待評審完成后進行用例的修改工作。通常測試工作進行一段時間評審就會結束，這個時候測試執行人員可以在工作中對測試用例的內容進行動態的調整，再次執行被修改過的部分用例（如果能夠采用正式評審，效果肯定會更好。）。

外部評審主要工作方式是用文檔直接記錄評審結果，測試人員根據評審結果對用例進行升級修改。

測試部門內部評審––部門內部同行對測試策略的評審，評審的核心內容是測試策略和用例編制思路是否正確，以此來保證測試用例的有效性?？梢越M織正式的評審，由用例的設計人員進行講解，然后大家共同評審；也可以把文檔發給部門的同事進行評審。內部評審有些象開發人員在單元測試中的交叉測試。

內部評審的主要工作方式是項目會議，大家可以進行激烈的討論，共同探討用例編寫、交流經驗，這樣用例的編寫水平才能提高，同時可以進行一些創新。

評審方式中的外部評審最為重要。因為開發人員很容易發現用例中遺漏了什么內容，同時還可以發現錯誤的用例––因為存在對需求理解的偏差。用例外部評審可以理解為開發人員在查找測試人員編寫的“程序”缺陷。

通常情況下先執行內部評審，然后執行外部評審。很多時候，內部評審會被忽略，建議要進行內部評審。這樣至少有兩個好處：集思廣益和提高測試小組輸出文檔的質量。

3.2 管理方案

國內大多數IT公司在測試用例的發展經歷了以下幾個階段：

• 無用例而執行測試：測試的初級階段，完全手工測試，測試執行工程中沒有測試用例作為執行依據，可能會按照需求進行測試；
• 有用例而不使用用例執行測試：已經編寫測試用例，但是受各種環境的影響，例如需求變動頻繁、編寫的用例過于簡單等，測試用例編寫后在實際工作中不能使用；
• 按照部分用例執行測試：隨著用例編寫水平的提高，部分測試用例可以在測試中發揮作用；
• 完全按照用例執行測試：組織建立了規范的項目管理過程，對測試用例進行規范的管理，執行測試用例以用例為準則來執行測試。

完全按照測試用例執行測試是一個公司測試水平的體現，測試用例管理成為這一階段的主要內容。測試用例管理的核心內容是版本管理。如果測試用例是采用文字編輯軟件例如word編寫，建議采用工具（例如Visual SourceSafe）對用例進行控制?？梢詤⒄請D2進行。

編寫用例

用例評審

進入版本控制庫

用例修改

使用用例&維護&升級

圖2 測試用例管理示意圖

1、 編寫用例：測試工程師根據需求分析、概要設計、詳細設計等文檔編寫測試用例。

2、 用例評審：3.1小結說明了用例的評審。原則上用例像程序一樣，要經過多次的修改才可以通過，而實際工作中只進行一到兩次。

3、 用例修改：評審結束后，需要根據評審意見進行修改，修改后通常不再進行評審。建議在時間和人力資源比較充裕的情況下，對用例的評審要像測試開發部門的產品一樣，經過反復的評審和修改，然后正式投入使用，因為每次評審可能都有新的發現。

4、 使用用例：在執行任務時，從版本控制庫取出用例，執行時建議直接在用例上記錄測試結果。這樣做會帶來兩個好處：首先是下次測試時可以看見上次測試的結果記錄，可以起一個提醒的作用；其次可以一次性的把發現的缺陷輸入到缺陷跟蹤數據庫中，在輸入時可以進行綜合統計，避免輸入重復的缺陷。每次使用后送入版本控制庫中，進行版本的管理。

5、 用例升級/維護：隨著軟件產品的不斷修改、升級，對應的用例也需要升級和維護。針對同一個項目，可以根據需求的變更不斷進行維護；如果是產品，用例的維護則更加重要，要達到用例和產品的版本一一對應。

測試用例的管理還可以采用專門的測試軟件例如TestDirector等來進行管理，測試工具通常會具備上面的功能。如果有條件，建議采用集成華的測試工具，這樣更容易對測試執行全程進行監控，可以把測試需求、測試用例、缺陷管理統一起來，大大提高測試效率。

在測試用例管理規范化并成為測試的執行準則后，管理測試用例帶來的巨大好處開始逐漸顯現出來，測試用例成為評估測試和改進測試工作的主要依據，可以給工具帶來巨大的方便。例如可以通過測試用例的執行情況來統計分析執行結果，編寫測試報告，判斷軟件測試是否完成，通過統計測試覆蓋率、測試合格率、重要測試對象的合格率是多少來完成對軟件質量的評估；尤其是新員工到崗后，可以更容易介入工作。

總之，不管是性能測試還是其它測試都要本著“一切從實際出發”的原則，根據不同產品的特性進行用例編寫，最后按照要求完成測試，達到提高產品質量的目的。在測試用例的編寫過程中，尤其要記得“創新”，如果長期依靠某一測試用例編寫模式、采用某些固定的模板，測試用例編寫工作肯定會停滯在某一層次上不再發展，一定要跟著測試對象的不斷變化來調整策略，在具體的工作中改進和提高，才能“開發”出優秀的測試用例！

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