性能測試方案編寫

1、2性能用例編寫方案性能測試在軟件測試中占有重要的地位，而性能測試又關(guān)聯(lián)很多內(nèi)容。例如壓力和強度測試就與性能測試密切相關(guān)：針對一個網(wǎng)站進行測試，模擬10到50個用戶就是在進行常規(guī)性能測試，用戶增加到1000乃至上萬就變成了壓力/負(fù)載測試，如果同時對系統(tǒng)進行大量的數(shù)據(jù)查詢操作，就包含了強度測試。為了便于性能測試工作的實施，這里的性能測試綜合了性能、強度、壓力、負(fù)載等多方面的測試內(nèi)容，主要包含的內(nèi)容有：預(yù)期性能指標(biāo)測試、用戶并發(fā)性能測試、疲勞強度測試、大數(shù)據(jù)量測試和速度測試、網(wǎng)絡(luò)、服務(wù)器等方面的內(nèi)容。性能測試不同的系統(tǒng)有不同的要求，編寫方法要根據(jù)實際要求進行編寫，本文提出一個常見的參考方案，在實際工

2、作中，可以根據(jù)需要加入其它例如內(nèi)存泄露等和性能相關(guān)的測試用例。下面介紹各個部分性能測試用例包含的內(nèi)容：2.1預(yù)期性能指標(biāo)測試用例通常系統(tǒng)在設(shè)計前都會提出一些性能指標(biāo)，這些指標(biāo)是性能測試要完成的首要工作之一。針對每個指標(biāo)都要編寫多個測試用例來驗證是否達到要求，并根據(jù)測試結(jié)果來改進系統(tǒng)的性能。這類通常以單用戶為主，如果遇到并發(fā)用戶的情況，可以歸到并發(fā)用戶測試用例中。這類用例通常都是可以通過手工來執(zhí)行的用例，例如示例中的上傳一份文件，期望的性能為2M/S，完全可以手動上傳文件，同時用秒表計時。這些內(nèi)容通常在需求說明書中可以顯而易見的查到。不過當(dāng)看到如支持并發(fā)用戶300人，就應(yīng)該放到后面進行。測試結(jié)果

3、也是直接記錄是否達到要求，如果系統(tǒng)沒有達到要求則進行改善。2.2用戶并發(fā)性能測試用例用戶并發(fā)測試是性能測試的最主要部分，包含了負(fù)載測試和壓力測試的過程。主要是逐漸增加用戶數(shù)量來加重系統(tǒng)負(fù)擔(dān)，直到出現(xiàn)不能接收的性能點或者瓶頸。一般要測試正常數(shù)量的用戶并發(fā)和極限數(shù)量下用戶并發(fā)的情況。并發(fā)用戶測試主要是對系統(tǒng)的核心功能和重要業(yè)務(wù)進行測試，要以真實的業(yè)務(wù)數(shù)據(jù)作為輸入，選擇有代表性和關(guān)鍵的業(yè)務(wù)操作來設(shè)計測試用例。主要編寫以下兩個方面的用例：核心模塊的測試（可以理解為“單元性能測試”）：對核心功能模塊進行并發(fā)用戶測試，測試系統(tǒng)是否能夠穩(wěn)定運行。例如對于互聯(lián)網(wǎng)的公用郵件系統(tǒng)，每天早上9點左右可能是收發(fā)郵件的

4、高峰，這時候上千的用戶都要在上班后進入郵件系統(tǒng)，系統(tǒng)這個時候需要接收和發(fā)送大量的郵件。所以郵件系統(tǒng)這一功能模塊要進行并發(fā)測試。通過測試可以知道數(shù)據(jù)庫服務(wù)器、操作系統(tǒng)、網(wǎng)絡(luò)設(shè)備等是否能夠承受住考驗，同時可以對瓶頸進行分析。表2列出來一些常見的參數(shù)(表格中的數(shù)據(jù)為示例的測試用例和測試結(jié)果)，可以根據(jù)實際需要進行增加和刪除，其中磁盤I/O、數(shù)據(jù)庫相關(guān)測試參數(shù)要根據(jù)實際情況進行選擇，因此沒有列出。在編寫這類用例時，要進行綜合分析，選出系統(tǒng)中的各個核心模塊，分別設(shè)計每個模塊的測試用例：把模塊劃分成小的“事務(wù)”進行測試，這樣在測試分析中便于定位問題究竟出現(xiàn)在哪里。例如郵件系統(tǒng)可以劃分成：接收郵件、發(fā)送郵件

5、、打開郵件等小的事務(wù)進行測試用例的編寫，每個操作做為一個用例來執(zhí)行。業(yè)務(wù)組合性能測試（可以理解為“集成性能測試”）：所有的用戶不會只使用核心模塊，通常每個功能都可能被使用到，所有既要模擬多用戶的“相同”操作，又要模擬多用戶的不同操作，對多個業(yè)務(wù)進行組合性能測試。業(yè)務(wù)組合測試是更接近用戶實際操作系統(tǒng)的測試，因此用例編寫要充分考慮實際情況，選擇最接近實際的場景進行設(shè)計。這里的業(yè)務(wù)組成單位以不同模塊中的“子操作事務(wù)”為單位，進行各個模塊的不同業(yè)務(wù)的組合。例如在辦公自動化系統(tǒng)中就可以選擇“公文模塊中的發(fā)送公文、電子公告模塊中的查看公告信息、網(wǎng)上論壇模塊中的上傳文件”等事務(wù)作為一組組合業(yè)務(wù)進行測試，用例

6、設(shè)計信息如下：功能：在線用戶達到高峰時，用戶可以正常使用系統(tǒng)，保證500個以內(nèi)用戶可以同時在線使用系統(tǒng)。目的：測試系統(tǒng)500個以內(nèi)的用戶同時在線能否使用比較常見的模塊：公文系統(tǒng)、電子公告、網(wǎng)上論壇。方法：采用LoadRunner的錄制工具錄制三個業(yè)務(wù)：業(yè)務(wù)1在公文系統(tǒng)內(nèi)，進行打開、修改等操作；業(yè)務(wù)2在電子公告系統(tǒng)內(nèi)，查看、發(fā)布公告；業(yè)務(wù)3在網(wǎng)上論壇系統(tǒng)內(nèi)發(fā)布帖子，查看文章。每個業(yè)務(wù)分配一定數(shù)目的用戶，利用LoadRunner來完成相關(guān)參數(shù)的測試。其它部分設(shè)計可以參考表2。執(zhí)行時要分別記錄各個事務(wù)的執(zhí)行情況。多用戶并發(fā)性能測試是性能測試的核心內(nèi)容，包含了全部與多用戶相關(guān)的測試。因此設(shè)計時要全面考

7、慮，不要有遺漏。在測試執(zhí)行時，本部分通常是采用性能測試工具例如LoadRunner來進行測試的，因此更容易執(zhí)行和提高效率。2.3疲勞強度與大數(shù)據(jù)量測試疲勞強度測試是在系統(tǒng)穩(wěn)定運行下模擬最大用戶數(shù)量、并長時間運行系統(tǒng)，通過綜合分析執(zhí)行指標(biāo)和資源監(jiān)控來確定系統(tǒng)處理最大業(yè)務(wù)量時的性能。疲勞強度測試的目的就是檢驗系統(tǒng)長時間運行后的性能，因此設(shè)計用例時，需要編寫不同參數(shù)或者負(fù)載條件下的多個測試用例，對服務(wù)器、軟件、網(wǎng)絡(luò)進行不同條件下的綜合測試分析，測試時要記錄系統(tǒng)發(fā)生故障的信息作為測試結(jié)果。疲勞強度測試也是采用測試工具進行的。大數(shù)據(jù)量測試分為兩種：一個是針對某些系統(tǒng)存儲、傳輸、統(tǒng)計查詢等業(yè)務(wù)進行大數(shù)據(jù)量

8、的測試；另一個是與前面并發(fā)測試相結(jié)合的綜合數(shù)據(jù)測試。編寫用例時主要編寫前一部分，后一部分盡量放在并發(fā)測試中。大數(shù)據(jù)量測試一般是針對那些對數(shù)據(jù)庫有特殊要求的系統(tǒng)進行測試，例如電信業(yè)務(wù)系統(tǒng)的手機短信息表，由于有的用戶關(guān)機或者不在服務(wù)區(qū)，每秒鐘需要有大量的短信息保存，同時在用戶聯(lián)機后還要及時發(fā)送，因此對數(shù)據(jù)庫性能有極高的要求，需要專門測試。本部分用例設(shè)計表格可以參考用戶并發(fā)性能測試部分。2.4網(wǎng)絡(luò)性能測試網(wǎng)絡(luò)性能測試主要是為了準(zhǔn)確展示帶寬、延遲、負(fù)載和端口的變化是如何影響用戶的響應(yīng)時間的。在實際的軟件項目中，主要是測試用戶數(shù)目與網(wǎng)絡(luò)帶寬的關(guān)系。編寫用例的格式如表3(表格中的數(shù)據(jù)為示例數(shù)據(jù))：本部分可

9、以獨立測試，也可以和用戶并發(fā)性能測試、疲勞強度與大數(shù)據(jù)量性能測試結(jié)合起來，在原有的基礎(chǔ)上采用工具來調(diào)整網(wǎng)絡(luò)設(shè)置，從而達到監(jiān)視網(wǎng)絡(luò)性能的目的。通常網(wǎng)絡(luò)性能都是采用工具進行性能評估，由系統(tǒng)集成工程師來進行。2.5服務(wù)器性能測試本部分的測試用例不必獨立編寫，或者根據(jù)實際需要編寫少量的測試用例，建議這部分的用例編寫和前兩部分結(jié)合起來，在用戶并發(fā)性能測試、疲勞強度與大數(shù)據(jù)量性能測試時完成對服務(wù)器性能的監(jiān)控，完成對服務(wù)器性能的評估。2.6性能分析基本策略在上面的用例執(zhí)行完成后，接下來要進行性能分析。性能分析是性能測試的最終目的，否則測試出的指標(biāo)就不會有實際意義，這里主要介紹一下性能分析的基本思路。性能分析

10、通常要圍繞三個方面進行：軟件、服務(wù)器、網(wǎng)絡(luò)。軟件主要是分析具體事務(wù)執(zhí)行時間，尤其并發(fā)用戶部分，根據(jù)測試工具測試出的結(jié)果分析那些事務(wù)執(zhí)行的慢，然后可以分析執(zhí)行較慢的代碼，針對網(wǎng)頁可以分析具體的頁面元素執(zhí)行情況。服務(wù)器的分析要結(jié)合軟件的運行情況進行分析，著重分析硬件的執(zhí)行參數(shù)，CPU、硬盤、內(nèi)存、中斷、內(nèi)存等情況，分析尤其要注意對這些參數(shù)進行綜合分析，往往各個參數(shù)之間會互相影響，最后在調(diào)查、分析整體系統(tǒng)的基礎(chǔ)上，找出影響服務(wù)器整體性能的瓶頸，確定相應(yīng)的升級需求：1. 服務(wù)器硬盤負(fù)載較重，需增加硬盤。2. CPU整體性能偏低，需增加或更新CPU。3. 網(wǎng)卡性能偏低，需更換光纖網(wǎng)卡。4. 硬盤I/O負(fù)

11、載任務(wù)繁重，需使用高轉(zhuǎn)速硬盤或采用RAID卡。5. 內(nèi)存資源短缺，需增大內(nèi)存。6. 其他方面，需要升級軟件系統(tǒng)、合理進行子網(wǎng)劃分、加強管理等。網(wǎng)絡(luò)性能分析要結(jié)合結(jié)合服務(wù)器和測試目標(biāo)軟件，通常網(wǎng)絡(luò)傳輸慢會有軟件和服務(wù)器方面的原因，甚至有時候會有客戶端方面的原因。不過目前網(wǎng)絡(luò)的環(huán)境普遍可以，不管是局域網(wǎng)還是廣域網(wǎng)，網(wǎng)絡(luò)的環(huán)境越來越好。3用例管理測試用例的管理我們可以借鑒開發(fā)過程中對程序的管理方法，我們可以把測試用例看成程序測試工程師編寫的程序，這個程序也要經(jīng)過“設(shè)計”、“開發(fā)”、“測試”、“版本管理”、“發(fā)布”、“維護”等一系列操作，然后按照管理軟件程序的方法來管理測試用例。用例管理主要包含評審、

12、修改、執(zhí)行用例、用例版本維護、用例升級方面的內(nèi)容。3.1 用例評審測試用例評審是測試用例不可缺少的一個環(huán)節(jié)，這是對“測試部門開發(fā)出的產(chǎn)品”進行的“測試”?；舅悸肥菍y試準(zhǔn)備階段的成果進行分期評審，依次評審系統(tǒng)/驗收測試用例、集成測試用例、單元測試用例。評審用例在比較正規(guī)的公司更容易實施，要求相應(yīng)的軟件開發(fā)團隊必須在實際工作中對測試給予足夠的重視，才可以把這項工作做好，否則只是走走形式。有效的用例評審?fù)ǔＳ上旅鎯煞N形式組成：測試部門外部評審主要是由開發(fā)部、項目實施部、甚至銷售人員參加的評審，目的主要是查找測試工程師編寫的用例是否缺少內(nèi)容。建議采用非正式評審的形式進行，因為我們很難把開發(fā)人員組織

13、在一起，一般來說他們的開發(fā)進度壓力很大，能夠抽出時間看文檔已經(jīng)是“很給面子了”。當(dāng)然不統(tǒng)一進行評審會耽誤工程的進度，所以在實際工作中如果時間緊迫，可以提前啟動測試實施工作，待評審?fù)瓿珊筮M行用例的修改工作。通常測試工作進行一段時間評審就會結(jié)束，這個時候測試執(zhí)行人員可以在工作中對測試用例的內(nèi)容進行動態(tài)的調(diào)整，再次執(zhí)行被修改過的部分用例（如果能夠采用正式評審，效果肯定會更好。）。外部評審主要工作方式是用文檔直接記錄評審結(jié)果，測試人員根據(jù)評審結(jié)果對用例進行升級修改。測試部門內(nèi)部評審部門內(nèi)部同行對測試策略的評審，評審的核心內(nèi)容是測試策略和用例編制思路是否正確，以此來保證測試用例的有效性。可以組織正式的評

14、審，由用例的設(shè)計人員進行講解，然后大家共同評審；也可以把文檔發(fā)給部門的同事進行評審。內(nèi)部評審有些象開發(fā)人員在單元測試中的交叉測試。內(nèi)部評審的主要工作方式是項目會議，大家可以進行激烈的討論，共同探討用例編寫、交流經(jīng)驗，這樣用例的編寫水平才能提高，同時可以進行一些創(chuàng)新。評審方式中的外部評審最為重要。因為開發(fā)人員很容易發(fā)現(xiàn)用例中遺漏了什么內(nèi)容，同時還可以發(fā)現(xiàn)錯誤的用例因為存在對需求理解的偏差。用例外部評審可以理解為開發(fā)人員在查找測試人員編寫的“程序”缺陷。通常情況下先執(zhí)行內(nèi)部評審，然后執(zhí)行外部評審。很多時候，內(nèi)部評審會被忽略，建議要進行內(nèi)部評審。這樣至少有兩個好處：集思廣益和提高測試小組輸出文檔的質(zhì)

15、量。3.2 管理方案國內(nèi)大多數(shù)IT公司在測試用例的發(fā)展經(jīng)歷了以下幾個階段：無用例而執(zhí)行測試：測試的初級階段，完全手工測試，測試執(zhí)行工程中沒有測試用例作為執(zhí)行依據(jù)，可能會按照需求進行測試； 有用例而不使用用例執(zhí)行測試：已經(jīng)編寫測試用例，但是受各種環(huán)境的影響，例如需求變動頻繁、編寫的用例過于簡單等，測試用例編寫后在實際工作中不能使用； 按照部分用例執(zhí)行測試：隨著用例編寫水平的提高，部分測試用例可以在測試中發(fā)揮作用； 完全按照用例執(zhí)行測試：組織建立了規(guī)范的項目管理過程，對測試用例進行規(guī)范的管理，執(zhí)行測試用例以用例為準(zhǔn)則來執(zhí)行測試。 完全按照測試用例執(zhí)行測試是一個公司測試水平的體現(xiàn)，測試用例管理成為這

16、一階段的主要內(nèi)容。測試用例管理的核心內(nèi)容是版本管理。如果測試用例是采用文字編輯軟件例如word編寫，建議采用工具（例如Visual SourceSafe）對用例進行控制。可以參照圖2進行。編寫用例用例評審進入版本控制庫用例修改使用用例&維護&升級圖2 測試用例管理示意圖1、 編寫用例：測試工程師根據(jù)需求分析、概要設(shè)計、詳細(xì)設(shè)計等文檔編寫測試用例。2、 用例評審：3.1小結(jié)說明了用例的評審。原則上用例像程序一樣，要經(jīng)過多次的修改才可以通過，而實際工作中只進行一到兩次。3、 用例修改：評審結(jié)束后，需要根據(jù)評審意見進行修改，修改后通常不再進行評審。建議在時間和人力資源比較充裕的情況下

17、，對用例的評審要像測試開發(fā)部門的產(chǎn)品一樣，經(jīng)過反復(fù)的評審和修改，然后正式投入使用，因為每次評審可能都有新的發(fā)現(xiàn)。4、 使用用例：在執(zhí)行任務(wù)時，從版本控制庫取出用例，執(zhí)行時建議直接在用例上記錄測試結(jié)果。這樣做會帶來兩個好處：首先是下次測試時可以看見上次測試的結(jié)果記錄，可以起一個提醒的作用；其次可以一次性的把發(fā)現(xiàn)的缺陷輸入到缺陷跟蹤數(shù)據(jù)庫中，在輸入時可以進行綜合統(tǒng)計，避免輸入重復(fù)的缺陷。每次使用后送入版本控制庫中，進行版本的管理。5、 用例升級/維護：隨著軟件產(chǎn)品的不斷修改、升級，對應(yīng)的用例也需要升級和維護。針對同一個項目，可以根據(jù)需求的變更不斷進行維護；如果是產(chǎn)品，用例的維護則更加重要，要達到用例和產(chǎn)品的版本一一對應(yīng)。測試用例的管理還可以采用專門的測試軟件例如TestDirector等來進行管理，測試工具通常會具備上面的功能。如果有條件，建議采用集成華的測試工具，這樣更容易對測試執(zhí)行全程進行監(jiān)控，可以把測試需求、測試用例、缺陷管理統(tǒng)一起來，大大提高測試效率。在測試用例管理規(guī)范化并成為測試的執(zhí)行準(zhǔn)則后，管理測試用例帶來的巨大好處開始逐漸顯現(xiàn)出來，測試用例成為評估測試和改進測試工作的主要依據(jù)，可以給工具帶來巨大的方便。例如可以通過測試用例的執(zhí)行情況來統(tǒng)計分析執(zhí)行結(jié)果，編寫測試報