本篇文章給大家談談測試用例文檔模板，以及測試用例文檔模板包括哪些內(nèi)容對應的知識點，希望對各位有所幫助，不要忘了收藏本站喔。

本文目錄一覽：

• 1、如何寫測試用例
• 2、想快速又簡單地編寫測試用例？看這里！
• 3、軟件測試用例文檔怎么寫
• 4、各種測試用例簡要模板
• 5、如何編寫測試用例

如何寫測試用例

對各個功能模塊進行測試點分析，提取測試點再堆測試點進行用例編寫。

比如對PC端QQ賬號的登錄模塊，提取測試點就有：

①正常登陸；

②賬號為空時點擊登錄；

③密碼為空時點擊登錄；

④賬號密碼都為空時點擊登錄；

⑤密碼錯誤時點擊登錄 ；

⑥找回密碼功能是否有效；

⑦記住密碼功能是否有效；

⑧自動登錄功能是否有效。

編寫測試用例該注意：

①根據(jù)項目的實際情況設計測試用例表格；

②用例格式不要生搬硬套；

③根據(jù)具體情況編寫。

想快速又簡單地編寫測試用例？看這里！

本文適用對象

初級軟件測試人員，或想開拓思路拓展測試范圍、提高測試覆蓋率的所有測試人員等等。

本文目的

講述如何快速、簡單、有效、有條理地編寫一條測試用例，并幫助測試人員從測試用例角度拓展測試思路。

如何簡單、快速地

描述（編寫）一個測試用例

測試用例的目的在于指導、幫助測試人員按照既定的計劃步驟執(zhí)行測試，并比對測試結(jié)果與預期結(jié)果是否一致。

對于中大型軟件公司而言，測試用例的管理都有既定的規(guī)范和工具，如表格管理用例、測試管理軟件管理用例（如下圖1所示為MeterSphere測試管理軟件用例編寫頁面）等。

但總而言之，測試用例的內(nèi)容主要不外乎3個部分：前置條件、步驟、預期結(jié)果。

那么，對于沒有明確地測試管理軟件的小型軟件公司，或者對于測試人員而言，需要暫時快速地編寫一個測試用例或記錄測試過程的時候，可以怎么做呢？

推薦一個臨時性的用例編寫模板：GIVEN...WHEN…THEN。

讓我們套用GIVEN…WHEN…THEN的模式來描述下編寫用例的大致步驟：

有沒有覺得很簡單？

讓我們再用實際案例，描述下如何用GIVEN…WHEN…THEN模板編寫真實用例。以測試訪問 鏈接這個用例為例1：

使用GIVEN…WHEN…THEN能夠簡單呈現(xiàn)用例前置條件、執(zhí)行步驟和預期結(jié)果間的邏輯關系，并能清晰地表述一個用例。

那么，什么地方可以用GIVEN…WHEN..THEN這個模板呢？這個模板較之文檔用例更為簡潔，如下圖2所示，對于測試用例提交故障，闡述引發(fā)故障的操作方法或故障復現(xiàn)方法，以及故障修復后的驗證時都可以使用。

如何使用探索式場景聯(lián)想法

衍生測試用例

探索式測試更多的是一種測試風格和測試思想，要求測試人員在測試過程中不斷思考、發(fā)散思維，記錄、修改和更新測試方法和測試用例。

場景法則是要求測試人員認真分析測試需求，了解用戶使用場景，根據(jù)不同的場景進行測試。

而本文討論的 探索式場景聯(lián)想法，則是將探索式測試方法、場景法和聯(lián)想法相結(jié)合，在已有測試用例的基礎上衍生更多的測試用例。

那么，如何使用探索式場景聯(lián)想法衍生測試用例呢？

由上一節(jié)可知，測試用例是指導測試人員在xx預知條件（場景）下，執(zhí)行xx步驟，預期得到xx結(jié)論。

顯而可見，通過改變測試用例的預知條件和操作步驟，則可以衍生出不同的測試用例。而這些測試用例包含不同的測試場景和不同的測試步驟。

如下圖3所示，為探索式場景聯(lián)想法衍生測試用例的結(jié)構(gòu)腦圖。

改變前置條件

測試用例的前置條件基本包括：硬件資源和軟件系統(tǒng)兩個部分。

改變前置條件可以從這幾方面入手。

以上節(jié)的訪問 鏈接用例1為例，改變前置條件衍生新的測試用例。由于該用例的前置條件較簡單，改變前置條件只需改變?yōu)g覽器類型和版本即可。

由此，衍生的部分測試用例可如下所示：

改變操作步驟

改變用例操作步驟可以從以下幾方面入手：插入步驟、刪除步驟、改變步驟和重復步驟。

插入步驟

如圖3所示，插入步驟又可以分為插入相關聯(lián)步驟和不相關聯(lián)步驟。并在插入步驟中增加用戶輸入。

同樣以用例1為例，插入步驟衍生的測試用例可如下：

刪除步驟

刪除步驟可以分為刪除部分步驟或者刪除部分步驟中的部分操作。刪除部分步驟，又可以分為刪除關鍵步驟和非關鍵步驟。

例如，以例1為例，刪除關鍵步驟“點擊鍵盤回車鍵“衍生新的測試用例如下所示：

改變步驟

改變步驟主要涉及步驟順序的改變和步驟內(nèi)容的改變。當測試用例具有多個步驟，且步驟間具有關聯(lián)性和順序性的時候，改變步驟順序則會變得很有意義。改變步驟內(nèi)容主要是改變步驟中用戶的輸入（包括數(shù)據(jù)輸入、用戶操作等）。

以用例1為例，改變步驟內(nèi)容衍生的用例如下所示：

重復步驟

對于大多測試人員來說，衍生測試用例時更多關注點在于操作步驟的變化。

但是，對于不同的測試場景，重復相同的測試步驟，仍然具有很大的測試意義。重復步驟進行測試能夠挖掘不同前置條件（場景）下的故障，亦能挖掘軟件在多個重復步驟操作下潛藏的故障。

以用例1為例，重復步驟衍生的用例如下所示：

測試結(jié)論衍生測試用例

除了通過改變前置條件和操作步驟衍生測試用例外，還可以根據(jù)測試結(jié)論中的異常信息，逆推測試場景，衍生新的測試用例。

這個部分更多的需要測試人員掌握探索式測試方法，對測試過程中的軟件資源監(jiān)控信息、錯誤日志等保持警惕性，挖掘錯誤信息中的內(nèi)容，逆推產(chǎn)生錯誤信息的原因，構(gòu)建新的測試用例。

小結(jié)

本文闡述了一種可以在提交測試故障信息和驗證測試故障時使用的快速測試用例編寫模板，快速記錄測試場景、測試步驟等關鍵信息。

并在此基礎上，簡單講解了基于探索式場景聯(lián)想法的測試用例衍生方法，可以幫助測試人員借助已有的測試用例拓展新的測試用例，擴大測試范圍，提高覆蓋率，挖掘更多場景下的軟件故障。

轉(zhuǎn)自公眾號投稿：

軟件測試用例文檔怎么寫

用例編號、用例名稱、測試環(huán)境、前置條件、測試步驟、預期結(jié)果、實際結(jié)果

望采納

各種測試用例簡要模板

0 .? 文檔介紹

提示：請用戶根據(jù)項目的實際測試狀況，裁剪本測試用例模板。

0.1?文檔目的

?

0.2?文檔范圍

?

0.3?讀者對象

?

0.4?參考文獻

提示： 列出本文檔的所有參考文獻（可以是非正式出版物），格式如下：

[ 標識符 ]? 作者，文獻名稱，出版單位（或歸屬單位），日期

例如：

[ AAA ] ? 作者，《立項建議書》，機構(gòu)名稱，日期

?[ SPP-PROC-ST ] ? SEPG，系統(tǒng)測試規(guī)范，機構(gòu)名稱，日期

0.5?術語與縮寫解釋

縮寫、術語 解 釋

SPP精簡并行過程，Simplified Parallel Process

…

1 .? 接口－路徑測試用例

1 .1? 被測試對象（單元）的介紹

1.2 測試范圍與目的

1 . 3 測試環(huán)境與測試輔助工具的描述

1.4 測試驅(qū)動程序的設計

1.5 接口測試用例

接口A的函數(shù)原型

輸入/動作期望的輸出/相應實際情況

典型值…

邊界值…

異常值…

接口B的函數(shù)原型

輸入/動作期望的輸出/相應實際情況

典型值…

邊界值…

異常值…

…

1.6 路徑測試的檢查表

檢查項 結(jié)論

數(shù)據(jù)類型問題

（1）變量的數(shù)據(jù)類型有錯誤嗎？

（2）存在不同數(shù)據(jù)類型的賦值嗎？

（3）存在不同數(shù)據(jù)類型的比較嗎？

變量值問題

（1）變量的初始化或缺省值有錯誤嗎？

（2）變量發(fā)生上溢或下溢嗎？

（3）變量的精度不夠嗎？

邏輯判斷問題

（1）由于精度原因?qū)е卤容^無效嗎？

（2）表達式中的優(yōu)先級有誤嗎？

（3）邏輯判斷結(jié)果顛倒嗎？

循環(huán)問題

（1）循環(huán)終止條件不正確嗎？

（2）無法正常終止（死循環(huán)）嗎？

（3）錯誤地修改循環(huán)變量嗎？

（4）存在誤差累積嗎？

內(nèi)存問題

（1）內(nèi)存沒有被正確地初始化卻被使用嗎？

（2）內(nèi)存被釋放后卻繼續(xù)被使用嗎？

（3）內(nèi)存泄漏嗎？

（4）內(nèi)存越界嗎？

（5）出現(xiàn)野指針嗎？

文件I/O問題

（1）對不存在的或者錯誤的文件進行操作嗎？

（2）文件以不正確的方式打開嗎？

（3）文件結(jié)束判斷不正確嗎？

（4）沒有正確地關閉文件嗎？

錯誤處理問題

（1）忘記進行錯誤處理嗎？

（2）錯誤處理程序塊一直沒有機會被運行？

（3）錯誤處理程序塊本身就有毛病嗎？如報告的錯誤與實際錯誤不一致，處理方式不正確等等。

（4）錯誤處理程序塊是“馬后炮”嗎？如在被它被調(diào)用之前軟件已經(jīng)出錯。

…

2.? 功能測試用例

2 .1? 被測試對象的介紹

2 .2 測試范圍與目的

2. 3 測試環(huán)境與測試輔助工具的描述

2 .4 測試驅(qū)動程序的設計

2 .5 功能測試用例

功能A描述

用例目的

前提條件

輸入/動作期望的輸出/相應實際情況

示例：典型值…

示例：邊界值…

示例：異常值…

功能B描述

用例目的

前提條件

輸入/動作期望的輸出/相應實際情況

……

3.? 健壯性測試用例

3 .1? 被測試對象的介紹

3 .2 測試范圍與目的

3. 3 測試環(huán)境與測試輔助工具的描述

3 .4 測試驅(qū)動程序的設計

3 .5 容錯能力 / 恢復能力測試用例

異常輸入/動作容錯能力/恢復能力造成的危害、損失

示例：錯誤的數(shù)據(jù)類型…

示例：定義域外的值…

示例：錯誤的操作順序…

示例：異常中斷通信…

示例：異常關閉某個功能…

示例：負荷超出了極限…

4 .? 性能測試用例

4 .1? 被測試對象的介紹

4 .2 測試范圍與目的

4. 3 測試環(huán)境與測試輔助工具的描述

4 .4 測試驅(qū)動程序的設計

4 .5 性能測試用例

性能A描述

用例目的

前提條件

輸入數(shù)據(jù)期望的性能（平均值）實際性能（平均值）

性能B描述

用例目的

前提條件

輸入數(shù)據(jù)期望的性能（平均值）實際性能（平均值）

……

5 .? 圖形用戶界面測試用例

5 .1? 被測試對象的介紹

5 .2 測試范圍與目的

5. 3 測試環(huán)境與測試輔助工具的描述

5 .4 測試驅(qū)動程序的設計

5 .5 測試人員分類

類別特征

A類

B類

……

5.6? 用戶界面測試的檢查表

檢查項測試人員的類別及其評價

窗口切換、移動、改變大小時正常嗎？

各種界面元素的文字正確嗎？（如標題、提示等）

各種界面元素的狀態(tài)正確嗎？（如有效、無效、選中等狀態(tài)）

各種界面元素支持鍵盤操作嗎？

各種界面元素支持鼠標操作嗎？

對話框中的缺省焦點正確嗎？

數(shù)據(jù)項能正確回顯嗎？

對于常用的功能，用戶能否不必閱讀手冊就能使用？

執(zhí)行有風險的操作時，有“確認”、“放棄”等提示嗎？

操作順序合理嗎？

有聯(lián)機幫助嗎？

各種界面元素的布局合理嗎？美觀嗎？

各種界面元素的顏色協(xié)調(diào)嗎？

各種界面元素的形狀美觀嗎？

字體美觀嗎？

圖標直觀嗎？

…

6.? 信息安全性測試用例

6 .1? 被測試對象的介紹

6 .2 測試范圍與目的

6. 3 測試環(huán)境與測試輔助工具的描述

6 .4 測試驅(qū)動程序的設計

6 .5 信息安全性測試用例

假想目標A

前提條件

非法入侵手段是否實現(xiàn)目標代價－利益分析

……

假想目標B

前提條件

非法入侵手段是否實現(xiàn)目標代價－利益分析

……

7.? 壓力測試用例

7 .1? 被測試對象的介紹

7 .2 測試范圍與目的

7. 3 測試環(huán)境與測試輔助工具的描述

7 .4 測試驅(qū)動程序的設計

7 .5 壓力測試用例

極限名稱A 例如“最大并發(fā)用戶數(shù)量”

前提條件

輸入/動作輸出/響應是否能正常運行

例如10個用戶并發(fā)操作

例如20個用戶并發(fā)操作

…

極限名稱B

前提條件

輸入/動作輸出/響應是否能正常運行

…

8.? 可靠性測試用例

8 .1? 被測試對象的介紹

8 .2 測試范圍與目的

8. 3 測試環(huán)境與測試輔助工具的描述

8 .4 測試驅(qū)動程序的設計

8 . 5?可靠性測試用例

任務A描述

連續(xù)運行時間

故障發(fā)生的時刻故障描述

……

統(tǒng)計分析

任務A無故障運行的平均時間間隔（CPU小時）

任務A無故障運行的最小時間間隔（CPU小時）

任務A無故障運行的最大時間間隔（CPU小時）

任務B描述

連續(xù)運行時間

故障發(fā)生的時刻故障描述

……

統(tǒng)計分析

任務B無故障運行的平均時間間隔（CPU小時）

任務B無故障運行的最小時間間隔（CPU小時）

任務B無故障運行的最大時間間隔（CPU小時）

9.? 安裝 / 反安裝測試用例

9 .1? 被測試對象的介紹

9 .2 測試范圍與目的

9. 3 測試環(huán)境與測試輔助工具的描述

9 .4 測試驅(qū)動程序的設計

9 . 5?安裝 / 反安裝測試用例

配置說明

安裝選項描述是否正常使用難易程度

全部

部分

升級

其它

反安裝選項描述是否正常使用難易程度

附錄：評審意見

如何編寫測試用例

這邊有一些測試用例的一些原則：

1.系統(tǒng)頁面必須與照設計文檔一致.測試時須檢查的地方有:各頁面的列名,提示信息等文字描述是否存在錯別字.列寬長度是否合適,能否完全顯示輸入信息.(注意:頁面如出現(xiàn)有變量,則須對這些變更的正確性進行驗證)

2.測試基礎信息錄入，必填項必須測試數(shù)據(jù)錄入范圍，保證所有的信息能夠有效的錄入系統(tǒng)?？刹捎门R界值測試法

3.測試與業(yè)務有關的功能，必須包證輸入金額，日期格式正確，金額方向正確,。可采用先做業(yè)務，后做查詢的方法驗證

4.測試查詢功能時必須保證錄入查詢條件即可查出相應的正確結(jié)果.

5.流程測試應保證流程流向能按設計的流程圖走,如一個流程結(jié)束后才能出下個流程,這時應保證上個流程結(jié)束后才能出下個流程,而且上個流程的任務必須是結(jié)束狀態(tài).測試方法可以用列舉法,把所有的情況列舉出來后逐步測試.

6.對有可能引起糾紛的業(yè)務須重點測試,維護中心形象.(如:余額查詢,個人明細查詢結(jié)息等業(yè)務)

7.測試系統(tǒng)性能時應該制定性能測試計劃,出具性能測試報告.

測試用例文檔模板的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關于測試用例文檔模板包括哪些內(nèi)容、測試用例文檔模板的信息別忘了在本站進行查找喔。