掃盲內容：前端
1.什麼是接口？java
2.接口都有哪些類型？web
3.接口的本質是什麼？算法
4.什麼是接口測試？數據庫
5.問什麼要作接口測試？json
6.怎樣作接口測試？後端
7.接口測測試點是什麼？api
8.接口測試都要掌握哪些知識？瀏覽器
9.其餘相關知識？安全
一.什麼是接口？
接口測試主要用於外部系統與系統之間以及內部各個子系統之間的交互點，定義特定的交互點，而後經過這些交互點來，經過一些特殊的規則也就是協議，來進行數據之間的交互。
二.接口都有哪些類型？
接口通常分爲兩種：
1.程序內部的接口
2.系統對外的接口
系統對外的接口：好比你要從別的網站或服務器上獲取資源或信息，別人確定不會把數據庫共享給你，他只能給你提供一個他們寫好的方法來獲取數據，你引用他提供的接口就能使用他寫好的方法，從而達到數據共享的目的。
程序內部的接口：方法與方法之間，模塊與模塊之間的交互，程序內部拋出的接口，好比bbs系統，有登陸模塊、發帖模塊等等，那你要發帖就必須先登陸，那麼這兩個模塊就得有交互，它就會拋出一個接口，供內部系統進行調用。
接口的分類：
1.webservice接口
2.http api接口
webService接口是走soap協議經過http傳輸，請求報文和返回報文都是xml格式的，咱們在測試的時候都用經過工具才能進行調用，測試。
http api接口是走http協議，經過路徑來區分調用的方法，請求報文都是key-value形式的，返回報文通常都是json串，有get和post等方法，這也是最經常使用的兩種請求方式。
json是一種通用的數據類型，全部的語言都認識它。（json的本質是字符串，他與其餘語言無關，只是能夠通過稍稍加工能夠轉換成其餘語言的數據類型，好比能夠轉換成Python中的字典，key-value的形式，能夠轉換成JavaScript中的原生對象，能夠轉換成java中的類對象等。）
三.接口的本質及其工做原理是什麼？
接口你能夠簡單的理解他就是URL，工做原理就會說URL經過get或者post請求像服務器發送一些東西，而後獲得一些相應的返回值，本質就是數據的傳輸與接收。
四.什麼是接口測試？
簡答的說就是經過URL像服務器或者其餘模塊等，傳輸咱們想傳輸的數據，而後看看他們返回的是否是咱們預期想要的。
五.問什麼要作接口測試？
①.越底層發現bug，它的修復成本是越低的。
②.前端隨便變，接口測好了，後端不用變，先後端是兩撥人開發的。
③.檢查系統的安全性、穩定性，前端傳參不可信，好比京東購物，前端價格不可能傳入-1元，可是經過接口能夠傳入-1元。
④.現在的系統複雜度不斷上升，傳統的測試方法成本急劇增長且測試效率大幅降低，接口測試能夠提供這種狀況下的解決方案。
⑤. 接口測試相對容易實現自動化持續集成，且相對UI自動化也比較穩定，能夠減小人工迴歸測試人力成本與時間，縮短測試周期，支持後端快速發版需求。接口持續集成是爲何能低成本高收益的根源。
⑥. 如今不少系統先後端架構是分離的，從安全層面來講：
(1)、只依賴前端進行限制已經徹底不能知足系統的安全要求（繞過前面實在太容易）， 須要後端一樣進行控制，在這種狀況下就須要從接口層面進行驗證。
(2)、先後端傳輸、日誌打印等信息是否加密傳輸也是須要驗證的，特別是涉及到用戶的隱私信息，如身份證，銀行卡等。
六.怎樣作接口測試？
工具備不少如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。
--也能夠用 接口自動化來實現，就是用代碼實現，框架和UI自動化差很少，發送請求用斷言來判斷。
七.接口測測試點是什麼？
目的：測試接口的正確性和穩定性；
原理：模擬客戶端向服務器發送請求報文，服務器接收請求報文後對相應的報文作處理並向客戶端返回應答，客戶端接收應答的過程；
重點：檢查數據的交換，傳遞和控制管理過程，還包括處理的次數；
核心：持續集成是接口測試的核心；
優勢：爲高複雜性的平臺帶來高效的缺陷監測和質量監督能力，平臺越複雜，系統越龐大，接口測試的效果越明顯（提升測試效率，提高用戶體驗，下降研發成本）；
用例設計重點：一般狀況下主要測試最外層的兩類接口:數據進入系統接口（調用外部系統的參數爲本系統使用）和數據流出系統接口（驗證系統處理後的數據是否正常）；
PS：設計用例時還須要注意外部接口提供給使用這些接口的外部用戶什麼功能，外部用戶真正須要什麼功能；
一、基本功能測試：
因爲是針對基本業務功能進行測試，因此這部分是兩種測試重合度最高的一塊，開發同窗一般所指的也主要是這部分的內容。
二、邊界分析測試：
在基本功能測試的基礎上考慮輸入輸出的邊界條件，這部份內容也會有重複的部分（好比業務規則的邊界）。可是，前端的輸入輸出不少時候都是提供固守的值讓用戶選擇（以下拉框），在這種狀況下測試的邊界範圍就很是有限，但接口測試就不存在這方面的限制，相對來講接口能夠覆蓋的範圍更廣，一樣的，接口出現問題的機率也更高。
三、性能測試：
這個比較容易區分，雖然都須要作性能測試，但關注點確大不相同。App端性能主要關注與手機相關的特性，如手機cpu、內存、流量、fps等。而接口性能主要關注接口響應時間、併發、服務端資源的使用狀況等。兩種測試時的策略和方法都有很大區別，因此這部份內容是須要分開單獨進行測試的，理論上來講這也是不一樣的部分。
綜論：
一、接口測試和app測試的活動有部分重複的內容，主要集中在業務功能測試方面。除此以外，針對各自特性的測試都不同，須要分別進行有針對性的測試，才能確保整個產品的質量。
二、接口測試能夠關注於服務器邏輯驗證，而UI測試能夠關注於頁面展現邏輯及界面前端與服務器集成驗證
三、接口測試持續集成：
對接口測試而言，持續集成自動化是核心內容，經過持自動化的手段咱們才能作到低成本高收益。目前咱們已經實現了接口自動化，主要應用於迴歸階段，後續還須要增強自動化的程度，包括但不限於下面的內容：
a) 流程方面：在迴歸階段增強接口異常場景的覆蓋度，並逐步向系統測試，冒煙測試階段延伸，最終達到全流程自動化。
b) 結果展現：更加豐富的結果展現、趨勢分析，質量統計和分析等
c) 問題定位：報錯信息、日誌更精準，方便問題復現與定位。
d) 結果校驗：增強自動化校驗能力，如數據庫信息校驗。
e) 代碼覆蓋率：不斷嘗試由目前的黑盒向白盒下探，提升代碼覆蓋率。
f) 性能需求：完善性能測試體系，經過自動化的手段監控接口性能指標是否正常。
四、接口測試質量評估標準：
a) 業務功能覆蓋是否完整
b) 業務規則覆蓋是否完整
c) 參數驗證是否達到要求（邊界、業務規則）
d) 接口異常場景覆蓋是否完整
e) 接口覆蓋率是否達到要求
f) 代碼覆蓋率是否達到要求
g) 性能指標是否知足要求
h) 安全指標是否知足要求
八.接口測試都要掌握哪些知識？
①瞭解系統及內部各個組件之間的業務邏輯交互；
②瞭解接口的I/O（input/output：輸入輸出）；
③瞭解協議的基本內容，包括：通訊原理、三次握手、經常使用的協議類型、報文構成、數據傳輸方式、常見的狀態碼、URL構成等；
④經常使用的接口測試工具，好比：jmeter、loadrunner、postman、soapUI等；
⑤數據庫基礎操做命令（檢查數據入庫、提取測試數據等）；
⑥常見的字符類型，好比：char、varchar、text、int、float、datatime、string等；
如何獲取接口相關信息？
通常的企業，都會由開發或者對應的技術負責人員編寫接口文檔，裏面會註明接口相關的地址、參數類型、方法、輸入、輸出等信息，若是沒有，想辦法獲取。。。
接口文檔八要素：
封面：封面最好是本公司規定的封面，有logo，內容標題，版本號，公司名稱，文檔產生日期；
修訂歷史：表格形式較好些，包括：版本、修訂說明、修訂日期、修訂人、審覈時間審覈人等；
接口信息：接口調用方式，經常使用的GET/POST方式，接口地址；
功能描述：簡潔清晰的描述接口功能，好比：接口獲取的信息不包括哪些；
接口參數說明：每一個參數都要和實際中調用的同樣，包括大小寫；參數的含義言簡意賅的說明，格式，是string 仍是int 仍是long等格式；
說明部分，說明參數值是須要哪裏提供，並詳細說明參數怎麼生成的，例如時間戳，是哪一個時間段的，參數是否必填，一些參數是必需要有的，有些是可選參數等；
返回值說明：
①最好有一個模板返回值，並說明每一個返回參數的意義；
②提供一個真實的調用接口，真實的返回值；
調用限制，安全方面：
加密方式，或者本身公司一個特殊的加密過程，只要雙方採用一致的加密算法就能夠調用接口，保證了接口調用的安全性，好比常見的md5；
文檔維護：文檔在維護的時候，若有修改必定要寫上修改日期，修改人，對大的修改要有版本號變動；
九.其餘相關知識？
get請求，post請求的區別：
一、GET使用URL或Cookie傳參。而POST將數據放在BODY中。
二、GET的URL會有長度上的限制，則POST的數據則能夠很是大。
三、POST比GET安全，由於數據在地址欄上不可見。
四、通常get請求用來獲取數據，post請求用來發送數據。
其實上面這幾點，只有最後一點說的是比較靠譜的，第一點post請求也能夠把數據放到url裏面，get請求其實也沒長度限制，post請求看起來參數是隱式的，稍微安全那麼一些些，可是那只是對於小白用戶來講的，就算post請求，你經過抓包也是能夠抓到參數的。（惟一區別就是這一點，上面3點區別都是不許確的）
http狀態碼：
一、200 2開頭的都表示這個請求發送成功，最多見的就是200，就表明這個請求是ok的，服務器也返回了。
二、300 3開頭的表明重定向，最多見的是302，把這個請求重定向到別的地方了。
三、400 400表明客戶端發送的請求有語法錯誤，401表明訪問的頁面沒有受權，403表示沒有權限訪問這個頁面，404表明沒有這個頁面。
四、500 5開頭的表明服務器有異常，500表明服務器內部異常，504表明服務器端超時，沒返回結果。
webservice接口怎麼測試：
它不須要你在拼報文了，會給一個webservice的地址，或者wsdl文件，直接在soapui導入，就能夠看到這個webservice裏面的全部接口，也有報文，直接填入參數調用，看返回結果就能夠了。
天氣預報wsdl地址：http://www.webservicex.net/globalweather.asmx?wsdl
cookie與session的區別：
一、cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。
二、cookie不是很安全，別人能夠分析存放在本地的cookie並進行cookie欺騙考慮到安全應當使用session。
三、session會在必定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能考慮到減輕服務器性能方面，應當使用cookie。
四、單個cookie保存的數據不能超過4K，不少瀏覽器都限制一個站點最多保存20個cookie。
五、因此我的建議：
將登錄信息等重要信息存放爲session
其餘信息若是須要保留，能夠放在cookie中