隨著技術(shù)的進步,我們對API的依賴也將變得越來越重要?，F(xiàn)在你在互聯(lián)網(wǎng)上交流的一切都是通過API(應(yīng)用程序接口)傳輸?shù)摹?
在將它們集成到我們的技術(shù)中時,我們還必須考慮API測試。因為,如果我們考慮到它,我們的API和其他任何東西一樣,都需要根據(jù)各種質(zhì)量屬性進行嚴格的評價。
我們不僅要嚴格注意功能需求,還要密切注意非功能需求。
API代表應(yīng)用程序編程接口。它是一個計算機接口,允許兩個獨立的軟件系統(tǒng)連接和共享數(shù)據(jù)。
例如,具有API的軟件系統(tǒng)具有其他軟件系統(tǒng)可以執(zhí)行的許多功能。
一個API解釋了可以提出的請求的類型、如何提出這些請求、我們需要使用的數(shù)據(jù)格式,以及兩個軟件系統(tǒng)之間的關(guā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ù)格式進行數(shù)據(jù)比較。
2.界面獨立
在沒有用戶界面或與系統(tǒng)交互的情況下訪問應(yīng)用程序是API測試的一個顯著優(yōu)勢。換句話說,質(zhì)量保證測試人員可以執(zhí)行API測試,而無需事先了解軟件應(yīng)用程序。
這是一個很大的好處,因為它給質(zhì)量保證工程師提供了早期可見性的缺陷和錯誤,允許開發(fā)人員在損害圖形界面之前解決問題。
3.改進測試覆蓋率
由于大多數(shù)API和服務(wù)都有規(guī)范,我們可以創(chuàng)建覆蓋率高的自動化測試,包括功能測試(快樂案例)和非功能測試。
4.能夠更快地釋放
用戶界面回歸測試套件通常需要8-10小時才能執(zhí)行。相反,與API測試相同的場景只需要1到2個小時。API測試也比UI測試更少。所有這些都使您能夠更快地發(fā)布API測試。
5.降低測試成本
API測試使我們能夠及早發(fā)現(xiàn)錯誤和缺陷,每當你在早期發(fā)現(xiàn)錯誤時,你就可以省錢和節(jié)省時間。
6.方便與圖形界面集成
API測試支持高度可積測試。如果您打算在API測試之后運行功能性圖形界面測試,這將更加有用。例如,易于集成將允許在啟動圖形界面測試之前在程序中引入新用戶。
7.測試核心功能
在執(zhí)行圖形界面測試之前,測試應(yīng)用程序的代碼級功能提供了對其總體構(gòu)建強度的早期評估。這有助于暴露在圖形界面測試中的一些小缺陷,這些缺陷可能會增長并變得更大。
核心訪問允許測試與開發(fā)同時運行,促進兩個團隊之間的通信和協(xié)作。如果一個離岸質(zhì)量保證團隊進行API測試,這將特別有用。
8.API測試可自動化
我們可以使用許多工具包和框架來自動化API請求,使您可以構(gòu)建一個API測試自動化套件。
例如,在CI/CD時代,當執(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本身是否是解決當前問題的正確產(chǎn)品,是否存在任何實質(zhì)性代碼膨脹或特性蠕變,從而將原本精益和重點突出的實現(xiàn)推向了不可接受的方向?
行為: API訪問正確數(shù)據(jù)的方式是否正確?考慮到數(shù)據(jù)集的保密性和完整性要求,API是否獲得了過多的信息并正確地存儲了它?
效率: API是完成手頭任務(wù)的最精確、最優(yōu)、最有效的方式嗎?是否可以刪除或修改任何代碼庫以改進整體服務(wù)?
這些問題可以驗證API是一個全面的解決方案.
它們是在根據(jù)一套既定標準開發(fā)出API之后進行的,以確保正確的環(huán)境集成、遵守標準以及實現(xiàn)具體的最終目標和結(jié)果。
最后,這個測試可以簡單地描述為對指定的用戶需求和標準的精確發(fā)展的保證。
2.用戶界面測試
雖然驗證和功能測試方法是相對普遍的,但UI測試更特別。用戶界面測試正是聽起來像是對API及其組件的用戶界面的測試。
這個測試涉及UI的功能,不管它是圖形化的還是依賴于命令行端點調(diào)用。
在許多方面,這與其說是對API的測試,不如說是對連接到API的接口和開發(fā)人員使用該接口的經(jīng)驗的檢查。
然而,雖然不是API的直接代碼欄測試,但這提供了一個非常通用的觀點,即前端和后端的可用性和效率。
這就是為什么我們經(jīng)常使用UI測試來代替功能測試--在許多方面,它執(zhí)行相同的工作,盡管不那么全面,也不那么通用。
然而,在現(xiàn)代測試中,這是一種糟糕的技術(shù),而UI測試應(yīng)該完全局限于驗證UI本身的操作。
WebUI測試是這種類型測試的一部分,它側(cè)重于Web實例和它們所代表的API之間的端到端集成。雖然在線用戶界面測試是用戶界面測試的一個獨特的子集,但值得一提的是,它也包括在這一類中。
3.功能測試
功能測試是一種廣泛的測試方法,但它比驗證測試狹窄。功能測試只是對某些代碼庫函數(shù)的測試。
這些函數(shù)反過來描述特定的情況,以保證API在預(yù)期參數(shù)內(nèi)的功能,并檢查結(jié)果超出預(yù)期參數(shù)時是否正確處理了錯誤。
一個場景使得功能測試更容易傳達.例如,假設(shè)我們的API通過互聯(lián)網(wǎng)網(wǎng)關(guān)處理音樂訂購。
當一個人在尋找一首歌時,他們會用歌曲名和藝術(shù)家名來尋找它。功能測試采用分層的方法,在這種情況下處理一些具體的情況。
首先,我們用適當?shù)妮斎腧炞CAPI的功能。API驗證請求并返回預(yù)期結(jié)果。
由于測試結(jié)構(gòu)的原因,我們應(yīng)該期待一些明確的響應(yīng)。然而,我們應(yīng)該預(yù)料到錯誤或修復(fù)的反應(yīng)包含所要求的材料。
功能測試應(yīng)該解決所有這些問題--不僅標準測試用例應(yīng)該包括在內(nèi),而且真實和邊緣情況也應(yīng)該包括在測試程序中。
4.負荷測試
負載測試是一種對現(xiàn)實主義著迷的測試--它有意避免理論上的錯誤和實踐上的錯誤。
我們通常在完成一個特定單元或整個代碼欄之后進行這個測試,以確定理論解是否在某一負載下作為一個實際解。
負載測試模擬各種場景,以確保峰值性能。第一種情況稱為"基線",它將API與API在日常正常使用中預(yù)期的典型理論流量進行比較。
這包括常規(guī)大小的測試,其中有一些相當可觀的請求,可以在實踐中看到這兩種請求類型之間的任何區(qū)別。
通常,我們使用最大流量執(zhí)行第二次負載測試。這樣做是為了確保,即使是在峰值負載時,適當節(jié)流請求的程序也已到位。雖然API可能永遠不會達到這一理論上的最大值,但這是很好的保證。
最后,我們執(zhí)行了一個過載測試,包括測試到理論上的最大值,并在頂部增加10%-20%的流量。
雖然這種類型的測試幾乎可以保證失敗,因為它是對API函數(shù)的測試以及錯誤代碼的生成、處理和集成到API中,因此它幾乎成為一個混合測試。
5.安全測試
這個實踐確保了API實現(xiàn)不受外部攻擊。安全測試的其他步驟包括驗證加密技術(shù)和API訪問控制的架構(gòu)。它還管理用戶權(quán)限和驗證授權(quán)。
6.滲透測試
審計過程中的第二個測試是滲透測試。了解最少API的用戶將嘗試從外部分析威脅向量,這涉及到函數(shù)、資源、流程或整個API及其組件。
7.模糊測試
安全審計過程的另一個階段是模糊測試。大量隨機數(shù)據(jù)(稱為"噪音"或"模糊")在模糊測試期間進入系統(tǒng),以檢測任何碰撞或不良行為。這項技術(shù)將API置于測試中,以便為"最壞的情況"做準備。"
8.性能測試
我們試圖在每個提交時將負載測試范式向左轉(zhuǎn)移。以前,負載測試只限于少數(shù)人,在CI/CD設(shè)置中很難實現(xiàn)。準備好的API是一個性能測試解決方案,用于RESTVUY、SOAP和其他Web服務(wù),允許幾乎任何團隊成員將性能測試集成到其CI/CD工作流中。
9.端到端測試
我們在軟件開發(fā)生命周期(SDLC)中使用端到端測試來評估應(yīng)用程序在類似產(chǎn)品的條件下的功能和性能,并在數(shù)據(jù)中模擬現(xiàn)場設(shè)置。
目的是從一開始到結(jié)束重新創(chuàng)建一個真實的用戶場景。該測試旨在驗證測試中的系統(tǒng),并確保其子系統(tǒng)的功能和行為如預(yù)期。
10.組件測試
組件測試是一種軟件測試,我們可以在不與其他元素集成的情況下分別檢查每個組件。
當我們從架構(gòu)的角度考慮它時,它也被稱為模塊測試。單元測試、程序測試和模塊測試描述組件測試.
11.情景測試
場景測試是一種軟件測試技術(shù),它使用場景或推測故事來幫助測試人員處理復(fù)雜的問題或測試系統(tǒng)。理想場景測試是一個可靠的,有挑戰(zhàn)性的,有說服力的,或有激勵性的故事,結(jié)果明確。
通常,這些測試不同于測試用例,因為測試用例是單個階段,而場景則跨越多個過程。
場景測試保證了軟件的端到端功能和流程流正在有效工作。在場景測試中,測試人員假裝是最終用戶,尋找最終用戶可以在產(chǎn)品上執(zhí)行的真實場景或用例。
場景測試涉及測試人員與客戶端、利益相關(guān)者和開發(fā)人員一起設(shè)計測試場景。
12.全通道測試
全通道測試在多個設(shè)備和平臺上測試一個應(yīng)用程序或產(chǎn)品。目標是保證用戶體驗在所有平臺上是一致和無縫的。
這種無縫用戶體驗的保證是更廣泛的數(shù)字保證主題的一個重要組成部分。
下載文檔
