背景說明
乙個系統可為其他系統提供能力或者直接為ui層提供資料，在設計系統測試方案時應考慮上游呼叫的各種場景，不僅考慮順利且正向思維操作的場景，還應逆向的場景。例如：人為操作造成的不合理資料、服務錯誤的呼叫、請求時由於網路等環境原因造成的異常。但在此之前，也應考慮系統本身穩定性和規範性，應從本身定義約束。定義自身規範，不僅可從一方面保證系統穩定，同時有了自身的介入規範更適用於多業務接入，而不是單獨承接某一上游。系統穩定和規範會規避後續更多的bug。換句話來說，使用契約式設計的方式，執行前條件必須滿足，引數不正確不可執行；執行中內部狀態必須不變；執行後結果必須保持一致。
在設計介面用例設計時，除實現功能外，應關注：冪等性、空校驗、流程節點限制、異常校驗。
01 冪等性
何為冪等性？
冪等為一數學概念，指使用相同引數重複執行，能獲取相同結果。換句話說，冪等性就是呼叫一次成功後，再次呼叫後仍返回原來結果，即使呼叫100次後結果都相同。
如何使介面冪等性？
首先引入乙個概念—唯一索引，一句話介紹：資料表中每個唯一索引對應的資料記錄只會有一條。當第一次呼叫生成唯一一條記錄時，再次呼叫時，介面內部應前置根據唯一索引進行查詢，如果發現存在記錄直接返回查詢結果，不進行後續操作。例如：呼叫建立支付單介面會建立一條支付單資料落入支付單資料表，我們定義呼叫方欄位a和呼叫流水標識欄位b為唯一索引，當然介面引數中包含這兩個字段。當再次呼叫介面時，會首先使用a引數和b引數進行查詢，當對應記錄已存在時，直接返回查詢結果。
為什麼要做冪等性校驗？
試想沒有冪等性校驗會怎樣，還以建立支付單為例，當上游乙個單子l準備建立支付單，第一次呼叫建立成功支付單p1，當觸發再次呼叫時：
如果資料表已建立唯一索引，則會插入資料失敗，介面丟擲異常，上游可能更是一臉懵逼。不僅僅是造成一條廢棄資料，上游可能只是想借助支付中心能力讓使用者完成支付，當已經建立對應支付單時只需返回結果讓使用者繼續完成支付操作即可。
如果資料表沒有唯一索引, 上游多次呼叫，單子l就會對應多個支付單，沒有了唯一關聯，試想如果單子l想查詢對應的支付單，結果返回多個當然不合理，又如，多個支付單是不是使用者就可以多次支付了？當單子l首次支付成功後應該對應哪個支付單置為支付成功呢？對後續針對支付單打款退款等操作影響更是將之大，造成資金混亂和不安全。從另一層面來說，當無數次呼叫，就要生成無數條資料，造成無數不必要資料或者說無效資料，增加系統壓力。
如何進行介面冪等性測試？首先，確認及檢驗一條資料的唯一標識組合：資料表根據建立唯一索引，介面引數中包含組合中的每個元素。
首次呼叫介面後，觀察返回結果，並根據唯一索引確定資料表中的資料已存在。
引數無任何改變時，再次呼叫，結果返回為首次呼叫的返回結果，且資料表不會生成新的記錄。
改變除唯一索引外其他引數(此引數對應資料表乙個字段)，再次呼叫，返回結果仍為首次呼叫結果，改變的引數值仍為首次呼叫的值。資料表不會插入新的記錄且記錄不會更改，重點關注呼叫引數中改變引數對應的字段仍為首次呼叫後的值，不會更新。
改變唯一標識中乙個元素對應的引數，再次呼叫，返回結果會生成新的一條記錄，且資料表生成一條新的記錄。
02 非空校驗 && 相容為空
非空校驗即對引數進行非空校驗，當引數為空時，介面會前置校驗提示錯誤，不繼續向下執行。
為何要做介面非空校驗？
增加系統穩定性，介面健壯性。假如介面未做非空校驗，向下執行在資料表建立一條資料，再對資料進行操作時由於引數為空無法完成。例如呼叫打款介面，引數打款金額不可為空。假如去掉前置非空校驗，首先會生成一條初始化狀態的打款單據，然後打款介面內部中有一套複雜的後續執行邏輯，轉入個人餘額、記賬、提現等，當真實和三方打款互動時，由於金額為空而報錯。可見，生成了一系列處於中間節點的髒資料，而且進行了許多無用的呼叫或執行。
如何判斷哪些需要進行非空校驗？
可根據系統本身功能、其他介面依賴情況、依賴下游介面引數判斷。具體來說，例如乙個簡單的積分充值介面，積分幣數量不可空。從系統本身來說，無充值數量此充值單據即無意義。而充值數量會作為積分消費、失效等介面呼叫的起始資料來源依賴。同時，積分充值本質為給使用者充值錢款，積分數量會轉化 為金額且向下請求支付中心進行資金流轉，而資金流轉功能限制金額不可為空。
除此之外，需注意對功能的嚴格定義，有些引數不可非空校驗且需相容為空。直接舉例，查詢支付方式介面，金額字段不是必傳字段，當介面內部對金額處理就需相容為空情況，當金額引數傳空時，呼叫此不可報錯。
如何進行具體測試？明確哪些引數為必傳，哪些為非必傳。
對非空引數依次傳空，觀察介面呼叫情況。
當然，首先需明白業務邏輯，從而進行用例設計。尤其對於引數複雜的介面，當某一條呼叫規則下 某些非空引數就需要作為必傳了。
03 流程節點限制
流程節點限制，即需嚴格遵守流程流轉。當呼叫某就流程時，必須由上一節點呼叫。
為何需做流程節點限制？
支付單系統的流程為流程1：建立、支付完成、支付後的使用，流程2：建立、取消。如果目前支付單據為建立狀態，對其呼叫支付後的使用介面，會導致巨大功能問題。如果對支付完成的支付單據進行取消操作，邏輯也不合理，產生問題。故系統需在介面內部前置作流程節點限制。
如何做流程節點限制測試？
明確系統的狀態流轉，乙個系統設計初期就需明確功能及狀態流轉，會依據產品對系統的定義及依賴的下游或三方產品的功能。
測試正常流程節點。按照正向流程依次呼叫，觀察呼叫結果及生成狀態。呼叫建立介面，呼叫成功且生成單據狀態為建立， 再使用此單據進行完成介面的呼叫，觀察呼叫結果及生成狀態。然後再進行下一介面呼叫。
測試不合理流程節點下的呼叫，包含單一流程和交叉流程，觀察介面返回及資料狀態。例如單據狀態為建立時呼叫使用介面，單據狀態為完成時呼叫取消介面。首先需觀察資料表中單據並未作任何更新，再觀察介面並不會出現呼叫級別的錯誤，最後觀察介面返回資訊，提示"xx狀態不可進行xx呼叫"。
04 異常校驗
為何做異常校驗？
確保主功能可使用，不讓非主功能異常影響主功能。且會出現介面內部未校驗異常，後續功能不可實現的情況。異常可大致分為三種：環境異常，即非強依賴的服務異常時，應過濾掉此服務繼續向下執行。例如收銀台查詢支付方式介面內部實現為，先查詢出支付方式為列表1，然後會將列表1請求風控介面再次過濾得到支付方式列表2。生產環境中如果出現請求風控超時或者服務異常等情況，而查詢支付方式並未相容此異常情況，會直接系統報錯導致使用者無法支付。而如果查詢支付方式介面相容了請求風控服務異常，會直接返回支付列表1，讓使用者繼續支付。
資料異常，當資料值異常時，無法實現功能或者向下執行。例如必須為整數情況不可傳入小數，又如積分充值介面需對積分充值數量限制為匯率的整數倍，如果不進行此校驗，當執行到錢款流轉時，會出現比1分還小的值，導致無法進行。又如，當使用者可用支付方式匹配為0條時，應展示出缺省的一通道，讓使用者可支付。
前置條件異常：舉例來說，通過支付單打款，需對支付可用金額校驗，當打款金額大於支付單可用金額應直接前置提示，不可向下執行。
如何測試異常場景？首先深入了解業務特點和系統流轉，判斷哪些異常場景需要進行測試。
通過關閉下游服務構造環境異常和手動構造其他異常場景進行測試。
介面冪等性設計
在系統中，乙個介面執行多次，與執行一次的效果是一致的 冪等性的核心思想 通過唯一的業務單號保證冪等 update自身帶鎖。直接update不會出現併發修改問題。樂觀鎖是先查詢在修改 update 商品表 set 庫存 庫存 購買量 version 查詢version值 1 where version...
關於介面冪等性的設計
關於支付相關，訂單相關以及一些涉及費用的操作在業務上都是要求介面具有冪等性的。否則在高併發的場景下，同一筆交易請求多次，則會造成損失，這是不可忽視的錯誤。例如一筆訂單，因為網路或者操作的原因，造成同時發起了兩次申請。一般的介面設計中，對於重 起的交易都是先查詢是否存在這筆訂單，如果不存在，則繼續進行...
介面的冪等性怎麼設計？
一 什麼是冪等?看一下維基百科怎麼說的 冪等性 多次呼叫方法或者介面不會改變業務狀態，可以保證重複呼叫的結果和單次呼叫的結果一致。二 使用冪等的場景 1 前端重複提交 使用者註冊，使用者建立商品等操作，前端都會提交一些資料給後台服務，後台需要根據使用者提交的資料在資料庫中建立記錄。如果使用者不小心多...