重新編程未來：人工智能如何重新定義開發(fā)人員和語言
3. 負(fù)載測試
負(fù)載測試用于查看 API 可以處理多少個(gè)調(diào)用。此測試通常在特定單元或代碼庫完成后執(zhí)行，以確定理論解決方案在給定負(fù)載下運(yùn)行時(shí)是否也可以作為實(shí)際解決方案。
4. 可靠性測試
可靠性測試確保API能夠產(chǎn)生一致的結(jié)果，并且平臺(tái)之間的連接是可靠的。
5. 安全測試
API安全性測試嘗試驗(yàn)證 API 使用的加密方法以及訪問控制設(shè)計(jì)。它包括對資源訪問和用戶權(quán)限管理的授權(quán)檢查的驗(yàn)證。
6. 滲透測試
滲透測試建立在安全測試的基礎(chǔ)上。在這種類型的測試中，API 會(huì)受到對軟件了解有限或一無所知的人的攻擊。這使得測試人員能夠從外部角度分析攻擊向量。滲透測試中使用的攻擊可以僅限于 API 的特定元素，也可以針對整個(gè) API。
7. 模糊測試
模糊測試強(qiáng)行將大量隨機(jī)數(shù)據(jù)（也稱為噪聲或模糊）輸入到系統(tǒng)中，試圖產(chǎn)生負(fù)面行為，例如強(qiáng)制崩潰或溢出。
8. 單元測試
單元測試是一種測試過程，其中對應(yīng)用程序的最小可測試部分（稱為單元）進(jìn)行單獨(dú)和獨(dú)立的檢查以確保正確運(yùn)行。對 API 進(jìn)行單元測試的過程包括使用單個(gè)請求測試單個(gè)端點(diǎn)。
9. 集成測試
集成測試是一種軟件測試，其中應(yīng)用程序的不同單元、模塊或組件作為組合實(shí)體進(jìn)行測試。由于 API 用于兩個(gè)或多個(gè)軟件之間的集成，因此集成測試會(huì)分析 API 如何集成軟件。
UI 測試對于驗(yàn)證 API 服務(wù)功能通常效率低下，并且通常無法涵蓋后端測試的所有必要方面。這可能會(huì)導(dǎo)致服務(wù)器或單元級別中留下錯(cuò)誤——這是一個(gè)代價(jià)高昂的錯(cuò)誤，會(huì)大大延遲產(chǎn)品發(fā)布，并可能需要重寫大量代碼。
API測試允許開發(fā)人員在UI 準(zhǔn)備就緒之前在開發(fā)周期的早期開始測試。任何在服務(wù)器層未生成適當(dāng)值的請求都不會(huì)顯示在 UI 層上。這使得開發(fā)人員能夠在現(xiàn)有錯(cuò)誤變得更嚴(yán)重之前消除至少一半的錯(cuò)誤。它還使測試人員能夠提出通過 UI 可能無法實(shí)現(xiàn)的請求——這是暴露安全缺陷的必要條件。
許多公司在其軟件應(yīng)用程序中使用微服務(wù)，因?yàn)樗鼈兛梢愿行У夭渴疖浖Ｈ绻麘?yīng)用程序的一個(gè)區(qū)域正在更新，其他區(qū)域可以繼續(xù)運(yùn)行而不會(huì)中斷。每個(gè)應(yīng)用程序部分都有一個(gè)單獨(dú)的數(shù)據(jù)存儲(chǔ)和用于與該數(shù)據(jù)存儲(chǔ)交互的不同命令。大多數(shù)微服務(wù)都使用 API；因此，隨著越來越多的企業(yè)采用微服務(wù)，API 測試將變得越來越有必要，以確保所有部分都能正常工作。
API 測試也是敏捷軟件開發(fā)不可或缺的一部分，其中即時(shí)反饋對于流程來說是必要的。在敏捷環(huán)境中，單元測試和 API 測試優(yōu)于圖形用戶界面 ( GUI ) 測試，因?yàn)樗鼈円子诰S護(hù)且效率更高。如果 GUI 測試想要跟上敏捷環(huán)境中頻繁變化的步伐，則通常需要進(jìn)行大量的返工。
總體而言，將 API 測試納入測試驅(qū)動(dòng)的開發(fā)過程可以使工程和開發(fā)團(tuán)隊(duì)在整個(gè)開發(fā)生命周期中受益。然后，這些好處會(huì)以改進(jìn)的服務(wù)和軟件產(chǎn)品的形式傳遞給客戶。
API測試保證平臺(tái)之間的連接可靠、安全和可擴(kuò)展。具體好處包括以下幾點(diǎn)：
· API 測試自動(dòng)化比自動(dòng)化 GUI 測試需要更少的代碼，從而加快測試速度并降低總體成本。
· API 測試使開發(fā)人員能夠在沒有 UI 的情況下訪問應(yīng)用程序，從而幫助測試人員在開發(fā)生命周期的早期發(fā)現(xiàn)錯(cuò)誤，而不是等待它們成為更大的問題。這可以節(jié)省資金，因?yàn)楸M早發(fā)現(xiàn)錯(cuò)誤可以更有效地解決。
· API 測試與技術(shù)和語言無關(guān)。數(shù)據(jù)使用JavaScript 對象表示法或可擴(kuò)展標(biāo)記語言進(jìn)行交換，并且包含 HTTP 請求和響應(yīng)。
· API 測試在分析應(yīng)用程序時(shí)使用極端條件和輸入。這有助于消除漏洞并保護(hù)應(yīng)用程序免受惡意代碼和破壞。
· API 測試可以與 GUI 測試集成。例如，集成可以在執(zhí)行 GUI 測試之前在應(yīng)用程序中創(chuàng)建新用戶。
雖然 API 測試帶來了各種好處，但它也帶來了挑戰(zhàn)。
API 測試中最常見的限制是參數(shù)選擇、參數(shù)組合和調(diào)用順序：
· 參數(shù)選擇需要驗(yàn)證通過 API 請求發(fā)送的參數(shù)——這個(gè)過程可能很困難。然而，有必要保證所有參數(shù)數(shù)據(jù)滿足驗(yàn)證標(biāo)準(zhǔn)，例如使用適當(dāng)?shù)淖址驍?shù)字?jǐn)?shù)據(jù)、指定的值范圍以及符合長度限制。
· 參數(shù)組合可能具有挑戰(zhàn)性，因?yàn)楸仨殰y試每個(gè)組合以查看其是否存在與特定配置相關(guān)的問題。
· 呼叫排序也是一個(gè)挑戰(zhàn)，因?yàn)槊總€(gè)呼叫都必須按特定順序出現(xiàn)，以確保系統(tǒng)正常工作。
API 測試的其他挑戰(zhàn)包括：
· 沒有可用于測試應(yīng)用程序的 GUI，這使得提供輸入值變得更加困難。
· 測試人員需要知道如何編碼。
· 每個(gè) API 在獨(dú)立測試時(shí)可能可以工作，但在測試整個(gè)應(yīng)用程序時(shí)可能無法一起工作。
· 測試時(shí)不包括 API 依賴項(xiàng)可能會(huì)導(dǎo)致軟件整體無法正常工作。
在執(zhí)行 API 測試時(shí)，開發(fā)人員可以編寫自己的框架，也可以從各種 API 測試工具中進(jìn)行選擇。設(shè)計(jì) API 測試框架使開發(fā)人員能夠自定義測試，因?yàn)樗麄儾幌抻谔囟üぞ呒捌洳寮墓δ堋y試人員可以添加他們認(rèn)為適合其所選編碼平臺(tái)的任何庫，構(gòu)建獨(dú)特的報(bào)告標(biāo)準(zhǔn)并將復(fù)雜的邏輯合并到測試中。然而，如果測試人員選擇設(shè)計(jì)自己的框架，則需要編碼技能。
API 測試工具提供用戶友好的界面和最少的編碼要求，使經(jīng)驗(yàn)不足的開發(fā)人員能夠部署測試。不幸的是，由于這些工具通常設(shè)計(jì)用于分析一般 API 問題，因此測試人員 API 的更具體問題可能會(huì)被忽視。
API 測試通?？梢詸z測如下軟件錯(cuò)誤：
· API可靠性問題。
· API 響應(yīng)時(shí)間。
· 重復(fù)的功能。
· 超出請求限制。
· 不兼容的錯(cuò)誤處理機(jī)制。
· 不正確的錯(cuò)誤和警告。
· 響應(yīng)數(shù)據(jù)結(jié)構(gòu)不正確。
· 缺少功能。
· 多線程問題。
· 安全問題。
· 未使用的標(biāo)志。
雖然 API 測試的用例是無窮無盡的，但這里有兩個(gè)測試示例，可以執(zhí)行這些測試來保證 API 產(chǎn)生適當(dāng)?shù)慕Y(jié)果。
當(dāng)用戶打開社交媒體應(yīng)用程序（例如 微博 或 小紅書）時(shí)，系統(tǒng)會(huì)要求他們登錄。這可以在應(yīng)用程序內(nèi)完成，也可以通過第三方（例如 微信 或 QQ）完成，這意味著社交媒體應(yīng)用程序具有與 微信 和 QQ 達(dá)成的現(xiàn)有協(xié)議，可訪問已提供給這兩個(gè)來源的一定程度的用戶信息。
然后，開發(fā)人員必須進(jìn)行 API 測試，以確保社交媒體應(yīng)用程序可以與 微信 和 QQ 合作，獲取必要的信息，從而授予用戶訪問該應(yīng)用程序的權(quán)限。
另一個(gè)例子是旅行預(yù)訂系統(tǒng)，例如 攜程 或 去哪。用戶希望能夠根據(jù)要求向他們顯示特定日期的所有最便宜的航班選擇。這需要應(yīng)用程序與所有航空公司進(jìn)行通信，以找到最佳的航班選擇——通過 API 完成。
因此，開發(fā)人員必須執(zhí)行 API 測試，以確保旅行預(yù)訂系統(tǒng)能夠與其他公司成功通信，并在適當(dāng)?shù)臅r(shí)間范圍內(nèi)向用戶呈現(xiàn)正確的結(jié)果。此外，如果用戶隨后選擇預(yù)訂航班并使用第三方支付服務(wù)（例如 易寶）進(jìn)行支付，則 API 測試必須保證支付服務(wù)和旅行預(yù)訂系統(tǒng)能夠有效地進(jìn)行通信、處理支付并保持用戶的敏感度。整個(gè)過程數(shù)據(jù)安全。
雖然有很多 API測試最佳實(shí)踐，但以下是一些最重要的實(shí)踐：
· 定義測試用例時(shí)按類別對其進(jìn)行分組。
· 將選定的參數(shù)包含在測試用例中。
· 為每個(gè)潛在的 API 輸入組合開發(fā)測試用例。
· 重用和重復(fù)測試用例以在整個(gè)生產(chǎn)過程中監(jiān)控 API。
· 使用手動(dòng)和自動(dòng)測試來產(chǎn)生更好、更值得信賴的結(jié)果。
· 測試 API 時(shí)，請注意哪些內(nèi)容一致發(fā)生，哪些內(nèi)容不一致。
· 使用 API 負(fù)載測試來測試系統(tǒng)的壓力。
· 在測試故障時(shí)，應(yīng)測試 API，使其始終失敗，以便隔離問題。
· 制定可靠的計(jì)劃來執(zhí)行呼叫排序。
· 通過優(yōu)先考慮 API 函數(shù)調(diào)用來簡化測試。
· 使用易于理解的高水平文檔，并盡可能自動(dòng)化文檔流程。
· 如果可能的話，使每個(gè)測試用例保持獨(dú)立并與依賴項(xiàng)分開。
更多相關(guān)內(nèi)容推薦：
60個(gè)API測試最佳實(shí)踐
全面指南：API測試定義、測試方法與高效實(shí)踐技巧
什么是API滲透測試？
語-API經(jīng)濟(jì).png)
