接口測試——必備知識整理

時間 2019-12-18

標籤接口測試必備知識整理简体版

原文原文鏈接

WEB架構發展html

1.單機架構，全部應用內程序都在本機運行，全部的數據也都保存在本機上。表示層，應用層喝數據層位於統一主機上前端

2.工做站/服務器架構（W/S）在服務器上保存數據，在工做站上處理數據。數據層位於服務器端，應用層和表示層位於工做站。linux

3.客戶端/服務器架構（C/S）客戶機想服務器發出之靈，服務器上存儲喝處理數據，服務器完成數據處理將結果返回客戶機進行二次處理。數據層和應用位於服務器，表示層位於客戶端。web

4.瀏覽器/服務器架構（B/S）霧浮起處理數據並生成頁面，客戶級上瀏覽請求頁面和顯示頁面算法

5.客戶端/應用服務器/數據服務器（C/S/S）在客戶端和和服務器之間加入中間層，即應用服務器。數據庫

6.Web瀏覽器/Web服務器/數據庫服務器（B/S/S）由Web瀏覽器、Web服務器、中間件、數據庫服務器組成，各組成部分之間物理上經過intranet或Internet相連接，軟件上遵照HTTP協議，瀏覽器經過發送請求和服務器端創建連接，從而實現整個Internet爲背景的數據存儲和訪問。中間件是一個用API定義的軟件層，是具備清大通訊能力和良好可擴展性的分佈式軟件管理框架windows

7.四層體系結構，包括WEB瀏覽器、WEB服務器、應用服務器、數據庫服務器後端

從單機結構到四層結構或者多層結構，技術方面也從最初的瀏覽器展現，服務端控制，經歷前端組件化、後端爲主api

MVC時代、Ajax帶來的SPA時代（Single Page Application 單頁免應用）、先後端分離、前端爲主的MV*時代。瀏覽器

隨着WEB架構的不斷髮展API重要性逐漸提現出來，目前API 接口層已經在軟件開發過程當中被獨立出來

OSI七層協議
應用層文件傳輸，電子郵件，文件服務，虛擬終端 TFTP，HTTP，SNMP，FTP，SMTP，DNS，Telnet
表示層數據格式化，代碼轉換，數據加密沒有協議
會話層解除或創建與別的接點的聯繫沒有協議
傳輸層提供端對端的接口 TCP，UDP
網絡層爲數據包選擇路由 IP，ICMP，RIP，OSPF，BGP，IGMP
數據鏈路層傳輸有地址的幀以及錯誤檢測功能 SLIP，CSLIP，PPP，ARP，RARP，MTU
物理層以二進制數據形式在物理媒體上傳輸數據 ISO2110，IEEE802，IEEE802.2

TCP/IP 五層模型的協議
應用層
傳輸層
網絡層
數據鏈路層
物理層

http協議：超文本傳輸協議,用於從www服務器傳輸超文本到本地瀏覽器的傳送協議, 由請求和響應構成

在Web應用中，服務器把網頁傳給瀏覽器，實際上就是把網頁的HTML代碼發送給瀏覽器，讓瀏覽器顯示出來。而瀏覽器和服務器之間的傳輸協議是HTTP
HTML是一種用來定義網頁的文本，超文本標記語言
HTTP是在網絡上傳輸HTML的協議，用於瀏覽器和服務器的通訊

HTTP長鏈接和短鏈接

HTTP的長鏈接和短鏈接本質上是TCP長鏈接和短鏈接。HTTP屬於應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。 IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠地傳遞數據包，使得網絡上接收端收到發送端所發出的全部包，而且順序與發送順序一致。TCP協議是可靠的、面向鏈接的。

當網絡通訊時採用TCP協議時，在真正的讀寫操做以前，客戶端與服務器端之間必須創建一個鏈接，當讀寫操做完成後，雙方再也不須要這個鏈接時能夠釋放這個鏈接。鏈接的創建依靠「三次握手」，而釋放則須要「四次握手」，因此每一個鏈接的創建都是須要資源消耗和時間消耗的。

短鏈接：client向server發起鏈接請求，server接到請求，而後雙方創建鏈接。client向server發送消息，server迴應client，而後一次請求就完成了。這時候雙方任意均可以發起close操做，不過通常都是client先發起close操做。上述可知，短鏈接通常只會在 client/server間傳遞一次請求操做。操做步驟是：創建鏈接——數據傳輸——關閉鏈接...創建鏈接——數據傳輸——關閉鏈接

長連接：client向server發起鏈接，server接受client鏈接，雙方創建鏈接，client與server完成一次請求後，它們之間的鏈接並不會主動關閉，後續的讀寫操做會繼續使用這個鏈接。操做步驟是：創建鏈接——數據傳輸...（保持鏈接）...數據傳輸——關閉鏈接

工做流程
一、客戶端與服務器創建鏈接；
二、創建鏈接後，客戶端發送一個請求給服務器；
三、服務器接到請求後，給予相應的響應信息；
四、客戶端接收服務器所返回的信息經過瀏覽器顯示，而後斷開鏈接。

每次鏈接只處理一個請求

URL：（Uniform Resource Locator）統一資源定位符，對能夠從互聯網上獲得的資源的位置和訪問方法的一種簡潔的表示，是互聯網上標準資源的地址。

HTTP使用統一資源標識符（URI）來傳輸數據和創建鏈接。URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息。

如下面這個URL爲例：

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

1.協議部分：表明網頁使用的是HTTP協議。在Internet中可使用多種協議，如HTTP，FTP等等。在"HTTP"後面的「//」爲分隔符

2.域名部分：「www.aspxfans.com」。一個URL中，也可使用IP地址做爲域名使用

3.端口部分：跟在域名後面的是端口，域名和端口之間使用「:」做爲分隔符。端口不是一個URL必須的部分，若是省略端口部分，將採用默認端口80/tcp

4.虛擬目錄部分：從域名後的第一個「/」開始到最後一個「/」爲止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是「/news/」

5.文件名部分：從域名後的最後一個「/」開始到「？」爲止，是文件名部分，若是沒有「?」,則是從域名後的最後一個「/」開始到「#」爲止，是文件部分，若是沒有「？」和「#」，那麼從域名後的最後一個「/」開始到結束，都是文件名部分。本例中的文件名是「index.asp」。文件名部分也不是一個URL必須的部分，若是省略該部分，則使用默認的文件名

6.錨部分：從「#」開始到最後，都是錨部分。本例中的錨部分是「name」。錨部分也不是一個URL必須的部分（能夠理解爲定位）

7.參數部分：從「？」開始到「#」爲止之間的部分爲參數部分，又稱搜索部分、查詢部分。本例中的參數部分爲「boardID=5&ID=24618&page=1」。參數能夠容許有多個參數，參數與參數之間用「&」做爲分隔符。

域名解析

第一步：瀏覽器會檢查緩存中有沒有這個域名對應的解析過的IP地址，若是有，這個解析過程就結束了，直接拿到IP進行訪問。這個瀏覽器緩存域名是有限制的，除了緩存大小有限制，緩存的時間也有限制，一般狀況下由TTL屬性來設置。

第二步：若是用戶瀏覽器緩存中沒有，瀏覽器會查找操做系統中是否有這個域名對應的DNS解析結果。windows中c:/windows/system32/drivers/etc/hosts文件設置，linux中/etc/hosts文件中設置。當解析到這個配置文件中的某個域名時，操做系統會在緩存中緩存這個解析結果。（修改文件後不當即生效的緣由）

第三步：在網絡配置中都會有「DNS服務器地址」這一項，當前面兩步都不能解析時，操做系統會把這個域名發送給設置的DNS服務器（簡稱LDNS）-local縮寫，通常是本地區的域名服務器也能夠是本身設置的域名服務器地址，若是命中，那解析就此結束並返回IP並標記爲非權威服務器的應答。如是學校的互聯網，那麼你的DNS服務器確定在你的學校，若是你是一個小區接入互聯網，那這個DNS就是提供給你接入互聯網的應用供應商，即電信或聯通。windows中能用ipconfig查看DNS服務器地址，linux中cat /etc/resolv.conf查看DNS Server。

第四步：若是LDNS沒有命中，LDNS就會向Root Server域名服務器請求解析。LDNS會從配置文件裏面讀取13個根域名服務器的地址（這些地址是不變的，直接在BIND的配置文件中），而後像其中一臺發起請求。

第五步:根服務器拿到這個請求後，知道他是com.這個頂級域名下的，因此就會返回com.域中的NS記錄，通常來講是13臺主機名和IP（主域名服務器地址即gTLD-國際頂級域名服務器地址），返回給本地域名服務器即LDNS，

第六步：LDNS再向上一步返回的其中一臺gTLD服務器發送請求。com.域的服務器（gTLD）發現你這請求是baidu.com這個域的，一查發現了這個域的NS（通常就是你註冊的域名服務器），那就返回給你，你再去查。

第七步：LDNS接受gTLD返回的域服務器地址（即域名服務提供商的域服務器）並向其中一臺再次發起請求，在baidu.com的域下面查了下有www的這臺主機，就把這個IP返回給你了。

第八步：LDNS接受返回的IP和TLL值

第九步：LDNS緩存這個域名和IP的對應關係，緩存時間有TLL控制

第十步：LDNS把解析的結果返回給用戶，用戶根據TLL值緩存在本地系統緩存中，域名解析結束。

請求方法

一、OPTIONS
返回服務器針對特定資源所支持的HTTP請求方法，也能夠利用向web服務器發送‘*’的請求來測試服務器的功能性
二、HEAD
向服務器索與GET請求相一致的響應，只不過響應體將不會被返回。這一方法能夠再沒必要傳輸整個響應內容的狀況下，就能夠獲取包含在響應小消息頭中的元信息。
三、GET
向特定的資源發出請求。它本質就是發送一個請求來取得服務器上的某一資源。資源經過一組HTTP頭和呈現數據（如HTML文本，或者圖片或者視頻等）返回給客戶端。GET請求中，永遠不會包含呈現數據。
四、POST
向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的創建和/或已有資源的修改。 Loadrunner中對應POST請求函數：web_submit_data,web_submit_form
五、PUT
向指定資源位置上傳其最新內容
六、DELETE
請求服務器刪除Request-URL所標識的資源
七、TRACE
回顯服務器收到的請求，主要用於測試或診斷
八、CONNECT
HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。

狀態碼
狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：
1xx：指示信息--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操做
4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現
5xx：服務器端錯誤--服務器未能實現合法的請求
常見狀態代碼、狀態描述、說明：
200 OK //客戶端請求成功
400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解
401 Unauthorized // 請求未經受權，這個狀態代碼必須和WWW-Authenticate 報頭域一塊兒使用
403 Forbidden //服務器收到請求，可是拒絕提供服務
404 Not Found //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error //服務器發生不可預期的錯誤
503 Server Unavailable // 服務器當前不能處理客戶端的請求，一段時間後，可能恢復正常

request

Host:請求的域名
User_agent:發出請求的用戶信息,客戶端操做系統和瀏覽器的名稱和版本
Accept:瀏覽器端能夠接收的媒體類型
Accept-Language:瀏覽器申明主機接收的語言
Accept-Encoding:瀏覽器申明接收的編碼方法，一般指定壓縮方法，是否支持壓縮，支持什麼壓縮方法
Referer:提供request的上下文信息的服務器，告訴服務器我是從哪一個連接過來的
Cookie：最重要的header,將cookie值發送給http服務器
Connection:
keep-alive當一個網頁打開完成後，客戶端和服務器之間用於傳輸http數據的tcp連接不會關閉，若是客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經創建的連接
Close表明一個request完成後，客戶端和服務器之間用於傳輸http數據的tcp連接會關閉，當客戶端再次發送request，須要從新創建tcp連接

Cache-Control：這個是很是重要的規則，用來指定response-request遵循的緩存機制。
Cache-Control:Public 能夠被任何緩存所緩存（）
Cache-Control:Private 內容只緩存到私有緩存中
Cache-Control:no-cache 全部內容都不會被緩存
max-age>0 時直接從遊覽器緩存中提取 max-age<=0 時向server 發送http 請求確認 ,該資源是否有修改，有的話返回200 ,無的話返回304.
X-Forwarded-For:client1, proxy1, proxy2, proxy3
Content-Type:web服務器告訴瀏覽器本身響應的對象的類型和字符集。
Date:生成消息的具體時間和日期。
Server:指明http服務器的軟件信息。
Tracecode:跟蹤代碼
Transfer-encoding:傳輸編碼，chunked便士輸出的內容長度不能肯定。
X-powered-by:表示網站用什麼技術開發的。
Expires:瀏覽器會在指定過時時間內使用本地緩存
Last-modified:指示資源的最後修改日期和時間
Content-length:實體正文長度

cookie，session，token

session

session的中文翻譯是「會話」，當用戶打開某個web應用時，便與web服務器產生一次session。服務器使用session把用戶的信息臨時保存在了服務器上，用戶離開網站後session會被銷燬。這種用戶信息存儲方式相對cookie來講更安全，但是session有一個缺陷：若是web服務器作了負載均衡，那麼下一個操做請求到了另外一臺服務器的時候session會丟失。

cookie

cookie是保存在本地終端的數據。cookie由服務器生成，發送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內，下一次請求同一網站時會把該cookie發送給服務器。因爲cookie是存在客戶端上的，因此瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會佔據太多磁盤空間，因此每一個域的cookie數量是有限的。

cookie的組成有：名稱(key)、值(value)、有效域(domain)、路徑(域的路徑，通常設置爲全局:"\")、失效時間、安全標誌(指定後，cookie只有在使用SSL鏈接時才發送到服務器(https))。下面是一個簡單的js使用cookie的例子:

用戶登陸時產生cookie:

document.cookie = "id="+result.data['id']+"; path=/";

document.cookie = "name="+result.data['name']+"; path=/";

document.cookie = "avatar="+result.data['avatar']+"; path=/";

使用到cookie時作以下解析：

var cookie = document.cookie;var cookieArr = cookie.split(";");var user_info = {};for(var i = 0; i < cookieArr.length; i++) {

user_info[cookieArr[i].split("=")[0]] = cookieArr[i].split("=")[1];

}

$('#user_name').text(user_info[' name']);

$('#user_avatar').attr("src", user_info[' avatar']);

$('#user_id').val(user_info[' id']);

token

token的意思是「令牌」，是用戶身份的驗證方式，最簡單的token組成:uid(用戶惟一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以哈希算法壓縮成必定長的十六進制字符串，能夠防止惡意第三方拼接token請求服務器)。還能夠把不變的參數也放進token，避免屢次查庫

cookie 和session的區別

一、cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。

二、cookie不是很安全，別人能夠分析存放在本地的COOKIE並進行COOKIE欺騙
考慮到安全應當使用session。

三、session會在必定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能
考慮到減輕服務器性能方面，應當使用COOKIE。

四、單個cookie保存的數據不能超過4K，不少瀏覽器都限制一個站點最多保存20個cookie。

五、因此我的建議：
將登錄信息等重要信息存放爲SESSION
其餘信息若是須要保留，能夠放在COOKIE中

token 和session 的區別

session 和 oauth token並不矛盾，做爲身份認證 token安全性比session好，由於每一個請求都有簽名還能防止監聽以及重放攻擊，而session就必須靠鏈路層來保障通信安全了。如上所說，若是你須要實現有狀態的會話，仍然能夠增長session來在服務器端保存一些狀態

App一般用restful api跟server打交道。Rest是stateless的，也就是app不須要像browser那樣用cookie來保存session,所以用session token來標示本身就夠了，session/state由api server的邏輯處理。若是你的後端不是stateless的rest api, 那麼你可能須要在app裏保存session.能夠在app裏嵌入webkit,用一個隱藏的browser來管理cookie session.

Session 是一種HTTP存儲機制，目的是爲無狀態的HTTP提供的持久機制。所謂Session 認證只是簡單的把User 信息存儲到Session 裏，由於SID 的不可預測性，暫且認爲是安全的。這是一種認證手段。而Token ，若是指的是OAuth Token 或相似的機制的話，提供的是認證和受權，認證是針對用戶，受權是針對App 。其目的是讓某App有權利訪問某用戶的信息。這裏的 Token是惟一的。不能夠轉移到其它 App上，也不能夠轉到其它用戶上。轉過來講Session 。Session只提供一種簡單的認證，即有此 SID，即認爲有此 User的所有權利。是須要嚴格保密的，這個數據應該只保存在站方，不該該共享給其它網站或者第三方App。因此簡單來講，若是你的用戶數據可能須要和第三方共享，或者容許第三方調用 API 接口，用 Token 。若是永遠只是本身的網站，本身的 App，用什麼就無所謂了。

token就是令牌，好比你受權（登陸）一個程序時，他就是個依據，判斷你是否已經受權該軟件；cookie就是寫在客戶端的一個txt文件，裏面包括你登陸信息之類的，這樣你下次在登陸某個網站，就會自動調用cookie自動登陸用戶名；session和cookie差很少，只是session是寫在服務器端的文件，也須要在客戶端寫入cookie文件，可是文件裏是你的瀏覽器編號.Session的狀態是存儲在服務器端，客戶端只有session id；而Token的狀態是存儲在客戶端。

web緩存(cache)

Web緩存通常分爲瀏覽器緩存、代理服務器緩存以及網關緩存，本文主要講的是 瀏覽器緩存，其它兩種緩存你們自行去了解下。

Web 緩存遊走於服務器和客戶端之間。這個服務器多是源服務器（資源所駐留的服務器），數量多是1個或多個；這個客戶端也多是1個或多個。Web 緩存就在服務器-客戶端之間搞監控，監控請求，而且把請求輸出的內容（例如html頁面、圖片和文件）（統稱爲副本）另存一份；而後，若是下一個請求是相同的 URL，則直接請求保存的副本，而不是再次麻煩源服務器。

使用緩存的2個主要緣由：