如何根據需求設計測試用例

如何根據需求設計？

測試

用例從拿到需求文件不要立馬開始著手寫測試用例，需要仔細推敲整理需求，畫出系統級、模組內流程圖，並找出各種測試點，等對需求進行了頭腦風暴般的整理之後，此時已對測試系統的功能很清楚了，再著手開始寫測試用例。那麼編寫測試用例的總體思路是什麼呢？通過半年的測試用例編寫經驗，總結如下，如有不妥之處需改進。

1、整理分析需求文件

仔細將需求文件文件閱讀一遍，記錄不明白的地方及關鍵測試點，簡單畫出總體流程圖。然後再來一遍，仔細分析各個模組的功能，畫出模組內流程圖，找出所有功能，並列出主要測試點

2、編寫用例

按照不同的業務規則可將測試用例分為四部分：場景用例、系統用例、功能用例

場景用例：按照使用者的實際操作與業務邏輯設計用例，不必涉及很複雜的操作或邏輯，把使用者最常用的、正常的操作流程作為乙個場景設計測試用例。

系統用例：是使用者場景的細化，包含正常場景、分支場景和異常場景，是兩個或多個有關聯的功能組合而成的場景。

功能用例：用於驗證各功能點的業務規則，包括介面元素和各功能的業務規則驗證。主要針對單個功能點。

第一步：場景用例（關鍵字：模擬使用者實際操作）

根據畫出的模組內流程圖，描述使用者的主要業務目標，包含完整的系統級場景和模擬使用者實際操作的不同場景，幾個功能點的組合也算是使用者場景。

第二步：系統各角色的系統用例

結合畫出的模組內流程圖，將系統劃分多個角色，再將每個角色分解為多個任務，每個任務就是乙個系統用例。系統用例分別正常流程、異常流程，分支流程，以場景的形式描述。

第三步：功能用例

描述單點功能的邏輯規則及頁面元素，分層描述邏輯規則，對邏輯規則細化可直接作為用例的操作步驟描述。

編寫用例的過程中也有一些迷茫：

問題1：場景法用什麼方式描述比較清楚，並且後期需求改動了易維護？

問題2：測試用例與測試資料的關係是什麼呢？如何將兩者區分開來？

3、報表類功能模組如何編寫測試用例？

報表類的模組基本沒有業務流，不適用場景法。其實報表類模組主要驗證能否依據查詢條件正確查詢顯示資料，並保證資料的正確性。可將測試用例分為功能點測試用例和報表資料正確性驗證。

如何根據需求設計測試用例

如何根據需求設計測試用例？從拿到需求文件不要立馬開始著手寫測試用例，需要仔細推敲整理需求，畫出系統級 模組內流程圖，並找出各種測試點，等對需求進行了頭腦風暴般的整理之後，此時已對測試系統的功能很清楚了，再著手開始寫測試用例。那麼編寫測試用例的總體思路是什麼呢？1 整理分析需求文件 仔細將需求文件文件...

根據需求設計測試用例

上篇寫了關於做測試之前要明確需求，這一篇講講在讀需求文件的時候，怎麼設計測試用例。我就我工作的這邊，需求文件就是一張張的表，剛開始測試的時候不知道表的意義何在，覺得看這些表太浪費時間了，沒有好好研究，好在亡羊補牢，為時不晚，其實所有的內容都蘊含在一張張的表裡。表中有表字段，表字段有取值範圍，我們的測...

這樣的需求如何設計測試用例

測試點 1.db查詢a標誌位成功清除 2.db查詢a標誌位清除後，不會影響到b c d e f g標誌位 邏輯 手動下架商品，可以清除a標誌位 商品賣完自動下架，也可以清除a標誌位 實現方式 某資料表的w欄位用來標識商品的 a b c d e f g 標誌位 w欄位的值 是十進位制 轉換成16進製制...