API代表應用程序編程接口。它是通用的軟件實用程序，可以接受輸入參數并根據特定的業務邏輯提供所需的輸出。當我們談論API開發時，該過程需要在安全性，業務邏輯處理，有效的輸入數據參數，數據類型等方面進行嚴格的測試。如果未對任何API進行徹底的測試，則該API將存在缺陷。問題以及這些問題可能導致合作伙伴應用程序出現故障，甚至可能導致整個生命周期中的安全漏洞。
API測試期間的9個常見錯誤：
行為不當：
通常會觀察到，當使用一組必需的輸入參數對API進行單獨測試時，API可以正常工作;但與合作伙伴(例如web前端)集成時，API會開始出現異常和故障。這是因為合作伙伴可能正在為某些必填字段發送“ NULL”值，這在集成模式下可能很難弄清楚。它有一個簡單的解決方案，即在測試期間，我們應該具有測試用例來涵蓋當API收到“ NULL”或錯誤的條目作為輸入參數時的行為。API應該使用適當的錯誤消息將響應發送回合作伙伴，在該錯誤消息中，API可以指出來自合作伙伴應用程序的輸入數據不正確并且API可以正常工作。
無效的回應：
API響應可能像HTTP 200代碼一樣成功，也可能像404一樣失敗，即找不到資源。有時，從API返回的格式對于伙伴應用程序來說是不可消化的，因為它的字段數可能有所不同。測試解決方案非常簡單，應明確定義成功和失敗響應消息的響應字段數，并應在所有類型的API響應中進行一致的測試。
緩存API響應：
API充當黑匣子，接受輸入參數并針對觸發的所需業務功能提供響應。合作伙伴應用程序可以選擇為相同的重復輸入參數集緩存來自API的輸出響應。現在，如果對于相同的輸入參數，API的輸出頻繁變化，則在伙伴應用程序處緩存的輸出結果將過時并傳達不正確的信息。它有一個簡單的解決方案，盡管API可以按預期工作，但是合作伙伴應用程序必須決定他們需要緩存什么結果，什么不需要緩存。如果結果像實時數據一樣頻繁地從API更改，則不應該進行緩存，但是如果預期不會頻繁更改的任何結果(例如產品圖像，說明等)可以緩存在合作伙伴應用程序中。
處理錯誤的負面回應：
當HTTP通過200返回響應時，API被認為是成功的，但這種響應也可能具有NULL值，這是False 的情況。盡管合作伙伴應用程序將讀取成功等響應，但是響應中的那些NULL值對它們有意義嗎?這是要求實際測試覆蓋率以防止誤報的地方。
團隊溝通失敗：
隨著API根據用戶體驗和業務變化而增長，API維護變得非常重要。這是需要最佳團隊溝通的地方。不會發生API更改，它已經開始影響所有合作伙伴應用程序。對API或合作伙伴應用程序的任何形式的更改都應進行良好的溝通，實施，集成和測試。此外，應不時更新標準接口API文檔的版本，以避免開發人員的任何不良開發實踐。
非標準編碼方式：
API開發團隊應該在輸入參數和輸出響應參數方面就特定的標準方法達成一致，并且任何與該標準的偏差都應直接導致API拒絕輸入或合作伙伴應用程序拒絕。有時，開發人員接受空白或null作為輸入或輸出伙伴，這可能會導致長期問題。應當明確定義數據類型，強制性或非強制性，范圍，閾值等，并且測試應針對此類標準對API進行測試，并且以任何方式完全不接受與此類標準的任何偏差。
確保字符集：
API應該為輸入和輸出參數指定可接受的字符集，例如ASCII，Unicode等。這是為了確保合作伙伴應用程序正在與API交互以獲取約定的字符集，并且接收到超出約定范圍的任何字符，從而導致直接拒絕。另外，應事先同意使用英語，法語，西班牙語等語言作為回應。我們的測試用例應滿足對字符集和語言的所有此類要求。
API與合作伙伴應用程序的兼容性：
建立API時要牢記合作伙伴應用程序的兼容性。來自API端或合作伙伴應用程序端的任何發行版都應在添加到API或合作伙伴應用程序的新功能之上，針對所有現有測試用例進行回歸測試。換句話說，API或合作伙伴應用程序的所有發行版都應始終符合兼容性標準。
使用你的測試技能：
API可能有許多隱藏的問題，這些問題實際上可以通過經驗豐富的測試團隊擁有的測試技能來揭示。建議測試人員執行負面方案，以發現傳統測試實踐無法發現的缺陷。測試人員可以進行猴子測試來破壞API，這將為開發人員提供很大的空間來編寫高效，強大且智能的API。
結論：
在API測試中，如果沒有正確編碼和測試，則對于任何API都是不可避免的缺陷。它要求測試人員設計高效的測試用例，避免本文所述的常見錯誤，并利用他們的測試技能，以便為生產提供高效且經過良好測試的最終產品。
以上內容為大家介紹了API測試期間的9個常見錯誤，本文由多測師親自撰寫，希望對大家有所幫助。