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