第一篇：組隊測試用例樣式

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

-被邀請

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

-不在同一個地圖、GS上

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

-不在線、傳送

-處于別的玩家隊伍中

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

-被邀請后收到提示

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

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

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

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

-被兩個、多個玩家邀請

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

-邀請別人

-邀請人狀態(tài)

-邀請人沒有隊伍

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

-是不是隊長

-邀請人隊伍已滿

-邀請人隊伍未滿

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

-發(fā)出邀請后

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

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

-對方拒絕邀請是否提示

-對方接受邀請時的提示

-申請入隊

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

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

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

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

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

-向多個隊伍發(fā)起申請

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

-隊長同意申請

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

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

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

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

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

-隊長拒絕申請

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

-其他隊員不可操作

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

-隊長重新組隊后是否清空申請名單

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

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

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

-玩家的位置

-同一個地圖

-不同地圖、GS

-隊員上線/離線

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

-隊長/全隊離線后的處理

-移交隊長

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

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

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

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

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

-獎勵的分配方式

-擊殺獎勵，如EXP

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

-是否需要隊員參與擊殺

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

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

-拾取獎勵

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

-是否需要隊員參與擊殺

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

-其他幾種分配方式

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

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

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

-其他功能

-任務(wù)共享

-隊伍聊天

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

-隊長解散/離開隊伍

-隊員離開隊伍

-離隊后可以重新組建隊伍

-離隊后需要檢查

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

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

第二篇：自動售貨機測試用例

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

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

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

結(jié)果：

21.售貨機〖零錢找完〗燈亮

22.退還1元硬幣

23.退還5角硬幣

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第三篇：測試用例怎么寫

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

● 測試用例編號

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

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

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

● 測試項目

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

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

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

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

● 測試標(biāo)題

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

規(guī)則

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

低：實際使用頻率不高、對系統(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è)計相關(guān)的測試用例編寫規(guī)范和模板。標(biāo)準(zhǔn)模板中主要元素如下。

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

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

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

? 輸入標(biāo)準(zhǔn)（input criteria）：用來執(zhí)行測試用例的輸入需求。這些輸入可能包括數(shù)據(jù)、文件，或者操作（例如鼠標(biāo)的左鍵單擊，鼠標(biāo)的按鍵處理等），必要的時候，相關(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)行，此時需要在A的測試用例中表明對B的依賴性，從而保證測試用例的嚴(yán)謹(jǐn)性。

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

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

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

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

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

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

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

|---------文件/打?。?006）

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

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

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

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

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

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

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

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

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

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

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

1． 用戶登錄

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

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

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

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

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

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

3． 錯誤信息描述

3．1

3．2密碼為空

3，3用戶名/

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

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

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

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

1． 安全性描述

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

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

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

1．4SSL校驗：所有的站點訪問時，都必須經(jīng)過SSL校驗。

2． 錯誤描述（略）

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

C）測試用例

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

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

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

用戶登錄功能測試用例

完善的測試用例

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

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

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

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

1、測試需求分析

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

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

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

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

A、主流程是什么

B、條件備選流程是什么

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4、測試用例評審

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

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

5、測試用例更新完善

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