技術分享：冪等測試總結

冪等是什麼?

百度百科：

冪等(idempotent、idempotence)是一個數學與計算機學概念，常見於抽象代數中。

在編程中一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。冪等函數，或冪等方法，是指可以使用相同參數重複執行，並能獲得相同結果的函數。這些函數不會影響系統狀態，也不用擔心重複執行會對系統造成改變。例如，「setTrue()」函數就是一個冪等函數,無論多次執行，其結果都是一樣的.更複雜的操作冪等保證是利用唯一交易號(流水號)實現.

冪等來源於數學概念：

單目運算中，x為某集合中的任意數，f為運運算元，如果滿足f(x)=f(f(x))，那麼f運算就是冪等的。

冪等性是系統介面的一種承諾，承諾只要調用介面成功，多次相同的輸入會有相同的結果反饋和等同一次處理的影響力。聲明為冪等的介面會認為外部調用失敗是常態，並且失敗後必然會有重試。

簡單的說，冪等測試就是驗證數據一致性和事務完整性，通常我們會說防重放。

為什麼要做冪等測試?

用戶重複提交——非常容易發生，前端、後端均需要控制;

網路重發——容易遺漏，但有可能發生;

消息重發——容易遺漏，但有可能發生;

系統間重試——需要根據業務情況來判斷是否需要重試，哪些情況哪些系統需要重試;

所以說保證介面的冪等性是非常重要的。

怎麼做冪等?

在涉及資金的系統中，如：銀行、電商系統，冪等問題有著十分重要的地位，比如我們定義一個介面withdraw，

bool withdraw(accountId, amount)

withdraw的語義是從accountId對應的賬戶中扣除amount數額的錢;如果扣除成功則返回true，賬戶餘額減少amount;如果扣除失敗則返回false，賬戶餘額不變。

一種典型的情況是withdraw請求已經被伺服器端正確處理，但伺服器端的返回結果由於網路等原因被丟掉了，導致客戶端無法得知處理結果。如果是在交互設計或者前端展示上處理的不夠好，用戶會以為這次操作執行失敗，然後刷新頁面或者重複提交請求，這就導致了withdraw被調用兩次，賬戶也被多扣了一次錢。整個過程如下圖所示：

為解決此問題，需要對介面進行冪等性改造，增加一個唯一ID參數，如：

bool idempotent_withdraw(uniqId,accountId,amount)

這個ID需要全局唯一的標識一次請求，客戶端的同一個業務請求只有一個uniqId，服務端在收到請求後去檢查一下是否已存在這個 uniqId並且執行成功了，如果執行成功就不會再處理第二次的調用請求，如此就避免了重複扣款的問題。

總體而言，在技術實現上，控制冪等問題的關鍵在於唯一鍵 狀態機。

首先，調用者在請求中攜帶一個唯一ID，這個ID唯一的標識一個工作單元，這個工作單元只允許被成功執行一次。

其次，接受者在收到請求，獲得唯一ID時，要先去查詢這個ID所標識的工作單元是否被執行過。 檢查是否執行的邏輯通常是根據唯一請求ID ，在服務端查詢請求是否有記錄，是否有對應的響應信息，如果有，直接把響應信息查詢後返回;如果沒有，那麼就當做新請求去處理。

冪等測試關注點

(1)需要更多的關注業務性質和產品設計上，是否需要做到冪等，是時間維度的冪等還是空間維度的冪等;

(2)介面的冪等測試一定不能遺漏，由於冪等場景相對容易製造出來，冪等測試的難度遠遠小於並發測試，因此在做介面測試時不妨對每個介面都思考一下是否需要冪等，需要的話就測試一下其冪等性;

(3)業務場景，特別是涉及到資金流動的業務場景，對失敗重試機制一定要慎重;

(4)前端冪等測試，注意按鈕的多次快速點擊;

(5)後端冪等測試，就是介面的冪等測試，使用postman或jmeter多次發送同一參數的請求，查看服務端響應。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！