1. 在實際介面測試中，介面測試工作的詳細開展方式是怎麼樣的
在實際工作中，介面的展現形式不是固定。但是市場上，最多的還是HTTP協議的介面測試。
基於HTTP協議的介面測試，工作開展方式類似於這樣：
項目立項階段 -> 項目經理、產品經理、測試經理、CEO等人員參與
需求階段 -> 產品經理根據項目，輸出需求規則說明書，產品說明書；然後需求評審
項目排期 -> 項目經理根據產品功能，確定開發、測試、上線計劃的時間節點
研發階段 -> 輸出概要設計和詳細設計文檔，並且各個角色根據文檔設計系統架構、資料庫、配置文件；並開始編寫業務功能的代碼
測試階段 -> 單元測試、集成測試、系統測試、驗收測試（介面測試屬於集成測試）
發布上線 -> 上線問題驗證和維護
測試階段的細節：
測試工作的開展，與公司對測試流程的管理和把控有很大關系，不同的公司，把控力度都不一樣。在標準的測試流程裡面，我們需要編寫測試用例，但是有的公司甚至測試用例都不用寫，對測試質量的控制，停留在「測試人員的責任心和技術水平」上。
如果是一個有前後端的項目，那麼介面測試流程是這么開展的：
1. 後端開發人員完成代碼編寫，輸出介面文檔
2. 前端開發和後端開發進行前後端聯調，打通主幹流程；聯調結束後，後端開發人員提測介面
3. 介面測試人員，根據後端開發的提測的介面，按照介面文檔在【測試環境】進行介面測試。此時前端開發人員在並行開發前端頁面
4. 此時，由於項目中，前端開發、後端介面都在同時進行，所以會出現測試和前端開發的進度問題：
前端開發完成、介面測試完成：這是最理想的情況，此時手工功能測試介入測試，介面測試人員進入驗收測試。
前端開發完成、介面測試未完成：此時手工功能測試也會介入測試，與介面測試並行測試；（PS：如果功能測試結束了，介面測試依然未完成，那麼手工功能和介面一起進入驗收測試。）
前端開發未完成、介面測試已完成：手工功能測試無法介入。
5. 【測試環境】的介面測試結束後，介面測試人員需要在【驗收環境】進行驗收回歸測試
6. 【驗收環境】執行通過後，介面測試人員，可以把介面自動化腳本，利用持續集成技術，集成到平台中，進行持續的校驗。
7. 最後發布上線後，一般介面測試人員不需要介入生產環境的介面測試。但是少數情況下，介面測試人員，也需要在生產環境進行介面測試（不建議）
了解了嗎？如果想晉升，或者是學習軟體測試的最新知識，歡迎來看黑馬程序員視頻庫內容，有最新的軟體測試學習內容哦！
2. 如何進行介面測試，如何做好介面測試
題主所說的介面是指server後台提供給前端調用的api介面還是程序內部提供的類介面；
不管是哪一種，做介面測試都要明確想要藉助介面測試達到的測試目的，不同的公司、項目和背景下相應的要求都不同；
一般來說如果是server介面測試，基本目的是為了測試覆蓋後台的介面業務能力，保證在後端提供介面之後立即能夠執行測試，而不需要延遲到客戶端聯調才來發現介面本身存在的業務問題；對於server介面測試，一般的要求是快速反饋、可持續迭代、問題定位方便；通常用例設計上不考慮異常值的case，這些由客戶端調用時驗證並保證；介面框架和用例的實現通常比較簡單，除非調用介面的協議是私有協議，這種情況下就需要構建對應的消息請求接收器。
如果是內部類介面的測試，屬於單元測試范疇，具體要求也是視情況而定，但一般也是為了保證提供的類介面功能的准確性；具體實現上要注意，類介面的單元測試對於類介面一般會要求開發盡量解耦，如果解耦不徹底在編寫測試代碼時往往要藉助打樁[stub]或者模擬[mock]；
總的說來，想做好介面測試，必須先明確測試的目的，否則容易出現很多形式上的代碼實際沒有半毛錢用處，反而浪費人力物力。
3. app有哪些介面需要測試
一般原生App各自使用系統的方法測試介面即可完成開發並提交。如果讓h5自己調用一些原生介面，由於Andriod和iOS系統，Pad版本等等不一樣的原因，H5可能需要做一大堆的判斷去做兼容，這會大大加大前端的工作量，而且很容易出現兼容性問題。所以讓Android和iOS原生預定義一些統一的介面，h5直接調用使用，從而免去了復雜的兼容性判斷，大大地減少前端工作，也使得性能更好。同時這里也可以看出介面測試最重要的一方面測試——兼容性測試，測試必要盡可能大地覆蓋系統版本，解析度，機型。
4. 為什麼做介面測試介面測試能發現哪些問題
舉個例子吧：
測試用戶注冊功能，規定用戶名為6~18個字元，包含字母（區分大小寫）、數字、下劃線。首先功能測試時肯定會對用戶名規則進行測試時，比如輸入20個字元、輸入特殊字元等，但這些可能只是在前端做了校驗，後端可能沒做校驗，如果有人通過抓包繞過前端校驗直接發送到後端怎麼辦呢？試想一下，如果用戶名和密碼未在後端做校驗，而有人又繞過前端校驗的話，那用戶名和密碼不就可以隨便輸了嗎？如果是登錄可能會通過SQL注入等手段來隨意登錄，甚至可以獲取管理員許可權，那這樣不是很恐怖？
所以，介面測試的必要性就體現出來了：
①、可以發現很多在頁面上操作發現不了的bug
②、檢查系統的異常處理能力
③、檢查系統的安全性、穩定性
④、前端隨便變，介面測好了，後端不用變
5. 介面測試測試點
1.可以發現很多在頁面上操作發現不了的bug（介面的）
2.可以檢查系統（介面）的異常處理能力
3.可以檢查系統（介面）的安全性、穩定性
4.前端隨便變，介面測好了，後端不用變
5.可以測試並發情況，一個賬號，同時（大於2個請求）對最後一個商品下單，或不同賬號，對最後一個商品下單
6.可以修改請求參數，突破前端頁面輸入限制（如金額），檢查系統（介面）有沒有進行校驗
6. 啥是介面測試
介面也就是我們通常說的API吧，個人認為介面分為程序內部介面，程序外部介面，內部介面的測試通常是進行白盒測試（測試通常是開發進行的），你這里說的應該是程序的外部介面。其實程序的外部介面也可以進一步細分的，比如組件的介面，web服務介面等等。對於組件的介面的測試也是使用白盒測試的，需要准備驅動程序。而web服務介面的測試，可以藉助一些工具來進行。你說的淘寶的介面測試應該就是對web服務的測試，其實原理就是你根據web服務的格式要求准備測試數據（xml文件），然後通過工具把請求發送的web伺服器，然後驗證返回的結果。
7. 什麼是介面測試
介面測試是測試系統組件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及百內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。
由於如今的系統復雜度不斷度上升，傳統的測試方法成本急劇增加且測試問效率大幅下降，所以就要做介面測試。同時，介面測試相對容易實現自動化持續集成，且相對UI自動化也比較穩定，可以減少人工回歸測試人力成本與時間，縮答短測試周期，支持後端快速發版需求。介面持續集成是為什麼能低成本高收益的根源。現在很多系統前後端架構是分離的，從安全層面來說，只依賴前端進行限制已專經完全不能滿足系統的安全要求(繞過前面實在太容易)，
需要後端同樣進行控制，在這種情況下就需要從介面層面進行驗證。前後端傳輸、日誌列印等信息是否加密傳輸也是需要驗證的，特別是涉及到用戶的屬隱私信息，如身份證，銀行卡等。
8. 介面測試的類型有哪些
我們在做介面測試的時候通常是對普通的http協議介面進行測試。但實際上介面測試還有很多種類型，下面就列舉下介面測試的具體類型
①基於http協議的介面，具體分為get、post、put、delete類型的介面
②基於web service的介面，具體有如下3種：
Ⅰ. SOAP類型，表示簡單對象訪問協議的一種介面
Ⅱ. RMI類型，針對於java語言的一個介面
Ⅲ. RPC類型：遠程過程調用協議，程序可向網路中另一台計算機請求服務
建議多去聽聽黑馬程序員視頻庫，此類的知識點有非常多，而且還是免費的。
9. 介面測試的測試點有哪些
介面測試是測試系統組件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。
測試的策略：
介面測試也是屬於功能測試，所以跟我們以往的功能測試流程並沒有太大區別，測試流程依舊是：
評審測試介面文檔（需求文檔）
根據介面文檔編寫測試用例（用例編寫完全可以按照以往規則來編寫，例如等價類劃分，邊界值等設計方法）
執行測試，查看不同的參數請求，介面的返回的數據是否達到預期
介面的功能是否正確實現了
介面是否按照設計文檔中來實現（比如username參數寫為了user，那麼這就不符合，因為介面文檔在整個開發中都需要使用，所以介面實際的設計要與介面設計文檔中保持一致）
兼容性測試： 比如說今天介面進行了調整，但是前端沒有進行變更，這時候需要驗證新的介面是否滿足舊的調用方式
錯誤碼測試： 通用的錯誤碼與業務錯誤碼是否能夠清晰的說明調用問題，錯誤碼是否能夠盡可能的全的覆蓋所有的情況
返回值測試： 返回值除了內容需要是正確的，還需要類型也是正確的，保證調用方拿到這些參數能夠正確的解析
參數邊界值、等價類測試
json格式測試： 通常我們的介面一般設計的都是傳遞json串，那麼就需要去測試 如果傳遞非json的情況，這時候程序會不會正確的處理，返回相應的 error code
默認值測試： 很多情況一些非必填的參數會有默認值，比如說一個查詢的介面，參數count為返回查詢的結果數量， 默認為10，那麼就應該有一條case來測試，當然前置條件是資料庫裡面必須要存在這樣的數據超過10條。
是否有依賴業務，比如查看訂單，是需要用戶首先登錄的，所以肯定要保證登錄了或有相應的cookie
業務邏輯測試： 傳遞正確的參數，介面對資料庫進行查詢的操作，需要去驗證資料庫查詢是否正確，介面對資料庫進行 增刪改的操作，也需要看資料庫是否同步進行了這些操作
關鍵字參數：將參數寫為開發語言中的關鍵字
參數為空：比如去掉了username參數
多或少參數：多或者少參數的驗證，現在還不確定如果一個介面多了參數如果沒有報錯是否是合理的，或者是否需要優化，因為就目前開發給予的答案是，一般不對介面多了參數的處理
錯誤參數：比如將username參數寫為了user等看是否能返回相應的errorcode
關鍵字數據：將參數的值填為開發語言中的關鍵字
數據為空：將參數的額值填為空
長度不一致：因為資料庫中每個欄位都設置有欄位長度，填寫不符合的長度進行驗證
錯誤數據：就是將參數的值任意填寫，或填寫不存在的數值
異常類型測試： 比如count參數，這個參數的類型一定是可以轉換為int類型的，這時候我們需要測試如果傳的一些不可以 轉換為int類型值來測試代碼是否加入判斷
響應時間
吞吐量
並發用戶數
佔用內存，CPU等
敏感信息是否加密
必要參數是否後端也進行校驗（現在很多系統前後端架構是分離的，從安全層面來說，只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前端太容易了）， 需要後端同樣進行控制，在這種情況下就需要從介面層面進行驗證）
介面是否防惡意請求（SQL注入）
cookie：就是將header中的cookie修改或刪除後看是否能返回相應的errorcode
header：就是刪除或修改header中部分參數的值，看是否能返回相應的error code
唯一識別碼：刪除修改唯一識別碼測試
那麼設計測試用例時我們主要考慮如下幾個方面：
功能測試：
邏輯業務：
異常測試：
異常分為兩類，參數異常和數據異常
參數異常：
數據異常：
性能測試：
安全性測試：
10. 常見的介面測試工具有哪些
介面一般來說有兩種，一種是程序內部的介面，一種是系統對外的介面。
系統對外的介面：比如你要從別的網站或伺服器上獲取資源或信息，別人肯定不會把資料庫共享給你，他只能給你提供一個他們寫好的方法來獲取數據，你引用他提供的介面就能使用他寫好的方法，從而達到數據共享的目的，比如說咱們用的app、網址這些它在進行數據處理的時候都是通過介面來進行調用的。
程序內部的介面：方法與方法之間，模塊與模塊之間的交互，程序內部拋出的介面，比如bbs系統，有登錄模塊、發帖模塊等等，那你要發帖就必須先登錄，要發帖就得登錄，那麼這兩個模塊就得有交互，它就會拋出一個介面，供內部系統進行調用。
一、常見介面：
1、webService介面：是走soap協議通過http傳輸，請求報文和返回報文都是xml格式的，我們在測試的時候都用通過工具才能進行調用，測試。可以使用的工具有SoapUI、jmeter、loadrunner等；
2、http api介面：是走http協議，通過路徑來區分調用的方法，請求報文都是key-value形式的，返回報文一般都是json串，有get和post等方法，這也是最常用的兩種請求方式。可以使用的工具有postman、RESTClient、jmeter、loadrunner等；
二、前端和後端：
在說介面測試之前，我們先來搞清楚這兩個概念，前端和後端。
前端是什麼呢，對於web端來說，咱們使用的網頁，打開的網站，這都是前端，這些都是html、css寫的；對於app端來說呢，它就是咱們用的app，android或者object-C（開發ios上的app）開發的，它的作用就是顯示頁面，讓我們看到漂亮的頁面，以及做一些簡單的校驗，比如說非空校驗，咱們在頁面上操作的時候，這些業務邏輯、功能，比如說你購物，發微博這些功能是由後端來實現的，後端去控制你購物的時候扣你的余額，發微博發到哪個賬號下面，那前端和後端是怎麼交互的呢，就是通過介面。
前面說的你可能不好理解，你只需記住：前端負責貌美如花，後端負責掙錢養家。
三、什麼是介面測試：
介面測試是測試系統組件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。
OK，上面是網路上說的，下面才是我說的
其實我覺得介面測試很簡單，比一般的功能測試還簡單（這話我先這樣說，以後可能會刪O(∩_∩)O哈！），現在找工作好多公司都要求有介面測試經驗，也有好多人問我（也就兩三個人）什麼是介面測試，本著不懂也要裝懂的態度，我會說：所謂介面測試就是通過測試不同情況下的入參與之相應的出參信息來判斷介面是否符合或滿足相應的功能性、安全性要求。
我為啥說介面測試比功能測試簡單呢，因為功能測試是從頁面輸入值，然後通過點擊按鈕或鏈接等傳值給後端，而且功能測試還要測UI、前端交互等功能，但介面測試沒有頁面，它是通過介面規範文檔上的調用地址、請求參數，拼接報文，然後發送請求，檢查返回結果，所以它只需測入參和出參就行了，相對來說簡單了不少。