第一篇：測試用例教案2

測試用例教案

綜合測試策略（萬金油）

? 任何情況下都必須使用等價類與邊界值設計測試用例

? 當條件間存在邏輯關系、約束關系會使用因果圖法追加測試用例 ? 若存在狀態間轉換或狀態間切換會使用狀態圖法追加測試用例 ? 如果存在業務流，使用場景法追加測試用例 ? 最后使用錯誤推測法追加測試用例 ? PS：正交試驗法一般不適用

第一講

1.測試思想：先考慮測試大方向（確定測試類型、方法），再細分。2.缺陷的項（缺陷的屬性、缺陷的內容）：

前置條件、測試環境、操作步驟、預期結果、實際結果、狀態、優先級、嚴重級、附件、用例編號、缺陷標題、缺陷編號、發現人、發現日期……

3.測試用例含義：一個包含測試數據、操作步驟、預期結果、實際結果的集合 4.測試用例的內容：

前置條件、測試環境、操作步驟（輸入數據）、預期結果、實際結果、優先級、用例編號、用例名稱、模塊名稱、是否通過、設計人、設計日期……

5.編寫測試用例的作用 ? 指導性：測試用例對測試過程提供要求和指導，降低對執行測試人員的能力要求 ? 組織性：編寫測試用例有利于測試的組織和管理 ? 功能覆蓋：編寫測試用例可以減少軟件功能漏測現象 ? 重復性：便于對軟件的不同版本進行重復測試 ? 統計：統計數據可以確定測試的覆蓋程度及軟件產品的質量 6.注意事項 ? 使用最有可能發現錯誤的用例 ? 用例不重復、不冗余 ? 選取一組相似測試用例中最有效的

? 在測試過程中，測試用例并不是一成不變的，需要不斷地進行更新和維護 7.測試用例是測試中最小的實體（entity）；

8.編寫測試用例方式：word、excel（使用較多）、工具 ? 使用excel編寫測試用例：

前置條件：省略重復步驟；

用例編號規則：模塊首字母+流水號： 用例編號的作用： 1）對用例進行很好的分類管理； 2）唯一標識、便于查找；

3）缺陷與用例進行關聯，便于bug定位；

9.Bvt測試（優先級測試）：根據設計的測試用例的優先級進行測試； ? 設計一條用例能夠發現至今還未發現的問題，該用例為高效用例。

10.測試方法：黑盒測試八大法：1.等價類 2.邊界值 3.因果圖 4.判定表 5.狀態圖 6.場景法 7.正交試驗法 8.錯誤推測法

? 運用邊界值的方法：剛剛小于界值、等界值、剛剛等于界值。

第二講

? 等價類劃分方法：把程序的輸入劃分成若干部分，從每個部分中選取少數代表性數據作為測試數據

? 根據等價類表，編寫測試用例 ? 為等價類表中的每一個等價類分配一個唯一的編號 ? 設計一個測試用例，使它能夠盡量覆蓋尚未覆蓋的有效等價類；重復這一步驟，從而使所有有效等價類均被測試用例所覆蓋

? 設計一個測試用例，使它只覆蓋一個無效等價類；重復這一步驟，從而使所有無效等價類均被測試用例所覆蓋

? 等價類的假設 ? 如果等價類中的一個測試用例能夠捕獲缺陷，那么選擇該等價類中的其他測試用例也能夠捕獲該缺陷

? 如果等價類中的一個測試用例不能捕獲缺陷，那么選擇該等價類中的其他測試用例也不能夠捕獲該缺陷

? 確定邊界值的方法：選擇正好等于、剛剛大于或剛剛小于邊界的值作為測試數據，重點測試最后一個肯定合法的數據和剛剛超過邊界的非法數據 ? 如果輸入條件對取值范圍進行界定，則應以邊界內部以及恰巧超過邊界外的值來作為測試用例

? 如果對取值的個數進行界定，則應當分別以最大個數、最小個數、比最大個數大1或小

1、比最小個數大1或小1作為測試用例

? 對于輸出條件，同樣可以應用上面提到的兩條原則來進行測試用例設計 ? 若在需求說明書提到的輸入是一個有序的集合，就應該注意選取該有序集合中的第一個和最后一個元素作為測試用例

作業：根據所學的等價類以及邊界值方法設計1到99加法計算器的測試用例 第三講

? 布爾邏輯運算符 ? ? ? ? ? ? 恒等 與 或 非 與非 或非

? 約束關系

? E約束：原因不能同時為真，但可以同時為假 ? I約束：各原因中總有一個為真，也可以同時為真，但不可以同時為假 ? O約束：有且只有兩個原因中的一個為真 ? R約束：當原因a為真時，原因b必須同時為真；反之則不成立 ? M約束：如果結果a為真，則結果b一定為假；如果結果a為假，則結果b狀態不定

? 使用因果圖設計測試用例步驟

? 分析被測應用，確定原因（輸入）和結果（輸出）? 確定因果邏輯關系 ? 確定約束關系 ? 把因果圖轉換為判定表 ? 根據約束條件簡化判定表，并給出結果 ? 根據判定表設計測試用例

? 使用因果圖法設計用例的優勢：

? 考慮了多個輸入之間的相互組合、相互制約關系 ? 提供了一種針對輸入組合條件的系統的測試用例設計方法

作業：使用因果圖設計販賣果汁機器的測試用例

第四講

? 正交試驗法

L行數（水平數^因素數）? L：正交表的代號 ? 行數：正交表中行的個數，即試驗次數

標準正交表：行數=因素數*（水平數-1）+1 混合正交表：行數=∑（因素數*（水平數-1））+1 ? 因素數：正交表中列的個數，即測試的功能點 ? 水平數：單個因素能夠取得的值的最大個數

? 正交表的兩大特性 ? 整齊可比性 ? 均衡分散性 ? 正交試驗法設計測試用例的步驟 ? 判斷有哪些因素 ? 每個因素有哪幾個水平? 選擇一個合適的正交表

? 選取行數大于等于實際行數

? 選取因素數大于等于實際因素數之和 ? 選取水平數大于等于實際最大水平數 ? 行數最少

? 把輸入的值映射到表中 ? 把每一行的各因素水平的組合作為一個測試用例 ? 加上可疑且沒有在表中出現的組合

? 使用正交表的好處

? 保證對所有輸入成對組合 ? 生成一組高效精簡的測試用例集，有效地提高測試效率 ? 生成的所有成對組合是均勻分布的，即對各個輸入項的測試是均衡的 ? 直接對照正交表設計測試用例，過程簡單，不易出錯 ? 易開發出基于正交表策略的測試用例工具，自動生成測試用例

第五講

? 根據狀態圖設計測試用例的最低要求

? 測試用例必須覆蓋所有的狀態 ? 用戶常用的工作流程必須設計測試用例 ? 測試狀態之間最不常用的分支 ? 測試所有狀態及其返回值

? 使用狀態圖法設計測試用例的步驟

? 列出被測系統的輸入事件 ? 對空閑狀態加所有可能的輸入，判斷產生哪些新狀態 ? 對上一步產生的每個新狀態分別加所有可能的輸入，判斷產生哪些新狀態 ? 循環執行第三步，直到沒有新狀態產生為止 ? 列出所有的狀態，根據系統流程，設計測試用例表（必須滿足最低要求）? 把測試用例表轉換成測試用例

? 使用場景法的基本設計步驟

? 根據說明，描述出程序的基本流及各項備選流 ? 根據基本流和各項備選流生成不同的場景 ? 對每一個場景生成相應的測試用例 ? 對生成的所有測試用例重新復審，去掉多余的測試用例，測試用例確定后，對每一個測試用例確定測試數據值

? 基本流：經過用例的最簡單的路徑 ? 其他流均為備選流，一個備選流可能從基本流開始，在某個特定條件下執行，然后重新加入基本流中；也可能起源于另一個備選流，或者終止用例而不再加入到某個流

題目

1.1--99計算器等價類分析，設計測試用例 1.電梯上下，時間段，單雙樓層 2.位置套餐

3.機頂盒（嵌入式）

第六講

web測試重點：

1.功能測試：功能的實現是否滿足客戶需求。2.性能測試：

2.1 鏈接速度測試：測試頁面鏈接的速度

2.2 負載測試：web應用系統能允許多少個用戶同時在線？超過這個數量會出現什么現象？

2.3 壓力測試：測試web應用在一定壓力下會不會奔潰以及性能瓶頸在哪里。3.用戶界面測試：界面是否協調美觀，風格是否一致

4.兼容性測試：操作系統（windows xp,windows 7,蘋果，linux），瀏覽器（不同廠商不同版本），分辨率

5.安全測試：登陸次數是否有限制，是否有超時限制（用戶登錄后一定時間內不做操作是否會自動退出），日志文件以及cookies（這兩者是否顯式地顯示用戶密碼賬號？）

第七講

app測試重點 1.安裝和卸載

1.1應用是否可以在IOS不同系統版本或android不同系統版本上安裝（有的系統版本過低，應用不能適配）

1.2 軟件安裝后是否可以正常運行 1.3 安裝過程中是否可以取消

1.4 安裝空間不足時是否有相應提示 1.5 聯網安裝時斷網是否有對應提示 1.6 能否正常卸載軟件

1.7 卸載時出現死機、斷電、重啟等意外，待環境回復后是否可以正確卸載 1.8 卸載過程中是否可以取消，點擊取消卸載后能否正常使用

2.登錄

2.1 賬號和密碼錯誤時界面是否有提示

2.2 用戶主動退出登錄后，下次重新啟動時應該進入登錄界面

2.3 記住密碼時能否正確自動登陸

2.4 密碼修改后，下次登陸是否及時同步（用原密碼登錄提示密碼錯誤）

2.5 未登錄狀態操作一些頁面是否做了控制（未登錄時將商品加入購物車提示請先登錄）

2.6 切換賬號時用戶信息是否及時更新（QQ切換關聯賬戶，用戶信息及時更改）

2.7 多個端都進行操作時，確保數據準確無誤并且每個端及時看到更新的數據（QQ：電腦、手機）

2.8 IOS與android不同設備登錄同一個賬戶對數據進行修改，確保數據無誤且能及時看到更新的數據

3.運行：安裝后能否正常打開、使用；運行時是否有加載提示；運行速度以及模塊之間切換速度是否流暢 4.離線

4.1 登錄后斷網能否瀏覽本地數據

4.2 獲取數據時斷網是否有友好提示

4.3 斷網后重新連接網絡能否正常使用 5.消息推送開關

5.1 消息推送開關是否默認打開（默認是打開的）

5.2 推送開關能否自由打開關閉

5.3 打開推動開關能否正常接收消息推送

5.4 app后臺掛機時，手機消息欄能接收消息提醒，可點擊查看，點擊后從消息欄中消失

5.5 app運行時消息提示不會進入消息欄

5.6 關閉推送開關不能接收消息推送 6.軟件更新

6.1 有新版本時，有更新提示

6.2 確保IOS與android端都可以更新最新版本，能安裝并正常運行

6.3 取消更新時舊版本可以正常使用，下次啟動仍出現更新提示

6.4 能否在不卸載舊版本的情況下直接更新新版本并能正常使用 7.異常測試

7.1 app運行時內存不足是否正確提示

7.2 app運行時突然斷電、斷網、不斷點、不斷刷新、切換后臺是否閃退、奔潰（變態測試）

7.3 app運行時撥打或接聽電話、發送信息、接收郵件、啟動相機等有何提示

7.4 2G、3G、4G、WIFI網路下app響應速度

7.5 網絡不好時，提交數據是否一直處理提交中，是有有延遲，提交失敗是否有提醒

7.6 有網到無網再到有網時，提交數據、做操作是否正常加載

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

1.入隊（默認可以自由組隊）

-被邀請

-被邀請人狀態

-不在同一個地圖、GS上

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

-不在線、傳送

-處于別的玩家隊伍中

-處于系統隊伍中，如戰場

-被邀請后收到提示

-被邀請人做出選擇后的響應

-被邀請人沒有選擇時的響應

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

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

-被兩個、多個玩家邀請

-提示界面相關

-邀請別人

-邀請人狀態

-邀請人沒有隊伍

-邀請人已經組建了一個隊伍

-是不是隊長

-邀請人隊伍已滿

-邀請人隊伍未滿

-在玩家回應前，繼續邀請多個玩家

-發出邀請后

-對方未響應前，隊伍已滿

-對方未響應前，隊伍已解散

-對方拒絕邀請是否提示

-對方接受邀請時的提示

-申請入隊

-申請進入的目標隊伍狀態

-申請目標沒有隊伍

-申請目標隊伍人數已滿，是否繼續進入申請名單

-申請目標是隊長

-申請目標是隊員

-向多個隊伍發起申請

-申請目標（隊長）接到的響應

-隊長同意申請

-同意申請時，發起人已經離線

-同意申請時，發起人已有隊伍

-同意申請時，發起人已經切換地圖、GS

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

-同意申請時，隊伍人數已滿

-隊長拒絕申請

-發起人收到的提示

-其他隊員不可操作

-隊長能收到申請信息的數量

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

-申請界面相關 2.隊伍中（默認即時戰斗游戲）

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

-玩家的狀態，如HP、等級、職業等

-玩家的位置

-同一個地圖

-不同地圖、GS

-隊員上線/離線

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

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

-移交隊長

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

-移交后新隊長擁有的權限

-移交后原隊長的權限

-是否需要確認框提示

-確認框彈出后目標玩家離隊

-獎勵的分配方式

-擊殺獎勵，如EXP

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

-是否需要隊員參與擊殺

-每一個分配到的玩家得到的數值

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

-拾取獎勵

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

-是否需要隊員參與擊殺

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

-其他幾種分配方式

-戰斗關系

--具體需要考慮技能與PK規則相關

-隊伍界面相關

-其他功能

-任務共享

-隊伍聊天

-標記 3.離隊

-隊長解散/離開隊伍

-隊員離開隊伍

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

-離隊后需要檢查

-戰斗關系

-地圖上的位置標記

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

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

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

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

結果：

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

22.退還1元硬幣

23.退還5角硬幣

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

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

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

3.轉換成判定表：

4.設計測試用例

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

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

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

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

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

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

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

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

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

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

第四篇：手機鬧鐘測試用例

鬧鐘測試用例

1、基本功能測試：

用例名稱

用例編號

01

設計人

測試目標

基本功能：測試鬧鈴是否正常響起

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

點擊關閉鬧鈴

出現提示框詢問是否關閉

點擊是

鬧鈴關閉

點擊否

鬧鈴繼續響

用例名稱

用例編號

02

設計人

測試目標

基本功能：瀏覽網頁時，鬧鐘可以響起

前置條件

設定鬧鈴時間為17:00

步驟

操作描述

期望結果

瀏覽網頁時，鬧鈴時間到

主界面出現鬧鈴界面，鈴聲響起

點擊關閉鬧鈴

鬧鈴關閉，停留在網頁頁面

用例名稱

用例編號

03

設計人

測試目標

基本功能：輸入鬧鈴后，可以正常響起

前置條件

輸入鬧鈴時間為17:00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

點擊關閉鬧鈴

出現提示框詢問是否關閉

點擊是

鬧鈴關閉

點擊否

鬧鈴繼續響

用例名稱

用例編號

04

設計人

測試目標

基本功能：設置鬧鈴后，可以正常響起

前置條件

輸入鬧鈴時間為23:59

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

點擊關閉鬧鈴

出現提示框詢問是否關閉

點擊是

鬧鈴關閉

點擊否

鬧鈴繼續響

用例名稱

用例編號

05

設計人

測試目標

基本功能：設置鬧鈴時間后，可以正常響起

前置條件

輸入鬧鈴時間為00:00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

點擊關閉鬧鈴

出現提示框詢問是否關閉

點擊是

鬧鈴關閉

點擊否

鬧鈴繼續響

用例名稱

用例編號

06

設計人

測試目標

基本功能：輸入鬧鈴說明（漢字/英文/數字），鬧鈴響起時出現提示字

前置條件

輸入鬧鈴時間為17:00

步驟

操作描述

期望結果

鬧鈴時間到

鈴聲響起，主界面出現輸入的提示字

點擊關閉鬧鈴

出現提示框詢問是否關閉

點擊是

鬧鈴關閉

點擊否

鬧鈴繼續響

用例名稱

用例編號

07

設計人

測試目標

基本功能：設置鬧鈴重復，在重復日期可以響起

前置條件

輸入鬧鈴時間為17:00，重復為每天

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

點擊關閉鬧鈴

鬧鈴關閉

次日鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

點擊關閉鬧鈴

鬧鈴關閉

用例名稱

用例編號

08

設計人

測試目標

基本功能：鬧鈴響起后點擊重響

前置條件

輸入鬧鈴時間為17:00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

點擊重響

鬧鈴暫時關閉

五分鐘后

主界面出現鬧鈴界面，鈴聲繼續響起

點擊關閉鬧鈴

鬧鈴關閉

用例名稱

用例編號

09

設計人

測試目標

基本功能：鬧鈴設置成功后，關閉手機看時間到鬧鈴是否響起

前置條件

輸入鬧鈴時間為17:00

步驟

操作描述

期望結果

設置完成鬧鈴，關閉手機

手機關閉

鬧鈴時間到

鈴聲響起，出現關閉/重響提示

選擇重響

鬧鈴暫時關閉，五分鐘后再次響起

選擇關閉

出現時候開機提示

用例名稱

用例編號

設計人

測試目標

基本功能：編輯短信時，鬧鈴響起

前置條件

輸入鬧鈴時間為17:00

步驟

操作描述

期望結果

正在編輯短信，鬧鈴響起

短信模塊中出現鬧鈴界面

點擊重響鬧鈴

鈴聲暫停，繼續編輯短信

五分鐘后鈴聲再次響起

點擊關閉鬧鈴

鈴聲停止，繼續編輯短信

2、沖突測試：

用例名稱

用例編號

01

設計人

測試目標

沖突測試：鬧鈴響起時，拔出內存卡

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

拔出內存卡

若鬧鈴鈴聲來自內存卡則鬧鈴鈴聲停止

若鬧鈴鈴聲來自手機則鈴聲依然響

點擊關閉鬧鈴

出現提示框詢問是否關閉

點擊是

鬧鈴關閉

點擊否

鬧鈴繼續響

用例名稱

用例編號

02

設計人

測試目標

沖突測試：鬧鈴響起時，插入內存卡

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

插入內存卡

鬧鈴停頓幾秒后繼續響起

點擊關閉鬧鈴

出現提示框詢問是否關閉

點擊是

鬧鈴關閉

點擊否

鬧鈴繼續響

用例名稱

用例編號

03

設計人

測試目標

沖突測試：鬧鈴響起時，插入充電器

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

插入充電器

鬧鈴停頓幾秒后繼續響起

若鬧鈴鈴聲來自手機則鈴聲依然響

點擊關閉鬧鈴

出現提示框詢問是否關閉

點擊是

鬧鈴關閉

點擊否

鬧鈴繼續響

用例名稱

用例編號

04

設計人

測試目標

沖突測試：鬧鈴響起時，拔出充電器

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

拔出充電器

鬧鈴停頓幾秒后繼續響起

若鬧鈴鈴聲來自手機則鈴聲依然響

點擊關閉鬧鈴

出現提示框詢問是否關閉

點擊是

鬧鈴關閉

點擊否

鬧鈴繼續響

用例名稱

用例編號

05

設計人

測試目標

沖突測試：鬧鈴響起時，拔出充電器

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

拔出充電器

鬧鈴停頓幾秒后繼續響起

若鬧鈴鈴聲來自手機則鈴聲依然響

點擊關閉鬧鈴

出現提示框詢問是否關閉

點擊是

鬧鈴關閉

點擊否

鬧鈴繼續響

用例名稱

用例編號

06

設計人

測試目標

沖突測試：鬧鈴響起時，來電話但不接聽

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到，來電話

出現電話界面，鬧鈴暫時不響

掛斷電話

鬧鈴停頓幾秒后響起

點擊關閉鬧鈴

鬧鈴關閉

用例名稱

用例編號

07

設計人

測試目標

沖突測試：鬧鈴響起時，來短信

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到，來短信

顯示有短信，并且鬧鈴響起

點開短信

鬧鈴停止響起

退出短信

鬧鈴繼續響起

點擊關閉鬧鈴

鬧鈴關閉

用例名稱

用例編號

08

設計人

測試目標

沖突測試：鬧鈴響起時，來彩信

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到，來彩信

顯示有彩信，并且鬧鈴響起

點開短彩信

鬧鈴停止響起

退出彩信

鬧鈴繼續響起

點擊關閉鬧鈴

鬧鈴關閉

用例名稱

用例編號

09

設計人

測試目標

沖突測試：鬧鈴響起時，收到短信發送報告

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到，收到短信發送報告

顯示發送報告，并且鬧鈴暫停

退出發送報告

鬧鈴繼續響起

點擊關閉鬧鈴

鬧鈴關閉

用例名稱

用例編號

設計人

測試目標

沖突測試：鬧鈴響起時，收到彩信發送報告

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到，收到彩信發送報告

顯示發送報告，并且鬧鈴暫停

退出發送報告

鬧鈴繼續響起

點擊關閉鬧鈴

鬧鈴關閉

用例名稱

用例編號

設計人

測試目標

沖突測試：鬧鈴響起時，來電話接聽

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到，來電話

接聽電話，鬧鈴暫時不響

掛斷電話

鬧鈴停頓幾秒后響起

點擊關閉鬧鈴

鬧鈴關閉

用例名稱

用例編號

設計人

測試目標

沖突測試：鬧鈴響起時，來電話對方掛斷

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到，來電話

出現電話界面，鬧鈴暫時不響

對方掛電話，點擊顯示來電

鬧鈴依然停頓

退出顯示來電

鬧鈴繼續響起

點擊關閉鬧鈴

鬧鈴關閉

用例名稱

用例編號

設計人

測試目標

沖突測試：鬧鈴響起時，來電話接聽后對方掛斷

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到，來電話

接聽電話，鬧鈴暫時不響

對方掛電話

鬧鈴繼續響起

點擊關閉鬧鈴

鬧鈴關閉

用例名稱

用例編號

設計人

測試目標

沖突測試：鬧鈴響起時，插入耳機

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

插入耳機

顯示插入耳機提示，鬧鈴繼續響起

點擊關閉鬧鈴

鬧鈴關閉

用例名稱

用例編號

設計人

測試目標

沖突測試：鬧鈴響起時，拔出耳機

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

拔出耳機

顯示拔出耳機提示，鬧鈴繼續響起

點擊關閉鬧鈴

鬧鈴關閉

用例名稱

用例編號

設計人

測試目標

沖突測試：鬧鈴響起時，充電完成前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

此時充電完成屏幕上顯示充電完成提示，鬧鈴繼續響起

點擊關閉鬧鈴

鬧鈴關閉

用例名稱

用例編號

設計人

測試目標

沖突測試：鬧鈴響起時，低電量

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

此時手機電量低

屏幕上顯示手機電量低提示，鬧鈴繼續響起

點擊關閉鬧鈴

鬧鈴關閉

用例名稱

用例編號

設計人

測試目標

沖突測試：鬧鈴響起時，低電量自動關機

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

此時手機電量低自動關機

屏幕上顯示手機電量低自動關機，鬧鈴關閉，自動關機

用例名稱

用例編號

設計人

測試目標

沖突測試：鬧鈴響起時，長按關機鍵

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

此時長按關機鍵

屏幕上顯示是否關機提示，鬧鈴關閉，自動關機

用例名稱

用例編號

設計人

測試目標

沖突測試：鬧鈴響起時，拔出電池

前置條件

將鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現鬧鈴界面，并且鈴聲響起

此時拔出電池

鈴聲消失，非法關機

3、壓力測試：

用例名稱

用例編號

01

設計人

測試目標

壓力測試：設置多個鬧鈴

前置條件

將10個鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

進入鬧鈴設置界面

出現設置新鬧鈴

點擊設置新鬧鈴

出現設置新鬧鈴界面

一次設置多個新鬧鈴

鬧鈴設置成功，并且主界面顯示鬧鈴圖標

用例名稱

用例編號

02

設計人

測試目標

壓力測試：清空設置的鬧鈴

前置條件

將50個鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間未到

手機主界面顯示鬧鈴圖標

進入鬧鈴設置清空鬧鈴，退出鬧鈴設置

手機主界面鬧鈴圖標消失

用例名稱

用例編號

03

設計人

測試目標

壓力測試：設置多個鬧鈴同時響起

前置條件

將10個鬧鐘響起時間設定為17：00

步驟

操作描述

期望結果

鬧鈴時間到

主界面出現多個鬧鈴界面，并且鈴聲響起

點擊關閉鬧鈴

出現提示框詢問關閉當前界面/關閉全部界面

點擊關閉當前界面

有一個鬧鈴界面關閉，鈴聲依然響起

點擊關閉全部界面

退出鬧鈴界面，鈴聲停止

第五篇：測試用例設計步驟

測試用例設計步驟

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

1、測試需求分析

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

2、業務流程分析

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

從業務流程上，應得到以下信息：

A、主流程是什么

B、條件備選流程是什么

C、數據流向是什么

D、關鍵的判斷條件是什么

3、測試用例設計

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

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

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

適合的技術：由業務需求和設計說明導出的功能測試、等價類劃分

邊界測試：對某個功能的邊界情況進行測試。

適合的技術：邊界值劃分

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

可能發生的，類似這樣的情況需要書寫相關的異常測試。

適合的技術：由業務需求和設計說明導出的特殊業務流程、錯誤猜測法、邊界值

分析、內部邊界值測試。

性能測試：檢查系統是否滿足在需求中所規定達到的性能，性能主要包括了解程序的內外部

性能因素。內部性能因素包括測試環境的配置，系統資源使用狀況；外部因素包

括響應時間，吞吐量等。

適合的技術：業務需求和設計說明導出的測試

壓力測試：壓力測試又稱強度測試，主要是檢查系統運行環境在極限情況下軟件運行的能力，比如說給一個相當大的負荷或網絡流量給應用軟件兼容測試：測試軟件產品在不

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

4、測試用例評審

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

測試用例評審一般是由測試leader安排，參加的人員包括：測試用例設計者、測試leader、項目經理、開發工程師、其它相關開發測試工程師。測試用例評審完畢，測試工程師根據評審結果，對測試用例進行修改，并記錄修改日志。

5、測試用例更新完善

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