文章目錄

• 總目錄
• 業務流程測試
• • 用例設計主要問題
  • 目標
  • 1、狀態遷移法
  • 2、訂單測試
  • 3、業務流程測試
  • • 3.1 流程圖介紹（復習）
    • 3.2 繪制流程圖
    • 3.3 業務流程測試
    • 3.4 業務流程測試用例設計
    • 3.5 測試團隊中體現專業價值，個人價值
  • 4、tpshop業務流程測試
  • • 4.1 繪制tpshop下單流程
    • 4.2 繪制tpshop發貨流程
    • 4.3 設計tpshop業務流程測試用例
  • 總結
  • 作業說明

總目錄

測試開發系列（功能+接口+性能+自動化）

業務流程測試

用例設計主要問題

主要問題存在于：

• 測試點分析：

  邏輯性不強對于整個頁面功能劃分不清晰；不同測試點歸類不清晰；不能形成相對固定的套路，書寫耗費大量時間...

• 測試用例：

  關于，要細致到什么程度，不太明確對于UI效果等的檢查也要寫進初次測試的用例嗎？

• 測試用例設計時是依據需求說明書還是系統？

+ 流程規范的公司，一定是基于需求說明書（或原型圖）來設計測試用例+ 進入項目的時間節點來看+ 項目初期介入，依據**需求**說明書+ 項目中后期介入，依據還是**需求**說明書+ 有可能在實際測試過程中，沒有需求說明書，可以參考當前的系統，同時需要結合自身測試經驗進行結果的甄別+ 項目維護階段介入，依據**需求**說明書+ 有可能在實際測試過程中，沒有需求說明書，可以參考當前的系統、用戶手冊、bug清單等

4、這個用例沒啥問題 就是時間問題 沒寫完

測試數據：

• 注意測試數據的時效性（測試準備）
  • 如注冊時的手機號在第一次注冊時是未注冊的，第二次再注冊時就變為已注冊了，所以不是特定的數據場合下，我們可以省略這些測試數據。
• 標題與預期結果要明確
  • 注意：如果需求中沒有說明類似的錯誤提示消息，我們應該借助于其他同類型產品的處理方案或消息來設置用例的預期結果。

測試標題：

• 直接點明測試的目的

• 簡明扼要，不要太冗長

  • 比如異常類測試時，重點關注導致異常的條件即可，（其他正確參數可以放在預置條件里面、實際工作中約定的規則下可以不寫其他正常的參數）
  • 如果是正常類測試時，可以依據有效等價類的類別（如登錄時，qq、手機號、郵箱等）來細分設計測試用例

• 標題一般來說不重復

優先級：

目標

• 掌握狀態遷移法的使用
• 掌握訂單的狀態測試
• 掌握流程圖主要元素及畫法
• 能夠繪制tpshop下單及發貨流程圖
• 掌握tpshop業務流程測試用例的編寫

1、狀態遷移法

• 概念：

  • 基于系統中模塊或節點之間的狀態。來描繪狀態與狀態之間的關系，從而找到狀態之間轉化的路線設計測試用例的一種方法。

• 適用場景

  • 需要針對復雜業務場景設計測試用例時

• 使用步驟：

• 找出系統所有的節點

• 繪制狀態遷移圖

• 繪制狀態遷移樹

• 找出狀態之間的轉換路徑

• 案例分析——飛機售票系統

飛機售票系統： （1）客戶向航空公司打電話預定機票，此時機票信息處于【預定】狀態。 （2）顧客支付了機票費用后，機票信息變為【已支付】狀態。 （3）旅客當天到達機場，拿到機票后，機票信息變為【已出票】狀態。 （4）登機檢票后，機票信息變為【已使用】狀態。 （5）在檢票之前任何時間都可以取消自己的訂票信息，取消后，訂單信息處于【已取消】狀態。

明確狀態節點:【預定】、【已支付】、【已出票】、【已使用】、【已取消】

繪制狀態遷移圖

繪制狀態遷移樹

抽取測試路徑設計用例

路徑1：預定==》已支付==》已出票==》已使用

路徑2：預定==》已取消

路徑3：預定==》已支付==》已取消

路徑4：預定==》已支付==》已出票==》已取消

2、訂單測試

需求說明： 1.用戶在網站完成下單后，訂單狀態為“等待付款” 2.用戶完成付款后，訂單狀態變為“待發貨” 3.管理員對訂單進行確認并發貨后，訂單狀態變為“待收貨” 4.用戶收到商品后，在系統中進行確認收貨，訂單狀態變為“待評價” 5.用戶使用商品后，對商品進行評價，評價提交后，訂單狀態變為“已完成” 6.商品發貨前，用戶可以對訂單進行取消操作，取消后訂單狀態變為“已取消” 7.用戶付款前，管理員可以認定訂單無效，此時訂單處于“已作廢”狀態

找出流程節點與狀態

【等待付款】、【待發貨】、【待收貨】、【待評價】、【已完成】、【已取消】、【已作廢】

繪制狀態遷移圖

繪制狀態遷移樹

找到狀態之間轉換的所有路徑

路徑1：【等待付款】》【待發貨】》【待收貨】》【待評價】》【已完成】

路徑2：【等待付款】==》【已作廢】

路徑3：【等待付款】==》【已取消】

路徑4：【等待付款】》【待發貨】》【已取消】

3、業務流程測試

3.1 流程圖介紹（復習）

流程圖：

流程圖是對過程、算法、流程的一種圖像表示，在技術設計、交流及商業簡報等領域有廣泛的應用。 通常用一些圖框來表示各種類型的操作，在框內寫出各個步驟，然后用帶箭頭的線把它們連接起來，以表示執行的先后順序。用圖形表示算法，直觀形象，易于理解。有時候也被稱之為輸入-輸出圖。

• 橢圓：開始/結束
• 箭頭：路徑，流程的走向
• 平行四邊形：數據的輸入/輸出
• 長方形：處理/步驟/過程
• 菱形：判定/判斷

3.2 繪制流程圖

繪制原則：

• 不要漏掉流程路徑
• 現有判斷，再有判斷結果
• 推薦講主業務流程放在最中間，便于閱讀

案例1：ATM取款流程

案例2：缺陷管理流程

3.3 業務流程測試

• 業務流程測試的關注點：

  • 關注點在核心業務是否能夠跑通

• 重點不是關注單個功能模塊的細節點

• 業務流程測試的價值：

  • 客戶角度：對客戶最有價值的是業務的實現，不是單功能模塊的質量
  • 測試人員角度：分配任務往往是針對功能模塊劃分，業務流程的測試容易遺漏

• 進行業務流程測試的時機

  • 上線前進行業務流程測試的確認

  • 單功能模塊基本可用的情況下，盡早進行（冒煙測試）

3.4 業務流程測試用例設計

• 需求分析，明確流程
• 畫出流程圖
• 編寫測試用例，一條路徑對應一條測試用例
  • 路徑比較多時，可以對所測業務路徑設置優先級

3.5 測試團隊中體現專業價值，個人價值

• 熟悉項目階段，畫出組織架構圖，展現工作成果
• 進入項目，進行一段時間的測試之后，畫出項目的業務流程圖
  • 體現個人對項目業務的深入理解
  • 業務流程圖可以作為整個團隊的知識積累

4、tpshop業務流程測試

4.1 繪制tpshop下單流程

4.2 繪制tpshop發貨流程

4.3 設計tpshop業務流程測試用例

• 前臺下單
  

• 后臺發貨
  

總結

• 掌握狀態遷移法的使用
• 掌握訂單的狀態測試
• 掌握流程圖主要元素及畫法
• 能夠繪制tpshop下單及發貨流程圖
• 掌握tpshop業務流程測試用例的編寫

作業說明

1.用xmind梳理今日知識點。 2.繪制tpshop業務流程圖，完成業務流程用例設計與執行、并提交缺陷。

總結

以上是生活随笔為你收集整理的功能测试Ⅷ——业务流程测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。