我相信自動化技能已經成爲高級測試工程師總體技能的標配。敏捷和持續測試破壞了傳統的測試自動化實踐，導致測試工程師重新考慮自動化的完成方式。當今的自動化工程師需要在GUI的下方深入到API級別完成軟件質量的保護。

導致轉向API測試的第二個變化是物聯網。物聯網是具有嵌入式功能的日常對象，允許它使用HTTP或HTTPS在Web上進行通信以與遠程後端服務進行通信。

下面分享一下API測試的基礎使用指南：

什麼是API測試？

應用程序編程接口（API）是充當軟件組件接口的規範。大多數功能測試都涉及測試網頁或表單等用戶界面，而API測試涉及繞過用戶界面並通過調用其API直接與服務程序通信。

API測試允許測試繞過GUI並將請求直接發送到應用程序的後端或服務，並在驗證響應內容以確保按預期運行的同時收到響應。

上面的示例通常稱爲客戶/服務器關係。客戶端通過請求資源來發出請求，然後請求出去尋找將滿足請求的服務器。服務器找到所需的資源，然後將響應發送回客戶端。

爲什麼API測試很重要？

隨着敏捷開發成爲大多數互聯網公司的標準，我們開發軟件和自動化測試的方式已經發生了巨大變化。在敏捷開發之前，大部分自動化時間都是通過圖形用戶界面（GUI）完成的。這是Selenium和UFT/QTP等工具處理的部分。

但是，如果您已經進行了一段時間的自動化操作，您就會知道這些類型的測試是多麼耗時，脆弱且難以維護。企業投入大量資金來創建自定義功能GUI測試自動化框架，單很可能最終使他們對其可靠性失去了信心，直到人們停止投入。

同樣，針對用戶界面的GUI測試往往需要花費很長時間才能運行。對於某些敏捷實踐（例如連續構建），遷入新代碼時，從GUI迴歸測試套件接收反饋所花費的時間是不能被接受的。

  • API快速反饋

在這些情況下，需要更快的反饋。發現錯誤的時間越早越好，因爲開發人員會立即知道他們所做的代碼更改已破壞了構建，因此需要進行檢查。在測試驅動的流程中，用戶需要大量測試集才能快速且頻繁地運行，並且必須能夠將它們集成到開發生命週期中。

GUI測試仍然非常重要。它是唯一能夠真正測試用戶在生產過程中如何體驗應用程序的測試類型。某些缺陷只能通過GUI測試來捕獲。換句話說，儘管至關重要，但GUI不應是用戶關注的唯一自動化類型，也不應該是自動化測試總量中最大的一部分。

敏捷關注的自動化類型是更可靠的API下層測試，而較少涉及GUI自動化。

API測試金字塔

GUI測試

GUI測試專注於測試應用程序用戶界面，以確保其功能正確。GUI測試位於金字塔的頂部，僅佔應該創建的自動化測試類型總數的一小部分。

單元測試

單元測試構成了金字塔的最大部分，形成了堅實的基礎。創建單元測試以驗證源代碼的單個單元，例如方法。通過這樣做，開發人員可以隔離其代碼中最小的可測試部分。單元測試是最容易創建的，並能帶來最大的收益。由於單元測試通常是用與編寫應用程序相同的語言編寫的，因此開發人員可以輕鬆將它們添加到開發過程中。

API測試

中間服務層是創建諸如Rest-Assured和Postman之類的工具的“最佳位置” 。

服務測試的重點是驗證許多小組件的交互是否可以集成在一起而不會出現問題。由於API測試繞過了用戶界面，因此它們往往比GUI測試更快，更可靠。

最重要的是：由於API測試不依賴UI即可完成，因此可以在開發週期的早期創建它們。

API負載測試

API測試的另一個好處是，您可以利用相同的功能性API自動測試來在性能測試工作中使用。很多公司使用JMeter進行負載測試，而這些測試用例都是基於API功能測試。

基本思想是，您正在使用工具進行性能測試，但是在針對您的API運行例如負載測試之前，需要確保它實際上可以正常工作。因此，您想先進行功能測試，然後可以利用功能測試腳本完成性能測試。

因此，API測試腳本是性能測試工作流程中的一大優勢。

API測試工具如何選擇

您可以使用許多工具來幫助您進行API測試自動化。

如何測試Web服務

測試任何其他應用程序一樣！通常，對於Web服務，正常功能測試的最佳方法是相同的（除了與大多數其他應用程序不同的是，Web服務沒有GUI用戶界面這一區別除外）。

因此，一直使用的功能測試技術仍然適用。只需將Web服務視爲沒有業務流程，然後相應地編寫測試用例。

自動化Web服務時要問的一些好問題：

  • 服務是否以正確的值響應？
  • 該行爲是否符合最終用戶的預期要求？
  • 該服務多快將響應發送給用戶？
  • 服務可以處理預期和意外的用戶負載嗎？
  • 服務可以處理無效數據和錯誤數據導致的異常嗎？
  • Web服務測試術語

對於大多數測試人員而言，最大的障礙是適應談論Web服務時使用的術語。

例如：

  • XML格式

XML是一種創建標記語言的方法，您可以使用它定義自己的標籤。XML允許用戶與衆多系統共享結構化數據，包括通過Internet。

  • REST

REST（表示性傳輸狀態）是用於開發使用HTTP協議的Web服務的輕量級選項。

HTTP

HTTP是一種通過網絡傳輸消息的通信協議。HTTP也被稱爲無狀態協議，因爲它發出的每個請求都獨立於所有先前的請求。

Cookies用於跟蹤會話的先前請求的狀態。Cookies是存儲在客戶端上的文件，具有從HTTP標頭信息中添加的信息。當向用戶已經訪問過的網站發出請求時，存儲在Cookies中的信息將發送回瀏覽器。以這種方式，網站能夠記住用戶的先前活動和當前的狀態。

  • 理解HTTP將爲我們瞭解大多數API測試工具功能奠定良好的基礎。

關於HTTP請求

HTTP客戶端請求包含三個主要部分。他們是：

請求行（HTTP方法）

告訴服務器正在發出什麼類型的請求。在上面的示例中，我們發出了GET請求，但您可以使用更多請求，具體取決於您需要發出的請求類型。HTTP方法具有以下選項（前四個方法是最常見的）：

GET –從指定來源檢索數據

POST –將新數據發送到指定的源

PUT –更新指定來源的信息

DELETE –從指定的源中刪除數據

TRACE –要求代理人聲明自己

選項 –詢問有關服務器上可用選項的信息

HEAD –與GET請求類似，但僅發送有關文檔的信息

CONNECT –客戶端必須使用HTTPS服務器時使用

標頭

包含要發送到服務器的其他信息，例如瀏覽器，操作系統，接受和Cookie信息。標頭的不同類型是：

常規 -可選的標頭，其中包含諸如當前時間之類的信息

請求 -向服務器提供有關客戶端的更多信息

實體 -包含有關發送文檔的特定信息，例如長度和編碼方案。

請求體

包含用於需要它的方法的數據，Get方法爲空。

從服務器返回的響應也包含三個部分，就像我們在HTTP請求中看到的那樣：

  • 響應行（狀態碼）
  • 標頭信息
  • 包含響應中所有文本的正文

HTTP狀態碼

在我們的示例中，狀態代碼爲200，表示一切正常。狀態代碼將根據原始請求發生的情況而有所不同。

可以從服務器返回的狀態碼是：

1xx – 100-199範圍內的響應表示服務器正在處理請求。

2xx – 200-299範圍內的響應表示請求成功。

3xx –響應範圍在300-399之間表示未執行請求-需要採取進一步的措施。

4xx –響應範圍爲400-499，表示請求不完整，可能需要更多信息。

5xx – 500-599範圍內的響應表示服務器遇到錯誤。

什麼是REST API？

REST（表示性傳輸狀態）是用於使用HTTP協議開發Web服務的輕量級選項，這一事實使其比使用SOAP協議的Web服務更簡單，開銷也更少。當API遵循REST體系結構時，它稱爲REST API。當圍繞REST標準設計服務時，可以說使該服務“ RESTful”。

REST API由大量資源組成。這稱爲資源模型，它利用統一資源標識（URI）。URI語法允許您指定一個查詢，該查詢從REST API返回所需的信息。REST系統的主要元素是：

  • 資源是客戶端請求從主機獲取的信息，例如網頁或數據庫記錄。
  • 資源標識符是用於命名資源的URI。
  • 表示形式是服務器發送帶有完成格式的資源的響應時。
  • REST API測試（如何創建REST API測試）

瞭解使用返回JSON的服務

也許是我，但是每次我聽到“ JSON”一詞時，都不會感到不安，而是13號恐怖電影《星期五》中傑森的恐怖形象浮現在我的腦海。

但是實際上，JSON只是另一個無害的技術首字母縮寫，您很快就會發現它沒什麼好害怕的。

什麼是JSON

JSON代表JavaScript Object Notation，並且被設計爲輕量級的數據交換格式。JSON無疑變得越來越流行，並且在某些情況下正在取代XML進行API數據交換。www.json.org網站描述瞭如何在兩種結構上構建JSON：

“ 名稱/值對的集合。在各種語言中，這被實現爲對象，記錄，結構，字典，哈希表，鍵列表或關聯數組。

“值的有序列表。在大多數語言中，這是通過數組，向量，列表或序列來實現的。”

末了，極力推薦《圖解HTTP協議》這本書。 圖解HTTP腦圖

  • 鄭重聲明 ：文章首發於公衆號“FunTester”，禁止第三方（騰訊雲除外）轉載、發表。
相關文章