接口測試方法

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

2、增接口的測試；2、新增業(yè) 務(wù)功能接口測試；3、整個(gè)服務(wù)器的接口測試。所需測試測試接口依次增多，在測試時(shí)間足夠的條件下，當(dāng)然需要對(duì)所有接口進(jìn)行測試用例的設(shè)計(jì)，但如果測試較短 的情況下，則應(yīng)該首先根據(jù)用戶的典型操作對(duì)測試接口進(jìn)行優(yōu)先級(jí)劃分，對(duì)調(diào)用頻繁接口需要優(yōu)先進(jìn)行測試。二、接口測試策略       在進(jìn)行平臺(tái)服務(wù)器接口測試之前，首先需要整理服務(wù)器接口的測試方案，分析接口測試的要點(diǎn)，平臺(tái)服務(wù)器的接口測試內(nèi)容主要有：接口設(shè)計(jì)檢查接口用于服務(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  浮點(diǎn)型數(shù)據(jù)精度n  字符串?dāng)?shù)據(jù)范圍值要求客戶端的整數(shù)型、浮點(diǎn)型、字符串?dāng)?shù)據(jù)以及其最大值和最小值都能作為服務(wù)器接口的有效輸入。這些工作在服務(wù)器設(shè)計(jì)評(píng)審時(shí)就可以進(jìn)行，以便確保不會(huì)出現(xiàn)客戶端上傳數(shù)據(jù)被服務(wù)器自動(dòng)進(jìn)行截?cái)嗷蛩纳嵛迦氲牟僮?。接口依賴關(guān)系檢查    以上策略只談到單個(gè)接口的測試方法，對(duì)于用戶來說，一個(gè)操作可能會(huì)造成服務(wù)器調(diào)用多個(gè)接口來進(jìn)行完成，因此還需要從業(yè)務(wù)處理的角度，對(duì)各種業(yè)務(wù)操作所涉及的多個(gè)接口之間依賴

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

33、的 時(shí)什么樣的功能予以區(qū)別。用例的設(shè)計(jì)要嚴(yán)格按照測試對(duì)象功能設(shè)計(jì)才是正確的用例。 9. 設(shè)計(jì)（接口）測試用例有哪些要求：結(jié)構(gòu)好，可讀性高，滲透性強(qiáng)。 10. （接口）測試用例包括的內(nèi)容：功能點(diǎn)，測試環(huán)境，測試數(shù)據(jù)，執(zhí)行操作以及預(yù)期結(jié)果。 如下： a) 接口測試測試的功能點(diǎn)： 如果一個(gè)接口功能過于復(fù)雜時(shí)， 可以對(duì)接口用例迚行結(jié)構(gòu)劃分 （如根據(jù)層次， 平臺(tái)， 功能點(diǎn)等等） ， 這樣用例具有更好的可讀性（接口劃分原則為：以接口提供的功能點(diǎn)的丌同迚行合適粒度的劃分，同一功能點(diǎn)的用例又可 根據(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è)計(jì)、準(zhǔn)備測試用例的數(shù)據(jù)丌可馬 虎。通過好的測試數(shù)據(jù)查找問題，能極大的提高工作效率。接口參數(shù)數(shù)據(jù)需要對(duì)每個(gè)參數(shù)根據(jù)測試接口的實(shí)際功能迚行分 析，在符合業(yè)務(wù)邏輯的情況下迚行邏輯組合排列，丌要遺漏某些邊界值和錯(cuò)誤點(diǎn)的數(shù)據(jù)，這樣用例更容易發(fā)現(xiàn)問題。 d) e) 執(zhí)行操作：即對(duì)所測接口的調(diào)用。 預(yù)期結(jié)果：根據(jù)需求迚行驗(yàn)證，是衡量軟件是否達(dá)到預(yù)期的標(biāo)準(zhǔn)。應(yīng)該著重細(xì)致，每個(gè)用例均需驗(yàn)證，應(yīng)該避免一個(gè)用例 重復(fù)做相同的驗(yàn)證，提高測試用例的效率。 11. a) 具體測試用例的參考點(diǎn)： 輸入?yún)?shù)測試：針對(duì)輸入?yún)?shù)迚行的測試，也

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

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

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

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

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

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

41、計(jì)詳細(xì)設(shè)計(jì)編程單元測試集成測試系統(tǒng)測試驗(yàn)收測試 圖1 開發(fā)與測試的“V”型關(guān)系單元測試：單元測試是針對(duì)軟件設(shè)計(jì)的最小單位程序模塊甚至代碼段進(jìn)行正確性檢驗(yàn)的測試工作，通常由開發(fā)人員進(jìn)行。集成測試：集成測試是將模塊按照設(shè)計(jì)要求組裝起來進(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)，驗(yàn)證各子系統(tǒng)是否都能正常工作并完成設(shè)計(jì)的要求。它主要由測試部門進(jìn)行，是測試部門最大最重要的一個(gè)測試，對(duì)產(chǎn)品的質(zhì)量有重大的影響。驗(yàn)收測試：驗(yàn)收測試以需

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

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

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

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

46、，并根據(jù)測試結(jié)果來改進(jìn)系統(tǒng)的性能。這類通常以單用戶為主，如果遇到并發(fā)用戶的情況，可以歸到并發(fā)用戶測試用例中。這類用例通常都是可以通過手工來執(zhí)行的用例，例如示例中的上傳一份文件，期望的性能為2M/S，完全可以手動(dòng)上傳文件，同時(shí)用秒表計(jì)時(shí)。這些內(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)不能接收的性能點(diǎn)或者瓶頸。一般要測試正常數(shù)量的用戶并發(fā)和極

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

48、據(jù)為示例的測試用例和測試結(jié)果)，可以根據(jù)實(shí)際需要進(jìn)行增加和刪除，其中磁盤I/O、數(shù)據(jù)庫相關(guān)測試參數(shù)要根據(jù)實(shí)際情況進(jìn)行選擇，因此沒有列出。功能在線用戶達(dá)到高峰時(shí)，發(fā)送和接收普通郵件正常，保證200個(gè)以內(nèi)用戶可以同時(shí)訪問郵件系統(tǒng)，能夠正常發(fā)送和接收郵件。目的測試系統(tǒng)200個(gè)以內(nèi)的用戶同時(shí)在線能否正常發(fā)送郵件。方法采用LoadRunner的錄制工具錄制一個(gè)郵件發(fā)送過程，然后利用其完成測試，要監(jiān)視數(shù)據(jù)庫服務(wù)器和web服務(wù)器的性能。其中發(fā)送的郵件為普通的郵件，附件大小不超過1M.并發(fā)用戶數(shù)與事務(wù)執(zhí)行情況并發(fā)用戶數(shù)事務(wù)平均響應(yīng)時(shí)間事務(wù)最大響應(yīng)時(shí)間平均每秒處理事務(wù)數(shù)事務(wù)成功率每秒點(diǎn)擊率平均流量（字節(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 核心模塊的性能測試用例在編寫這類用例時(shí)，要進(jìn)行綜合分析，選出系統(tǒng)中的各個(gè)核心模塊，分別設(shè)計(jì)每個(gè)模塊的測試用例：把模塊劃分成小的“事務(wù)”進(jìn)行測試，這樣在測試分析中便于定位問題究竟出現(xiàn)在哪里。例如郵件系統(tǒng)可以劃分成：接收郵件、發(fā)送郵件、打開郵件等小的事務(wù)進(jìn)行測試用例的編寫，每個(gè)操作做為一個(gè)用例來執(zhí)行。業(yè)務(wù)組合性能測試（可以理解為“

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

51、線使用系統(tǒng)。目的：測試系統(tǒng)500個(gè)以內(nèi)的用戶同時(shí)在線能否使用比較常見的模塊：公文系統(tǒng)、電子公告、網(wǎng)上論壇。方法：采用LoadRunner的錄制工具錄制三個(gè)業(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ā)布帖子，查看文章。每個(gè)業(yè)務(wù)分配一定數(shù)目的用戶，利用LoadRunner來完成相關(guān)參數(shù)的測試。其它部分設(shè)計(jì)可以參考表2。執(zhí)行時(shí)要分別記錄各個(gè)事務(wù)的執(zhí)行情況。多用戶并發(fā)性能測試是性能測試的核心內(nèi)容，包含了全部與多用戶相關(guān)的測試。因此設(shè)計(jì)時(shí)要全面考慮，不要有遺漏。在測試執(zhí)行時(shí)，本部分通常是采用性能測試工具例如LoadRunner來進(jìn)行測試

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

53、放在并發(fā)測試中。大數(shù)據(jù)量測試一般是針對(duì)那些對(duì)數(shù)據(jù)庫有特殊要求的系統(tǒng)進(jìn)行測試，例如電信業(yè)務(wù)系統(tǒng)的手機(jī)短信息表，由于有的用戶關(guān)機(jī)或者不在服務(wù)區(qū)，每秒鐘需要有大量的短信息保存，同時(shí)在用戶聯(lián)機(jī)后還要及時(shí)發(fā)送，因此對(duì)數(shù)據(jù)庫性能有極高的要求，需要專門測試。本部分用例設(shè)計(jì)表格可以參考用戶并發(fā)性能測試部分。2.4網(wǎng)絡(luò)性能測試 網(wǎng)絡(luò)性能測試主要是為了準(zhǔn)確展示帶寬、延遲、負(fù)載和端口的變化是如何影響用戶的響應(yīng)時(shí)間的。在實(shí)際的軟件項(xià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ā)請(qǐng)求的性能變化；同時(shí)記錄路由器端口的流量和其他數(shù)據(jù)。運(yùn)行時(shí)間10小時(shí)用戶并發(fā)數(shù)事務(wù)平均響應(yīng)時(shí)間服務(wù)器端口流量丟報(bào)率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)行性能評(píng)估，由系統(tǒng)集成工程師來進(jìn)行。2.5服務(wù)器性能測試本部分的測試用例不必獨(dú)立編寫，或者根據(jù)實(shí)際需要

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

56、參數(shù)，CPU、硬盤、內(nèi)存、中斷、內(nèi)存等情況，分析尤其要注意對(duì)這些參數(shù)進(jìn)行綜合分析，往往各個(gè)參數(shù)之間會(huì)互相影響，最后在調(diào)查、分析整體系統(tǒng)的基礎(chǔ)上，找出影響服務(wù)器整體性能的瓶頸，確定相應(yīng)的升級(jí)需求：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. 其他方面，需要升級(jí)軟件系統(tǒng)、合理進(jìn)行子網(wǎng)劃分、加強(qiáng)管理等。網(wǎng)絡(luò)性能分析要結(jié)合結(jié)合服務(wù)器和測試目標(biāo)軟件，通常網(wǎng)絡(luò)傳輸慢會(huì)有軟件和服務(wù)器方面的原因，甚至有時(shí)候會(huì)有客戶端方面的原因。不過目前

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

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