伺服器介面測試

1、如何做介面測試

1、可以使用postman軟體進行介面測試，這里以較復雜的上傳圖片的介面為例進行測試，首先打開postman軟體選擇Post方式，輸入後台介面調用地址。

2、然後填寫Headers，注意這里的Headers部分不要寫任何東西，如果之前是有Content-Type頭信息， 那麼就會上傳失敗。

3、接著填寫Body，選擇form-data，填寫Key後台規定的接收文件的名稱參數，格式選擇為File，此時value會自動變成選擇文件。

4、最後點擊Send，可以發現下方返回了介面的響應，說明上傳圖片是成功的，這樣簡單的圖片上傳的介面測試就完成了。

2、介面測試流程是什麼？

1介面測試的定義與分類，以下就是介面測試
介面測試是測試系統組件間介面的一種測試。
主要用於檢測外部系統與系統之間以及系統內部各個子系統之間的交互點。
重點測試數據的交換、傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等等。
這要求對業務邏輯有一定程度上的理解，對數據流向有較好的定位。
介面測試般會用於多系統間交互開發，或者擁有多個子系統的應用系統開發的測試。
介面測試適用於為其他系統提供服務的底層框架系統和中心服務系統，主要測試這些系統對外部提供的介面，驗證其正確性和穩定性。
介面測試同樣適用於一個上層系統中的服務層介面，越往上層，其測試的難度越大。
介面測試實施在多系統多平台的構架下，有著極為高效的成本收益比。
介面測試天生為高復雜性的平台帶來高效的缺陷監測和質量監督能力。平台越復雜，系統越龐大，介面測試的效果越明顯。
介面測試的目的是測試介面，尤其是那些與系統相關聯的外部介面，測試的重點是要檢查數據的交換、傳遞和控制管理過程，還包括處理的次數。外部介面測試一般是作為系統測試來看待的。
不是所有的團隊都可以在一個隔離的測試環境中進行測試工作的，因此使得對外部介面的測試顯得困難。
我們應該確保較早地與相關的組織協調好並確定進行外部介面測試的方案。
有時候相關的組織只是人工的靜態的審閱一次數據而並不真正的用這些數據來測試，這些都增加了實際測試執行中遇到的風險，但有些時候是可以避免的。
介面測試有的公司是歸納在集成測試裡面，也有的公司會放在系統測試階段，不過這個都沒有什麼區別，本質上介面測試就是通過某個功能模塊對外暴露的一個介面地址傳參進行測試。
一般來說介面分為如下三類：
A. 系統與系統之間的調用(如我們一般常見的分享內容到朋友圈或者是微信朋友時，微信會提供介面給這些需要用到分享的應用)上層服務對下層服務的調用（這個理解難度稍微有點大，在我們程序中功能是分層的，那麼屬於上層對底層服務的調用，以後能夠有機會接觸到代碼或者更加稍微復雜點的介面測試就能夠理解。舉個例子，我們的程序框架分為三層，分別是web層：提供給用戶請求的層次；feb遷至層：作為信息傳遞的中轉站；service層：作為程序應用的核心，處理所有的請求
C.服務之間的調用（如添加一條數據時，會先調用數據查詢的服務，查詢該數據是否是重復數據）
不同類型的介面測試方法可能不一致，但總體來說不管是哪種類型，被測介面即為服務，測試手段為客服方，介面測試的目的就是：通過我們的測試手段，去驗證滿足其申明提供的功能。
2如何做介面測試
介面測試的原理：通過測試程序模擬客服端向伺服器發送請求報文，伺服器接收請求報文後對相應的報文做出處理然後再把應答報文發送給客戶端，客戶端接收應答報文這一過程（reques->response）。
介面測試的流程與功能測試有什麼區別呢？從原則上以及流程上講，是沒有啥區別的，都同一套軟體測試流程：需求討論->評審需求->確定需求->產出介面定義->根據需求文檔及介面定義設計測試用例（測試用例主要從業務場景，功能以及異常測試幾個方面考慮）->評審用例->執行測試。
介面測試採用的最基本的就是黑盒測試，在這個測試過程中我們最需要關注的是，如何來設計測試用例，設計測試用例所採用的方法也是我們常所用的幾大方法：等價類、邊界值以及錯誤推測法、場景法。在設計測試用例之前，我們先來看看常見的介面文檔形式。
這就是上圖是一種比較規范的介面文檔說明，包含了如下內容模塊：介面的類型說明、介面地址、http請求方式、輸入參數和請求介面後返回的響應結果。
介面測試編寫測試用例，主要關注點是輸入參數、輸出結果以及內部業務邏輯是否正常『，所以我夢設計用例也要從這幾方面出發考慮：
a）輸入參數測試：針對輸入參數進行的測試，也可以說是假定介面參數的不正確性 進行的測試，確保介面對任意類型的輸入都做了相應的處理：輸入參數合法（不合法），輸入參數為空，為null,輸入參數超長等等；
b）介面是否滿足了所提供的功能，相當正常情況測試，如果一個介面功能復雜時推薦對介面用例進行結構劃分，這樣子用例就有更好的可讀性和可維護性；
c）邏輯測試：邏輯測試嚴格講應為單元測試，單元測試應保持內部邏輯的正確性，可單元測試和介面測試的界限並不是那麼清晰，所以我們也可以從給出的設計文檔中考慮內部邏輯錯誤的分支情況和異常；
d）異常情況介面測試：介面實現是否對異常情況都進行了處理，介面輸入參數雖然合法，但是在介面實現中，也會出現異常，因為內部的異常不一定是輸入的數據造成的，而有可能是其他邏輯造成的，程序需要對任何異常都進行處理；
針對上面的注冊介面，我們利用測試用例設計方法來編寫測試用例，如下所示：
3介面測試的工具選擇
可以進行介面測試的工具有很多，這里簡單介紹幾個：
>loadrunner :一款商業性能測試工具，用來做介面測試，很好很強大。
>jmeter :一款開源的性能測試工具，操作簡單方便，既有jdbc request 操作資料庫數據，也有http request 和 soap request 應對測試；
>httprequester :火狐瀏覽器自帶介面測試工具，插件中安裝即可，界面簡單明了，容易上手。
>postman :谷歌瀏覽器的擴展工具，界面簡潔，開發者比較常用的一款插件工具。
>soapui : 開源測試工具，通過soap/http 來檢查、調用、實現web service的功能/負載/符合性測試。
我們將在後面的教學中，重點講解Jmeter這款綜合性比較高的工具；

3、介面測試怎麼做

首先弄懂測試的需求，比如介面功能測試需求是什麼（什麼樣的輸入參數，返回什麼樣的輸出）、介面性能測試需求是什麼（最大支持多少並發訪問，後台伺服器資源配置極限是多少等等）

然後選擇一款介面測試工具（一般推薦 POSTMANJMETER等等），也可以自己開發介面工具。

編寫介面功能測試和性能測試的用例（這個和一般的黑盒測試用例差不多，預置條件，測試步驟，預期結果）

使用測試工具或者腳本，執行測試用例。含提交BUG，跟蹤BUG閉環等等。

分析測試結果，出具測試報告。

PS：介面的功能測試很簡單，一般是訪問的URL，帶什麼參數，然後什麼加密方式，然後看返回值符不符合預期就可以了，把各種正常異常情況考慮到。介面性能測試的話除了要設置集合點並發訪問後台介面，然後還要在後台伺服器加監控，以便於檢測系統資源，一般通用的監控指標CPU內存 網路 等等。當然具體也要看你要測試什麼樣的介面，弄懂介面的協議再測試。希望能幫到你。

4、如何做介面測試？

對於介面測試，首先測試人員要懂代碼，你只需要知道介面的作用是什麼就可以了，其次，自己去讀開發的代碼。

然後，根據該介面功能及代碼寫測試用例：根據該介面參數，構造不同的用例，測試介面在參數合法及非法情況下能否達到預期效果，根據該介面中的邏輯，測試該介面實現代碼的邏輯，進行容錯及健壯性測試，靜態檢測代碼，看是否有內存泄露、或永遠走不到的分支、代碼規范及邏輯是否合理，對於一些介面，需要進行多線程測試。

5、windows伺服器怎麼做介面測試

伺服器測試方法

伺服器測試方法分為兩個大方面，性能測試與功能測試。

我們在性能測試方面採用了新的測試方法，主要分為文件測試、資料庫性能測試與
Web
性能測試三個
方面。其中，文件性能與資料庫性能採用美國
Quest
軟體公司的
Benchmark Factory
負載測試和容量規劃
軟體，
Web
性能測試則使用了
Spirent
公司提供的
Caw WebAvalanche
測試儀。

一、性能測試

1
、文件性能測試方法

Benchmark Factory
軟體能按照文件讀寫的關鍵指標定製事務。軟體最大支持
1000
個虛擬客戶。

本次測試環境包括
10
台配置為
PIII800/128MB
內存
/20G
硬碟以上的客戶端，它們用來模擬虛擬用戶。
控制台為配置是
PIII 850/128MB
內存
/40G
硬碟的
Acer
筆記本電腦。交換機為帶有兩個千兆
GBIC
介面、
24
個
10/100M
自適應埠的
Cisco 2950
，客戶端與控制台通過
100M
網卡連到交換機上，被測伺服器則通
過千兆光纖網卡與交換機相連接。

被測伺服器均安裝帶
SP4
的
Windows
2000
Advanced Server
操作系統，在所有三項性能測試中都統一
RAID
級別為
5
。

在具體測試方案設置上，測試軟體把決定文件讀寫操作的關鍵因素設定為：讀
/
寫、隨機
/
順序、操作
塊大小、對象大小四個。在本次測試中，考慮到我們設有單獨的資料庫及
Web
測試項目，所以在文件測試
中，我們把目標確定為測試伺服器基本的
I/O
性能，這主要由網路介面、系統帶寬、磁碟子系統等幾大部
分所決定。同時，從幾部分的作用看，以大操作塊讀寫大對象文件，小操作塊讀寫小對象文件，較能反映
伺服器最基本的
I/O
性能，即「大操作塊讀寫大文件」對系統帶寬、緩存的考察，以及「小操作塊讀寫小
文件」對磁碟子系統、網路介面的考察。最終我們確定的四個事務是：

大文件順序讀寫
(
操作塊
8KB
，對象文件
80% 500KB
、
20% 1MB)

大文件隨機讀寫
(
操作塊
8KB
，對象文件
80% 500KB
、
20% 1MB)

小文件隨機讀
(
操作塊
1KB
，對象文件
80% 1KB
、
10% 10KB
、
10% 50KB)

小文件順序寫
(
操作塊
1KB
，對象文件
80% 1KB
、
10% 10KB
、
10% 50KB)

每個事務的用戶數均以固定步長逐漸增加，
最大可增加到
1000
個虛擬用戶。
其中，
「大文件順序讀寫」
事務的用戶數按照
40
的步長從
1
可增加到
400
個
(
測試至強伺服器
)
或
200
個
(
測試
TUALATIN
伺服器
)
，其
他事務則將用戶數按照
100
的步長從
1
增加至
1000
。我們期望得到其在不同用戶數時被測伺服器的性能表
現。總體上其走勢及峰值反映了該伺服器的性能。每項事務均運行三次，每次之間被測伺服器進行重啟，
最終結果為三次平均值。

2
、資料庫性能測試方法

「乘機安全小貼士」安全出行要重視

資料庫性能測試同樣使用了
Benchmark Factory
軟體，測試環境如同文件性能測試。測試時，在被測
伺服器上安裝
SQL Server 2000
使用企業版。首先在被測伺服器上創建新的資料庫，通過使用
Benchmark
Factory
預定義的
Database Spec
項目向資料庫中創建表，裝載數據。在伺服器端創建以
CPU
計算為主的
存儲過程，通過
10
台客戶機模擬用戶、按照
40
個虛擬用戶的步長遞增到
400
個用戶，執行該存儲過程。
結果是以獲得的每秒事務數
(TPS)
衡量伺服器的資料庫事務處理能力。
整個測試分為三次，
每次之間重新啟
動被測伺服器，最終取三次平均值作為評價結果。

3
、
Web
性能測試方法

Web
性能測試工具是由
Spirent
公司提供的
Caw WebAvalanche
。
WebAvalanche
模擬實際的用戶發出
HTTP
請求，
並根據回應給出具體的詳細測試結果。
它有以下特點：
能夠模擬成百上千的客戶端對伺服器發
出請求
;
能夠模擬真實的網路應用情況，
比如網站在高峰期的訪問量應該是動態的維持，
有新客戶端的加入，
同時也有原客戶的離去，
訪問量不是固定不變的
;
可以產生
20000
個連接
/
秒請求量，
足以滿足測試的需要
;
測試項目豐富，有訪問請求的成功失敗數，有
URL
和頁面的響應時間，有網路流量數，還有
HTTP
和
TCP
協
議的具體情況。

測試時，被測伺服器與
WebAvalanche
上都裝有千兆光纖網卡，兩網卡通過光纖直接連接。監控端
(
配
置為
PIII 1GHz/128M
內存
/20G
硬碟
)
安裝了帶
SP4
的
Windows 2000 Server,
該監控端與
WebAvalanche
通
過交叉線直連。在監控端通過
Web
瀏覽器配置
WebAvalanche
，在被測伺服器安裝了
SQL Server 2000
企業
版，並用微軟的
IIS
建立了
Web
伺服器。

測試分為靜態性能與動態性能兩部分。主要是因為在實際的
Web
應用中，有的站點靜態內容居多，提
供的服務也絕大多數是靜態的，
因此，
他們就會特別的關心伺服器靜態性能
;
同樣，
有的站點提供的服務交
互性的內容居多，他們就會更關心伺服器的動態性能。

被測網站中頁面大小及靜態、動態頁面所佔比例均參照實際網站得出，整個網站靜態、動態頁面所佔
比例是
70%
和
30%
，使用的動態頁面類型為
ASP
。請求頁面樣本的文件大小分布比例與整個網站的相同。

靜態性能測試模擬發出的均是靜態頁面請求。在測試動態性能時，動態頁面的訪問請求占
20%
，其餘
80%
為靜態頁面請求。我們根據實際的
Web
伺服器一天中的運行情況建立了一個伺服器頁面請求模型，該
模型由
4
個階段組成，第一階段是預熱階段，
WebAvalanche
發出的請求量由
0
慢慢上升到
200;
第二階段
是逐步加壓階段，請求量逐步累加到最大值
8200;
第三階段是動態維持階段
;
第四階段是下降階段，請求量
由最大值迅速下降為
0
。其中，最大請求量略大於實際伺服器能夠提供的事務處理量。

被測伺服器的靜態與動態測試分別測試三遍，每遍之間被測伺服器和測試儀均重啟，結果取三次的平
均值。由此可見，此伺服器測試方法立志於最終結果的准確性。

二、功能測試

在功能測試方面，我們對被測伺服器的可擴展性、可用性以及可管理性進行了綜合評價，其中可擴展
性包括硬碟、
PCI
槽以及內存等的擴展能力，可用性包括對熱插拔、冗餘設備
(
如硬碟、電源、風扇、網卡
等
)
的支持，可管理性則指的是伺服器隨機所帶的管理軟體。
我們在對伺服器進行總體評價時，綜合了性能、功能和價格三方面因素，依據《網路世界》所做的用
戶調查結果，分別給予不同權重，性能占
50%
，功能占
40%
，而價格則占
10%
。在分析性能時，資料庫性能
占其中的
50%
，而文件性能占
30%
，
Web
性能占
20%
。

綜上所述，這種全新的伺服器測試方法更夠更准確更直接的對伺服器進行測試，而且數據更加精確。
希望能給又需要的讀者朋友帶來一定的幫助

6、如何測試伺服器

伺服器測試方法

伺服器測試方法分為兩個大方面，性能測試與功能測試。

我們在性能測試方面採用了新的測試方法，主要分為文件測試、資料庫性能測試與
Web
性能測試三個
方面。其中，文件性能與資料庫性能採用美國
Quest
軟體公司的
Benchmark Factory
負載測試和容量規劃
軟體，
Web
性能測試則使用了
Spirent
公司提供的
Caw WebAvalanche
測試儀。

一、性能測試

1
、文件性能測試方法

Benchmark Factory
軟體能按照文件讀寫的關鍵指標定製事務。軟體最大支持
1000
個虛擬客戶。

本次測試環境包括
10
台配置為
PIII800/128MB
內存
/20G
硬碟以上的客戶端，它們用來模擬虛擬用戶。
控制台為配置是
PIII 850/128MB
內存
/40G
硬碟的
Acer
筆記本電腦。交換機為帶有兩個千兆
GBIC
介面、
24
個
10/100M
自適應埠的
Cisco 2950
，客戶端與控制台通過
100M
網卡連到交換機上，被測伺服器則通
過千兆光纖網卡與交換機相連接。

被測伺服器均安裝帶
SP4
的
Windows
2000
Advanced Server
操作系統，在所有三項性能測試中都統一
RAID
級別為
5
。

在具體測試方案設置上，測試軟體把決定文件讀寫操作的關鍵因素設定為：讀
/
寫、隨機
/
順序、操作
塊大小、對象大小四個。在本次測試中，考慮到我們設有單獨的資料庫及
Web
測試項目，所以在文件測試
中，我們把目標確定為測試伺服器基本的
I/O
性能，這主要由網路介面、系統帶寬、磁碟子系統等幾大部
分所決定。同時，從幾部分的作用看，以大操作塊讀寫大對象文件，小操作塊讀寫小對象文件，較能反映
伺服器最基本的
I/O
性能，即「大操作塊讀寫大文件」對系統帶寬、緩存的考察，以及「小操作塊讀寫小
文件」對磁碟子系統、網路介面的考察。最終我們確定的四個事務是：

大文件順序讀寫
(
操作塊
8KB
，對象文件
80% 500KB
、
20% 1MB)

大文件隨機讀寫
(
操作塊
8KB
，對象文件
80% 500KB
、
20% 1MB)

小文件隨機讀
(
操作塊
1KB
，對象文件
80% 1KB
、
10% 10KB
、
10% 50KB)

小文件順序寫
(
操作塊
1KB
，對象文件
80% 1KB
、
10% 10KB
、
10% 50KB)

每個事務的用戶數均以固定步長逐漸增加，
最大可增加到
1000
個虛擬用戶。
其中，
「大文件順序讀寫」
事務的用戶數按照
40
的步長從
1
可增加到
400
個
(
測試至強伺服器
)
或
200
個
(
測試
TUALATIN
伺服器
)
，其
他事務則將用戶數按照
100
的步長從
1
增加至
1000
。我們期望得到其在不同用戶數時被測伺服器的性能表
現。總體上其走勢及峰值反映了該伺服器的性能。每項事務均運行三次，每次之間被測伺服器進行重啟，
最終結果為三次平均值。

2
、資料庫性能測試方法

「乘機安全小貼士」安全出行要重視

資料庫性能測試同樣使用了
Benchmark Factory
軟體，測試環境如同文件性能測試。測試時，在被測
伺服器上安裝
SQL Server 2000
使用企業版。首先在被測伺服器上創建新的資料庫，通過使用
Benchmark
Factory
預定義的
Database Spec
項目向資料庫中創建表，裝載數據。在伺服器端創建以
CPU
計算為主的
存儲過程，通過
10
台客戶機模擬用戶、按照
40
個虛擬用戶的步長遞增到
400
個用戶，執行該存儲過程。
結果是以獲得的每秒事務數
(TPS)
衡量伺服器的資料庫事務處理能力。
整個測試分為三次，
每次之間重新啟
動被測伺服器，最終取三次平均值作為評價結果。

3
、
Web
性能測試方法

Web
性能測試工具是由
Spirent
公司提供的
Caw WebAvalanche
。
WebAvalanche
模擬實際的用戶發出
HTTP
請求，
並根據回應給出具體的詳細測試結果。
它有以下特點：
能夠模擬成百上千的客戶端對伺服器發
出請求
;
能夠模擬真實的網路應用情況，
比如網站在高峰期的訪問量應該是動態的維持，
有新客戶端的加入，
同時也有原客戶的離去，
訪問量不是固定不變的
;
可以產生
20000
個連接
/
秒請求量，
足以滿足測試的需要
;
測試項目豐富，有訪問請求的成功失敗數，有
URL
和頁面的響應時間，有網路流量數，還有
HTTP
和
TCP
協
議的具體情況。

測試時，被測伺服器與
WebAvalanche
上都裝有千兆光纖網卡，兩網卡通過光纖直接連接。監控端
(
配
置為
PIII 1GHz/128M
內存
/20G
硬碟
)
安裝了帶
SP4
的
Windows 2000 Server,
該監控端與
WebAvalanche
通
過交叉線直連。在監控端通過
Web
瀏覽器配置
WebAvalanche
，在被測伺服器安裝了
SQL Server 2000
企業
版，並用微軟的
IIS
建立了
Web
伺服器。

測試分為靜態性能與動態性能兩部分。主要是因為在實際的
Web
應用中，有的站點靜態內容居多，提
供的服務也絕大多數是靜態的，
因此，
他們就會特別的關心伺服器靜態性能
;
同樣，
有的站點提供的服務交
互性的內容居多，他們就會更關心伺服器的動態性能。

被測網站中頁面大小及靜態、動態頁面所佔比例均參照實際網站得出，整個網站靜態、動態頁面所佔
比例是
70%
和
30%
，使用的動態頁面類型為
ASP
。請求頁面樣本的文件大小分布比例與整個網站的相同。

靜態性能測試模擬發出的均是靜態頁面請求。在測試動態性能時，動態頁面的訪問請求占
20%
，其餘
80%
為靜態頁面請求。我們根據實際的
Web
伺服器一天中的運行情況建立了一個伺服器頁面請求模型，該
模型由
4
個階段組成，第一階段是預熱階段，
WebAvalanche
發出的請求量由
0
慢慢上升到
200;
第二階段
是逐步加壓階段，請求量逐步累加到最大值
8200;
第三階段是動態維持階段
;
第四階段是下降階段，請求量
由最大值迅速下降為
0
。其中，最大請求量略大於實際伺服器能夠提供的事務處理量。

被測伺服器的靜態與動態測試分別測試三遍，每遍之間被測伺服器和測試儀均重啟，結果取三次的平
均值。由此可見，此伺服器測試方法立志於最終結果的准確性。

二、功能測試

在功能測試方面，我們對被測伺服器的可擴展性、可用性以及可管理性進行了綜合評價，其中可擴展
性包括硬碟、
PCI
槽以及內存等的擴展能力，可用性包括對熱插拔、冗餘設備
(
如硬碟、電源、風扇、網卡
等
)
的支持，可管理性則指的是伺服器隨機所帶的管理軟體。
我們在對伺服器進行總體評價時，綜合了性能、功能和價格三方面因素，依據《網路世界》所做的用
戶調查結果，分別給予不同權重，性能占
50%
，功能占
40%
，而價格則占
10%
。在分析性能時，資料庫性能
占其中的
50%
，而文件性能占
30%
，
Web
性能占
20%
。

綜上所述，這種全新的伺服器測試方法更夠更准確更直接的對伺服器進行測試，而且數據更加精確。
希望能給又需要的讀者朋友帶來一定的幫助
。
謝謝採納。

7、介面測試必須知道伺服器地址和介面路徑嗎

介面是別人暴露給你的，所以說介面的地址是別人提供，比如說請求淘寶的介面。如果是自己開發測試，介面的地址就是伺服器的地址加路徑，有時也會採用虛擬目錄的形式，介面地址不一定是介面所在的路徑

8、介面測試的原理？

對於介面測試，首先測試人員要懂代碼，你只需要知道介面的作用是什麼就可以了（有文檔更好，但大部分都沒有）；其次，自己去讀開發的代碼；然後，根據該介面功能及代碼寫測試用例；用例設計： 1：寫一個程序去調用該介面，看是否能夠達到該介面所定義的功能 2：根據該介面參數，構造不同的用例，測試介面在參數合法及非法情況下能否達到預期效果 3：根據該介面中的邏輯，設計不同條件的用例，測試該介面實現代碼的邏輯 4：進行容錯及健壯性測試 5：靜態檢測代碼，看是否有內存泄露、或永遠走不到的分支、代碼規范及邏輯是否合理。 6：對於一些介面，需要進行多線程測試

9、什麼是介面測試?

1介面測試的定義與分類，以下就是介面測試
介面測試是測試系統組件間介面的一種測試。
主要用於檢測外部系統與系統之間以及系統內部各個子系統之間的交互點。
重點測試數據的交換、傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等等。
這要求對業務邏輯有一定程度上的理解，對數據流向有較好的定位。
介面測試般會用於多系統間交互開發，或者擁有多個子系統的應用系統開發的測試。
介面測試適用於為其他系統提供服務的底層框架系統和中心服務系統，主要測試這些系統對外部提供的介面，驗證其正確性和穩定性。
介面測試同樣適用於一個上層系統中的服務層介面，越往上層，其測試的難度越大。
介面測試實施在多系統多平台的構架下，有著極為高效的成本收益比。
介面測試天生為高復雜性的平台帶來高效的缺陷監測和質量監督能力。平台越復雜，系統越龐大，介面測試的效果越明顯。
介面測試的目的是測試介面，尤其是那些與系統相關聯的外部介面，測試的重點是要檢查數據的交換、傳遞和控制管理過程，還包括處理的次數。外部介面測試一般是作為系統測試來看待的。
不是所有的團隊都可以在一個隔離的測試環境中進行測試工作的，因此使得對外部介面的測試顯得困難。
我們應該確保較早地與相關的組織協調好並確定進行外部介面測試的方案。
有時候相關的組織只是人工的靜態的審閱一次數據而並不真正的用這些數據來測試，這些都增加了實際測試執行中遇到的風險，但有些時候是可以避免的。
介面測試有的公司是歸納在集成測試裡面，也有的公司會放在系統測試階段，不過這個都沒有什麼區別，本質上介面測試就是通過某個功能模塊對外暴露的一個介面地址傳參進行測試。
一般來說介面分為如下三類：
A. 系統與系統之間的調用(如我們一般常見的分享內容到朋友圈或者是微信朋友時，微信會提供介面給這些需要用到分享的應用)上層服務對下層服務的調用（這個理解難度稍微有點大，在我們程序中功能是分層的，那麼屬於上層對底層服務的調用，以後能夠有機會接觸到代碼或者更加稍微復雜點的介面測試就能夠理解。舉個例子，我們的程序框架分為三層，分別是web層：提供給用戶請求的層次；feb遷至層：作為信息傳遞的中轉站；service層：作為程序應用的核心，處理所有的請求
C.服務之間的調用（如添加一條數據時，會先調用數據查詢的服務，查詢該數據是否是重復數據）
不同類型的介面測試方法可能不一致，但總體來說不管是哪種類型，被測介面即為服務，測試手段為客服方，介面測試的目的就是：通過我們的測試手段，去驗證滿足其申明提供的功能。
2如何做介面測試
介面測試的原理：通過測試程序模擬客服端向伺服器發送請求報文，伺服器接收請求報文後對相應的報文做出處理然後再把應答報文發送給客戶端，客戶端接收應答報文這一過程（reques->response）。
介面測試的流程與功能測試有什麼區別呢？從原則上以及流程上講，是沒有啥區別的，都同一套軟體測試流程：需求討論->評審需求->確定需求->產出介面定義->根據需求文檔及介面定義設計測試用例（測試用例主要從業務場景，功能以及異常測試幾個方面考慮）->評審用例->執行測試。
介面測試採用的最基本的就是黑盒測試，在這個測試過程中我們最需要關注的是，如何來設計測試用例，設計測試用例所採用的方法也是我們常所用的幾大方法：等價類、邊界值以及錯誤推測法、場景法。在設計測試用例之前，我們先來看看常見的介面文檔形式。
這就是上圖是一種比較規范的介面文檔說明，包含了如下內容模塊：介面的類型說明、介面地址、http請求方式、輸入參數和請求介面後返回的響應結果。
介面測試編寫測試用例，主要關注點是輸入參數、輸出結果以及內部業務邏輯是否正常『，所以我夢設計用例也要從這幾方面出發考慮：
a）輸入參數測試：針對輸入參數進行的測試，也可以說是假定介面參數的不正確性 進行的測試，確保介面對任意類型的輸入都做了相應的處理：輸入參數合法（不合法），輸入參數為空，為null,輸入參數超長等等；
b）介面是否滿足了所提供的功能，相當正常情況測試，如果一個介面功能復雜時推薦對介面用例進行結構劃分，這樣子用例就有更好的可讀性和可維護性；
c）邏輯測試：邏輯測試嚴格講應為單元測試，單元測試應保持內部邏輯的正確性，可單元測試和介面測試的界限並不是那麼清晰，所以我們也可以從給出的設計文檔中考慮內部邏輯錯誤的分支情況和異常；
d）異常情況介面測試：介面實現是否對異常情況都進行了處理，介面輸入參數雖然合法，但是在介面實現中，也會出現異常，因為內部的異常不一定是輸入的數據造成的，而有可能是其他邏輯造成的，程序需要對任何異常都進行處理；
針對上面的注冊介面，我們利用測試用例設計方法來編寫測試用例，如下所示：
3介面測試的工具選擇
可以進行介面測試的工具有很多，這里簡單介紹幾個：
>loadrunner :一款商業性能測試工具，用來做介面測試，很好很強大。
>jmeter :一款開源的性能測試工具，操作簡單方便，既有jdbc request 操作資料庫數據，也有http request 和 soap request 應對測試；
>httprequester :火狐瀏覽器自帶介面測試工具，插件中安裝即可，界面簡單明了，容易上手。
>postman :谷歌瀏覽器的擴展工具，界面簡潔，開發者比較常用的一款插件工具。
>soapui : 開源測試工具，通過soap/http 來檢查、調用、實現web service的功能/負載/符合性測試。
我們將在後面的教學中，重點講解Jmeter這款綜合性比較高的工具；