API測試最佳實踐 - 身份驗證

適用等級：高級

1. 概況

身份驗證一般被定義爲是對某個資源的身份的確認的活動，這裏面資源的身份指代的是API的消費者（或者說是調用者）。一旦一個用戶的身份驗證經過了，他將被受權訪問那些期待訪問的資源或API。

驗證（Authentication）- 指的是對API最終使用者的確認的活動。

受權（Authorization）- 指對那些驗證經過的用戶能所可以訪問的資源進行確認的活動。

2. 身份驗證的標準（Authentication Standars）

身份驗證的標準和技術太多了，好比，

2. 1 基於表單的驗證（Form Based）

基於Web/HTML的身份驗證一般適用HTTP Cookie。

2.2 Basic/Digest/NTLM身份驗證

這種身份驗證方式使用HTTP頭來鑑別用戶。

2. 3 WS-Security SAML and Username Tokens

基於SOAP/XML的身份驗證方式是經過在SOAP的消息頭傳遞憑證明現的，同時你也能夠對該憑證信息進行簽名或加密，固然這個過程不是必須的，可選的。

2.4 API關鍵字（API Key）

每個API的請求都包含一個惟一標識用戶的關鍵字。

2.5 OAuth 1.x/2 

基於HTTP的交互和工做流，受權對資源的使用，如API、Web等。

OAuth包括了一個間接進行身份驗證的步驟，可是並無宣佈這個驗證要如何進行。

 

當你的身份驗證以來於憑證或者關鍵字，而且經過HTTP傳輸，那麼你就要當心了。

所以爲了不潛在的攻擊者偷聽或竊取你得身份信息，你應該強迫本身使用HTTP/SSL而不是未加密的HTTP請求。

當你考慮測試API的身份驗證的時候，這方面有不少最佳實踐供你選擇。

這些最佳實踐除了與通用的測試管理相關，還有關於通身份驗證測試技術。

3. 集中而且安全存儲身份憑證信息

若是你的測試用例腳本包含用戶身份憑證信息或者包含訪問限制的令牌，那麼你就必須考慮集中存儲這些信息，而且可以使該信息被輕鬆及安全的修改，就算其餘人可以訪問你的測試腳本但也不見得就能讀取用戶的身份憑證或訪問令牌信息。另外，也要確保這些信息不會在日誌文件或者測試報告文件中出現：好比你有一個驗證用戶登錄的測試用例，那麼就別把用戶名和密碼都輸出來，至少得作些「手腳」掩蓋一下吧。

（我至今還沒發現哪一個項目組對於用戶名和密碼有轉義、加密或編碼的，能徹底遵照這條的請護住你的臉~~）

4. 像真實世界的用戶同樣進行身份驗證

不論是做爲演示，仍是測試環境作測試，都別建立超級用戶（超級用戶指權限很高的用戶）進行登錄或訪問關鍵字身份驗證（對於API接口來講）。若是按接下來的方式進行測試，那這種測試絕對是不可信的；沒有跟你的實際用戶同樣使用相同的身份驗證機制，就不能發現相應的問題，例如回話過時，未受權訪問錯誤，或者身份驗證流程自己存在的錯誤等。所以，若是具備可行性，請確保你對系統身份驗證的方式與現實中的用戶保持一致；千萬被給你的測試用例或腳本留下後門和隱患。

5. 考慮建立負面測試

你固然也要確保擁有一些身份驗證和受權驗證相關的測試用例。好比：

• 輸入無效的用戶名和密碼。
• 試圖在沒有身份憑證信息的狀況下訪問受保護的內容（或資源）。
• 嘗試使用無效的身份憑證或會話令牌。
• 鎖住一個帳戶，而後驗證這個鎖定邏輯或時間段被強制執行了。
• 嘗試經過不安全的信道發送（無效或非法）的憑證信息，如使用HTTP而不是HTTPS，未加密的的XML或JSON等等。

任何一個負面的測試用例，都應該驗證響應信息，或者返回報文裏所包含的響應的錯誤代碼，可是對於客戶來講沒啥有用的信息返回給他，所以他不能把系統怎麼地。例如，一個失敗登錄嘗試應該被粉飾一下，若是輸入的用戶名已經在系統中註冊過了。

6. 內心時刻想着設計關於身份驗證的測試用例

當你設計測試用例的時候，有若干技術可以使身份驗證相關的流程更加簡便：

• 模塊化你得測試用例 - 若是可行，把你每個流程裏的用來進行身份驗證的測試用例、代碼或腳本放到一個共享的測試腳本或測試用例李米娜，經過其餘的測試用例調用。這樣，你就能很容易的修改和維護，尤爲是底層的技術或需求變化的時候。
• 參數化環境配置 - 若是你的測試用例支持不一樣的測試環境，（dev/test/stagin/production/etc）- 確保你的測試用例很容就能在各環境之間切換。
• 使用數據驅動的技術 - 對於運行大量的用戶身份的測試用例，請使用數據驅動的技術（啥是數據驅動，不須要我解釋吧？簡單來講就是數據是變化，代碼邏輯是不變，你看到是傳入的數據和輸出的結果。）這麼作也是爲了在考慮訪問控制的狀況下全部的數據請求都被正確接收和處理。

7. 也別忘了跑跑性能與壓力測試

以上的任意一個測試用例都應該做爲負載測試跑一跑，確保一個API的身份驗證機制在極端壓力下依然正常工做（這也是黑客最經常使用的手段）。若是有問題，可能跟錯誤的線程管理有關，數據庫鏈接共享有關等等。若是（沒有若是）可能，考慮組合多種不一樣的身份驗證的測試用例，例如，爲了獲取很挫的錯誤信息，同時運行負面的身份驗證相關的測試用例以及受權相關的測試用例。