概述

當(dāng)我們在構(gòu)建、測試、發(fā)布一套新的HTTP API時，包括我在內(nèi)的大多數(shù)人都不知道他們所構(gòu)建的每一個組件的復(fù)雜性和細(xì)微差別。

即使你對每一個組件都有深刻的理解，也可能會有太多的信息在你的腦海中出現(xiàn)。

以至于我們不可能一下把所有的信息進(jìn)行梳理，形成成體系的API測試策略，下面我們就HTTP API測試將其checklist進(jìn)行細(xì)化。

主要從以下四個方面進(jìn)行:

HTTP
API設(shè)計(jì)
內(nèi)容
安全
客戶端
其他
HTTP
HTTP RFC(Request For Comments)相關(guān)文檔規(guī)定了HTTP交互機(jī)制及參數(shù)選項(xiàng)，因此你需要了解相關(guān)RFC文檔才能做好HTTP API的測試：

HTTP1.0: https://tools.ietf.org/html/rfc1945

HTTP1.1: https://tools.ietf.org/html/rfc7232

HTTP2: https://tools.ietf.org/html/rfc7540

在進(jìn)行HTTP API測試時，以下協(xié)議選項(xiàng)或機(jī)制是應(yīng)該考慮覆蓋的：

HTTP方法的安全性和冪等性。Http協(xié)議規(guī)定了不同方法的安全特性和冪等特性，作為服務(wù)提供者的服務(wù)器必需為客戶端提供這些特性。安全性，僅指該方法的多次調(diào)用不會產(chǎn)生副作用，不涉及傳統(tǒng)意義上的“安全”，這里的副作用是指資源狀態(tài)。即，安全的方法不會修改資源狀態(tài)，盡管多次調(diào)用的返回值可能不一樣(被其他非安全方法修改過)。冪等性，是指該方法多次調(diào)用返回的效果(形式)一致，客戶端可以重復(fù)調(diào)用并且期望同樣的結(jié)果。
HTTP方法的安全性和冪等性見下表：

認(rèn)證，驗(yàn)證準(zhǔn)確地實(shí)現(xiàn)HTTP身份驗(yàn)證，API應(yīng)該提供一個401狀態(tài)代碼。
狀態(tài)碼201 Created，使用“201 Created”標(biāo)識響應(yīng)代碼來表示請求已成功處理，并導(dǎo)致創(chuàng)建新資源。201響應(yīng)可以包括位置標(biāo)頭中的新資源URI。
狀態(tài)碼202 Accepted，使用“202 Accepted”的響應(yīng)代碼來表示請求是有效的，并且將被處理，但是還沒有完成。通常情況下，這是在服務(wù)器端后臺處理隊(duì)列的情況下使用的。
狀態(tài)碼4xx與5xx狀態(tài)代碼之間有一個重要的區(qū)別:4xx和5xx的狀態(tài)碼:4xx代碼是用來表示客戶端錯誤的，而5xx代碼表示服務(wù)器端錯誤。
狀態(tài)碼410 Gone響應(yīng)代碼是一種未得到充分利用的響應(yīng)代碼，該代碼通知客戶端在該URL中使用的資源，但不再是?？梢栽谀腁PI中使用它來表示已刪除、歸檔或過期的項(xiàng)。
狀態(tài)碼100-Continue——如果API客戶端準(zhǔn)備發(fā)送一個大型實(shí)體的請求，比如POST、PUT或補(bǔ)丁，他們可以在HTTP頭中發(fā)送“Expect:100-Continue”，然后在發(fā)送實(shí)體實(shí)體之前等待“100繼續(xù)”響應(yīng)。這允許API服務(wù)器在浪費(fèi)帶寬返回錯誤響應(yīng)(例如401或403)之前驗(yàn)證請求的有效性。支持這種功能不是很常見，但是它可以提高API的響應(yīng)能力并在某些場景中減少帶寬。
Connection Keep-Alive，為多個API請求維護(hù)與API服務(wù)器的連接可能是一個很大的性能改進(jìn)。如果配置正確，幾乎每個web服務(wù)器都應(yīng)該支持保持生命連接。
HTTP Compression，HTTP壓縮既可以用于響應(yīng)主體(接受編碼:gzip)，也可以用于請求主體(內(nèi)容編碼:gzip)來提高HTTP API的網(wǎng)絡(luò)性能。
HTTP Caching, 在API響應(yīng)中提供一個cache-control報(bào)頭。如果它們不能緩存，“cache-control:no-cache”將確保代理和瀏覽器能夠理解這一點(diǎn)。如果它們是可緩存的，則需要考慮各種因素，比如緩存是否可以由代理共享，或者資源是否"fresh"。
Cache Validation, 如果有可緩存的API，那么應(yīng)該在響應(yīng)中提供最后修改或ETag頭，然后支持If-修飾性請求，因?yàn)橛袟l件的請求。這將允許客戶機(jī)檢查它們的緩存副本是否仍然有效，并在不需要時阻止完整的資源下載。如果正確實(shí)現(xiàn)，可以使條件請求比通常的請求更有效，并節(jié)省一些服務(wù)器端負(fù)載。
Conditional Modifications, ETag頭也可以用于支持資源的條件修改。通過在獲取上提供一個ETag頭，稍后的POST、補(bǔ)丁或刪除請求可以提供一個if-match頭來檢查它們是否在更新或刪除它們上次看到的相同狀態(tài)的資源。
Absolute Redirects, 對http/1.1的重定向(例如:……201、301、302、303、307響應(yīng)代碼)應(yīng)該包含位置響應(yīng)頭中的一個絕對URI。許多客戶機(jī)在位置上支持相對uri，但是如果希望API與許多客戶機(jī)廣泛兼容，那么應(yīng)該在任何重定向中使用絕對uri。
Link Response Header，在RESTful API中，即使響應(yīng)的內(nèi)容類型沒有提供鏈接的自然方式(例如，PDF或圖像表示)，通常也需要提供指向其他資源的鏈接。RFC5988指定了在響應(yīng)頭中提供鏈接的方法。
Canonical URLs, 對于具有多個URL的資源，RFC6596定義了提供規(guī)范URL鏈接的一致方法。
Chunked Transfer Encoding, 如果有大量的內(nèi)容響應(yīng)，則轉(zhuǎn)換編碼:分塊是一種很好的方式來對客戶端進(jìn)行響應(yīng)。它將減少服務(wù)器和中間服務(wù)器的內(nèi)存使用需求(特別是實(shí)現(xiàn)HTTP壓縮)，并提供更快的第一個字節(jié)響應(yīng)。
Error Handling in Chunked Transfer Encoding, 在執(zhí)行并實(shí)現(xiàn)分塊傳輸編碼之前，要弄清楚如何處理在請求中出現(xiàn)的錯誤。一旦開始處理響應(yīng)，就無法更改HTTP狀態(tài)代碼。通常，需要定義一種表示內(nèi)容類型內(nèi)的錯誤的方法。
X-HTTP-Method-Override, 一些HTTP客戶端除了GET和POST以外什么都不支持;可以通過POST來隧道其他HTTP方法，并使用實(shí)際的標(biāo)準(zhǔn)x-HTTP-method-重寫頭來記錄“真正的”HTTP方法。
URL Length，如果API支持復(fù)雜的或任意的過濾選項(xiàng)作為GET參數(shù)，請記住，客戶端和服務(wù)器都可以在超過2000個字符的URL上存在兼容性問題。
API設(shè)計(jì)
學(xué)習(xí)和了解良好的API設(shè)計(jì)原則，有利于你深入對API的測試和驗(yàn)證，以確保API具備更好的可用性、安全性。

Statelessness， 始終保持應(yīng)用服務(wù)器的狀態(tài)，就可以輕松且毫無痛苦地?cái)U(kuò)展和維護(hù)了。
Content Negotiation, 如果想要支持資源的多個表示，您可以使用Content Negotiation（內(nèi)容協(xié)商）(例如。接受標(biāo)頭)，或者不同的url的不同的url(例如。格式=json)，也可以將內(nèi)容協(xié)商資源重定向到特定的格式。
URI Templates, URI模板是一種定義良好的機(jī)制，用于向客戶端提供URL組合功能，或者將URL訪問模式記錄到終端用戶。
Design for Intent，不要僅僅通過API公開內(nèi)部業(yè)務(wù)對象。設(shè)計(jì)API具有語義意義，并匹配用戶所使用示例。
Versioning, 從理論上講，如果預(yù)先設(shè)計(jì)了一個非常棒的API，那么可能永遠(yuǎn)不需要在API中創(chuàng)建不兼容。對于我們中的實(shí)用主義者來說，在API url中放置版本控制(例如。a/v1/path)，這樣就有了一個機(jī)制來控制和升級API了。
Authorization, 通過認(rèn)證來控制哪些API是可以公開訪問的，哪些API是必須認(rèn)證后才能訪問的，從而對API的訪問權(quán)限進(jìn)行控制管理
Bulk Operations, 如果能夠減少發(fā)出更少的請求與服務(wù)器進(jìn)行交互，那么批量操作的API是一個很不錯的設(shè)計(jì)。
Pagination, 分頁在API中有兩個主要目的：一是減少了向客戶機(jī)發(fā)送的不需要的數(shù)據(jù)量，并且減少了應(yīng)用服務(wù)器上不必要的計(jì)算量； 二是更多不同的模式用于進(jìn)行分頁的收集資源;
Unicode， 統(tǒng)一的字符編碼
Error Logging, 確保有日志機(jī)制記錄API的錯誤，并將用戶輸入導(dǎo)致的錯誤與應(yīng)用程序的錯誤分開記錄
內(nèi)容
Content Types， 要把內(nèi)容類型進(jìn)行詳細(xì)的闡述可能需要一整本書。這里主要指出其重要性，在開發(fā)過程中，我們應(yīng)該盡可能的復(fù)用標(biāo)準(zhǔn)或是經(jīng)過實(shí)踐檢驗(yàn)的內(nèi)容格式，例如Atom, Collection+JSON, JSON HAL, or XHTML。
HATEOAS，作為應(yīng)用程序狀態(tài)引擎的超媒體是一個REST約束。簡單地描述，這意味著你的內(nèi)容應(yīng)該通過鏈接和表單告訴客戶它下一步要做什么。
Date/time，當(dāng)在API中提供日期/時間值時，使用包含時區(qū)信息的格式要統(tǒng)一。
安全
SSL-考慮是否應(yīng)該在HTTP和HTTPS下提供API，或者只使用HTTPS。HTTPS是一個越來越受歡迎的選擇。
CSRF跨站點(diǎn)請求偽造，如果您的API接受您的交互用戶使用的相同的身份驗(yàn)證配置，那么您可能很容易受到CSRF攻擊。所以要有機(jī)制防CSRF攻擊。
Throttling，確保一個API用戶不能通過編寫一個非常愚蠢的API客戶端來降低您的系統(tǒng)性能。如果API用戶超過了應(yīng)該為他們提供的API請求限制，那么就給他們一個503的響應(yīng)，并帶有一個retry-header。
Subtle Denial of Service, 防DDoS攻擊
客戶端
為了確保我們提供的API能被用戶有效的使用，我們應(yīng)該為用戶定制一些基本的規(guī)則，以防止API被用戶濫用：

Connection Keep-Alive, 一些HTTP客戶端庫要求您做一些額外的工作來啟用持久連接。持久的連接可能會對您的API的性能產(chǎn)生重大影響。
401 before Authorization, 一些HTTP客戶端庫的另一個奇怪之處在于，通常需要一個“401未授權(quán)”的響應(yīng)，然后才會用授權(quán)標(biāo)頭發(fā)出請求。這可以為您的API請求增加很多時間，特別是在移動網(wǎng)絡(luò)中，高延遲將成為一個糾結(jié)的問題。
Expect: 100-continue, 至少有一個API客戶端默認(rèn)使用“Expect:100continue”;如果它沒有接收到“100continue”響應(yīng)，它將在3秒超時之后繼續(xù)請求。如果您不支持“100continue”，最好在客戶端禁用該能力，否則會導(dǎo)致服務(wù)性能的下降。
其他
Documentation, 編寫API文檔確實(shí)很無聊，但是手工編寫的文檔通常是最好的文檔。一定要包含一些可運(yùn)行的代碼或curl命令行，以幫助用戶盡可能快地上手。
Design with a Customer, 不要悶著頭設(shè)計(jì)API，要盡可能多與你的用戶交流、交互。
FeedBack，確保為API用戶提供了一種方法，可以對API進(jìn)行反饋。這可以通過你的支持渠道，也可以是一個托管論壇，也可以是一個郵件列表。盡量讓用戶不受摩擦的影響。
Automated Testing，API應(yīng)該是為構(gòu)建自動化測試所做的最簡單的事情。畢竟，它是為自動化而生的。利用它!

學(xué)習(xí)安排上

作為一位過來人也是希望大家少走一些彎路，如果你不想再體驗(yàn)一次學(xué)習(xí)時找不到資料，沒人解答問題，堅(jiān)持幾天便放棄的感受的話，在這里我給大家分享一些自動化測試的學(xué)習(xí)資源，希望能給你前進(jìn)的路上帶來幫助?！颈ＷC100%免費(fèi)】

?文檔獲取方式：

加入我的軟件測試交流群：632880530免費(fèi)獲取~（同行大佬一起學(xué)術(shù)交流，每晚都有大佬直播分享技術(shù)知識點(diǎn)）

這份文檔，對于想從事【軟件測試】的朋友來說應(yīng)該是最全面最完整的備戰(zhàn)倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！

以上均可以分享，只需要你搜索vx公眾號：程序員雨果，即可免費(fèi)領(lǐng)取