每個人都曾試圖在平淡的學習、工作和生活中寫一篇文章。寫作是培養人的觀察、聯想、想象、思維和記憶的重要手段。寫范文的時候需要注意什么呢？有哪些格式需要注意呢？以下是小編為大家收集的優秀范文，歡迎大家分享閱讀。

組隊測試用例樣式怎么設置篇一

在編寫測試用例過程中，需要參考和規范一些基本的測試用例編寫標準，在ansi/ieee829-1983標準中列出了和測試設計相關的測試用例編寫規范和模板。標準模板中主要元素如下。

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

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

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

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

? 輸出標準（output criteria）：標識按照指定的環境和輸入標準得到的期望輸出結果。如果可能的話，盡量提供適當的系統規格說明書來證明期望的結果。

? 測試用例之間的關聯：用來標識該測試用例與其它的測試（或其它測試用例）之間的依賴關系，例如，用例a需要基于b的測試結果正確的基礎上才能進行，此時需要在a的測試用例中表明對b的依賴性，從而保證測試用例的嚴謹性。

綜上所述，如果使用一個數據庫的表來表征測試用例的話，它應該有以下的格式：

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

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

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

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

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

|---------文件/頁面設置（1005）

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

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

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

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

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

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

測試用例設計考慮因素

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

? 測試用例設計時，要濃縮系統設計。

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

a）用戶登錄的功能設計規格說明書（摘選）

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

1． 用戶登錄

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

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

1．3用戶密碼使用掩碼號（*）來標識。

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

2． 登錄出現錯誤

當出現錯誤時，在頁面的頂部會出現相應的錯誤提示。錯誤提示的內容見3。錯誤提示是高亮的紅色字體實現。

3． 錯誤信息描述

3．1

3．2密碼為空

3，3用戶名/

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

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

b）通用安全性設計規格說明書（摘選）

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

1． 安全性描述

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

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

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

1．4ssl校驗：所有的站點訪問時，都必須經過ssl校驗。

2． 錯誤描述（略）

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

c）測試用例

結合相關的規格說明書，理解和掌握測試用例設計的關鍵點，測試用例設計如下表所示。

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

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

用戶登錄功能測試用例

完善的測試用例

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

組隊測試用例樣式怎么設置篇二

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

-被邀請

-被邀請人狀態

-不在同一個地圖、gs上

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

-不在線、傳送

-處于別的玩家隊伍中

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

-被邀請后收到提示

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

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

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

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

-被兩個、多個玩家邀請

-提示界面相關

-邀請別人

-邀請人狀態

-邀請人沒有隊伍

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

-是不是隊長

-邀請人隊伍已滿

-邀請人隊伍未滿

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

-發出邀請后

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

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

-對方拒絕邀請是否提示

-對方接受邀請時的提示

-申請入隊

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

-申請目標沒有隊伍

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

-申請目標是隊長

-申請目標是隊員

-向多個隊伍發起申請

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

-隊長同意申請

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

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

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

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

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

-隊長拒絕申請

-發起人收到的提示

-其他隊員不可操作

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

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

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

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

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

-玩家的位置

-同一個地圖

-不同地圖、gs

-隊員上線/離線

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

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

-移交隊長

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

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

-移交后原隊長的權限

-是否需要確認框提示

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

-獎勵的分配方式

-擊殺獎勵，如exp

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

-是否需要隊員參與擊殺

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

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

-拾取獎勵

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

-是否需要隊員參與擊殺

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

-其他幾種分配方式

-戰斗關系

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

-隊伍界面相關

-其他功能

-任務共享

-隊伍聊天

-標記 3.離隊

-隊長解散/離開隊伍

-隊員離開隊伍

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

-離隊后需要檢查

-戰斗關系

-地圖上的位置標記

組隊測試用例樣式怎么設置篇三

測試用例教案

綜合測試策略（萬金油）

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

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

第一講

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

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

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

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

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

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

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

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

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

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

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

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 有網到無網再到有網時，提交數據、做操作是否正常加載

組隊測試用例樣式怎么設置篇四

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

● 測試用例編號

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

系統測試用例：產品編號-st-系統測試項名-系統測試子項名-xxx

集成測試用例：產品編號-it-集成測試項名-集成測試子項名-xxx單元測試用例：產品編號-ut-單元測試項名-單元測試子項名-xxx

● 測試項目

◇ 規則：當前測試用例所屬測試大類、被測需求、被測模塊、被測單元等◇ 約定：

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

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

單元測試用例測試項目：被測試的函數名 如：測試函數int readfile(char *pszfilename)

● 測試標題

規則：測試用例的概括簡單的描述用例的出發點、關注點，原則上不能重復。● 重要級別

規則

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

低：實際使用頻率不高、對系統業務功能影響不大的模塊或功能的測試用例。● 預置條件

規則：執行當前測試用例需要的前提條件，是后續步驟的先決條件● 輸入

規則：用例執行過程中需要加工的外部信息，輸入、文件、數據庫等● 操作步驟

規則：執行當前測試用例需要經過的操作步驟，保證操作步驟的完整性。● 預期輸出

規則：當前測試用例的預期輸出結果，包括返回值的內容、界面的響應結果、輸出結果的規則符合度等

組隊測試用例樣式怎么設置篇五

測試用例設計步驟

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

1、測試需求分析

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

2、業務流程分析

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

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

a、主流程是什么

b、條件備選流程是什么

c、數據流向是什么

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

3、測試用例設計

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

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

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

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

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

適合的技術：邊界值劃分

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

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

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

分析、內部邊界值測試。

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

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

括響應時間，吞吐量等。

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

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

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

4、測試用例評審

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

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

5、測試用例更新完善

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