❶ 測試用例設計怎麼做怎麼設計一個好的測試用例
1，功能性設計：利用等價類劃分、邊界值等方法設計功能用例
2，性能設計：基於內測試功能 預估功能點容擊率或者pv、uv 設計性能測試用例
3，業務相關設計：基於測試功能所影響的上下文關系，設計邏輯測試用例
希望的回答能幫到你，謝謝。
❷ 如何設計一個完整的測試用例
測試用例的重要性是毋庸置疑的，它是軟體測試全部過程的核心，是測試執行環節的基本依據。測試用例編寫應該遵循的原則：
1、測試用例要達到最大覆蓋軟體系統的功能點。測試工程師應該測試計劃編寫完成之後，在開發階段編寫測試用例，參考需求規格說明書和軟體功能點對每個功能點進行操作上的細化，盡可能趨向最大需求覆蓋率。
2、測試用例對測試功能點、測試條件、測試步驟、輸入值和預期結果應該有準確的定義。
3、 測試用例的設計應包括各種類型的測試用例。在設計測試用例的時候，除了滿足系統基本功能需求外，還應該考慮各種異常情況、邊界情況和承受壓力的能力等。
4、 測試用例的管理。使用測試用例管理系統對測試用例進行管理。
一個好的測試用例應該具有較高的發現某個尚未發現的錯誤的可能性，而一個成功的測試案例能夠發現某個尚未發現的錯誤，通常一個好的測試案例有以下特性：
1、具有高的發現錯誤的概率
2、沒有冗餘測試和冗餘的步驟
3、測試是「最佳類別」
4、既不太簡單也不太復雜
5、案例是可重用和易於跟蹤的.
6、確保系統能夠滿足功能需求
測試用例不可能設計得天衣無縫，也不可能完全滿足軟體需求的覆蓋率，測試執行過程里肯定會發現有些測試路徑或數據在用例里沒有體現，那麼事後該將其補充到用例庫里，以方便他人和後續版本的測試。
二、如何編寫測試用例
測試用例的信息有很多，可以根據實際的情況進行增刪，一般來說一個優秀的測試用例應該包含以下信息：
1、產品相關信息
（1）軟體產品或項目的名稱
（2）軟體產品或項目的版本
（3）功能模塊名
（4）功能描述
（5）測試平台
這些信息建議可以在測試案例手工選擇。
2、基本記錄信息
（1）測試用例入庫者
（2）測試用例入庫時間
（3）測試用例更新者
（4）測試用例更新時間
這些信息建議可以由測試案例自動生成。
3、測試用例的屬性
（1）測試用例ID：測試用例的ID（由案例管理系統自動生成，方便跟蹤管理）
（2）測試用例名稱：測試用例的名稱
（3）測試功能點：測試的功能檢查點
（4）測試目的：該測試功能點的測試目的
（5）測試級別：主路徑測試、煙霧測試、基本功能測試、詳細功能測試。
下面對這幾個測試級別進行說明：
A、主路徑測試：對照需求中重要模塊和功能的最主要功能路徑，主路徑測試為設計探針模塊，快速檢查程序的可測試性（可測試性還包括安裝測試是否成功）的主要依據的測試案例
B、煙霧測試：對照需求中所有模塊的主要功能路徑，主路徑測試案例為煙霧測試案例的子集，煙霧測試為做回歸測試的主要依據的測試案例。
C、基本功能測試：對照需求和總體設計中所有模塊和功能的基本功能路徑，基本功能測試為測試軟體產品的非重要級別模塊，書寫完全的自動測試腳本的主要依據。
D、詳細功能測試：對照總體設計中所有模塊和功能的功能路徑，測試各個模塊及功能各個層次，各種類型。詳細功能測試案例為對重點模塊，易發生錯誤的模塊的主要依據。
（6）測試類型：功能測試、邊界測試、異常測試、性能測試、壓力測試、兼容測試、安全測試、恢復測試、安裝測試、界面測試、啟動/停止測試、文檔測試、配置測試、可靠性測試、易用性測試、多語言測試。
（7）預置條件：對測試的特殊條件或配置進行說明
（8）測試步驟：詳細描述測試過程，案例的操作步驟建議少於15個。
（9）預期結果：預期的測試結果
三、測試用例設計過程
對一個全新的產品來說，首先需要了解的是產品需求文檔和產品模塊之間的關系。然後需要從需求文檔中書寫與所有需求相對應的主路徑測試案例和煙霧測試案例，這個時候也同時會包括一定的基本路徑測試案例甚至是詳細測試案例。在這個時候，因為對產品沒有直接的使用感受，書寫測試案例要考慮面廣而不要太過精細。繼續閱讀產品功能定義文檔，將所有的功能定義直接對應寫相關的測試案例，這個時候，最好能夠對程序的本身有一定的接觸，加深對程序的了解，以便寫出更好，更全面的測試案例。最後，在實際測試中，還需要不斷擴充，修改以前的測試案例，得到完整的基本功能測試案例和詳細測試案例。
如果對於一個已有一定或大部分案例的產品來說，不管測試者是否本身熟悉這個產品，其主要的任務就是閱讀，檢查需求及相關的變更，然後對原有的案例進行理解，擴充和修改。這就是案例的重用/復用。
❸ 訂單查詢系統怎麼設計測試用例僅需大綱
？ 從拿到需求文檔不要立馬開始著手寫測試用例，需要仔細推敲整理需求，畫出系統級、模塊內流程圖，並找出各種測試點，等對需求進行了頭腦風暴般的整理之後，此時已對測試系統的功能很清楚了，再著手開始寫測試用例。那麼編寫測試用例的總體思路是什麼呢？通過半年的測試用例編寫經驗，總結如下，如有不妥之處需改進。 1、整理分析需求文檔 仔細將需求文檔文檔閱讀一遍，記錄不明白的地方及關鍵測試點，簡單畫出總體流程圖。然後再來一遍，仔細分析各個模塊的功能，畫出模塊內流程圖，找出所有功能，並列出主要測試點 2、編寫用例 按照不同的業務規則可將測試用例分為四部分：場景用例、系統用例、功能用例 場景用例：按照用戶的實際操作與業務邏輯設計用例，不必涉及很復雜的操作或邏輯，把用戶最常用的、正常的操作流程作為一個場景設計測試用例。 系統用例：是用戶場景的細化，包含正常場景、分支場景和異常場景，是兩個或多個有關聯的功能組合而成的場景。 功能用例：用於驗證各功能點的業務規則，包括界面元素和各功能的業務規則驗證。主要針對單個功能點。 第一步：場景用例（關鍵字：模擬用戶實際操作） 根據畫出的模塊內流程圖，描述用戶的主要業務目標，包含完整的系統級場景和模擬用戶實際操作的不同場景，幾個功能點的組合也算是用戶場景。 第二步：系統各角色的系統用例 結合畫出的模塊內流程圖，將系統劃分多個角色，再將每個角色分解為多個任務，每個任務就是一個系統用例。系統用例分別正常流程、異常流程，分支流程，以場景的形式描述。 第三步：功能用例 描述單點功能的邏輯規則及頁面元素，分層描述邏輯規則，對邏輯規則細化可直接作為用例的操作步驟描述。 編寫用例的過程中也有一些迷茫： 問題1：場景法用什麼方式描述比較清楚，並且後期需求改動了易維護？ 問題2：測試用例與測試數據的關系是什麼呢？如何將兩者區分開來？ 3、報表類功能模塊如何編寫測試用例？ 報表類的模塊基本沒有業務流，不適用場景法。其實報表類模塊主要驗證能否依據查詢條件正確查詢顯示數據，並保證數據的正確性。
❹ 黑盒測試中，商品購買一般怎樣設計測試用例進行測試
四個方面抄：購物車、配送方式、支襲付方式、提交訂單
購買數量的上下限，數量限制邏輯，批量增刪改、支付方式、支付成功|失敗的處理方式，回調地址是否正確，訂單狀態的變化，數據傳輸是否正確 等等，參照著需求（PRD）寫
❺ 淘寶購物車測試用例，淘寶購物車怎麼用
未登錄點擊購物車跳轉到登錄界面，登錄直接跳轉到付款界面
❻ 淘寶網上購物測試用例怎麼寫
寫一下你的使用感受就行了，贊一下這個寶貝的之類的