第一篇：組隊(duì)測試用例樣式

1.入隊(duì)（默認(rèn)可以自由組隊(duì)）

-被邀請

-被邀請人狀態(tài)

-不在同一個(gè)地圖、GS上

-同一個(gè)地圖的同一區(qū)域、不同區(qū)域，即同步范圍

-不在線、傳送

-處于別的玩家隊(duì)伍中

-處于系統(tǒng)隊(duì)伍中，如戰(zhàn)場

-被邀請后收到提示

-被邀請人做出選擇后的響應(yīng)

-被邀請人沒有選擇時(shí)的響應(yīng)

-被邀請人收到提示后下線

-被邀請人收到提示后切換地圖、GS

-被兩個(gè)、多個(gè)玩家邀請

-提示界面相關(guān)

-邀請別人

-邀請人狀態(tài)

-邀請人沒有隊(duì)伍

-邀請人已經(jīng)組建了一個(gè)隊(duì)伍

-是不是隊(duì)長

-邀請人隊(duì)伍已滿

-邀請人隊(duì)伍未滿

-在玩家回應(yīng)前，繼續(xù)邀請多個(gè)玩家

-發(fā)出邀請后

-對方未響應(yīng)前，隊(duì)伍已滿

-對方未響應(yīng)前，隊(duì)伍已解散

-對方拒絕邀請是否提示

-對方接受邀請時(shí)的提示

-申請入隊(duì)

-申請進(jìn)入的目標(biāo)隊(duì)伍狀態(tài)

-申請目標(biāo)沒有隊(duì)伍

-申請目標(biāo)隊(duì)伍人數(shù)已滿，是否繼續(xù)進(jìn)入申請名單

-申請目標(biāo)是隊(duì)長

-申請目標(biāo)是隊(duì)員

-向多個(gè)隊(duì)伍發(fā)起申請

-申請目標(biāo)（隊(duì)長）接到的響應(yīng)

-隊(duì)長同意申請

-同意申請時(shí)，發(fā)起人已經(jīng)離線

-同意申請時(shí)，發(fā)起人已有隊(duì)伍

-同意申請時(shí)，發(fā)起人已經(jīng)切換地圖、GS

-同意申請時(shí)，發(fā)起人可以正常入隊(duì)

-同意申請時(shí)，隊(duì)伍人數(shù)已滿

-隊(duì)長拒絕申請

-發(fā)起人收到的提示

-其他隊(duì)員不可操作

-隊(duì)長能收到申請信息的數(shù)量

-隊(duì)長重新組隊(duì)后是否清空申請名單

-申請界面相關(guān) 2.隊(duì)伍中（默認(rèn)即時(shí)戰(zhàn)斗游戲）

-需要同步的信息是否正確

-玩家的狀態(tài)，如HP、等級、職業(yè)等

-玩家的位置

-同一個(gè)地圖

-不同地圖、GS

-隊(duì)員上線/離線

-以上信息發(fā)生改變時(shí)能否同步/實(shí)時(shí)刷新

-隊(duì)長/全隊(duì)離線后的處理

-移交隊(duì)長

-移交給不在線、不同地圖、GS的玩家

-移交后新隊(duì)長擁有的權(quán)限

-移交后原隊(duì)長的權(quán)限

-是否需要確認(rèn)框提示

-確認(rèn)框彈出后目標(biāo)玩家離隊(duì)

-獎(jiǎng)勵(lì)的分配方式

-擊殺獎(jiǎng)勵(lì)，如EXP

-同步范圍外的玩家能否分配到

-是否需要隊(duì)員參與擊殺

-每一個(gè)分配到的玩家得到的數(shù)值

-玩家參與擊殺中途死亡/離隊(duì)，是否能分配到

-拾取獎(jiǎng)勵(lì)

-同步范圍外的玩家能否參與分配

-是否需要隊(duì)員參與擊殺

-參與擊殺隊(duì)員中途下線/離隊(duì)/死亡，上線后是否能參與分配

-其他幾種分配方式

-戰(zhàn)斗關(guān)系

--具體需要考慮技能與PK規(guī)則相關(guān)

-隊(duì)伍界面相關(guān)

-其他功能

-任務(wù)共享

-隊(duì)伍聊天

-標(biāo)記 3.離隊(duì)

-隊(duì)長解散/離開隊(duì)伍

-隊(duì)員離開隊(duì)伍

-離隊(duì)后可以重新組建隊(duì)伍

-離隊(duì)后需要檢查

-戰(zhàn)斗關(guān)系

-地圖上的位置標(biāo)記

第二篇：自動售貨機(jī)測試用例

題目：有一個(gè)處理單價(jià)為5角錢的飲料的自動售貨機(jī)軟件測試用例的設(shè)計(jì)。其規(guī)格說明如下：若投入5角錢或1元錢的硬幣，押下〖橙汁〗或〖啤酒〗的按鈕，則相應(yīng)的飲料就送出來。若售貨機(jī)沒有零錢找，則一個(gè)顯示〖零錢找完〗的紅燈亮，這時(shí)在投入1元硬幣并押下按鈕后，飲料不送出來而且1元硬幣也退出來；若有零錢找，則顯示〖零錢找完〗的紅燈滅，在送出飲料的同時(shí)退還5角硬幣。1.分析這一段說明，列出原因和結(jié)果 原因：

1.售貨機(jī)有零錢找 2.投入1元硬幣 3.投入5角硬幣

4.押下橙汁按鈕 5.押下啤酒按鈕

結(jié)果：

21.售貨機(jī)〖零錢找完〗燈亮

22.退還1元硬幣

23.退還5角硬幣

24.送出橙汁飲料 25.送出啤酒飲料 2.畫出因果圖

如圖所示。所有原因結(jié)點(diǎn)列在左邊，所有結(jié)果結(jié)點(diǎn)列在右邊。建立中間結(jié)點(diǎn)，表示處理的中間狀態(tài)。中間結(jié)點(diǎn)：

11.投入1元硬幣且押下飲料按鈕 12.押下〖橙汁〗或〖啤酒〗的按鈕 13.應(yīng)當(dāng)找5角零錢并且售貨機(jī)有零錢找 14.錢已付清

3.轉(zhuǎn)換成判定表：

4.設(shè)計(jì)測試用例

1)在售貨機(jī)有零錢找的情況下，投入1元硬幣，押下橙汁按鈕，找回5角硬幣并送出橙汁飲料。

2)在售貨機(jī)有零錢找的情況下，投入1元硬幣，押下啤酒按鈕，找回5角硬幣并送出啤酒飲料。

3)在售貨機(jī)有零錢找的情況下，投入1元硬幣，系統(tǒng)不做任何處理。

4)在售貨機(jī)有零錢找的情況下，投入5角硬幣，押下橙汁按鈕，送出橙汁飲料。5)在售貨機(jī)有零錢找的情況下，投入5角硬幣，押下啤酒按鈕，送出啤酒飲料。6)在售貨機(jī)有零錢找的情況下，投入5角硬幣，系統(tǒng)不做任何處理。7)在售貨機(jī)有零錢找的情況下，押下橙汁按鈕，系統(tǒng)不做任何處理。8)在售貨機(jī)有零錢找的情況下，押下啤酒按鈕，系統(tǒng)不做任何處理。

9)在售貨機(jī)沒有零錢找的情況下，投入1元硬幣，押下橙汁按鈕，售貨機(jī)“零錢找完”燈亮，并退還1元硬幣。

10)在售貨機(jī)沒有零錢找的情況下，投入1元硬幣，押下啤酒按鈕，售貨機(jī)“零錢找完”燈亮，并退還1元硬幣。

11)在售貨機(jī)沒有零錢找的情況下，投入1元硬幣，售貨機(jī)“零錢找完”燈亮。

12)在售貨機(jī)沒有零錢找的情況下，投入5角硬幣，押下橙汁按鈕，售貨機(jī)“零錢找完”燈亮，并送出橙汁飲料。

13)在售貨機(jī)沒有零錢找的情況下，投入5角硬幣，押下啤酒按鈕，售貨機(jī)“零錢找完”燈亮，并送出啤酒飲料。

14)在售貨機(jī)沒有零錢找的情況下，投入5角硬幣，售貨機(jī)“零錢找完”燈亮。15)在售貨機(jī)沒有零錢找的情況下，押下橙汁按鈕，售貨機(jī)“零錢找完”燈亮。16)在售貨機(jī)沒有零錢找的情況下，押下啤酒按鈕，售貨機(jī)“零錢找完”燈亮。

第三篇：測試用例怎么寫

怎么寫測試用例我剛剛就業(yè)來到公司做軟件測試我在學(xué)校沒有太多的機(jī)會做測試，測試用例和測試報(bào)告應(yīng)該怎么寫。

● 測試用例編號

◇ 規(guī)則：編號具有唯一性、易識別性，由數(shù)字和字符組合成的字符串◇ 約定：

系統(tǒng)測試用例：產(chǎn)品編號-ST-系統(tǒng)測試項(xiàng)名-系統(tǒng)測試子項(xiàng)名-XXX

集成測試用例：產(chǎn)品編號-IT-集成測試項(xiàng)名-集成測試子項(xiàng)名-XXX單元測試用例：產(chǎn)品編號-UT-單元測試項(xiàng)名-單元測試子項(xiàng)名-XXX

● 測試項(xiàng)目

◇ 規(guī)則：當(dāng)前測試用例所屬測試大類、被測需求、被測模塊、被測單元等◇ 約定：

系統(tǒng)測試用例測試項(xiàng)目：軟件需求項(xiàng) 如：測試手機(jī)在沒有SIM卡的情況下，可以撥打緊急電話

集成測試用例測試項(xiàng)目：集成后的模塊名或接口名 如：測試模塊A提供的文件接口

單元測試用例測試項(xiàng)目：被測試的函數(shù)名 如：測試函數(shù)int ReadFile(char *pszFileName)

● 測試標(biāo)題

規(guī)則：測試用例的概括簡單的描述用例的出發(fā)點(diǎn)、關(guān)注點(diǎn)，原則上不能重復(fù)。● 重要級別

規(guī)則

高：保證系統(tǒng)基本功能、核心業(yè)務(wù)、重要特性、實(shí)際使用頻率高的測試用例；中：重要程度介于高和低之間的測試用例；

低：實(shí)際使用頻率不高、對系統(tǒng)業(yè)務(wù)功能影響不大的模塊或功能的測試用例。● 預(yù)置條件

規(guī)則：執(zhí)行當(dāng)前測試用例需要的前提條件，是后續(xù)步驟的先決條件● 輸入

規(guī)則：用例執(zhí)行過程中需要加工的外部信息，輸入、文件、數(shù)據(jù)庫等● 操作步驟

規(guī)則：執(zhí)行當(dāng)前測試用例需要經(jīng)過的操作步驟，保證操作步驟的完整性。● 預(yù)期輸出

規(guī)則：當(dāng)前測試用例的預(yù)期輸出結(jié)果，包括返回值的內(nèi)容、界面的響應(yīng)結(jié)果、輸出結(jié)果的規(guī)則符合度等

第四篇：測試用例書寫標(biāo)準(zhǔn)

測試用例書寫標(biāo)準(zhǔn)

在編寫測試用例過程中，需要參考和規(guī)范一些基本的測試用例編寫標(biāo)準(zhǔn)，在ANSI/IEEE829-1983標(biāo)準(zhǔn)中列出了和測試設(shè)計(jì)相關(guān)的測試用例編寫規(guī)范和模板。標(biāo)準(zhǔn)模板中主要元素如下。

? 標(biāo)識符（identification）：每個(gè)測試用例應(yīng)該有一個(gè)唯一的標(biāo)識符，它將成為所有和測試用例相關(guān)的文檔/表格引用和參考的基本元素，這些文檔/表格包括設(shè)計(jì)規(guī)格說明書、測試日志表、測試報(bào)告等。

? 測試項(xiàng)（test item）：測試用例應(yīng)該準(zhǔn)確地描述所需要測試地項(xiàng)及其特征，測試項(xiàng)應(yīng)該比測試設(shè)計(jì)說明書中所列出地特性描述更加具體，例如做windows計(jì)算器應(yīng)用程序地窗口設(shè)計(jì)，測試對象是整個(gè)地應(yīng)用程序用戶界面，這樣測試項(xiàng)就應(yīng)該是應(yīng)用程序地界面地特性要求，例如縮放測試、界面布局、菜單等。

? 測試環(huán)境要求（test environment）：用來表征執(zhí)行該測試用例需要地測試環(huán)境，一般來說，在整個(gè)的測試模塊里面應(yīng)該包含整個(gè)的測試環(huán)境的特殊要求，而單個(gè)測試用例的測試環(huán)境需要表征該測試用例所單獨(dú)需要的特殊環(huán)境需求。

? 輸入標(biāo)準(zhǔn)（input criteria）：用來執(zhí)行測試用例的輸入需求。這些輸入可能包括數(shù)據(jù)、文件，或者操作（例如鼠標(biāo)的左鍵單擊，鼠標(biāo)的按鍵處理等），必要的時(shí)候，相關(guān)的數(shù)據(jù)庫、文件也必須被羅列。

? 輸出標(biāo)準(zhǔn)（output criteria）：標(biāo)識按照指定的環(huán)境和輸入標(biāo)準(zhǔn)得到的期望輸出結(jié)果。如果可能的話，盡量提供適當(dāng)?shù)南到y(tǒng)規(guī)格說明書來證明期望的結(jié)果。

? 測試用例之間的關(guān)聯(lián)：用來標(biāo)識該測試用例與其它的測試（或其它測試用例）之間的依賴關(guān)系，例如，用例A需要基于B的測試結(jié)果正確的基礎(chǔ)上才能進(jìn)行，此時(shí)需要在A的測試用例中表明對B的依賴性，從而保證測試用例的嚴(yán)謹(jǐn)性。

綜上所述，如果使用一個(gè)數(shù)據(jù)庫的表來表征測試用例的話，它應(yīng)該有以下的格式：

例一：對Windows記事本程序進(jìn)行測試，選取其中的一個(gè)測試項(xiàng)――文件菜單欄的測試 測試對象：記事本程序文件菜單欄（測試用例標(biāo)識1000，下同），所包含的子測試用例描述如下：

|---------文件/新建（1001）

|---------文件/打開（1002）

|---------文件/保存（1003）

|---------文件/另存（1004）

|---------文件/頁面設(shè)置（1005）

|---------文件/打印（1006）

|---------文件/退出（1007）

|---------菜單布局（1008）

|---------快捷鍵（1009）

選取其中的一個(gè)子測試用例――文件/退出（1007）作為例子，測試用例如下表所示：

通過這個(gè)例子了解了測試用例的組成方法。要組織成一個(gè)完整的良好測試用例，還需要更多的技巧，并要考慮一些常見的因素。

測試用例設(shè)計(jì)考慮因素

測試是不可能實(shí)現(xiàn)窮舉測試的，因此試圖用所有的測試用例來覆蓋所有測試可能遇到的情形是不可能的，所以，在測試用例的編寫、組織過程中，盡量考慮有代表性的典型的測試用例，來實(shí)現(xiàn)以點(diǎn)帶面的窮舉測試。這要求在測試用例設(shè)計(jì)中考慮一些基本因素： ? 測試用例必須具有代表性、典型性。

? 測試用例設(shè)計(jì)時(shí)，要濃縮系統(tǒng)設(shè)計(jì)。

例二：常見的web登錄頁面，通過這個(gè)例子來闡述從功能規(guī)格說明書到具體測試用例編寫的過程

A）用戶登錄的功能設(shè)計(jì)規(guī)格說明書（摘選）

―――――――――――――――――――――――――――――――――――――――

1． 用戶登錄

1．1滿足基本頁面布局（圖示，略）

1．2當(dāng)用戶沒有輸入用戶名和密碼時(shí)，不立即彈出錯(cuò)誤對話框，而是在頁面上使用紅色字體來提示，見2描述

1．3用戶密碼使用掩碼號（*）來標(biāo)識。

1．4*代表必選字段，將出現(xiàn)在輸入文本框的后面。

2． 登錄出現(xiàn)錯(cuò)誤

當(dāng)出現(xiàn)錯(cuò)誤時(shí)，在頁面的頂部會出現(xiàn)相應(yīng)的錯(cuò)誤提示。錯(cuò)誤提示的內(nèi)容見3。錯(cuò)誤提示是高亮的紅色字體實(shí)現(xiàn)。

3． 錯(cuò)誤信息描述

3．1

3．2密碼為空

3，3用戶名/

（注：本例子中的頁面圖示，消息編號如WMSG001的描述均為給出。）

―――――――――――――――――――――――――――――――――――――――

B）通用安全性設(shè)計(jì)規(guī)格說明書（摘選）

―――――――――――――――――――――――――――――――――――――――

1． 安全性描述

1．1輸入安全性：在用戶登錄或者信用卡驗(yàn)證過程中，如果三次輸入不正確，頁面將需要重新打開才能生效。

1．2密碼：在所有的用戶密碼中，都必須使用掩碼符號（*），數(shù)據(jù)在數(shù)據(jù)庫中存儲使用統(tǒng)一的加密和解密算法。

1．3Cookie：在信用卡信息驗(yàn)證，用戶名輸入時(shí)，Cookie都是被禁止的，當(dāng)用戶第一次輸入后，瀏覽器將不再提供是否保存信息的提示，自動完成功能將被禁用。

1．4SSL校驗(yàn)：所有的站點(diǎn)訪問時(shí)，都必須經(jīng)過SSL校驗(yàn)。

2． 錯(cuò)誤描述（略）

―――――――――――――――――――――――――――――――――――――――

C）測試用例

結(jié)合相關(guān)的規(guī)格說明書，理解和掌握測試用例設(shè)計(jì)的關(guān)鍵點(diǎn)，測試用例設(shè)計(jì)如下表所示。

? 測試用例需要考慮到正確的輸入，也需要考慮錯(cuò)誤的或者異常的輸入，以及需要分

析怎樣使得這樣的錯(cuò)誤或者異常能夠發(fā)生。

用戶登錄功能測試用例

完善的測試用例

? 用戶測試用例的設(shè)計(jì)，要多考慮用戶實(shí)際使用場景。

第五篇：測試用例設(shè)計(jì)步驟

測試用例設(shè)計(jì)步驟

設(shè)計(jì)測試案例的時(shí)候，需要有清晰的測試思路，對要測試什么，按照什么順序測試，覆蓋哪些需求做到心中有數(shù)。測試用例編寫者不僅要掌握軟件測試的技術(shù)和流程，而且要對被測軟件的設(shè)計(jì)、功能規(guī)格說明、用戶試用場景以及程序/模塊的結(jié)構(gòu)都有比較透徹的理解。測試用例設(shè)計(jì)一般包括以下幾個(gè)步驟：

1、測試需求分析

從軟件需求文檔中，找出待測試軟件/模塊的需求，通過自己的分析、理解，整理成為測試需求，清楚被測試對象具有哪些功能。測試需求的特點(diǎn)是：包含軟件需求，具有可測試性。測試需求應(yīng)該在軟件需求基礎(chǔ)上進(jìn)行歸納、分類或細(xì)分，方便測試用例設(shè)計(jì)。測試用例中的測試集與測試需求的關(guān)系是多對一的關(guān)系，即一個(gè)或多個(gè)測試用例集對應(yīng)一個(gè)測試需求。

2、業(yè)務(wù)流程分析

軟件測試，不單純是基于功能的黑盒測試，還需要對軟件的內(nèi)部處理邏輯進(jìn)行測試。為了不遺漏測試點(diǎn)，需要清楚的了解軟件產(chǎn)品的業(yè)務(wù)流程。建議在做復(fù)雜的測試用例設(shè)計(jì)前，先畫出軟件的業(yè)務(wù)流程。如果設(shè)計(jì)文檔中已經(jīng)有業(yè)務(wù)流程設(shè)計(jì)，可以從測試角度對現(xiàn)有流程進(jìn)行補(bǔ)充。如果無法從設(shè)計(jì)中得到業(yè)務(wù)流程，測試工程師應(yīng)通過閱讀設(shè)計(jì)文檔，與開發(fā)人員交流，最終畫出業(yè)務(wù)流程圖。業(yè)務(wù)流程圖可以幫助理解軟件的處理邏輯和數(shù)據(jù)流向，從而指導(dǎo)測試用例的設(shè)計(jì)。

從業(yè)務(wù)流程上，應(yīng)得到以下信息：

A、主流程是什么

B、條件備選流程是什么

C、數(shù)據(jù)流向是什么

D、關(guān)鍵的判斷條件是什么

3、測試用例設(shè)計(jì)

完成了測試需求分析和軟件流程分析后，開始著手設(shè)計(jì)測試用例。測試用例設(shè)計(jì)的類型包括功能測試，邊界測試，異常測試，性能測試，壓力測試等。在用例設(shè)計(jì)中，除了功能測試用例外，應(yīng)盡量考慮邊界、異常、性能的情況，以便發(fā)現(xiàn)更多的隱藏問題。

黑盒測試的測試用例設(shè)計(jì)方法有：等價(jià)類劃分、邊界值劃分、因果圖分析和錯(cuò)誤猜測，白盒測試的測試用例設(shè)計(jì)方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這里主要討論黑盒測試。在設(shè)計(jì)測試用例的時(shí)候可以使用軟件測試用例設(shè)計(jì)方法，結(jié)合前面的需求分析和軟件流程分析進(jìn)行設(shè)計(jì)：

功能測試：測試某個(gè)功能是否滿足需求的定義，功能是否正確，完備。

適合的技術(shù)：由業(yè)務(wù)需求和設(shè)計(jì)說明導(dǎo)出的功能測試、等價(jià)類劃分

邊界測試：對某個(gè)功能的邊界情況進(jìn)行測試。

適合的技術(shù)：邊界值劃分

異常測試：對某些功能來說，其邊界情況無法簡單的了解或某些操作不完全是正確的但又是

可能發(fā)生的，類似這樣的情況需要書寫相關(guān)的異常測試。

適合的技術(shù)：由業(yè)務(wù)需求和設(shè)計(jì)說明導(dǎo)出的特殊業(yè)務(wù)流程、錯(cuò)誤猜測法、邊界值

分析、內(nèi)部邊界值測試。

性能測試：檢查系統(tǒng)是否滿足在需求中所規(guī)定達(dá)到的性能，性能主要包括了解程序的內(nèi)外部

性能因素。內(nèi)部性能因素包括測試環(huán)境的配置，系統(tǒng)資源使用狀況；外部因素包

括響應(yīng)時(shí)間，吞吐量等。

適合的技術(shù)：業(yè)務(wù)需求和設(shè)計(jì)說明導(dǎo)出的測試

壓力測試：壓力測試又稱強(qiáng)度測試，主要是檢查系統(tǒng)運(yùn)行環(huán)境在極限情況下軟件運(yùn)行的能力，比如說給一個(gè)相當(dāng)大的負(fù)荷或網(wǎng)絡(luò)流量給應(yīng)用軟件兼容測試：測試軟件產(chǎn)品在不

同的平臺，不同的工具，相同工具的不同版本下功能的兼容性。

4、測試用例評審

測試用例設(shè)計(jì)完成后，為了確認(rèn)測試過程和方法是否正確，是否有遺漏的測試點(diǎn)，需要進(jìn)行測試用例的評審。

測試用例評審一般是由測試leader安排，參加的人員包括：測試用例設(shè)計(jì)者、測試leader、項(xiàng)目經(jīng)理、開發(fā)工程師、其它相關(guān)開發(fā)測試工程師。測試用例評審?fù)戤叄瑴y試工程師根據(jù)評審結(jié)果，對測試用例進(jìn)行修改，并記錄修改日志。

5、測試用例更新完善

測試用例編寫完成之后需要不斷完善，軟件產(chǎn)品新增功能或更新需求后，測試用例必須配套修改更新；在測試過程中發(fā)現(xiàn)設(shè)計(jì)測試用例時(shí)考慮不周，需要對測試用例進(jìn)行修改完善；在軟件交付使用后客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進(jìn)行完善。一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟件的版本升級更新，測試用例一般也應(yīng)隨之編制升級更新版本。測試用例是“活”的，在軟件的生命周期中不斷更新與完善。