正文

外部接口測試方法（外部接口測試方法包括）

發(fā)布時間：2023-03-19 07:18:29 稿源：創(chuàng)意嶺閱讀： 97 問大家

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于外部接口測試方法的問題，以下是小編對此問題的歸納整理，讓我們一起來看看吧。

開始之前先推薦一個非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計劃、工作報告、論文、代碼、作文、做題和對話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫出的就越詳細(xì)，有微信小程序端、在線網(wǎng)頁版、PC客戶端

官網(wǎng)：https://ai.de1919.com

本文目錄:

1、什么是接口測試?
2、如何做好接口測試？
3、接口測試如何進(jìn)行?
4、如何簡單設(shè)計接口測試用例

外部接口測試方法（外部接口測試方法包括）

一、什么是接口測試?

1接口測試的定義與分類，以下就是接口測試

接口測試是測試系統(tǒng)組件間接口的一種測試。

主要用于檢測外部系統(tǒng)與系統(tǒng)之間以及系統(tǒng)內(nèi)部各個子系統(tǒng)之間的交互點。

重點測試數(shù)據(jù)的交換、傳遞和控制管理過程，以及系統(tǒng)間的相互邏輯依賴關(guān)系等等。

這要求對業(yè)務(wù)邏輯有一定程度上的理解，對數(shù)據(jù)流向有較好的定位。

接口測試般會用于多系統(tǒng)間交互開發(fā)，或者擁有多個子系統(tǒng)的應(yīng)用系統(tǒng)開發(fā)的測試。

接口測試適用于為其他系統(tǒng)提供服務(wù)的底層框架系統(tǒng)和中心服務(wù)系統(tǒng)，主要測試這些系統(tǒng)對外部提供的接口，驗證其正確性和穩(wěn)定性。

接口測試同樣適用于一個上層系統(tǒng)中的服務(wù)層接口，越往上層，其測試的難度越大。

接口測試實施在多系統(tǒng)多平臺的構(gòu)架下，有著極為高效的成本收益比。

接口測試天生為高復(fù)雜性的平臺帶來高效的缺陷監(jiān)測和質(zhì)量監(jiān)督能力。平臺越復(fù)雜，系統(tǒng)越龐大，接口測試的效果越明顯。

接口測試的目的是測試接口，尤其是那些與系統(tǒng)相關(guān)聯(lián)的外部接口，測試的重點是要檢查數(shù)據(jù)的交換、傳遞和控制管理過程，還包括處理的次數(shù)。外部接口測試一般是作為系統(tǒng)測試來看待的。

不是所有的團(tuán)隊都可以在一個隔離的測試環(huán)境中進(jìn)行測試工作的，因此使得對外部接口的測試顯得困難。

我們應(yīng)該確保較早地與相關(guān)的組織協(xié)調(diào)好并確定進(jìn)行外部接口測試的方案。

有時候相關(guān)的組織只是人工的靜態(tài)的審閱一次數(shù)據(jù)而并不真正的用這些數(shù)據(jù)來測試，這些都增加了實際測試執(zhí)行中遇到的風(fēng)險，但有些時候是可以避免的。

接口測試有的公司是歸納在集成測試?yán)锩?，也有的公司會放在系統(tǒng)測試階段，不過這個都沒有什么區(qū)別，本質(zhì)上接口測試就是通過某個功能模塊對外暴露的一個接口地址傳參進(jìn)行測試。

一般來說接口分為如下三類：

A. 系統(tǒng)與系統(tǒng)之間的調(diào)用(如我們一般常見的分享內(nèi)容到朋友圈或者是微信朋友時，微信會提供接口給這些需要用到分享的應(yīng)用)上層服務(wù)對下層服務(wù)的調(diào)用（這個理解難度稍微有點大，在我們程序中功能是分層的，那么屬于上層對底層服務(wù)的調(diào)用，以后能夠有機會接觸到代碼或者更加稍微復(fù)雜點的接口測試就能夠理解。舉個例子，我們的程序框架分為三層，分別是web層：提供給用戶請求的層次；feb遷至層：作為信息傳遞的中轉(zhuǎn)站；service層：作為程序應(yīng)用的核心，處理所有的請求

C.服務(wù)之間的調(diào)用（如添加一條數(shù)據(jù)時，會先調(diào)用數(shù)據(jù)查詢的服務(wù)，查詢該數(shù)據(jù)是否是重復(fù)數(shù)據(jù)）

不同類型的接口測試方法可能不一致，但總體來說不管是哪種類型，被測接口即為服務(wù)，測試手段為客服方，接口測試的目的就是：通過我們的測試手段，去驗證滿足其申明提供的功能。

2如何做接口測試

接口測試的原理：通過測試程序模擬客服端向服務(wù)器發(fā)送請求報文，服務(wù)器接收請求報文后對相應(yīng)的報文做出處理然后再把應(yīng)答報文發(fā)送給客戶端，客戶端接收應(yīng)答報文這一過程（reques->response）。

接口測試的流程與功能測試有什么區(qū)別呢？從原則上以及流程上講，是沒有啥區(qū)別的，都同一套軟件測試流程：需求討論->評審需求->確定需求->產(chǎn)出接口定義->根據(jù)需求文檔及接口定義設(shè)計測試用例（測試用例主要從業(yè)務(wù)場景，功能以及異常測試幾個方面考慮）->評審用例->執(zhí)行測試。

接口測試采用的最基本的就是黑盒測試，在這個測試過程中我們最需要關(guān)注的是，如何來設(shè)計測試用例，設(shè)計測試用例所采用的方法也是我們常所用的幾大方法：等價類、邊界值以及錯誤推測法、場景法。在設(shè)計測試用例之前，我們先來看看常見的接口文檔形式。

這就是上圖是一種比較規(guī)范的接口文檔說明，包含了如下內(nèi)容模塊：接口的類型說明、接口地址、http請求方式、輸入?yún)?shù)和請求接口后返回的響應(yīng)結(jié)果。

接口測試編寫測試用例，主要關(guān)注點是輸入?yún)?shù)、輸出結(jié)果以及內(nèi)部業(yè)務(wù)邏輯是否正常‘，所以我夢設(shè)計用例也要從這幾方面出發(fā)考慮：

a）輸入?yún)?shù)測試：針對輸入?yún)?shù)進(jìn)行的測試，也可以說是假定接口參數(shù)的不正確性進(jìn)行的測試，確保接口對任意類型的輸入都做了相應(yīng)的處理：輸入?yún)?shù)合法（不合法），輸入?yún)?shù)為空，為null,輸入?yún)?shù)超長等等；

b）接口是否滿足了所提供的功能，相當(dāng)正常情況測試，如果一個接口功能復(fù)雜時推薦對接口用例進(jìn)行結(jié)構(gòu)劃分，這樣子用例就有更好的可讀性和可維護(hù)性；

c）邏輯測試：邏輯測試嚴(yán)格講應(yīng)為單元測試，單元測試應(yīng)保持內(nèi)部邏輯的正確性，可單元測試和接口測試的界限并不是那么清晰，所以我們也可以從給出的設(shè)計文檔中考慮內(nèi)部邏輯錯誤的分支情況和異常；

d）異常情況接口測試：接口實現(xiàn)是否對異常情況都進(jìn)行了處理，接口輸入?yún)?shù)雖然合法，但是在接口實現(xiàn)中，也會出現(xiàn)異常，因為內(nèi)部的異常不一定是輸入的數(shù)據(jù)造成的，而有可能是其他邏輯造成的，程序需要對任何異常都進(jìn)行處理；

針對上面的注冊接口，我們利用測試用例設(shè)計方法來編寫測試用例，如下所示：

3接口測試的工具選擇

可以進(jìn)行接口測試的工具有很多，這里簡單介紹幾個：

>loadrunner :一款商業(yè)性能測試工具，用來做接口測試，很好很強大。

>jmeter :一款開源的性能測試工具，操作簡單方便，既有jdbc request 操作數(shù)據(jù)庫數(shù)據(jù)，也有http request 和 soap request 應(yīng)對測試；

>httprequester :火狐瀏覽器自帶接口測試工具，插件中安裝即可，界面簡單明了，容易上手。

>postman :谷歌瀏覽器的擴(kuò)展工具，界面簡潔，開發(fā)者比較常用的一款插件工具。

>soapui : 開源測試工具，通過soap/http 來檢查、調(diào)用、實現(xiàn)web service的功能/負(fù)載/符合性測試。

我們將在后面的教學(xué)中，重點講解Jmeter這款綜合性比較高的工具；

二、如何做好接口測試？

sgbtmy：基于selenium的自動化框架開發(fā)，我主要是想問一下，你的框架除了前臺的自動化，后臺的數(shù)據(jù)的測試是否集成在你的測試框架中？小刀：你好，個人理解的你所說的后臺的數(shù)據(jù)的測試是指的是對數(shù)據(jù)的校驗，不知理解的是否正確，那么根據(jù)這個理解，我的解釋是，在我們框架中，增加了很多的功能方法用來幫助進(jìn)行自動化腳本的編寫和結(jié)果校驗，其中就包括后臺數(shù)據(jù)校驗方法，當(dāng)我們的測試用例需要在后臺進(jìn)行數(shù)據(jù)校驗的時候，調(diào)用這些數(shù)據(jù)校驗方法即可。相當(dāng)于是，前臺頁面操作的自動化是封裝selenium的方法去操作頁面，而對后臺數(shù)據(jù)的校驗是通過增加功能方法來實現(xiàn)的，可以理解為不同的兩部分，但是在編寫測試腳本的似乎，根據(jù)測試用例的設(shè)計，這兩部分都可以拿過來使用。不知道是否解答了你的疑問，如果沒有，請你指出，謝謝你。 tjy688：你們做接口測試的流程一般是怎么樣的？小刀：接口測試的流程其實和功能測試的流程類似，因為接口測試依賴的主要對象也是需求說明書，所以，最初的流程就是參與需求討論，評審需求。需求確定以后，開發(fā)會根據(jù)需求進(jìn)行接口設(shè)計，會產(chǎn)出接口定義，在開發(fā)設(shè)計過程中，有能力的話，可以給出一些針對設(shè)計的建議，提高可測性，針對需求及設(shè)計，進(jìn)行測試計劃，測試設(shè)計，然后還需要和配管確定測試環(huán)境相關(guān)的事情。在開發(fā)完成接口定義之后，就根據(jù)需求文檔及接口定義進(jìn)行測試用例設(shè)計，測試用例設(shè)計主要從業(yè)務(wù)場景，功能，以及異常測試幾個方面考慮。測試用例設(shè)計完成后，針對測試用例進(jìn)行評審，然后，如果開發(fā)代碼部分可測時，即可進(jìn)入測試了，因為是部分可測，可能會使用到mock方法。已有測試代碼時，就要進(jìn)行測試代碼的持續(xù)集成了，我們是使用hudson來進(jìn)行持續(xù)集成的在項目結(jié)束后，會對每個項目進(jìn)行總結(jié)。如果有問題，請指出，我們一起討論。 xinhuayw：我想了解一下你們現(xiàn)在是怎樣保證項目測試用例的重復(fù)運行的。小刀：對于接口測試來說，項目測試用例的重復(fù)運行首先是表現(xiàn)在單個測試用例的獨立性方面的，也就是說，每一個測試用例的運行除了依賴被測對象和對應(yīng)的數(shù)據(jù)庫環(huán)境外，是不依賴于其他任何測試用例的，并且這個測試用例執(zhí)行完畢后，對系統(tǒng)來說，也是沒有任何痕跡的，這樣就保證了每個測試用例運行時，都在一個干凈的環(huán)境中運行。要實現(xiàn)測試用例的獨立性，就必須對被測系統(tǒng)的設(shè)計有詳細(xì)的了解，這樣，不會出現(xiàn)測試用例執(zhí)行后遺漏數(shù)據(jù)，環(huán)境未改變，另外，還需要對測試用例進(jìn)行詳細(xì)的設(shè)計。另外，要保證測試用例的重復(fù)使用，還需要做到測試用例的及時更新，在這個方面，我們是做接口測試的人會維護(hù)對應(yīng)的系統(tǒng)的接口測試用例，要保證，代碼每次更新，測試用例都必須全部執(zhí)行通過。 csun888：什么是接口測試，基礎(chǔ)知識什么的講講吧！小刀：你好，接口可以分下面幾種 1、系統(tǒng)與系統(tǒng)之間的調(diào)用，比如銀行會提供接口供電子商務(wù)網(wǎng)站調(diào)用，或者說，支付寶會提供接口給淘寶調(diào)用 2、上層服務(wù)對下層服務(wù)的調(diào)用，比如service層會調(diào)用DAO層的接口，而應(yīng)用層又會調(diào)用服務(wù)層提供的接口，一般會通過 3、服務(wù)之間的調(diào)用，比如注冊用戶時，會先調(diào)用用戶查詢的服務(wù)，查看該用戶是否已經(jīng)注冊。而我們所要做的接口測試，先要了解是基于哪一種類型的接口測試，不同類型的接口測試方法可能是不一致的，總體來說，不管是那種類型，我們只要把被測接口當(dāng)做是服務(wù)方，而把我們的測試手段當(dāng)做是客戶方，我們的目的就是，通過我們的測試手段，去驗證服務(wù)端滿足了他聲明提供的功能。至于說到具體的測試方法，http協(xié)議的接口測試，一般會用jmeter去測試，jmeter的好處是不用寫測試代碼，直接使用jmeter提供的http請求去測試，也可以使用HTTPClient去測試，好處是可以方便集成和自動化。java接口的測試，則需要編寫測試代碼去測試，有點類似于單元測試，但是需要更多的考慮業(yè)務(wù)場景。 gulun：接口測試的數(shù)據(jù)準(zhǔn)備，應(yīng)該怎么做呢？小刀：接口測試的數(shù)據(jù)準(zhǔn)備，可以從下面幾個方面去考慮： 1、如果是只測試一次的接口，可以使用硬編碼的方式準(zhǔn)備測試數(shù)據(jù)，在寫測試代碼的時候，使用到什么數(shù)據(jù)就寫什么數(shù)據(jù)，為了避免數(shù)據(jù)重復(fù)，可能比較多的會用到隨機字符或隨機數(shù) 2、可以直接通過調(diào)用其他API的方式準(zhǔn)備測試數(shù)據(jù)，這種情況在測試最上層服務(wù)的時候比較有用，比如測試團(tuán)購購買服務(wù)，就需要準(zhǔn)備要購買的團(tuán)購數(shù)據(jù)，購買團(tuán)購的用戶數(shù)據(jù)，這個時候，可以直接調(diào)用生產(chǎn)團(tuán)購的api和生成用戶的api直接生成測試數(shù)據(jù). 3、使用excel或xml準(zhǔn)備測試數(shù)據(jù)，這種準(zhǔn)備測試數(shù)據(jù)的方式，主要針對對象數(shù)據(jù)的準(zhǔn)備，比如可以將一條團(tuán)購數(shù)據(jù)對應(yīng)excel中的一條數(shù)據(jù)，因為一般開發(fā)都會使用pojo映射，而在準(zhǔn)備測試數(shù)據(jù)的時候，這些pojo對象屬性的設(shè)置往往是重復(fù)和大工作量的，用excel或XML方式準(zhǔn)備，則可以減少在代碼當(dāng)中重復(fù)去準(zhǔn)備這些數(shù)據(jù)。 4、也可以使用工具方法的形式去準(zhǔn)備測試數(shù)據(jù)，通過在代碼中寫工具方法去實現(xiàn)數(shù)據(jù)生成，而在測試代碼中調(diào)用工具方法去得到所需數(shù)據(jù)。水生哥哥：你好，我想問一下：接口測試怎么設(shè)計測試用例呢？小刀：你好，我覺得接口測試用例的設(shè)計方法其實和功能測試用例的設(shè)計方法是類似的，因為接口是需要滿足需求的，而接口測試所依賴的也是需求說明書，但是，因為接口測試畢竟是通過代碼去測試代碼，所以，為了保證覆蓋率，可能會使用到單元測試的方法，具體的測試用例設(shè)計，我考慮的如下，請參考，如果有錯誤，一起討論。輸入?yún)?shù)測試：針對輸入的參數(shù)進(jìn)行測試，也可以說是假定接口參數(shù)的不正確性進(jìn)行的測試，確保接口對任意類型的輸入都做了相應(yīng)的處理：輸入?yún)?shù)合法，輸入?yún)?shù)不合法，輸入?yún)?shù)為空，輸入?yún)?shù)為null，輸入?yún)?shù)超長；功能測試：接口是否滿足了所提供的功能，相當(dāng)于是正常情況測試，如果一個接口功能復(fù)雜時推薦對接口用例進(jìn)行結(jié)構(gòu)劃分，這樣子用例具有更好的可讀性和維護(hù)性。邏輯測試：邏輯測試嚴(yán)格講應(yīng)為單元測試，單元測試應(yīng)保持內(nèi)部邏輯的正確性，可單元測試和接口測試界限并不是那么清楚，所以我們也可以從給出的設(shè)計文檔中考慮內(nèi)部邏輯錯誤的分支情況和異常；異常情況測試：接口實現(xiàn)是否對異常情況都進(jìn)行了處理，接口輸入?yún)?shù)雖然合法，但是在接口實現(xiàn)中，也會出現(xiàn)異常，因為內(nèi)部的異常不一定是輸入的數(shù)據(jù)造成的，而有可能是其他邏輯造成的，程序需要對任何的異常都進(jìn)行處理。永遠(yuǎn)的測試者：才開始測試，對接口測試感興趣，可是，當(dāng)前的能力又無法進(jìn)行接口測試，怎么樣才能進(jìn)入接口測試呢？小刀：你好，如果要做接口測試，是需要一定的編程能力的，需要學(xué)習(xí)相對應(yīng)的開發(fā)語言的，然后還需要學(xué)習(xí)開發(fā)所使用的一些框架，比如ibatis，spring等，對數(shù)據(jù)庫的操作也需要了解一些，還有eclipse操作，這些內(nèi)容并不需要了解的多么深入，如果只是一般的做做接口測試，這些能夠使用就可以了，當(dāng)然，要做好接口測試，就另當(dāng)別論了。我不知道你當(dāng)前是什么樣的能力，所以，我的建議就是， 1、學(xué)習(xí)編程語言，基礎(chǔ)的語法，循環(huán)，條件等 2、學(xué)習(xí)項目工程管理及開發(fā)框架：eclipse，maven，svn，ibatis，spring等 3、學(xué)習(xí)Xunit 4、自己嘗試去寫測試代碼其實，上面的過程除了第一步是必須具備的意外，其他的都可以一邊寫測試代碼，一邊學(xué)習(xí)，最好的辦法就是看開發(fā)寫的代碼，并且，請開發(fā)寫一個正常的測試代碼，然后照著開發(fā)的測試代碼去模仿。 iTest99：你認(rèn)為接口測試由開發(fā)團(tuán)隊做好還是測試團(tuán)隊好？各有什么優(yōu)勢和弱點？小刀：我覺得，還是要區(qū)分一下單元測試和接口測試，單元測試一般來說，是針對具體的代碼邏輯進(jìn)行測試，盡量減少這些功能單元集成起來出錯的可能性，一般是由開發(fā)人員來完成，而接口測試，更注重從用戶的角度設(shè)計用例，更偏向于功能測試，單元測試設(shè)計測試用例的時候，可能更多的考慮是代碼覆，而接口測試，則需要更多的考慮業(yè)務(wù)覆蓋。單元測試由開發(fā)人員來做，可以保證從代碼角度來看是沒有問題的，但服務(wù)保證業(yè)務(wù)角度來看也是沒有問題的，而接口測試，則通過業(yè)務(wù)的角度去設(shè)計測試用例，其實，也可以說是從更早的時候，以功能測試的方法，先保證項目的流程及功能是正常的，而不至于在頁面開發(fā)完成后，又修改主要功能代碼，導(dǎo)致項目趕工及一系列的重寫。所以，我覺得，單元測試由開發(fā)人員來做，接口測試由測試人員來做。至于你說的學(xué)習(xí)接口的成本，我覺得這個成本并不高，原因是： 1、接口測試的用例也是依賴需求文檔的，并不是根據(jù)開發(fā)代碼去設(shè)計 2、接口測試的用例可以在功能測試中復(fù)用。 3、接口測試看似增加測試時間，實則不然，因為，接口測試會更早的發(fā)現(xiàn)bug，而使得修改bug的成本更低，接口測試會減少功能測試的時間，應(yīng)該接口測試會確保主要流程功能的正確性，接口測試更容易實現(xiàn)持續(xù)集成，從而減少回歸測試的次數(shù)。 txTester11：我想請問：接口測試盒單元測試有什么區(qū)別？接口測試和白盒測試又有什么區(qū)別？小刀：單元測試是針對具體的代碼邏輯進(jìn)行測試，主要測試被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。例如，你可能把一個很大的值放入一個有序list 中去，然后確認(rèn)該值出現(xiàn)在list 的尾部?；蛘?，你可能會從字符串中刪除匹配某種模式的字符，然后確認(rèn)字符串確實不再包含這些字符了。盡量減少這些功能單元集成起來出錯的可能性，單元測試一般是由開發(fā)人員自己去完成，單元測試可能不會考慮業(yè)務(wù)是如何的，會更多的考慮，我這個單元模塊邏輯是否正確。接口測試指的是針對程序內(nèi)部的或者外部的接口進(jìn)行的測試，一個接口方法可能會包含多個單元模塊，而且，一個接口會有自己特定的業(yè)務(wù)定義，所以，做接口測試的時候，更多的需要從業(yè)務(wù)的角度去考慮如何測試這個接口。不管是接口測試還是單元測試，其實都屬于白盒測試的一個階段，白盒測試具體的方法有很多種，比如代碼審查，比如代碼覆蓋。

三、接口測試如何進(jìn)行?

在測試過程中，很多場景都需要測試人員針對某個接口進(jìn)行測試，并針對不同類型的接口設(shè)計不同的測試方案，這時如果有一款功能強大的接口測試工具，就快速完成繁瑣工作，大幅提升工作效率。工具有很多如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。

也可以用接口自動化來實現(xiàn)，就是用代碼實現(xiàn)，框架和UI自動化差不多，發(fā)送請求用斷言來判斷。

四、如何簡單設(shè)計接口測試用例

接口測試是項目測試的一部分，它測試的主要對象是接口，是測試系統(tǒng)組件間接口的一種測試。接口測試主要用于檢測外部系統(tǒng)與所測系統(tǒng)之間以及內(nèi)部各系統(tǒng)之間的交互點。測試的重點是檢查數(shù)據(jù)交互、傳遞、和控制管理過程以及系統(tǒng)間的相互依賴關(guān)系等。如何設(shè)計接口測試用例？首先，明確出發(fā)點，和所有的測試一樣，接口測試出發(fā)點是你要證明所測的程序是錯誤的。以這個出發(fā)點為導(dǎo)向，你的設(shè)計行為就會盡量朝這個方向，更易發(fā)現(xiàn)問題其次，選擇好測試對象。對于一個系統(tǒng)做接口測試選擇好的測試對象是接口測試關(guān)鍵。一個系統(tǒng)有無數(shù)的接口，每個接口如果分別測試，那將是很痛苦的一件事情，而且任何一個內(nèi)部接口的變動，都將導(dǎo)致我們用例的不可用。可將這些最外層的接口分為兩類：一類是數(shù)據(jù)進(jìn)入系統(tǒng)的接口；一類是數(shù)據(jù)流出系統(tǒng)的接口。進(jìn)入系統(tǒng)的接口實際是我們用例的執(zhí)行調(diào)用的接口。可通過變化參數(shù)對這些接口進(jìn)行調(diào)用，模擬外部的使用；而流出的接口則是我們用例真正該驗證的點。數(shù)據(jù)從哪里流出，流出時的狀態(tài)如何，此時系統(tǒng)又是什么狀態(tài)都是我們所應(yīng)該驗證的。然后，確認(rèn)完整的測試對象的功能：確認(rèn)外部接口提供給使用這些接口的外部用戶什么樣的功能，外部用戶真正需要什么樣的功能。此兩個功能一定要準(zhǔn)確詳細(xì)，用例的設(shè)計要嚴(yán)格按照測試對象功能設(shè)計才是正確的用例。最后當(dāng)出發(fā)點、對象、功能都確定了，就可以真正設(shè)計用例了。下面詳細(xì)介紹下如何去設(shè)計一個結(jié)構(gòu)好、可讀性高、滲透性強的接口測試用例。接口測試用例設(shè)計和測試用例設(shè)計一樣，用例設(shè)計的內(nèi)容應(yīng)該包括：主要測試功能點、測試環(huán)境、測試數(shù)據(jù)、執(zhí)行操作以及預(yù)期結(jié)果。 1）接口測試環(huán)境分為兩種：一種是程序內(nèi)部的環(huán)境；一種是程序的所調(diào)用外部接口的環(huán)境。 2）接口測試測試數(shù)據(jù)分為接口參數(shù)數(shù)據(jù)和用例執(zhí)行所需系統(tǒng)數(shù)據(jù)。數(shù)據(jù)的設(shè)計、準(zhǔn)備測試用例的數(shù)據(jù)上需要花費更多的心思。要通過好的測試數(shù)據(jù)使用例查找問題。接口參數(shù)數(shù)據(jù)需對每個參數(shù)根據(jù)測試接口的實際的功能進(jìn)行分析，在符合業(yè)務(wù)邏輯的情況下進(jìn)行邏輯組合排列，不要遺漏了某些邊界值和錯誤點的數(shù)據(jù)。每個用例執(zhí)行所需系統(tǒng)數(shù)據(jù)和接口參數(shù)數(shù)據(jù)盡可能的采用不一樣的數(shù)據(jù) ，使用例更容易發(fā)現(xiàn)問題。 3）測試功能點，如果一個接口功能復(fù)雜時推薦對接口用例進(jìn)行結(jié)構(gòu)劃分，這樣子用例具有更好的可讀性和維護(hù)性。接口劃分原則為以接口提供的功能點的不同進(jìn)行合適粒度的劃分。同一功能點的用例又可根據(jù)測試環(huán)境的不同、數(shù)據(jù)的不同進(jìn)行用例的填充。 4）接口測試用例執(zhí)行操作非常簡單，就是所測接口的調(diào)用。 5）預(yù)期結(jié)果驗證，這也是接口用例設(shè)計的很關(guān)鍵的一步，應(yīng)該細(xì)而不冗余。每個用例均需驗證，避免一個用例中重復(fù)做相同的驗證，提高測試用例的效率。如何設(shè)計接口測試用例小例子：簡單劃分可以按照2個基本組成要素進(jìn)行劃分：1. 參數(shù) 2. 業(yè)務(wù) 以下為最簡單的一種劃分用例的方法，可能涵蓋不全，但只為說明一種劃分接口用例的方法方式以及需要考慮的測試用例的測試點為何要如此設(shè)計，是為了更好的將用例分類為程序規(guī)定型以及業(yè)務(wù)限制型，盡量的保證覆蓋，盡量細(xì)化到點的劃分形式來保證工作時間的預(yù)估和計劃。所有的自動化接口的測試用例都基本圍繞三部曲進(jìn)行，傳數(shù)據(jù)，執(zhí)行，校驗返回的數(shù)據(jù)和期望數(shù)據(jù)是否一致來構(gòu)成每個簡單的測試用例。有清晰的線路和清晰的思維，才能做好整體測試的掌控。

以上就是關(guān)于外部接口測試方法相關(guān)問題的回答。希望能幫到你，如有更多相關(guān)問題，您也可以聯(lián)系我們的客服進(jìn)行咨詢，客服也會為您講解更多精彩的知識和內(nèi)容。