接口測試方法

1、接口功能測試策略 分類： java 學(xué)習(xí) 2012-04-18 15:30 1105人閱讀 評論(0) 收藏 舉報 測試服務(wù)器數(shù)據(jù)庫游戲平臺網(wǎng)絡(luò)協(xié)議由于平臺服務(wù)器是通過接口來與客戶端交互數(shù)據(jù)提供各種服務(wù)，因此服務(wù)器測試工作首先需要 進(jìn)行的是接口測試工作。測試人員需要通過服務(wù)器接口功能測試來確保接口功能實現(xiàn)正確，那么其他測試人員進(jìn)行客戶端與服務(wù)器結(jié)合的系統(tǒng)測試過程中，就能夠排 除由于服務(wù)器接口缺陷所導(dǎo)致的客戶端問題，便于開發(fā)人員定位問題。以下便是個人的平臺服務(wù)器接口功能測試經(jīng)驗總結(jié):一、接口測試范圍    根據(jù)服務(wù)器的測試需求，接口測試范圍主要分為：1、新

2、增接口的測試；2、新增業(yè) 務(wù)功能接口測試；3、整個服務(wù)器的接口測試。所需測試測試接口依次增多，在測試時間足夠的條件下，當(dāng)然需要對所有接口進(jìn)行測試用例的設(shè)計，但如果測試較短 的情況下，則應(yīng)該首先根據(jù)用戶的典型操作對測試接口進(jìn)行優(yōu)先級劃分，對調(diào)用頻繁接口需要優(yōu)先進(jìn)行測試。二、接口測試策略       在進(jìn)行平臺服務(wù)器接口測試之前，首先需要整理服務(wù)器接口的測試方案，分析接口測試的要點，平臺服務(wù)器的接口測試內(nèi)容主要有：接口設(shè)計檢查接口用于服務(wù)器與客戶端的數(shù)據(jù)交互，客戶端通過網(wǎng)絡(luò)協(xié)議傳遞的數(shù)據(jù)為服務(wù)器接口的輸入數(shù)據(jù)，因此應(yīng)該首先通過服

3、務(wù)器接口文檔及客戶端數(shù)據(jù)約束文檔進(jìn)行交互數(shù)據(jù)的有效性檢查：n  整數(shù)型數(shù)據(jù)位數(shù)n  浮點型數(shù)據(jù)精度n  字符串?dāng)?shù)據(jù)范圍值要求客戶端的整數(shù)型、浮點型、字符串?dāng)?shù)據(jù)以及其最大值和最小值都能作為服務(wù)器接口的有效輸入。這些工作在服務(wù)器設(shè)計評審時就可以進(jìn)行，以便確保不會出現(xiàn)客戶端上傳數(shù)據(jù)被服務(wù)器自動進(jìn)行截斷或四舍五入的操作。接口依賴關(guān)系檢查    以上策略只談到單個接口的測試方法，對于用戶來說，一個操作可能會造成服務(wù)器調(diào)用多個接口來進(jìn)行完成，因此還需要從業(yè)務(wù)處理的角度，對各種業(yè)務(wù)操作所涉及的多個接口之間依賴

4、調(diào)用進(jìn)行測試。    接口依賴關(guān)系檢查主要是通過接口的輸出值為另一接口的輸入值來實現(xiàn)的，因此在進(jìn)行接口測試之前，需要分析所測試接口的輸入值是通過客戶端還是其他接口輸出來獲取的，在設(shè)計測試用例時，加入接口的依賴關(guān)系說明以便于測試。接口輸入/輸出驗證服務(wù)器接口功能測試類似于單元測試，在設(shè)計測試用例時，側(cè)重點在于接口模塊輸入/輸出項的正確性驗證，根據(jù)接服務(wù)器接口處理方式，對各種接口進(jìn)行分類：第一類：條件判斷接口       這類接口在接收到請求數(shù)據(jù)后，會根據(jù)輸入?yún)?shù)進(jìn)行條件判斷，然后返回相應(yīng)

5、結(jié)果碼，通常涉及條件判斷的接口有：用戶鑒權(quán)接口、升級狀態(tài)上報、密碼修改/重置等接口。因此輸入/輸出項驗證的側(cè)重點主要集中在：1）判斷條件的驗證要對判斷條件進(jìn)行驗證，則需要知道接口是根據(jù)哪些輸入項來進(jìn)行判斷的，以密碼重置接口為例：密碼重置接口接口功能：用戶登錄之后發(fā)起找回密碼操作，用戶輸入郵箱信息后，游戲中心將向平臺服務(wù)器發(fā)送請求，平臺服務(wù)器將隨機(jī)為用戶生成新的密碼，發(fā)到用戶的郵箱中。接口方向：游戲中心>平臺服務(wù)器遵循協(xié)議：HTTPS，請求消息使用Post方式參數(shù)名稱參數(shù)類型參數(shù)長度說明userIDInt10用戶ID號emailString60郵箱地址keyString50接口名稱vers

6、ionString8版本號響應(yīng)消息（sendMessageRes）參數(shù)名稱參數(shù)類型參數(shù)長度說明resultCodeInt5結(jié)果返回碼，返回42000表示處理成功此接口根據(jù)輸入的userID、email參數(shù)來進(jìn)行數(shù)據(jù)正確性的判斷（key是接口名 稱，如果錯誤服務(wù)器將不會處理，version是版本號，其值只是用于記錄，不參與判斷），設(shè)計接口測試用例時，應(yīng)該首先對接口的判斷參數(shù)進(jìn)行驗證，這些 輸入項不能為空，然后利用等價類劃分、邊界值方法來根據(jù)userID、email輸入項設(shè)計各種合法的數(shù)據(jù)，驗證接口是否可以正常處理。2）異常數(shù)據(jù)的響應(yīng)只考慮正常情況，而不考慮異常場景是無法保證接口功能運(yùn)行正常，對于

7、密碼重置接口，用戶 ID不存在、不合法，郵箱輸入格式錯誤、用戶郵箱信息不存在或未激活就是測試時需要考慮的異常場景，設(shè)計這類輸入值，并且檢查接口返回的響應(yīng)碼，響應(yīng)碼的 正確才能保證客戶端根據(jù)異常情況來顯示相應(yīng)的提示信息。簡而言之，條件判斷的接口其測試策略就是根據(jù)判斷條件來設(shè)計各種輸入值來檢驗接口的功能。第二類：數(shù)據(jù)查詢接口       這類接口接收到請求數(shù)據(jù)后，首先會驗證請求是否合法，然后會根據(jù)請求項查詢數(shù)據(jù)庫相應(yīng)表中數(shù)據(jù)返回給客戶端，通常涉及數(shù)據(jù)查詢的接口有：用戶基本資料/經(jīng)驗值/賽事信息查詢、游戲列表獲取、在線人數(shù)查詢等接

8、口。以用戶經(jīng)驗值查詢接口為例：用戶經(jīng)驗值查詢接口接口功能：用戶登錄游戲中心后，可以查詢自己每個游戲項目的經(jīng)驗值信息，包括此項目的經(jīng)驗值等級、等級稱號、今日經(jīng)驗值上限等。接口方向：游戲中心>平臺服務(wù)器遵循協(xié)議：HTTP+XML，請求消息使用Post方式參數(shù)名稱參數(shù)類型參數(shù)長度說明userIDInt10用戶ID號webkeyString60當(dāng)前分配給指定登錄用戶的密鑰keyString50接口名稱versionString8版本號isAllInt1是否查詢用戶所有的運(yùn)動項目經(jīng)驗值 0：是；1否sportItemIDString50運(yùn)動項目ID，當(dāng)isAll=1時不能為空，指定查詢某

9、個運(yùn)動項目的經(jīng)驗響應(yīng)消息（sendMessageRes）參數(shù)名稱參數(shù)類型參數(shù)長度說明sportItemIDString50運(yùn)動項目IDsumExpInt11運(yùn)動經(jīng)驗值總額expLevelInt3經(jīng)驗值等級minExpInt11本級最小經(jīng)驗值expOrderInt11經(jīng)驗值排名maxExpInt11本級最大經(jīng)驗值todayExpInt11今日獲得經(jīng)驗值todayExpLimitInt11今日經(jīng)驗值上限designationString30稱號（對應(yīng)于經(jīng)驗值）winCountInt11勝利場次lossCountInt11失敗場次isMaxExpInt1總經(jīng)驗值是否達(dá)到最大 0 

10、否；1 是此接口首先會根據(jù)webkey來判斷請求是否合法，然后根據(jù)請求參數(shù)中的userID、 isAll、sportItemID來查詢數(shù)據(jù)表中相應(yīng)數(shù)據(jù)。除了象條件判斷接口一樣根據(jù)判斷項webkey、請求參數(shù)userID、isAll、 sportItemID設(shè)計合法/不合法和正常/異常測試值之外，還需要結(jié)合數(shù)據(jù)庫來對查詢結(jié)果進(jìn)行驗證:1）是否根據(jù)正確的關(guān)聯(lián)數(shù)據(jù)表進(jìn)行查詢；2）驗證查詢結(jié)果是否從數(shù)據(jù)表中正確項中獲取，涉及到多表聯(lián)合查詢時，不同表中的相同項設(shè)計不同測試數(shù)據(jù)進(jìn)行驗證；3）修改查詢結(jié)果在數(shù)據(jù)表中對應(yīng)項中的數(shù)據(jù)，使其為空值或客戶端相應(yīng)項的范圍值的最大和最小值，查看接口輸出是否正確

11、。第三類：邏輯運(yùn)算接口       這類接口在收到請求數(shù)據(jù)之后，會進(jìn)行一系列邏輯運(yùn)算，然后根據(jù)處理結(jié)果更新數(shù)據(jù)庫中的數(shù)據(jù)，通常涉及邏輯運(yùn)算的接口有：比賽成績同步、商品支付、各種數(shù)據(jù)報表等接口。以比賽成績同步接口為例：比賽成績同步接口接口功能：游戲服務(wù)器將用戶每次的比賽成績傳給平臺服務(wù)器，平臺服務(wù)器根據(jù)用戶的比賽成績更新此用戶的賽事排名，然后存入數(shù)據(jù)庫。接口方向：游戲服務(wù)器>平臺服務(wù)器遵循協(xié)議：HTTPS+XML，請求消息使用Post方式參數(shù)名稱參數(shù)類型參數(shù)長度說明userIDInt10用戶i-dong號webKeySt

12、ring64當(dāng)前分配給指定登錄用戶的密鑰keyString50接口名稱versionString8版本號gymkanaCodeString30當(dāng)前比賽所參與的運(yùn)動會,該參數(shù)為空說明只是普通用戶的比賽sportItemIDString50游戲項目的IDsportItemNameString50游戲項目名稱sportServerIDString50游戲服務(wù)器IPmatchSystemInt3競速跑賽制：100米:1; 400米:2; 800米:4; 1500米:8; 4×100米:16;matchIdString50該場次比賽唯一idrecorddouble

13、 當(dāng)前用戶成績 （如record=8.123456）。非正常結(jié)束比賽時，即isWinner3或4，如果是單人跑，isWinner=5，record=-1unitString20成績單位isWinnerInt2當(dāng)前用戶是否贏了0=輸,1=贏，2未完成，3主動退出，4被迫退出competitorIDInt10對手idong號competitorRecorddouble 當(dāng)前對手成績，規(guī)則同recordcompetitorIsWinnerint2對手輸贏，規(guī)則同isWinnerstarttimeString14開始時間(yyyy-MM-dd HH:mm:ss)endti

14、meString14結(jié)束時間(yyyy-MM-dd HH:mm:ss)響應(yīng)消息（sendMessageRes）參數(shù)名稱參數(shù)類型參數(shù)長度說明resultCodeInt5結(jié)果返回碼，返回42000表示處理成功scoreInt11本次得分preRankInt11賽前積分在賽后的排名rankInt11積分排名upRankFlagInt1排名上升：1；排名不變：0；排名下降：-1isUpLevelInt1經(jīng)驗值是否升級 0 否；1 是expInt11本次增加的經(jīng)驗值expLevelInt3經(jīng)驗值等級designationString30稱號（對應(yīng)于經(jīng)驗值）cPreRankI

15、nt11對手賽前積分在賽后的排名cRankInt11對手賽后積分排名cUpRankFlagInt1對手排名上升：1；排名不變：0；排名下降：-1encourageWordString15鼓勵語句    此接口比數(shù)據(jù)查詢接口又更加復(fù)雜，除了用條件判斷和數(shù)據(jù)查詢類接口的策略對此接口進(jìn)行測試用例設(shè)計之外，還需要驗證對接口的算法規(guī)則進(jìn)行檢查，因為此接 口涉及根據(jù)用戶比賽成績(record)進(jìn)行排名然后返回其得分及排名情況(score、rank、upRankFlag、exp)，通過對相關(guān)數(shù)據(jù)表中 的數(shù)據(jù)進(jìn)行查看方式，接口算法規(guī)則驗證包括：1）用戶勝利、失敗、中途主動/被動退

16、出、規(guī)定時間內(nèi)未完成比賽情況下，此場比賽得分(scroe)是否正確；2）用戶比賽成績比上次成績花費(fèi)時間短、長、持平情況下，排名情況(upRankFlag)是否正確；3）用戶比賽成績處于第一名、最后一名、比上次成績花費(fèi)時間短/長/持平情況下，用戶積分排名（rank）是否正確；4）用戶勝利、失敗、中途主動/被動退出、規(guī)定時間內(nèi)未完成比賽，并且用戶經(jīng)驗值在各種經(jīng)驗等級范圍下，經(jīng)驗值根據(jù)得分進(jìn)行計算的公式是否正確。    邏輯運(yùn)算接口由于還涉及插入或更新數(shù)據(jù)庫操作，因此測試時還需要考慮數(shù)據(jù)庫特性，如數(shù)據(jù)精度問題，在MySQL數(shù)據(jù)庫中，如果是浮點型數(shù)據(jù)，存入時會有精度誤差（

17、131072.32插入float(10,2)類型的數(shù)據(jù)會變?yōu)?31072.31），因此對于需要用于金額計算、數(shù)據(jù)統(tǒng)計、成績比較的數(shù)據(jù)，最好使用定點型。    最后服務(wù)器接口的測試如果有足夠條件的話，還需要通過白盒測試來對接口代碼做進(jìn)一步的測試，通過編寫關(guān)鍵代碼的測試樁，可以有效查找將字符數(shù)組當(dāng)成字符 串使用造成的讀越界這類不易通過黑盒測試發(fā)現(xiàn)的BUG。接下來的工作就是如何通過測試工具來執(zhí)行服務(wù)器接口功能測試。編寫接口測試的測試用例體會 分類： 測試用例 2011-08-23 19:22 2680人閱讀 評論(0) 收藏 舉報 測試數(shù)據(jù)庫testing產(chǎn)品語言工作&

18、#160;  來淘寶目前已經(jīng)3周了，這三周只重復(fù)地做了一個事情，編寫測試用例，修改測試用例。不斷地修改讓我對自己的語言組織能力和邏輯思維能力產(chǎn)生了懷疑，同時，越來越覺得測試用例的寫法撲朔迷離。我問了3個人，結(jié)果每個人都告訴我不同的寫法。把我自己弄的不知所措。但是問的多了，慢慢也就明白了，每個人都有每個人的編寫風(fēng)格，作為測試新人，我們要了解如何去編寫測試用例，而不是copy別人的測試用例。只有真正了解了如何去編寫，才能寫出有自己風(fēng)格的測試用例。       測試用例基本上都包括以下五部分：  1.前置條件  2.輸入

19、參數(shù)  3.執(zhí)行步驟  4.校驗點  5.期望值這這是書寫用例的一種形式而已。有些測試用例中，輸入?yún)?shù)也可以省略掉。重要的是設(shè)計測試用例、剛接手工作還沒有編寫日常用例就跟進(jìn)了一個項目，我負(fù)責(zé)的是實體管理和屬性管理的增刪改查，這樣涉及到了頁面。我也最先接觸到了功能測試和接口測試。其實知道現(xiàn)在我還是沒有完全區(qū)分開這兩個測試。我覺得在書寫測試用例的時候兩者是相似的。只是功能測試一般是在頁面上，接口測試則接觸底層代碼。當(dāng)然，在接口中我也按功能點書寫了功能性的測試。書寫接口測試測試用例的考慮點：1，充分滴熟悉PRD（產(chǎn)品需求設(shè)計）    了解P

20、RD，熟悉業(yè)務(wù)規(guī)則，根據(jù)業(yè)務(wù)規(guī)則來確定測試點。為了輔助理解產(chǎn)品的架構(gòu)，可以畫mm圖，將需求分類。在編寫用例的過程中進(jìn)行等價類的劃分，最后用判定表進(jìn)行評判，補(bǔ)充缺少的用例，剔除冗余的用例。做到對需求的100%覆蓋。要明白哪些是核心功能！2 .以下轉(zhuǎn)載自      （測試用例的有效性）測試用例應(yīng)該包含清晰的輸入數(shù)據(jù)以及預(yù)期輸出，沒有測試數(shù)據(jù)的用例更多的是具有指導(dǎo)意義，執(zhí)行過程中更多的是靠個人根據(jù)指導(dǎo)的自由發(fā)揮。但是看看我們的基線庫更多的是這樣指導(dǎo)意義的用例。（但是輸入數(shù)據(jù)又涉及到了維護(hù)的問題，以及環(huán)境或者業(yè)務(wù)發(fā)生變更后引起的有效性問題）。對于預(yù)期的

21、結(jié)果不能僅僅是頁面上或者界面上的可見結(jié)果，如果和數(shù)據(jù)庫發(fā)生了交互，必須包含數(shù)據(jù)庫里準(zhǔn)確的驗證結(jié)果。用例基于數(shù)據(jù)驅(qū)動。      （測試用例的可理解性）測試用例步驟必須描述清晰，不能出現(xiàn)模棱兩可以及重復(fù)的話語，測試用例應(yīng)該按照增刪改的順序進(jìn)行安排，這樣執(zhí)行的時候效率比較高，避免不必要的重復(fù)測試，用例寫完不是就ok了，我們最好通讀2遍，進(jìn)行修改，讓單條用例流暢。      （測試用例的清晰性）測試用例的驗證點必須明確清晰重點突出，按照最新的用例標(biāo)準(zhǔn)，一個用例進(jìn)行一個功能點的驗證，一個蘿卜一個坑。對于

22、流程性的用例也是建議按照流程順序進(jìn)行用例安排，從第一個驗證點到最后一個驗證點，組成流程的開始到結(jié)束，方便測試執(zhí)行。測試用例包含前置條件的必須將前置條件描述清楚，包括入口等。     （測試用例的可維護(hù)性）我們的用例主要是基于web的，用例存在一定的變數(shù)。因此在測試用例因為業(yè)務(wù)需求發(fā)生變更的時候，請及時修改，維護(hù)測試用例，做到測試用例的實時性與有效性，同時也方便后來的新人同學(xué)及時學(xué)習(xí)，不會產(chǎn)生誤解與費(fèi)解【這里還應(yīng)該有一個（測試用例的可重現(xiàn)性），這個在準(zhǔn)備數(shù)據(jù)的時候要注意】 Ross Collard在”Use Case Testing”一文中說：“測試用例的

23、前10%到15%可以發(fā)現(xiàn)75%到90%的重要缺陷”。如果你在項目或者日常結(jié)束后，仔細(xì)的分析過我們的bug列表，那么你會覺的這句話非常適用。合理提高我們的測試效率就是在編寫測試用例時進(jìn)行測試用例優(yōu)先級的劃分。如何設(shè)計接口測試用例 接口測試是項目測試的一部分，正如其名，它測試的主要對象是接口，是測試系統(tǒng)組件 接口測試 間接口的一種測試。 接口測試主要用于檢測外部系統(tǒng)與所測系統(tǒng)之間以及內(nèi)部各系統(tǒng)之間的 交互點。 測試的重點是檢查數(shù)據(jù)交互、 傳遞、 和控制管理過程以及系統(tǒng)間的相互依賴關(guān)系等。 如何設(shè)計接口測試用例 測試用例？ 測試用例 首先，明確出發(fā)點。和所有的測試一樣，接口測試出發(fā)點是你要證明所測的

24、程序是錯誤 的。以這個出發(fā)點為導(dǎo)向，你的設(shè)計行為就會盡量朝這個方向發(fā)展，更易發(fā)現(xiàn)問題，不會出 現(xiàn)大方向的偏差。 其次，選擇好測試對象。對于一個系統(tǒng)做接口測試選擇好的測試對象是接口測試關(guān)鍵。 一個系統(tǒng)有無數(shù)的接口， 每個接口如果分別測試， 那將是很痛苦的一件事情， 不光繁瑣浪費(fèi)， 而且任何一個內(nèi)部接口的變動， 都將導(dǎo)致我們用例的不可用。 這里推薦把整個系統(tǒng)作為一個 整體，選擇整個系統(tǒng)提供給外部使用、交互的最外層接口作為你的測試對象，以此為測試對 象的用例將有很好的健壯性，并且更高效。另外，根據(jù)數(shù)據(jù)的流向，又可將這些最外層的接 口分為兩類：一類是數(shù)據(jù)進(jìn)入系統(tǒng)的接口；一類是數(shù)據(jù)流出系統(tǒng)的接口。進(jìn)入系

25、統(tǒng)的接口實 際是我們用例的執(zhí)行調(diào)用的接口?？赏ㄟ^變化參數(shù)對這些接口進(jìn)行調(diào)用，模擬外部的使用； 而流出的接口則是我們用例真正該驗證的點。數(shù)據(jù)從哪里流出，流出時的狀態(tài)如何，此時系 統(tǒng)又是什么狀態(tài)都是我們所應(yīng)該驗證的。 然后， 確認(rèn)完整的測試對象的功能： 確認(rèn)外部接口提供給使用這些接口的外部用戶什么 樣的功能，外部用戶真正需要什么樣的功能。此兩個功能一定要準(zhǔn)確詳細(xì)，用例的設(shè)計要嚴(yán) 格按照測試對象功能設(shè)計才是正確的用例。 最后當(dāng)出發(fā)點、對象、功能都確定了，就可以真正設(shè)計用例了。下面詳細(xì)介紹下如何去 設(shè)計一個結(jié)構(gòu)好、可讀性高、滲透性強(qiáng)的接口測試用例。 接口測試用例設(shè) 計和其他 其他測試用例設(shè)計一樣， 都

26、應(yīng)該本著盡可能的發(fā)現(xiàn) bug 的目標(biāo)。用 其他 例設(shè)計的內(nèi)容應(yīng)該包括：主要測試功能點、測試環(huán)境、測試數(shù)據(jù) 測試數(shù)據(jù)、執(zhí)行操作以及預(yù)期結(jié)果。 測試數(shù)據(jù) 1）接口測試環(huán)境分為兩種:一種是程序內(nèi)部的環(huán)境；一種是程序的所調(diào)用外部接口的環(huán) 境。用例在設(shè)計環(huán)境上有一個原則即：設(shè)計真實而危險的環(huán)境，不忽視偶發(fā)環(huán)境。真實，即 你的用例在測試某種功能時，應(yīng)該去思考這種情況發(fā)生時內(nèi)部、外部環(huán)境是什么，通過各種 手段將最準(zhǔn)確的環(huán)境模擬出來。危險，即在這種環(huán)境下系統(tǒng)出問題的概率會很大。在設(shè)計用 例環(huán)境時，如果兩種環(huán)境都能達(dá)到你本用例的要求，更推薦選擇更危險的環(huán)境。所謂偶發(fā)， 即這種環(huán)境出現(xiàn)的概率很小。 不要因為這種環(huán)

27、境很少出現(xiàn)就無視它， 開發(fā)很可能也是這種想 法，此處很有可能隱藏著問題。 2） 接口測試測試數(shù)據(jù)分為接口參數(shù)數(shù)據(jù)和用例執(zhí)行所需系統(tǒng)數(shù)據(jù)。 數(shù)據(jù)的設(shè)計學(xué)問大， 不要在設(shè)計、 準(zhǔn)備測試用例的數(shù)據(jù)上偷懶。 要通過好的測試數(shù)據(jù)使用例查錯的功能充分發(fā)揮。 接口參數(shù)數(shù)據(jù)需對每個參數(shù)根據(jù)測試接口的實際的功能進(jìn)行分析， 在符合業(yè)務(wù)邏輯的情況下 進(jìn)行邏輯組合排列， 不要遺漏了某些邊界值和錯誤點的數(shù)據(jù)。 每個用例執(zhí)行所需系統(tǒng)數(shù)據(jù)和 接口參數(shù)數(shù)據(jù)盡可能的采用不一樣的數(shù)據(jù)，使用例更容易發(fā)現(xiàn)問題。 3）測試功能點，如果一個接口功能復(fù)雜時推薦對接口用例進(jìn)行結(jié)構(gòu)劃分，這樣子用例 具有更好的可讀性和維護(hù)性。 接口劃分原則為以

28、接口提供的功能點的不同進(jìn)行合適粒度的劃 分。同一功能點的用例又可根據(jù)測試環(huán)境的不同、數(shù)據(jù)的不同進(jìn)行用例的填充。 4）接口測試用例執(zhí) 行操作非常簡單，就是所測接口的調(diào)用。 5）預(yù)期結(jié)果驗證，這也是接口用例設(shè)計的很關(guān)鍵的一步，應(yīng)該細(xì)而不冗余。所謂細(xì)， 用例中應(yīng)詳細(xì)列出應(yīng)該驗證的點。 每個用例均需驗證， 不要因為前幾個用例有驗證就認(rèn)為全 部是正確的。避免一個用例中重復(fù)做相同的驗證，提高測試用例的效率。關(guān)于接口測試的總結(jié) 1. 接口測試： 是測試系統(tǒng)組件間接口的一種測試。 主要用于檢測外部系統(tǒng)于系統(tǒng)乊間以及系統(tǒng)內(nèi)部各個子系統(tǒng)乊間的交互點。 重點測試的時數(shù)據(jù)的交換，傳遞和控制管理過程，以及系統(tǒng)間的相互邏

29、輯依賴關(guān)系等等，這要求對業(yè)務(wù)邏輯有一定程度上 的理解，對數(shù)據(jù)流向有較好的定位。 2. 接口測試的分類： a) b) c) 系統(tǒng)不系統(tǒng)乊間的調(diào)用（如分享時，微信會提供接口給“跑向珠峰”； ） 上層服務(wù)對下層服務(wù)的調(diào)用 服務(wù)乊間的調(diào)用（如添加一條數(shù)據(jù)時，會先調(diào)用數(shù)據(jù)查詢的服務(wù)，查詢改數(shù)據(jù)是否是重復(fù)數(shù)據(jù)） ； 丌同類型的接口測試方法可能丌一致，但總體來說，丌管是哪種類型，被測接口即為服務(wù)方，測試手段為客戶方，接口測 試的目的就是：通過我們的測試手段，去驗證滿足其聲明提供的功能。 3. 接口測試的原理：通過測試程序模擬客戶端向服務(wù)器發(fā)送請求報文，服務(wù)器接收請求報文后對相應(yīng)的報文做出處理然后再 把應(yīng)答報

30、文發(fā)送給客戶端，客戶端接收應(yīng)答報文這一過程（requestresponse） 4. 接口測試的流程：類似于功能測試，需求討論評審需求確定需求產(chǎn)出接口定義根據(jù)需求文檔及接口定義設(shè)計測試 用例（測試用例主要從業(yè)務(wù)場景，功能以及異常測試幾個方面考慮）評審用例執(zhí)行測試 5. 接口測試的價值：降低成本，提高效率。接口測試能夠提供系統(tǒng)復(fù)雜度上升情況下的低成本高效率的解決方案。它是一個 完整的體系，還包括功能測試，性能測試等。 6. 接口測試的適用范圍：一般用于多個系統(tǒng)間的交互開發(fā)，戒者擁有多個子系統(tǒng)的應(yīng)用系統(tǒng)開發(fā)的測試。接口測試適用于為 其他系統(tǒng)提供服務(wù)的底層框架系統(tǒng)和中心服務(wù)系統(tǒng)。主要測試這些對外部提供

31、的接口的正確性和穩(wěn)定性。它也同樣適用于 上層系統(tǒng)中服務(wù)層接口，測試難度隨層級而上升。即越往上難度越大。 7. 需求的頻繁變化，做接口測試的測試人員應(yīng)該如何應(yīng)對：個人覺得此在于團(tuán)隊開發(fā)的流程，團(tuán)隊乊間的溝通和測試人員的 警覺性。 、 在開發(fā)階段，需求的變更是一件極為頻繁和正常的事情，對于此點團(tuán)隊中的任何一人都應(yīng)該以正確的心態(tài)來面對。團(tuán) 隊需要規(guī)范的開發(fā)流程，良好的溝通方式，測試人員更需要及時跟迚軟件迚度，和開發(fā)人員并迚齊行。同時，測試不開發(fā) 需要相對獨(dú)立的工作環(huán)境，總結(jié)而言為乊知己知彼，亦敵亦友。 8. 關(guān)于如何簡單設(shè)計接口測試的設(shè)計用例 a) 明確出發(fā)點測試的目的是為了讓找出軟件的缺口， 修復(fù)

32、并使乊更加完善。 在這一基礎(chǔ)點上， 接口測試也丌例外。 以找出軟件的誤漏為出發(fā)點，測試用例需緊貼此線，更容易找出問題所在。 b) 明確測試點選擇好的測試對象。系統(tǒng)內(nèi)部層次繁復(fù)復(fù)雜，任何一個接口的變勱都將導(dǎo)致用例失效。 （可將這些 最外層的接口根據(jù)數(shù)據(jù)的流向分為迚入和流出兩類，迚入系統(tǒng)的接口實際上是我們用例的執(zhí)行調(diào)用的接口。可通過 參數(shù)對這些接口迚行調(diào)用，模擬外部的使用；而流出的接口則是我們用例真正該驗證的點。數(shù)據(jù)從哪里流出，流出 的狀態(tài)如何，此時系統(tǒng)的狀態(tài)都是作為測試目的所要著重關(guān)注的部分） c) 確認(rèn)完整的測試對象的功能確認(rèn)外部接口提供給使用這些接口的外部用戶什么樣的功能， 外部用戶真正需要

33、的 時什么樣的功能予以區(qū)別。用例的設(shè)計要嚴(yán)格按照測試對象功能設(shè)計才是正確的用例。 9. 設(shè)計（接口）測試用例有哪些要求：結(jié)構(gòu)好，可讀性高，滲透性強(qiáng)。 10. （接口）測試用例包括的內(nèi)容：功能點，測試環(huán)境，測試數(shù)據(jù)，執(zhí)行操作以及預(yù)期結(jié)果。 如下： a) 接口測試測試的功能點： 如果一個接口功能過于復(fù)雜時， 可以對接口用例迚行結(jié)構(gòu)劃分 （如根據(jù)層次， 平臺， 功能點等等） ， 這樣用例具有更好的可讀性（接口劃分原則為：以接口提供的功能點的丌同迚行合適粒度的劃分，同一功能點的用例又可 根據(jù)測試環(huán)境的丌同，數(shù)據(jù)的丌同迚行用例的填充） b) c) 接口測試用例的 環(huán)境：程序內(nèi)部環(huán)境和程序所調(diào)用的外部接口

34、的環(huán)境。 關(guān)于接口測試測試數(shù)據(jù)：分為兩部分：接口參數(shù)數(shù)據(jù)和用例執(zhí)行所需系統(tǒng)數(shù)據(jù)。數(shù)據(jù)的設(shè)計、準(zhǔn)備測試用例的數(shù)據(jù)丌可馬 虎。通過好的測試數(shù)據(jù)查找問題，能極大的提高工作效率。接口參數(shù)數(shù)據(jù)需要對每個參數(shù)根據(jù)測試接口的實際功能迚行分 析，在符合業(yè)務(wù)邏輯的情況下迚行邏輯組合排列，丌要遺漏某些邊界值和錯誤點的數(shù)據(jù)，這樣用例更容易發(fā)現(xiàn)問題。 d) e) 執(zhí)行操作：即對所測接口的調(diào)用。 預(yù)期結(jié)果：根據(jù)需求迚行驗證，是衡量軟件是否達(dá)到預(yù)期的標(biāo)準(zhǔn)。應(yīng)該著重細(xì)致，每個用例均需驗證，應(yīng)該避免一個用例 重復(fù)做相同的驗證，提高測試用例的效率。 11. a) 具體測試用例的參考點： 輸入?yún)?shù)測試：針對輸入?yún)?shù)迚行的測試，也

35、可以說是假定接口參數(shù)的丌正確性迚行的測試，確保接口對任意類型的輸入 都做了相應(yīng)的處理：輸入?yún)?shù)合法（丌合法） ，輸入?yún)?shù)為空，為 null，輸入?yún)?shù)超長等等； b) 功能測試 “接口是否滿足了所提供的功能， 相當(dāng)于正常情況測試， 如果一個接口功能復(fù)雜時推薦對接口用例迚行結(jié)構(gòu)劃分， 這樣子用例覺有更好的可讀性和可維護(hù)性； c) 邏輯測試：邏輯測試嚴(yán)格講應(yīng)為單元測試，單元測試應(yīng)保持內(nèi)部邏輯的正確性，可單元測試和接口測試的界限并丌是那么 清楚，所以我們也可以從給出的設(shè)計文檔中考慮內(nèi)部邏輯錯誤的分乊情況和異常； d) 異常情況測試：接口實現(xiàn)是否對清楚情況都迚行了處理，接口輸入?yún)?shù)雖然合法，但是在接口實

36、現(xiàn)中，也會出現(xiàn)異常，因 為內(nèi)部的異常丌一定是輸入的數(shù)據(jù)造成的，而有可能是其他邏輯造成的，程序需要對任何異常都迚行處理。 題外 關(guān)于單元測試，接口測試和白盒測試 a) 單元測試：針對具體代碼邏輯迚行測試，主要測試被測代碼的一個很小，很明確的功能是否正確。即單元模塊的邏輯是否正確，對業(yè)務(wù)關(guān)注 丌大； b) 接口測試：針對程序內(nèi)部的戒者外部的接口迚行的測試一個接口方法可能包含多個單元模塊，并且，一個接口會有自己特定的業(yè)務(wù)定義：做 接口測試更多的從業(yè)務(wù)的角度去考慮如何測試； c) 白盒測試：單元測試和接口測試都屬于白盒測試的一個階段測試用例之性能測試用例 性能測試、壓力測試、負(fù)載測試、強(qiáng)度測

37、試、穩(wěn)定性測試、健壯性測試、功能測試、接口測試 ,這么多眼花繚亂的測試類型名稱，估計很少有人能準(zhǔn)確的區(qū)分并說出定義來，至于對應(yīng)的測試用例如何編寫和執(zhí)行，就更不用說了。如果問測試工程師測試用例如何編寫，就象是問程序員如何編寫代碼得到的答案一樣，每個人都會給出不同的編寫方法，但實用的測試用例卻象優(yōu)秀的程序一樣難以編寫。目前國內(nèi)，測試工程師卻時常要面對“已經(jīng)延期幾倍計劃時間的項目”，測試用例如何發(fā)揮更大的作用，是一個迫切需要解決的問題。事實上，完全可以把測試用例看成是測試工程師編寫的程序：這個“程序”是為了輔助測試工作的進(jìn)行而開發(fā)的，目的是為了發(fā)現(xiàn)軟件問題，同時“順便”證明軟件功能是否符合要求。本文

38、針對上面的問題，以設(shè)計性能測試用例為示范，講解在企業(yè)實際工作中，如何有效劃分測試種類和編寫對應(yīng)的測試用例，使測試工作更加合理、高效率的開展。1測試種類和階段1.1 測試種類對于測試種類的說法多種多樣，最多的能達(dá)到30多種測試類型。而實際工作中很多測試是互相包含的。按照企業(yè)中實際工作需要，通常主要進(jìn)行下面幾種類型的測試：功能測試、健壯性測試、接口測試、強(qiáng)度測試、壓力測試、性能測試、用戶界面測試、可靠性測試、安裝/反安裝測試、文檔測試。下面介紹幾種重要的測試種類及其測試的內(nèi)容：功能測試：功能測試主要針對產(chǎn)品需求說明書的測試，是驗證功能是否否合需求，包括原定功能的檢驗、是否有冗余功能、遺漏功能。這類

39、測試應(yīng)由測試員做，這并不意味著程序員在發(fā)布前不必檢查他們的代碼能否工作，他們也需要進(jìn)行基本功能的測試。接口測試：程序員對各個模塊進(jìn)行系統(tǒng)聯(lián)調(diào)的測試，包含程序內(nèi)接口和程序外接口測試。這個測試，在單元測試階段進(jìn)行了一部分工作，而大部分都是在集成測試階段完成的。由開發(fā)人員進(jìn)行。性能測試：在交替進(jìn)行負(fù)荷和強(qiáng)迫測試時常用的術(shù)語。性能測試關(guān)注的是系統(tǒng)的整體。它和通常所說的強(qiáng)度、壓力/負(fù)載測試測試有密切關(guān)系。所以壓力和強(qiáng)度測試應(yīng)該與性能測試一同進(jìn)行。用戶界面測試：對系統(tǒng)的界面進(jìn)行測試，測試用戶界面是否友好、是否方便易用、設(shè)計是否合理、位置是否正確等一系列界面問題安裝/反安裝測試：安裝測試主要檢驗軟件是否可以

40、正確安裝，安裝文件的各項設(shè)置是否有效，安裝后能否影響原系統(tǒng)；反安裝是逆過程，測試是否刪除干凈，是否給影響原系統(tǒng)等。文檔測試：主要測試開發(fā)過程中針對用戶的文檔，以需求、用戶手冊、安裝手冊等為主，檢驗文檔是否和實際應(yīng)用存在差別。文檔測試不需要編寫測試用例。測試種類的劃分不要拘泥于上面的形式，總體來說應(yīng)該服從于測試策略，可以根據(jù)具體工作的特點進(jìn)行安排，為了工作更容易開展，完全可以把一些測試合在一起進(jìn)行。在后面的性能測試用例的編寫上，充分體現(xiàn)了這一思想。1.2 測試階段和開發(fā)過程相對應(yīng)，測試過程會依次經(jīng)歷單元測試、集成測試、系統(tǒng)測試、驗收測試四個主要階段。對應(yīng)關(guān)系如圖1所示：需求開發(fā) 高層設(shè)

41、計詳細(xì)設(shè)計編程單元測試集成測試系統(tǒng)測試驗收測試 圖1 開發(fā)與測試的“V”型關(guān)系單元測試：單元測試是針對軟件設(shè)計的最小單位程序模塊甚至代碼段進(jìn)行正確性檢驗的測試工作，通常由開發(fā)人員進(jìn)行。集成測試：集成測試是將模塊按照設(shè)計要求組裝起來進(jìn)行測試，主要目的是發(fā)現(xiàn)與接口有關(guān)的問題。由于在產(chǎn)品提交到測試部門前，產(chǎn)品開發(fā)小組都要進(jìn)行聯(lián)合調(diào)試，因此在大部分企業(yè)中集成測試是由開發(fā)人員來完成的。系統(tǒng)測試：系統(tǒng)測試是在集成測試通過后進(jìn)行的，目的是充分運(yùn)行系統(tǒng)，驗證各子系統(tǒng)是否都能正常工作并完成設(shè)計的要求。它主要由測試部門進(jìn)行，是測試部門最大最重要的一個測試，對產(chǎn)品的質(zhì)量有重大的影響。驗收測試：驗收測試以需

42、求階段的需求規(guī)格說明書為驗收標(biāo)準(zhǔn)，測試時要求模擬實際用戶的運(yùn)行環(huán)境。對于實際項目可以和客戶共同進(jìn)行，對于產(chǎn)品來說就是最后一次的系統(tǒng)測試。測試內(nèi)容為對功能模塊的全面測試，尤其要進(jìn)行文檔測試。盡管測試階段的劃分十分明確，但是在具體的項目和產(chǎn)品的測試中，尤其在執(zhí)行測試時，會根據(jù)實際需要來開展。1.3 測試種類、階段和用例的關(guān)系為了便于在實際工作中提高效率，同時方便測試用例的編寫和執(zhí)行，可以把上面提到的各個測試類型與對應(yīng)的測試用例合并。合并后的測試用例主要有以下幾種：1  功能測試用例：包含功能測試、健壯性測試、可靠性測試2  性能測試用例：包含性能測試、壓力測試、強(qiáng)度測試3

43、60; 集成測試用例：包含接口測試、健壯性測試、可靠性測試4  安全測試用例：安全測試用例5  用戶界面測試用例：包含用戶界面測試用例、少量功能測試用例6  安裝/反安裝測試用例：安裝/反安裝測試用例綜合上面的分析，測試種類、測試階段以及執(zhí)行人員具體的關(guān)系如表1所示。測試階段 測試類型執(zhí)行者單元測試模塊功能測試，包含部分接口測試、路徑測試開發(fā)工程師集成測試接口測試、路徑測試，含部分功能測試開發(fā)工程師 （如果測試人員水平較高，可以由測試人員執(zhí)行）系統(tǒng)測試功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試測試工程師驗收測試

44、對于實際項目來說基本同上，并包含文檔測試；對于軟件產(chǎn)品，主要測試相關(guān)的技術(shù)文檔。測試工程師（根據(jù)實際需要，可能包含用戶）表1 測試的種類、階段和執(zhí)行人員的關(guān)系總之，測試的種類應(yīng)該盡量的少，這樣每次都可以執(zhí)行更多的測試內(nèi)容。例如在進(jìn)行功能測試的同時，完全可以進(jìn)行健壯性的測試。（當(dāng)然如果產(chǎn)品健壯性方面要求較高，就可以把健壯性測試作為獨(dú)立的測試。）2性能用例編寫方案性能測試在軟件測試中占有重要的地位，而性能測試又關(guān)聯(lián)很多內(nèi)容。例如壓力和強(qiáng)度測試就與性能測試密切相關(guān)：針對一個網(wǎng)站進(jìn)行測試，模擬10到50個用戶就是在進(jìn)行常規(guī)性能測試，用戶增加到1000乃至上萬就變成了壓力/負(fù)載測試，如果同時對系統(tǒng)進(jìn)行大

45、量的數(shù)據(jù)查詢操作，就包含了強(qiáng)度測試。為了便于性能測試工作的實施，這里的性能測試綜合了性能、強(qiáng)度、壓力、負(fù)載等多方面的測試內(nèi)容，主要包含的內(nèi)容有：預(yù)期性能指標(biāo)測試、用戶并發(fā)性能測試、疲勞強(qiáng)度測試、大數(shù)據(jù)量測試和速度測試、網(wǎng)絡(luò)、服務(wù)器等方面的內(nèi)容。性能測試不同的系統(tǒng)有不同的要求，編寫方法要根據(jù)實際要求進(jìn)行編寫，本文提出一個常見的參考方案，在實際工作中，可以根據(jù)需要加入其它例如內(nèi)存泄露等和性能相關(guān)的測試用例。下面介紹各個部分性能測試用例包含的內(nèi)容：2.1預(yù)期性能指標(biāo)測試用例通常系統(tǒng)在設(shè)計前都會提出一些性能指標(biāo)，這些指標(biāo)是性能測試要完成的首要工作之一。針對每個指標(biāo)都要編寫多個測試用例來驗證是否達(dá)到要求

46、，并根據(jù)測試結(jié)果來改進(jìn)系統(tǒng)的性能。這類通常以單用戶為主，如果遇到并發(fā)用戶的情況，可以歸到并發(fā)用戶測試用例中。這類用例通常都是可以通過手工來執(zhí)行的用例，例如示例中的上傳一份文件，期望的性能為2M/S，完全可以手動上傳文件，同時用秒表計時。這些內(nèi)容通常在需求說明書中可以顯而易見的查到。不過當(dāng)看到如支持并發(fā)用戶300人，就應(yīng)該放到后面進(jìn)行。測試結(jié)果也是直接記錄是否達(dá)到要求，如果系統(tǒng)沒有達(dá)到要求則進(jìn)行改善。2.2用戶并發(fā)性能測試用例用戶并發(fā)測試是性能測試的最主要部分，包含了負(fù)載測試和壓力測試的過程。主要是逐漸增加用戶數(shù)量來加重系統(tǒng)負(fù)擔(dān)，直到出現(xiàn)不能接收的性能點或者瓶頸。一般要測試正常數(shù)量的用戶并發(fā)和極

47、限數(shù)量下用戶并發(fā)的情況。并發(fā)用戶測試主要是對系統(tǒng)的核心功能和重要業(yè)務(wù)進(jìn)行測試，要以真實的業(yè)務(wù)數(shù)據(jù)作為輸入，選擇有代表性和關(guān)鍵的業(yè)務(wù)操作來設(shè)計測試用例。主要編寫以下兩個方面的用例：核心模塊的測試（可以理解為“單元性能測試”）：對核心功能模塊進(jìn)行并發(fā)用戶測試，測試系統(tǒng)是否能夠穩(wěn)定運(yùn)行。例如對于互聯(lián)網(wǎng)的公用郵件系統(tǒng)，每天早上9點左右可能是收發(fā)郵件的高峰，這時候上千的用戶都要在上班后進(jìn)入郵件系統(tǒng)，系統(tǒng)這個時候需要接收和發(fā)送大量的郵件。所以郵件系統(tǒng)這一功能模塊要進(jìn)行并發(fā)測試。通過測試可以知道數(shù)據(jù)庫服務(wù)器、操作系統(tǒng)、網(wǎng)絡(luò)設(shè)備等是否能夠承受住考驗，同時可以對瓶頸進(jìn)行分析。表2列出來一些常見的參數(shù)(表格中的數(shù)

48、據(jù)為示例的測試用例和測試結(jié)果)，可以根據(jù)實際需要進(jìn)行增加和刪除，其中磁盤I/O、數(shù)據(jù)庫相關(guān)測試參數(shù)要根據(jù)實際情況進(jìn)行選擇，因此沒有列出。功能在線用戶達(dá)到高峰時，發(fā)送和接收普通郵件正常，保證200個以內(nèi)用戶可以同時訪問郵件系統(tǒng)，能夠正常發(fā)送和接收郵件。目的測試系統(tǒng)200個以內(nèi)的用戶同時在線能否正常發(fā)送郵件。方法采用LoadRunner的錄制工具錄制一個郵件發(fā)送過程，然后利用其完成測試，要監(jiān)視數(shù)據(jù)庫服務(wù)器和web服務(wù)器的性能。其中發(fā)送的郵件為普通的郵件，附件大小不超過1M.并發(fā)用戶數(shù)與事務(wù)執(zhí)行情況并發(fā)用戶數(shù)事務(wù)平均響應(yīng)時間事務(wù)最大響應(yīng)時間平均每秒處理事務(wù)數(shù)事務(wù)成功率每秒點擊率平均流量（字節(jié)/秒）1

49、001.3442.0785100%1025177并發(fā)用戶數(shù)與數(shù)據(jù)庫主機(jī)并發(fā)用戶數(shù)CPU利用率MEM利用率磁盤I/O參數(shù)DB參數(shù)1其它參數(shù)1002311  并發(fā)用戶數(shù)與應(yīng)用服務(wù)器的關(guān)系表并發(fā)用戶數(shù)CPU利用率MEM利用率磁盤I/O參數(shù)1003227表2 核心模塊的性能測試用例在編寫這類用例時，要進(jìn)行綜合分析，選出系統(tǒng)中的各個核心模塊，分別設(shè)計每個模塊的測試用例：把模塊劃分成小的“事務(wù)”進(jìn)行測試，這樣在測試分析中便于定位問題究竟出現(xiàn)在哪里。例如郵件系統(tǒng)可以劃分成：接收郵件、發(fā)送郵件、打開郵件等小的事務(wù)進(jìn)行測試用例的編寫，每個操作做為一個用例來執(zhí)行。業(yè)務(wù)組合性能測試（可以理解為“

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

51、線使用系統(tǒng)。目的：測試系統(tǒng)500個以內(nèi)的用戶同時在線能否使用比較常見的模塊：公文系統(tǒng)、電子公告、網(wǎng)上論壇。方法：采用LoadRunner的錄制工具錄制三個業(yè)務(wù)：業(yè)務(wù)1在公文系統(tǒng)內(nèi)，進(jìn)行打開、修改等操作；業(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è)計時要全面考慮，不要有遺漏。在測試執(zhí)行時，本部分通常是采用性能測試工具例如LoadRunner來進(jìn)行測試

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

53、放在并發(fā)測試中。大數(shù)據(jù)量測試一般是針對那些對數(shù)據(jù)庫有特殊要求的系統(tǒng)進(jìn)行測試，例如電信業(yè)務(wù)系統(tǒng)的手機(jī)短信息表，由于有的用戶關(guān)機(jī)或者不在服務(wù)區(qū)，每秒鐘需要有大量的短信息保存，同時在用戶聯(lián)機(jī)后還要及時發(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ù))：目的測試系統(tǒng)運(yùn)行網(wǎng)絡(luò)在不同并發(fā)用戶條件下的使用情況方法在不同的廣域網(wǎng)帶寬下（例如256K）使用L

54、oadRunner錄制郵件系統(tǒng)的相關(guān)事務(wù)操作腳本，以不同的并發(fā)用戶數(shù)進(jìn)行測試，記錄各種用戶連接數(shù)下，不同并發(fā)請求的性能變化；同時記錄路由器端口的流量和其他數(shù)據(jù)。運(yùn)行時間10小時用戶并發(fā)數(shù)事務(wù)平均響應(yīng)時間服務(wù)器端口流量丟報率1002.81650.2M/S0.001%5003.87698.2M/S0.002%表3 網(wǎng)絡(luò)性能測試本部分可以獨(dú)立測試，也可以和用戶并發(fā)性能測試、疲勞強(qiáng)度與大數(shù)據(jù)量性能測試結(jié)合起來，在原有的基礎(chǔ)上采用工具來調(diào)整網(wǎng)絡(luò)設(shè)置，從而達(dá)到監(jiān)視網(wǎng)絡(luò)性能的目的。通常網(wǎng)絡(luò)性能都是采用工具進(jìn)行性能評估，由系統(tǒng)集成工程師來進(jìn)行。2.5服務(wù)器性能測試本部分的測試用例不必獨(dú)立編寫，或者根據(jù)實際需要

55、編寫少量的測試用例，建議這部分的用例編寫和前兩部分結(jié)合起來，在用戶并發(fā)性能測試、疲勞強(qiáng)度與大數(shù)據(jù)量性能測試時完成對服務(wù)器性能的監(jiān)控，完成對服務(wù)器性能的評估。2.6性能分析基本策略在上面的用例執(zhí)行完成后，接下來要進(jìn)行性能分析。性能分析是性能測試的最終目的，否則測試出的指標(biāo)就不會有實際意義，這里主要介紹一下性能分析的基本思路。性能分析通常要圍繞三個方面進(jìn)行：軟件、服務(wù)器、網(wǎng)絡(luò)。軟件主要是分析具體事務(wù)執(zhí)行時間，尤其并發(fā)用戶部分，根據(jù)測試工具測試出的結(jié)果分析那些事務(wù)執(zhí)行的慢，然后可以分析執(zhí)行較慢的代碼，針對網(wǎng)頁可以分析具體的頁面元素執(zhí)行情況。服務(wù)器的分析要結(jié)合軟件的運(yùn)行情況進(jìn)行分析，著重分析硬件的執(zhí)行

56、參數(shù)，CPU、硬盤、內(nèi)存、中斷、內(nèi)存等情況，分析尤其要注意對這些參數(shù)進(jìn)行綜合分析，往往各個參數(shù)之間會互相影響，最后在調(diào)查、分析整體系統(tǒng)的基礎(chǔ)上，找出影響服務(wù)器整體性能的瓶頸，確定相應(yīng)的升級需求：1. 服務(wù)器硬盤負(fù)載較重，需增加硬盤。2. CPU整體性能偏低，需增加或更新CPU。3. 網(wǎng)卡性能偏低，需更換光纖網(wǎng)卡。4. 硬盤I/O負(fù)載任務(wù)繁重，需使用高轉(zhuǎn)速硬盤或采用RAID卡。5. 內(nèi)存資源短缺，需增大內(nèi)存。6. 其他方面，需要升級軟件系統(tǒng)、合理進(jìn)行子網(wǎng)劃分、加強(qiáng)管理等。網(wǎng)絡(luò)性能分析要結(jié)合結(jié)合服務(wù)器和測試目標(biāo)軟件，通常網(wǎng)絡(luò)傳輸慢會有軟件和服務(wù)器方面的原因，甚至有時候會有客戶端方面的原因。不過目前

57、網(wǎng)絡(luò)的環(huán)境普遍可以，不管是局域網(wǎng)還是廣域網(wǎng)，網(wǎng)絡(luò)的環(huán)境越來越好。3用例管理測試用例的管理我們可以借鑒開發(fā)過程中對程序的管理方法，我們可以把測試用例看成程序測試工程師編寫的程序，這個程序也要經(jīng)過“設(shè)計”、“開發(fā)”、“測試”、“版本管理”、“發(fā)布”、“維護(hù)”等一系列操作，然后按照管理軟件程序的方法來管理測試用例。用例管理主要包含評審、修改、執(zhí)行用例、用例版本維護(hù)、用例升級方面的內(nèi)容。3.1 用例評審測試用例評審是測試用例不可缺少的一個環(huán)節(jié)，這是對“測試部門開發(fā)出的產(chǎn)品”進(jìn)行的“測試”?；舅悸肥菍y試準(zhǔn)備階段的成果進(jìn)行分期評審，依次評審系統(tǒng)/驗收測試用例、集成測試用例、單元測試用例。評審用例在比較

58、正規(guī)的公司更容易實施，要求相應(yīng)的軟件開發(fā)團(tuán)隊必須在實際工作中對測試給予足夠的重視，才可以把這項工作做好，否則只是走走形式。有效的用例評審?fù)ǔＳ上旅鎯煞N形式組成：測 試部門外部評審主要是由開發(fā)部、項目實施部、甚至銷售人員參加的評審，目的主要是查找測試工程師編寫的用例是否缺少內(nèi)容。建議采用非正式評審的形式進(jìn) 行，因為我們很難把開發(fā)人員組織在一起，一般來說他們的開發(fā)進(jìn)度壓力很大，能夠抽出時間看文檔已經(jīng)是“很給面子了”。當(dāng)然不統(tǒng)一進(jìn)行評審會耽誤工程的進(jìn) 度，所以在實際工作中如果時間緊迫，可以提前啟動測試實施工作，待評審?fù)瓿珊筮M(jìn)行用例的修改工作。通常測試工作進(jìn)行一段時間評審就會結(jié)束，這個時候測試執(zhí) 行人員可以在工作中對測試用例的內(nèi)容進(jìn)行動態(tài)的調(diào)整，再次執(zhí)行被修改過的部分用例（如果能夠采用正式評審，效果肯定會更好。）。外部評審主要工作方式是用文檔直接記錄評審結(jié)果，測試人員根據(jù)評審結(jié)果對用例進(jìn)行升級修改。測試部門內(nèi)部評審部門內(nèi)部同行對測試策略的評審，評審的核心內(nèi)容是測試策略和用例