宜和購物項目流程：

我最近的項目做的是一個宜和購物電商的項目，主要包含了首頁、購物車、訂單管理、個人中心等模塊，我們客戶可以通過我們的首頁進行商品的選購并提交訂單，此時我們系統會調用創建訂單的接口，并創建一筆待支付的訂單，將訂單的數據落在訂單表中，然后客戶端可以發起支付，進行支付控件的喚醒和支付方式的選擇，在完成本筆訂單支付后，商家可以根據支付完成的狀態，進行快遞單號的錄入，這時候我們會調用三方物流的接口，對快遞進行追蹤，接下來就是訂單完成階段，訂單完成有兩個觸發條件，一個是客戶主動確認收貨，我們平臺將訂單修改為已完成的狀態，另一個是客戶沒有點擊，但是物流信息顯示已簽收，經過7*24小時之后，我們平臺會強制的將本筆訂單修改為已完成的狀態，就完成了本筆交易。在以上的流程中，我們測試工作的開展主要是分為幾個方向，第一個是關于功能性的校驗，比如在首頁做了一些關于商品的選購的功能，商品的展示和排序規則的校驗，以及商品的搜索和分類的功能測試；在支付階段做了一些支付控件的喚醒，支付渠道的唯一性選擇，涉及到優惠券的情況，我們也會對預付款金額的最優方案做了一些測試，在商品的確認收貨階段，功能方向主要做了確認收貨的功能處理，以及訂單評價的錄入等測試；此外還做了對應的接口測試，比如，創建訂單的接口、訂單查詢的接口、支付的接口，針對接口中的字段的必填、非必填、條件必填、依賴性型字段的入參類型以及長度做了接口功能的測試，其次，對整個交易鏈路進行分析，多接口的上下游場景進行組合，比如支付接口要依賴于訂單創建的接口成功/失敗/超時等場景，看下支付接口是否能完成支付，對調用下游系統的成功/超時/失敗的場景也要進行分析，針對每一種組合場景的落庫情況要進行數據比對，主要關注狀態的流轉，以及金額的邏輯對應關系?；旧衔覀冎暗捻椖渴亲隽艘陨蠋讉€方向的測試工作。

訂單的狀態轉換方面：來考慮，從訂單的生成，到待付款，到待收貨，到待評價，到訂單完成，最后到售后/退款，這幾個狀態來分析，還要結合后臺的數據跟數據庫表的數據來進行驗證。
訂單的生成方面：首先從用戶權限考慮，沒登錄的用戶無法生成訂單，只有登錄的用戶才可以進行購買操作:?一個訂單的生成也包括幾個方面，比如入口的測試，地址的編輯，積分、優惠券的使用規則，會員優惠，快遞，支付方式的選擇。

入口測試方面：可以從我們通過怎樣的操作進入支付頁面:
地址方面首先要區分之前有無地址，沒有地址的情況下我們要先創建地址，有地址的時候我們可以選擇其他的地址:
積分方面：我們要知道積分的兌換比例，以及積分的使用規則;
會員優惠：方面要知道有多少種會員，每種會員的優惠力度是怎樣的,我們要怎樣達到更高的會員
備注信息：的話要測試備注輸入框的合法性以及必須性
支付方式：支付方式我們要知道有哪些支付方式，是否可以組合支付，比如積分跟余額，優惠券跟余額，積分跟優惠券之類的組合是否可以使用

優惠券：還有一個需要詳細考慮的是優惠券方面的分析，從有無優惠券，到有哪些種類的優惠券，到每種優惠券的可用、不可用情況的分析，到不同種類的優惠券組合分析:比如滿減優惠券，一個無優惠券，?這個不用過多考慮，沒優惠券就是現實中沒優惠券，但是有優惠券的時候我們要考慮優惠券的分類，像通用滿減，品類滿減，專屬商品滿減，比如通用滿減券滿100減20,我們要分析什么時候是能用的，比如單件商品價格滿100,多件商品價格滿100,商品價格超過100,我們還要分析什么時候是不可用的，比如已使用過的優惠券我們是不可用的，后臺操作優惠券失效后我們也是不可用的，超過使用期限的優惠券也是不可用的，商品價格沒達到100的也是不可用的，這個是通用滿減優惠券的分析;品類優惠券的話我們不僅要考慮通用優惠券的所有情況，還要考慮商品是不是這個品類的，是的話才可以使用，不是這個品類的話品類輛減優惠券時不能使用的，專?屬商品滿減券情況類似，最后我們還要分析，如果我們有二種優惠券都有，-件商品價格滿100,商品同時是品類商品，專屬商品的情況，商品是品類商品，但不是專屬商品的情況，商品不.是品類商品，但是是專屬商品的情況,還要分析意見商品不是品類商品，不是專屬商品的情況，那我只有兩種優惠券的情況呢，我們也要一分析到;?無門檻券同理，之后，我們還要考慮滿減券跟無廣]檻券組合的情況，還有就是我有多張可用的優惠券，是否可以進行切換，我有可用的優惠券，但我不想使用是否可以選擇不使用優惠券，還有默認優惠券方式是否正確，這樣-?-分析下來思路就清晰了，也可以很好的避免遺漏現象的發生。

最后我們還要進行一次?弱網測試跟重復支付測試：
訂單生成之后要在后臺查看是否有這個訂單的數據，還要到數據庫表里面去查看是否有這個訂單的信息生成，盡量做到100%全覆蓋測試。待付款方面的話要考慮待付款的訂單能保存多久，什么時候會失效，比如般未支付訂單15分鐘未支付就會失效，訂單就會被取消，還有我們自已主動取消訂單要進行哪些操作之類的，如果取消訂單或者是付款成功，我們還需看看后臺的訂單是否也同步取消或增加,還要查看數據庫表的數據是否增加或者是刪除。

然后待發貨狀態，待收貨狀態，?已完成狀態，?售后/退款狀態都是比較簡單的，比如說查看訂單詳情，查看物流，復制訂單編號，聯系客服，確認收貨，刪除訂單,再次購買都是比較簡單的檢測點,其中要注意的是每個狀態下的退款中，請跟評價以及每種購買情況退款后的返還情況，退款申請跟評價里面有輸入柜的地方要測試它的合法性跟空值，照片上傳要測試照片的數量上:限跟照片格式還有照片是否必須上傳;然后就是退款后的返還情況分析，比如只用積分購買只返回積分，優惠券購買不返回優惠券，余額購買返還余額，組合購買之后.的退款返還情況:最后要記得前后端的數據檢查對比，以及數據庫表的檢查對比，避免前端操作了，后端沒有響應，發生重大bug。

項目中工作量最大的一部分/最難測的一部分
就是測試訂單的部分，要考慮各種優惠券，打折，組合消費等情況

印象深刻的bug1==》在計算優惠金額時要注意頁面的布局
服務器默認勾選了最大的優惠券500元。最大的優惠券在第二頁（在第一頁沒有顯示）?，F在想重新選擇優惠券時，進入優惠券頁面不進入滑動頁面，直接選擇優惠券100元。這時優惠券將金額累加起來了變成900。應該是100元。優惠券只能單個使用。（當時沒有復現原因，我將默認勾選的優惠券滑到了第一頁）。開發說布局只掃了第一頁。
測試的測試方法：第一次進來的時候選最底下的一個（第二頁），再回到提交訂單頁，再進入心上優惠頁選擇第一個，再返回到訂單頁看結果是否有累加現象。

印象深刻的bug2==》：在投保中我們可以客戶發起退單，后臺商戶可以發起退單，在我提交訂單時候當出現自動退單時，后臺沒有統計訂單數
原因：訂單的異常，不統計訂單數量，也不做冪等處理，導致訂單流失
解決方法：補償機制、再次發送訂單

總結

以上是生活随笔為你收集整理的软件测试中的“电商项目”讲解的全部內容，希望文章能夠幫你解決所遇到的問題。

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