API自動化測試指南
我相信自動化技能已經成為高階測試工程師總體技能的標配。敏捷和持續測試破壞了傳統的測試自動化實踐，導致測試工程師重新考慮自動化的完成方式。當今的自動化工程師需要在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”，禁止第三方（騰訊雲除外）轉載、發表。
技術類文章精選
- java一行程式碼列印心形
- Linux效能監控軟體netdata中文漢化版
- 效能測試框架第二版
- 如何在Linux命令列介面愉快進行效能測試
- 圖解HTTP腦圖
- 將swagger文件自動變成測試程式碼
- 五行程式碼構建靜態部落格
- 基於java的直線型介面測試框架初探
- Selenium 4.0 Alpha更新日誌
- Selenium 4.0 Alpha更新實踐
非技術文章精選
- 為什麼選擇軟體測試作為職業道路?
- 寫給所有人的程式設計思維
- 成為自動化測試的7種技能
- 如何在DevOps引入自動化測試
- Web端自動化測試失敗原因彙總
- 如何在DevOps引入自動化測試
- 測試人員常用藉口
- 2019年瀏覽器市場份額排行榜
- API測試基礎