上文中，談了一些接口測試的概念和原理鸳兽。接口測試的原理很簡單：模擬調用方往接口放數(shù)據(jù)后再校驗拿出來的數(shù)據(jù)。原理說起來的確很簡單罕拂，但如何模擬揍异、如何調用、如何校驗爆班？這些問題你必須在接口測試開始之前都得找到答案衷掷。
如何模擬？
目前柿菩，有很多的接口測試工具戚嗅，例如：postman、jmeter、SoapUI懦胞、robotframework+協(xié)議lib替久、firefox插件RESTClient等，是的躏尉，可以用來做接口測試工具很多蚯根，不同的工具能夠模擬協(xié)議也不盡相同。所以胀糜，需要先知道被測應用的接口是什么協(xié)議颅拦？HTTP、HTTPS教藻、SOAP距帅、XMPP、DUBOBO括堤、FTP锥债、SMTP等，確認接口協(xié)議后痊臭，再來挑選需要使用的接口測試工具哮肚。但作為一個靠譜的測試人員，應該提前儲備這些測試工具的使用方法广匙，在測試需求到來之時能直接上手開展接口測試允趟。
如何調用？
雖然所有的接口測試工具都能手動調用鸦致，但從長遠來看潮剪，更應該去使用支持No Gui（命令行）運行測試集的工具。因為分唾，在前期我們用來做接口手工測試的測試集能很快轉換為接口自動化測試的測試集抗碰，再接入到我們的CI平臺（eg.jenkins、Travis CI等）绽乔，通過Svn操作或定時任務觸發(fā)弧蝇，構建=>發(fā)布=>接口測試=>測試報告=>郵件，從而達到持續(xù)集成（持續(xù)集成不僅僅是接口測試）折砸，快速發(fā)現(xiàn)問題看疗。
如何校驗？
接口測試工具都會展示返回數(shù)據(jù)睦授，并提供展示模板（json两芳、html、xml等）去枷，我們除了校驗數(shù)據(jù)是否正確以外
校驗返回的數(shù)據(jù)格式是否符合協(xié)議文檔（例如：協(xié)議定義返回的數(shù)據(jù)格式是int怖辆，那么返回的數(shù)據(jù)不應該是“1”是复，而應該是類似1這樣的數(shù)據(jù)）
校驗返回的數(shù)據(jù)結構是否符合協(xié)議文檔（例如：協(xié)議定義返回的數(shù)據(jù)結構中name為必返回，那么返回的數(shù)據(jù)中必須包含name）
校驗指定場景下竖螃，非必返回的數(shù)據(jù)是否返回（例如：協(xié)議文檔中的字段sex非必返回淑廊，只有當請求值sex為空時才返回，那么在構造測試用例中斑鼻，要構造請求值sex為空的請求數(shù)據(jù)，再校驗返回的數(shù)據(jù)中是否包含字段sex猎荠，沒有則用例執(zhí)行失敿崛酢）
校驗數(shù)據(jù)持久化正確性（例如：需求定義查詢時保留查詢記錄，那么校驗返回數(shù)據(jù)之外关摇，還得校驗數(shù)據(jù)是否正確持久化荒叶，有沒有存到相關數(shù)據(jù)庫表或緩存服務器中）
從長遠來看，更應該去使用校驗手段更多的接口測試工具（能斷言返回數(shù)據(jù)输虱、能查詢并斷言數(shù)據(jù)庫和緩存服務器些楣、能橫向擴展校驗功能），從而確保全覆蓋的接口自動化測試宪睹。
下圖就是主流測試工具的橫向對比愁茁，僅供參考
總結下：
無編程能力、要快速上接口測試亭病，推薦：postman
要陸續(xù)推進鹅很、深耕接口測試，推薦：Jmeter
想同時推進UI和接口罪帖，推薦robotframework
基于SOAP協(xié)議的接口測試促煮，推薦：SoapUI
事實上，被測應用并不只是單個模塊整袁，很可能是多個產品構成的復雜架構菠齿，這種情況，如何最優(yōu)的進行接口測試坐昙？下篇講解
部分說明：
持續(xù)集成的目的绳匀，就是讓產品可以快速迭代，同時還能保持高質量炸客。它的核心措施是襟士，代碼集成到主干之前，必須通過自動化測試嚷量。只要有一個測試用例失敗陋桂，就不能集成。
Martin Fowler說過蝶溶，"持續(xù)集成并不能消除Bug嗜历，而是讓它們非常容易發(fā)現(xiàn)和改正宣渗。"
在編程語言中，“1”和1是不同的數(shù)據(jù)類型梨州，前者是字符串痕囱，后者是整數(shù)
數(shù)據(jù)持久化：持久化是將程序數(shù)據(jù)在持久狀態(tài)和瞬時狀態(tài)間轉換的機制。通俗的講暴匠，就是瞬時數(shù)據(jù)（比如內存中的數(shù)據(jù)鞍恢，是不能永久保存的）持久化為持久數(shù)據(jù)（比如持久化至數(shù)據(jù)庫中，能夠長久保存）
