介面測試覆蓋率-覆蓋業務、覆蓋程式碼。
UI自動化意義很小。自動化大概是10提升效率。介面和UI自動化100倍的效率差距。
工具：SOUPUI Loadrunner Firefox的firebug Chrome模擬手機端請求

介面型別：Http Webservice
1，http呼叫需要的是具體的請求地址
2，webservice需要的是wsdl(方法說明)

介面測試：化UI操作為請求操作。通過將一系列的UI操作轉換為資料包的互動，可以大大簡化測試的過程，並且快速驗證大量資料。
介面測試難點：RFC2616

1，REQUEST請求：
GET/WebTours/HTTP/1.1   GET從伺服器拿東西下來 POST發個資料給伺服器
Host：xxxx

Accept:告訴伺服器我們能接受的檔案型別
Accept-Language:客戶端所使用的語言
UA-CPU:客戶端所使用的cpu型別
Accept-Encoding:客戶端能接受的編碼格式  gzip:壓縮位元組,為了節約頻寬，將伺服器傳送的內容先通過gzip壓縮發給客戶端，客戶端再解壓展示
HTTP2.0可以壓縮header部分  HTTP1.1只能壓縮body部分
User-Agent:告訴伺服器我的客戶端的型別，介面測試和裝置終端無關，伺服器通過user-agent來識別客戶端
Connection：
Keep-Alive-長連線：比如打電話  缺點是一直佔用連線池，直至連線超時。訪問網頁時，往往是多請求，比如一個HTML請求，會載入css/js/img等
短連線：比如發簡訊
介面都是短連線，網站都是長連線。因為介面往往是針對某一個呼叫返回。介面一直為某個使用者服務時，才會長連線。


2，Response響應：
分為2部分：Header部分 Body部分-瀏覽器看到的內容

200OK:伺服器理解了你的意思，並且給了返回，但不代表返回內容是想要的  2xx都是伺服器正常返回
4xx都是客戶端問題
5xx都是伺服器問題 一般2種情況：1，傳送的資料非法（沒有正確驗證傳送的內容），導致伺服器上的某些邏輯錯誤  2，伺服器繁忙，掛掉

Last-modified:檔案的最後修改時間和本地上的檔案時間是否是一致的，快取，用於再次訪問時，如果相同body不再下載，只下載header就可以了