2.1 接口
2.1.1 API接口
定義：接口就是API玛迄，是一個軟件或服務器對外提供的接口，別人只要調(diào)用這接口棚亩，而內(nèi)部如何實現(xiàn)蓖议，不需要關心。你只按照要求進行接口調(diào)用即可讥蟆。
外部系統(tǒng)與系統(tǒng)之間以及內(nèi)部各子系統(tǒng)之間的交互點拒担。包括外部接口和內(nèi)部接口。
2.1.2 GUI
GUI 是圖形用戶接口攻询，主要提供可視化界面方面的接口从撼。
2.1.3 接口的表現(xiàn)形式
? ? 客戶要先操作服務端資源，首先要找到服務器端提供的接口钧栖，然后才能向服務端發(fā)送資源請求低零，那么何為服務端接口呢？其實就是一個地址（URL）拯杠，比如
http://www.qubaobei.com/ios/cf/dish_list.php?stage_id=1&limit=20&page=1
2.2 接口專遞數(shù)據(jù)的方式
2.2.1 get方法
Get方式是從服務器上獲取的數(shù)據(jù)：在做數(shù)據(jù)查詢時掏婶，建議使用Get方式；如：公共服務五大服務接口潭陪，查詢接口雄妥，搜索接口，博客訪客接口等依溯。
2.2.2 post方法
post方式是向服務器傳送數(shù)據(jù)老厌；在做數(shù)據(jù)添加、修改或者刪除時黎炉，建議使用post方式枝秤；如 微博圖片上傳圖片 接口 、picself API 接口等慷嗜。
2.2.3 put方法
put這個方法比較少見淀弹。HTML表單也不支持這個丹壕。本質(zhì)來講，put和post極為相似薇溃，都是向服務器發(fā)送數(shù)據(jù)菌赖，但他們之間有一個重要區(qū)別，put通常制定了資源存放位置沐序，而post則沒有盏袄，post的數(shù)據(jù)存放位置由 服務器自己決定。
2.2.4 delete方法
Delete：刪除某一個資源薄啥≡穑基本上這個也很少見。
2.3接口傳遞數(shù)據(jù)的差異性
1.GET后退按鈕/刷新無害垄惧，post數(shù)據(jù)會被重新提交刁愿。
2.GET書簽可收藏，POST書簽不可收藏
3.GET能被緩存到逊，POST 不能被緩存
4.GET歷史參數(shù)保留在瀏覽器的歷史中铣口。post參數(shù)不會保存在瀏覽器歷史中，get對數(shù)據(jù)長度有限制當發(fā)送數(shù)據(jù)時觉壶，get方法向URL添加數(shù)據(jù)脑题；URL長度是受限制的，（URL的最大長度是2048個字符）铜靶。post無限制叔遂。
5.與post相比，get的安全性較差争剿，因為所發(fā)送的數(shù)據(jù)是URL的一部分已艰。在發(fā)送密碼或其他敏感信息時絕不要使用GET
6.post 比 GET 更安全，因為參數(shù)不會被保存在瀏覽器歷史或web服務器日志中
7.GET的數(shù)據(jù)在URL中對所有人都是可見的蚕苇。post的數(shù)據(jù)不會顯示在URL中哩掺。
2.4接口測試
2.4.1概念
測試系統(tǒng)組件間接口的一種測試。接口測試主要用于檢測外部系統(tǒng)與系統(tǒng)與系統(tǒng)之間以及內(nèi)部各個子系統(tǒng)之間的交互點涩笤。
2.4.2 接口測試本質(zhì)和目的
實質(zhì)就是檢驗數(shù)據(jù)的傳輸和接受是否正確嚼吞，傳輸?shù)氖墙涌诘刂分械膮?shù)，接受的是文本字符串/文件蹬碧，然后對比內(nèi)容是否和預期的一樣舱禽。
目的：測試接口的正確性和穩(wěn)定性。
2.4.3接口測試的原理
接口測試的原理是通過測試程序模擬客戶端服務器發(fā)送請求報文锰茉，服務器接受請求報文后對相應的報文做出處理然后再把應答報文發(fā)送給客戶端呢蔫，客戶端接受應答報文這一過程。
2.4.4接口測試流程**
2.5接口測試內(nèi)容
2.5.1功能邏輯
通過查數(shù)據(jù)或緩存等驗證數(shù)據(jù)是否處理正確
通過其他輔助途徑進行驗證
2.5.2異常測試
接口測試中主要測試接口正常邏輯飒筑，但僅邏輯測試不能夠保證數(shù)據(jù)的安全及程序接口在異常情況下的邏輯處理的正確性片吊。
2.5.3路徑測試
當測試接口實現(xiàn)方法中，判斷邏輯復雜分支多协屡，且判斷中又調(diào)用了其他接口俏脊，此時必須要進行路徑覆蓋測試。
2.5.4結構檢查
1.檢查返回值的結構是否正確肤晓，如是json類型還是xml類型的數(shù)據(jù)
2.字段名稱是否正確等
xml和json都是使用結構方法來標記數(shù)據(jù)
2.5.5其他異常的場景
研發(fā)項目爷贫，有些項目是底層使用系統(tǒng)，根據(jù)項目特點补憾，可能會存在特殊的異常場景漫萄。
例如：支付異常操作，支付消息重試等
