接口測試的流程和功能測試流程類似，依據的對象是需求說明書和接口需求，接口測試流程如下：

業務功能（包括正常、異常場景是否實現）

業務規則（覆蓋度是否全面）

參數驗證（邊界、業務規則是否達到要求）

異常場景（重復提交、并發提交、事務中斷、多機環境、大數據量測試

性能測試（響應時間、吞吐量、并發數、資源要求）

安全測試（權限驗證、SQL注入等）

● 檢查接口的功能：檢查接口的功能有沒有實現，也就是請求會不會成功，如果不成功會不會返回錯誤代號（或錯誤信息）；

● 檢查接口返回的數據：檢查接口返回的數據、數據格式、數據類型是否與預期一致（正向且傳遞的參數正常）；

● 檢查接口的容錯性：接口是否可以正常處理（假如傳遞的參數足夠大或者為負、空值時）；

● 檢查接口的性能：http請求接口大多與后端執行的SQL語句性能、算法等比較相關；

● 檢查接口的安全性：外部調用的接口尤為重要。

● 首先根據接口設計的技術架構方案，了解清楚被測接口對應的公共入參、入參、出參及返回數據的Json結構規范，根據測試場景進行測試。

● 理解接口參數，熟悉接口參數的輸入要求、輸入值范圍、必填項等。

● 理解接口輸出，熟悉返回json的結構構成、返回值類別、返回值范圍、返回data的不同類型等。

● 理解接口的邏輯、接口的業務關聯，熟悉技術方案中的接口相互關聯、依賴的關系，接口與接口之間的數據傳遞等。

● 尋找測試點，根據輸入 (參數名、取值范圍)、輸出 (參數名、返回值范圍)、關聯關系，進行測試點分析。

接口測試的主要測試對象是接口，但是隨著系統復雜度越來越高，接口越來越多，完全覆蓋所有接口是很難的一件事情，并且實際過程中任意內部接口的變動都可能導致我們的測試用例的不可用。

接口用例設計優先級

優先級–>針對所有接口

暴露在外面的接口，因為通常該接口會給第三方調用；

供系統內部調用的核心功能接口；

供系統內部調用非核心功能接口。

優先級–>針對單個接口

正向用例優先測試，逆向（異常）用例次之 (通常情況，非絕對)；

是否滿足前提條件 > 是否攜帶默認參值參數 > 參數是否必填 > 參數之間是否存在關聯 > 參數數據類型限制 > 參數數據類型自身的數據范圍值限制。

接口用例設計方法

測試用例編寫注意事項

進行測試執行編寫時，有如下的原則：

1.不同的接口參數覆蓋不同的業務場景；

2.在后臺構造合適的數據來滿足接口的測試用例；

3.根據接口的返回值，斷言其是否返回期望結果，并查看數據庫驗證；

4.測試用例涉及多個步驟的，應對涉及的步驟都驗證；

5.刪除測試過程中產生的結果，確保每個用例執行前都是一個清潔的環境。

接口測試工具選擇

接口工具：Postman/Jmeter/SouapUI/python，單個接口測試時使用 Postman，多個接口測試時可以使用Jmeter，或者使用python腳本；

Jmeter：可以測試各種類型的接口，不支持的也可以通過網上或自己編寫的插件進行擴展。

postman：功能上更簡單，組織方式也更輕量級，它主要針對的就是單個的 HTTP 請求。

接口測試工具根據對比

個人比較喜歡Charles嘛，但是也可以使用fiddler或者其他的抓包工具。

jmeter使用dome

基礎配置，如域名、環境配置等，單出文件配置，方便不同環境測試、腳本維護；

明確接口實現什么樣的功能，實際需要什么樣的功能，是否一致；

接口測試數據太多，用該數據驅動模式更有層次，且易于維護；

要在眾多測試用例中選出冒煙測試用例及可用于性能測試的用例；

先單接口測試，再多接口業務測試；

測試完成以后，需要清洗臟數據。

11.1 使用Jmeter測試接口實例

接口測試環境準備

Jdk1.8 或以上：

http://www.oracle.com/technetwork/java/javase/downloads/index.html

Jmeter 下載址址：http://jmeter.apache.org/download_jmeter.cgi

插件的下載安裝地址：http://www.jmeter-plugins.org/

既然使用到了jmeter團隊又是多人的情況下，那么 jmeter 腳本的生產力是一個很大的問題，再加上團隊不是每個人對 jmeter 的熟悉程度都是不一樣的，所以腳本的編寫和快速生產就是個問題，針對這個個人建議腳本的生產建議從以下幾個方面考慮；

使用jemter原生的錄制器；

手寫jmeter腳本，但是需要對jmeter相對熟悉；

使用fiddles抓包工具導出生產；

針對web頁面個人推薦BlazeMeter的谷歌插件。

針對以上五種生產jmeter腳本快速生產的方案，都可以很好的輔助編寫jmeter 的腳本，在這里很多同學肯定會問為什么不使用metersphere，這個項目本身很優秀了，但是由于公司的原因，所以最后放棄，很多同學肯定想，錄制生成，直接回訪就完事，我只能說太簡單，這樣你的腳本使用一次基本就報廢， 會造成腳本的重復編寫費時費力，這個時候，需要測試強硬一點了大家采用統一的錄制控制方式去錄制，同意腳本編寫的方案，畢竟在怎么錄制都是不行的，所以最好的實踐方式就是采用錄制為主，修改為輔的解決方式，去編寫復用率高的腳本。

相信jmeter很多測試小伙伴都很熟悉，肯定也都熟悉他有一個最大通病，就是case太多的時候，一點都不方便管理。

其實這個問題，我也遇見了，因為現在的團隊不只是我一個人單打獨斗，我還有隊友，所以對jmx腳本的管理，我在團隊里面采用的是git管理我們的腳本，我們在團隊內部和開發約束，測試環境的時候，所有的部署都走test的一個代碼分支，這樣做的好處，就是為了減輕jmx腳本的復雜性，同時也避免了在發布生產環境的時候，將腳本發布到生產環境，因為最初的初衷使用jmeter做接口測試的情況下，就是因為團隊開發的同學不寫單元測試，測試同學會Java的只有一兩個，服務又多，公司的迭代速度又快，開發提測的功能一直沒有很好的健壯性，所以，我在想能不能在開發部署成功的時候或者定時輪詢執行一下每個服務的接口，以達到提測的質量。

在團隊實踐中也遇到了一些問題如下：

token的時效性原因，導致腳本老是執行失敗；

數據的唯一性，例如我每次請求的時間都是不一樣的等；

數據庫的連接數老是超標，因為團隊存在多個項目組，他們之間又是使用相同的數據庫，只是不同表；

Jenkins的并發限制，因為大家都是使用同一個Jenkins，不可能你一個老是占用Jenkins的執行。

針對以上的問題，我個人是如下解決的，首先token校驗的問題，存在這個問題的根本原因，是因為我們每次登錄都是圖片驗證碼的登錄，但是我又不能識別，只能求助開發經理，讓他在測試環境給我們測試寫了一個萬能驗證碼，再拿這個這個驗證碼去刷新token和或獲取對應的op（op參數是內部特有的驗證）

數據的唯一性，這個當時頭疼了好久，最后只能去百度，最后發現jmeter還有很強大的功能，就是函數助手，里面有各種函數，例如獲取時間戳，隨機數，生成uuid等，直接開箱即用。

熟悉mysql的小伙伴都知道MySQL的默認最大連接數是200數據庫連接池老是超標，最后查看了mysql日志發現連接數占用最大的是開發的代碼里面寫了很多多表聯查的大SQL，尤其是公司大數據那幫人的sql一個SQL語句執行半個小時…因為去年(2020年)MTSC深圳站的時候，聽了唯品會的同學分享接觸到了，sql掃描檢查，當時在sonar掃描代碼的時候，加入了sql的掃描，和開發老大商量，去除了項目中大部分的長sql語句，最后去請教了運維的同學和公司dba的大佬，當時運維同學有點不配合的，最后買了一包好煙，在加各種舔，最終終于同意擴大數據庫的連接數，最終勉強解決了這個問題。

jenkins并發機制的問題，這個是jenkisn本身就存在的瓶頸，當時給公司運維提了個需求，讓他多起幾個jenlkins的的節點，測試專門使用一個節點。

由于使用了jmeter為了測試的時候，可以實時查看，個人建議使用 influxdb+cadvisor+grafana 搭建一套配合 jmeter 的報告可視化的監控系統。

搭建步驟如下

創建容器掛載目錄

mkdir -p /dockerdata/influxdb
mkdir -p /dockerdata/grafana

安裝 influxdb 數據庫

docker run -d \-p 8083:8083 \-p 8086:8086 \--expose 8090 \--expose 8099 \--name influxsrv \-v $PWD:/var/lib/influxdb \influxdb;

安裝 cadvisor 容器監控

docker run \
--volume=/:/rootfs:ro \
--volume=/var/run:/var/run:rw \
--volume=/sys:/sys:ro \
--volume=/var/lib/docker/:/var/lib/docker:ro \
-p 8081:8080 \
--detach=true --link influxsrv:influxsrv \
--name=cadvisor \
google/cadvisor:latest \
-storage_driver=influxdb \
-storage_driver_db=cadvisor \
-storage_driver_host=influxsrv:8086;

安裝 grafana

docker run \
-d \
-p 3000:3000 \
-e INFLUXDB_HOST=localhost \
-e INFLUXDB_PORT=8086 \
-e INFLUXDB_NAME=cadvisor  \
-e INFLUXDB_USER=root \
-e INFLUXDB_PASS=root  \
--link influxsrv:influxsrv \
-v $PWD:/var/lib/grafana \
--name grafana \
grafana/grafana;

最終結果如下

需要注意的點

既然使用influxdb存儲jmeter的數據，那么就不得不提jmeter的Backend Listener后端控制器，的配置，這個超簡單，但是我沒有使用默認的，因為默認的只能查看 壓測的tps這些，再加上腳本的每個場景接口我加入事務控制器，所以我采集的是事務控制器，一個事務代表一個接口或者代表多個接口；

啟動了influxdb之后需要進入容器創建對應的數據庫，要不數據沒辦法存儲；

為了方便在grafana上面看到了每個接口的請求參數和返回值，這個是因為之前公司每個項目已經接入普羅米修斯的監控，在配置普羅米修斯監控的時候，我們加入了自定義監控，所以這款我直接使用普羅米修斯原有的配置的面板；

還有因為插件的原因當時遇見了influxdb里面沒辦法失敗 “/” 所以控制器的命令 “/” 可以使用下劃線代替。

接口測試經常遇到如下的bug和問題：

傳入參數處理不當，導致程序 crash;

類型溢出，導致數據讀出和寫入不一致；

因對象權限為進行校驗，可以訪問其他用戶敏感信息；

狀態處理不當，導致邏輯出現錯亂；

邏輯校驗不完善，可利用漏洞獲取非正當利益等。

接口自動化框架：Jmeter+maven+Jenkins+git

Jmeter作為執行者的角色，每次負責執行具體的接口/性能測試腳本，并得到結果，生成報表。

Maven和Git是作為管理者角色，前者主要負責項目的依賴管理，而后者主要負責項目的代碼管理。

Jenkins作為調度者，主要根據我們設置的build觸發條件和事件調用jmeter進行測試 ## maven集成jmeter插件。

<dependency><groupId>org.apache.jmeter</groupId><artifactId>ApacheJMeter_components</artifactId><version>5.4.1</version>
</dependency>

jmeter 鏡像的制作

因為在上面我們說了我們使用了自己的Backend Listener插件，由于網絡原因，所以在運行docker容器的時候，我們需要將jmeter容器使用-v參數掛在到本地。

再加上網絡的原因，我們只能自己制作鏡像了，制作鏡像的dockerfile如下：

FROM java:8
ENV http_proxy ""
ENV https_proxy ""RUN mkdir /jmeterdocker
RUN mkdir -p /jmeterdocker/test
RUN mkdir -p /jmeterdocker/test/input/jmx
RUN mkdir -p /jmeterdocker/test/input/testdata
RUN mkdir -p /jmeterdocker/test/report/html
RUN mkdir -p /jmeterdocker/test/report/jtl
RUN mkdir -p /jmeterdocker/test/report/outputdata
RUN chmod -R 777 /jmeterdockerRUN cd /jmeterdockerENV JMETER_VERSION=5.4.1
ENV JMETER_HOME=/jmeterdocker/apache-jmeter-${JMETER_VERSION}
ENV JMETER_PATH=${JMETER_HOME}/bin:${PATH}RUN wget https://archive.apache.org/dist/jmeter/binaries/apache-jmeter-${JMETER_VERSION}.tgz
RUN tar -zxvf apache-jmeter-${JMETER_VERSION}.tgz
RUN rm apache-jmeter-${JMETER_VERSION}.tgz

需要注意的點

因為使用了docker啟動運行容器，那么在運行完成之后，需要在對應的shell腳本中接入如下命令在每次運行構建之前刪除對應的容器。

docker rm - f [容器name]

測試前置、開發自測

一個新的自動化接口測試案例開發完成后，直接發給接口對應的開發，安排在開發本地環境執行，一旦開發確認完成接口開發，就開始執行接口測試案例，基本上可以實時拿到測試結果，方便開發快速做出判斷。【開發本地運行的方式就是打開JMeter工具，導入JMX文件，開始執行可。

回歸測試：開發本地測試通過后，或整個需求手工測試通過后，把自動化的接口測試案例做分類整理，挑選出需要納入到回歸測試中的案例，在持續集成環境重新準備測試數據，并把案例納入到持續集成的job中來，這些用于回歸的接口測試案例需要配置到持續集成平臺自動運行。對接口測試而言，持續集成自動化是核心內容，通過自動化的手段才能有效降低成本，提高接口測試的價值。如果使用LR、JMeter、SoapUI工具做自動化測試，工具本身支持命令行模式運行，可以結合Jenkins等自動化平臺，實現項目版本更新后的自動化回歸測試。

關于持續自動化回歸測試的建議：

接口腳本開發時要注意參數的取值的可用性，不因為時間或數據狀態的變化引起腳本不能正常運行，降低腳本維護成本。

接口回歸功能的覆蓋度控制，需要根據腳本的實際功能和重要性判斷自動化回歸覆蓋度，回歸內容越多腳本維護成本越高，一般應用接口不建議全功能覆蓋（畢竟接口有變化會做詳細測試，如果沒修改其它變更可能對其產生的影響一般不會影響其邏輯判斷）。

接口腳本需要一定的自動化校驗能力，除請求http狀態的判斷外，還需要對核心內容的正常性做判斷（判斷內容可與數據庫內容匹配等方式，不建議用寫死的內容）。

持續性能測試，還需要做好相關的監控、性能指標的分析自動化，減少人工操作。

最后：?為了回饋鐵桿粉絲們，我給大家整理了完整的軟件測試視頻學習教程，朋友們 如果需要可以自行免費領取?【保證100%免費】

軟件測試面試文檔

我們學習必然是為了找到高薪的工作，下面這些面試題是來自阿里、騰訊、字節等一線互聯網大廠最新的面試資料，并且有字節大佬給出了權威的解答，刷完這一套面試資料相信大家都能找到滿意的工作。