隨著技術(shù)的進(jìn)步,我們對API的依賴也將變得越來越重要。現(xiàn)在你在互聯(lián)網(wǎng)上交流的一切都是通過API(應(yīng)用程序接口)傳輸?shù)摹?

在將它們集成到我們的技術(shù)中時,我們還必須考慮API測試。因為,如果我們考慮到它,我們的API和其他任何東西一樣,都需要根據(jù)各種質(zhì)量屬性進(jìn)行嚴(yán)格的評價。

我們不僅要嚴(yán)格注意功能需求,還要密切注意非功能需求。

API代表應(yīng)用程序編程接口。它是一個計算機(jī)接口,允許兩個獨(dú)立的軟件系統(tǒng)連接和共享數(shù)據(jù)。

例如,具有API的軟件系統(tǒng)具有其他軟件系統(tǒng)可以執(zhí)行的許多功能。

一個API解釋了可以提出的請求的類型、如何提出這些請求、我們需要使用的數(shù)據(jù)格式,以及兩個軟件系統(tǒng)之間的關(guān)系。

簡而言之,安全。

為了代替使用標(biāo)準(zhǔn)的用戶輸入和輸出,API測試使用軟件向API發(fā)送呼叫,接收生產(chǎn),并記錄系統(tǒng)的響應(yīng)。

由于API測試不關(guān)注應(yīng)用程序的外觀和感覺,API測試不同于圖形界面測試。相反,它主要側(cè)重于軟件架構(gòu)的業(yè)務(wù)邏輯層。

API測試的重要性還是優(yōu)勢?

1.語言證明

由于數(shù)據(jù)是使用XML和JSON交換的,所以任何語言都可以用于自動化,而不管開發(fā)應(yīng)用程序時使用何種語言。

因為XML和JSON通常是結(jié)構(gòu)化數(shù)據(jù),所以驗證是快速和穩(wěn)定的。還有內(nèi)置庫來幫助使用這些數(shù)據(jù)格式進(jìn)行數(shù)據(jù)比較。

2.界面獨(dú)立

在沒有用戶界面或與系統(tǒng)交互的情況下訪問應(yīng)用程序是API測試的一個顯著優(yōu)勢。換句話說,質(zhì)量保證測試人員可以執(zhí)行API測試,而無需事先了解軟件應(yīng)用程序。

這是一個很大的好處,因為它給質(zhì)量保證工程師提供了早期可見性的缺陷和錯誤,允許開發(fā)人員在損害圖形界面之前解決問題。

3.改進(jìn)測試覆蓋率

由于大多數(shù)API和服務(wù)都有規(guī)范,我們可以創(chuàng)建覆蓋率高的自動化測試,包括功能測試(快樂案例)和非功能測試。

4.能夠更快地釋放

用戶界面回歸測試套件通常需要8-10小時才能執(zhí)行。相反,與API測試相同的場景只需要1到2個小時。API測試也比UI測試更少。所有這些都使您能夠更快地發(fā)布API測試。

5.降低測試成本

API測試使我們能夠及早發(fā)現(xiàn)錯誤和缺陷,每當(dāng)你在早期發(fā)現(xiàn)錯誤時,你就可以省錢和節(jié)省時間。

6.方便與圖形界面集成

API測試支持高度可積測試。如果您打算在API測試之后運(yùn)行功能性圖形界面測試,這將更加有用。例如,易于集成將允許在啟動圖形界面測試之前在程序中引入新用戶。

7.測試核心功能

在執(zhí)行圖形界面測試之前,測試應(yīng)用程序的代碼級功能提供了對其總體構(gòu)建強(qiáng)度的早期評估。這有助于暴露在圖形界面測試中的一些小缺陷,這些缺陷可能會增長并變得更大。

核心訪問允許測試與開發(fā)同時運(yùn)行,促進(jìn)兩個團(tuán)隊之間的通信和協(xié)作。如果一個離岸質(zhì)量保證團(tuán)隊進(jìn)行API測試,這將特別有用。

8.API測試可自動化

我們可以使用許多工具包和框架來自動化API請求,使您可以構(gòu)建一個API測試自動化套件。

例如,在CI/CD時代,當(dāng)執(zhí)行部署或集成時,該套件可能會被連接,從而節(jié)省了測試應(yīng)用程序背后的整個API集的人力。

API測試類型

讓我們看看不同類型的API測試,以便更好地了解:

1.驗證測試

驗證測試是開發(fā)過程的最后階段之一,但它是我們需要執(zhí)行的最關(guān)鍵的測試之一。

我們通常在主開發(fā)過程的末尾執(zhí)行驗證測試,特別是在API的組成元素和功能被驗證之后。雖然許多其他測試側(cè)重于特定的代碼庫或功能,但驗證測試更被考慮。

驗證測試只是我們應(yīng)用于整個產(chǎn)品的一系列簡單的查詢。其中包括:

產(chǎn)品:  我們創(chuàng)造了正確的產(chǎn)品嗎?API本身是否是解決當(dāng)前問題的正確產(chǎn)品,是否存在任何實質(zhì)性代碼膨脹或特性蠕變,從而將原本精益和重點(diǎn)突出的實現(xiàn)推向了不可接受的方向?

行為: API訪問正確數(shù)據(jù)的方式是否正確?考慮到數(shù)據(jù)集的保密性和完整性要求,API是否獲得了過多的信息并正確地存儲了它?

效率: API是完成手頭任務(wù)的最精確、最優(yōu)、最有效的方式嗎?是否可以刪除或修改任何代碼庫以改進(jìn)整體服務(wù)?

這些問題可以驗證API是一個全面的解決方案.

它們是在根據(jù)一套既定標(biāo)準(zhǔn)開發(fā)出API之后進(jìn)行的,以確保正確的環(huán)境集成、遵守標(biāo)準(zhǔn)以及實現(xiàn)具體的最終目標(biāo)和結(jié)果。

最后,這個測試可以簡單地描述為對指定的用戶需求和標(biāo)準(zhǔn)的精確發(fā)展的保證。

2.用戶界面測試

雖然驗證和功能測試方法是相對普遍的,但UI測試更特別。用戶界面測試正是聽起來像是對API及其組件的用戶界面的測試。

這個測試涉及UI的功能,不管它是圖形化的還是依賴于命令行端點(diǎn)調(diào)用。

在許多方面,這與其說是對API的測試,不如說是對連接到API的接口和開發(fā)人員使用該接口的經(jīng)驗的檢查。

然而,雖然不是API的直接代碼欄測試,但這提供了一個非常通用的觀點(diǎn),即前端和后端的可用性和效率。

這就是為什么我們經(jīng)常使用UI測試來代替功能測試--在許多方面,它執(zhí)行相同的工作,盡管不那么全面,也不那么通用。

然而,在現(xiàn)代測試中,這是一種糟糕的技術(shù),而UI測試應(yīng)該完全局限于驗證UI本身的操作。

WebUI測試是這種類型測試的一部分,它側(cè)重于Web實例和它們所代表的API之間的端到端集成。雖然在線用戶界面測試是用戶界面測試的一個獨(dú)特的子集,但值得一提的是,它也包括在這一類中。

3.功能測試

功能測試是一種廣泛的測試方法,但它比驗證測試狹窄。功能測試只是對某些代碼庫函數(shù)的測試。

這些函數(shù)反過來描述特定的情況,以保證API在預(yù)期參數(shù)內(nèi)的功能,并檢查結(jié)果超出預(yù)期參數(shù)時是否正確處理了錯誤。

一個場景使得功能測試更容易傳達(dá).例如,假設(shè)我們的API通過互聯(lián)網(wǎng)網(wǎng)關(guān)處理音樂訂購。

當(dāng)一個人在尋找一首歌時,他們會用歌曲名和藝術(shù)家名來尋找它。功能測試采用分層的方法,在這種情況下處理一些具體的情況。

首先,我們用適當(dāng)?shù)妮斎腧炞CAPI的功能。API驗證請求并返回預(yù)期結(jié)果。

由于測試結(jié)構(gòu)的原因,我們應(yīng)該期待一些明確的響應(yīng)。然而,我們應(yīng)該預(yù)料到錯誤或修復(fù)的反應(yīng)包含所要求的材料。

功能測試應(yīng)該解決所有這些問題--不僅標(biāo)準(zhǔn)測試用例應(yīng)該包括在內(nèi),而且真實和邊緣情況也應(yīng)該包括在測試程序中。

4.負(fù)荷測試

負(fù)載測試是一種對現(xiàn)實主義著迷的測試--它有意避免理論上的錯誤和實踐上的錯誤。

我們通常在完成一個特定單元或整個代碼欄之后進(jìn)行這個測試,以確定理論解是否在某一負(fù)載下作為一個實際解。

負(fù)載測試模擬各種場景,以確保峰值性能。第一種情況稱為"基線",它將API與API在日常正常使用中預(yù)期的典型理論流量進(jìn)行比較。

這包括常規(guī)大小的測試,其中有一些相當(dāng)可觀的請求,可以在實踐中看到這兩種請求類型之間的任何區(qū)別。

通常,我們使用最大流量執(zhí)行第二次負(fù)載測試。這樣做是為了確保,即使是在峰值負(fù)載時,適當(dāng)節(jié)流請求的程序也已到位。雖然API可能永遠(yuǎn)不會達(dá)到這一理論上的最大值,但這是很好的保證。

最后,我們執(zhí)行了一個過載測試,包括測試到理論上的最大值,并在頂部增加10%-20%的流量。

雖然這種類型的測試幾乎可以保證失敗,因為它是對API函數(shù)的測試以及錯誤代碼的生成、處理和集成到API中,因此它幾乎成為一個混合測試。

5.安全測試

這個實踐確保了API實現(xiàn)不受外部攻擊。安全測試的其他步驟包括驗證加密技術(shù)和API訪問控制的架構(gòu)。它還管理用戶權(quán)限和驗證授權(quán)。

6.滲透測試

審計過程中的第二個測試是滲透測試。了解最少API的用戶將嘗試從外部分析威脅向量,這涉及到函數(shù)、資源、流程或整個API及其組件。

7.模糊測試

安全審計過程的另一個階段是模糊測試。大量隨機(jī)數(shù)據(jù)(稱為"噪音"或"模糊")在模糊測試期間進(jìn)入系統(tǒng),以檢測任何碰撞或不良行為。這項技術(shù)將API置于測試中,以便為"最壞的情況"做準(zhǔn)備。"

8.性能測試

我們試圖在每個提交時將負(fù)載測試范式向左轉(zhuǎn)移。以前,負(fù)載測試只限于少數(shù)人,在CI/CD設(shè)置中很難實現(xiàn)。準(zhǔn)備好的API是一個性能測試解決方案,用于RESTVUY、SOAP和其他Web服務(wù),允許幾乎任何團(tuán)隊成員將性能測試集成到其CI/CD工作流中。

9.端到端測試

我們在軟件開發(fā)生命周期(SDLC)中使用端到端測試來評估應(yīng)用程序在類似產(chǎn)品的條件下的功能和性能,并在數(shù)據(jù)中模擬現(xiàn)場設(shè)置。

目的是從一開始到結(jié)束重新創(chuàng)建一個真實的用戶場景。該測試旨在驗證測試中的系統(tǒng),并確保其子系統(tǒng)的功能和行為如預(yù)期。

10.組件測試

組件測試是一種軟件測試,我們可以在不與其他元素集成的情況下分別檢查每個組件。

當(dāng)我們從架構(gòu)的角度考慮它時,它也被稱為模塊測試。單元測試、程序測試和模塊測試描述組件測試.

11.情景測試

場景測試是一種軟件測試技術(shù),它使用場景或推測故事來幫助測試人員處理復(fù)雜的問題或測試系統(tǒng)。理想場景測試是一個可靠的,有挑戰(zhàn)性的,有說服力的,或有激勵性的故事,結(jié)果明確。

通常,這些測試不同于測試用例,因為測試用例是單個階段,而場景則跨越多個過程。

場景測試保證了軟件的端到端功能和流程流正在有效工作。在場景測試中,測試人員假裝是最終用戶,尋找最終用戶可以在產(chǎn)品上執(zhí)行的真實場景或用例。

場景測試涉及測試人員與客戶端、利益相關(guān)者和開發(fā)人員一起設(shè)計測試場景。

12.全通道測試

全通道測試在多個設(shè)備和平臺上測試一個應(yīng)用程序或產(chǎn)品。目標(biāo)是保證用戶體驗在所有平臺上是一致和無縫的。

這種無縫用戶體驗的保證是更廣泛的數(shù)字保證主題的一個重要組成部分。