【轉載】接口測試用例的設計原則

1．接口概述

在與研發人員溝通過程中，經常會聽到這個值是通過xx接口傳遞的；這裡有個Bug，你看下xx接口調試下；系統要預留xx接口。這接口到底為何物呢，今天就來為大家介紹下接口（包括接口測試），讓大家看到接口不再陌生。

1.1什麼是接口

計算機中包括硬體接口和軟體接口。電腦等資訊機器硬體元件間的接口叫硬體接口，是可以看到的以實物存在的如序列槽、并口等；而電腦等資訊機器軟體元件間的接口叫軟體接口。而軟體接口則是虛拟存在的接口。

接口廣義的定義為：泛指實體把自己提供給外界的一種抽象化物（可以為另一實體），用以由内部操作分離出外部溝通方法，使其能被修改内部而不影響外界其他實體與其互動的方式。

接口狹義的定義為：是指特定的函數集合，一般是用interface（Delphi）聲明的，它表示一個方法集合，這個集合被成為一個命名接口。一個命名接口中的方法必須在一個類中實作後才能被使用，一個類繼承實作一個接口，稱為這個類實作了該接口，一個接口可以被多個類實作，一個類也可以實作繼承多個接口，這樣就形成了一種靈活的接口調用的方式，進而實作更加靈活和節省資源的多态。

這裡說下我個人對接口的了解：接口就是提供一個入口或者提供一個方法來改變要調用的對象的屬性，或者得到一些想要的值。

目前測試接觸到的接口基本都是以HTTP協定為基礎的接口（包括WebService接口）。

1.2什麼是接口測試

接口測試是項目測試的一部分，正如其名，它測試的主要對象是接口，是測試系統元件間接口的一種測試。接口測試主要用于檢測外部系統與系統之間以及内部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的互相邏輯依賴關系等。

不管是何種接口測試，其測試都為用戶端發送request請求，接着伺服器會傳回response封包，然後我們需要對response内容進行比對，進而來中判定接口通路是否成功，最終驗證業務是否符合需求。

1.3為什麼要做接口測試

早起的系統業務邏輯相對簡單，基本的功能測試、性能測試、GUI自動化測試已經足以覆寫項目的需求。而随着産品功能越來越多，系統架構越來越複雜，一些預想不到的Bug出現在我們面前，怎麼辦呢？這時候急需要一種更有效的測試方法來适應目前的變化，來持續的保證我們産品的品質，是以接口測試的出現就是為了解決該問題。

從回歸測試來說：系統Ａ改了一個接口，相關聯系統Ｂ的開發人員并不知道（當然系統Ａ的開發人員也不知道他會影響到Ｂ），導緻Ａ釋出後，Ｂ出錯，Ｂ的使用者開始抱怨。此時如果有那麼接口測試在持續內建運作的話，當Ｂ測試出錯，Ｂ的開發一下就能發現，也就能立即改掉。

另一方面，在測試原則中有這麼一條：盡早的和不斷的進行測試。闡述的是盡早的持續的測試過程，當進行接口測試時，發現的問題一般都與業務相關，此類Bug造成的危害比UI上發現的問題更為嚴重，是以有利于Bug的早起修複。

1.4接口測試分類

接口測試分為子產品接口測試和Web接口測試。子產品接口測試需要對代碼有一定的掌握能力，可以劃分到白盒測試中；而Web接口測試分為伺服器接口測試和外部接口測試。

伺服器接口測試：是測試浏覽器與伺服器的接口。這個很容易了解，我們知道web開發一般分前端和後端，前端開發人員用HTML/CSS/JavaScript等技術。後端開發人用PHP/JAVA/Python/Ruby等各種語言。使用者輸入的資料是輸入到的前端頁面上，怎樣把這些資料傳遞的背景的呢？通過HTTP協定的GET與POST請求來實作前後端的資料傳遞。這也可認為是接口測試，調用的登入接口還是查詢接口，傳參的是使用者密碼還是搜尋關鍵字。

外部接口測試：這個很典型的例子就是第三方登入，比如你做的新系統免于新使用者重新注冊的麻煩會提供第三方登入，那使用者在登入的時候調用的就是第三方登入的接口，由第三方驗證使用者名和密碼并且傳回給目前系統。

1.5接口測試目的及方式

         核心：保證系統接口的功能正常

         方式：持續內建

         目的：提高測試效率，保證資料的準确性

         文檔：接口測試對接口定義文檔要求很高，所有的接口資料類型及業務分支導緻的封包傳回結構是需要事先定義好的，是以要形成文檔的習慣，以友善查閱，盡量減少團隊與團隊間的溝通成本。

         同樣我們在接口測試中，也需要根據文檔，整理出我們的接口測試資料及接口測試案例，有效的生成相關測試報告，友善其它人去稽核、分析接口測試的成果。

2．接口測試用例設計

2.1測試用例設計流程

         首先，明确出發點。和所有的測試一樣，接口測試出發點是你要證明所測的程式是錯誤的。以這個出發點為導向，你的設計行為就會盡量朝這個方向發展，更易發現問題，不會出現大方向的偏差。

         其次，選擇好測試對象。對于一個系統做接口測試選擇好的測試對象是接口測試關鍵。一個系統有無數的接口，每個接口如果分别測試，那将是很痛苦的一件事情，不光繁瑣浪費，而且任何一個内部接口的變動，都将導緻我們用例的不可用。這裡推薦把整個系統作為一個整體，選擇整個系統提供給外部使用、互動的最外層接口作為你的測試對象，以此為測試對象的用例将有很好的健壯性，并且更高效。另外，根據資料的流向，又可将這些最外層的接口分為兩類：一類是資料進入系統的接口；一類是資料流出系統的接口。進入系統的接口實際是我們用例的執行調用的接口。可通過變化參數對這些接口進行調用，模拟外部的使用；而流出的接口則是我們用例真正該驗證的點。資料從哪裡流出，流出時的狀态如何，此時系統又是什麼狀态都是我們所應該驗證的。

         然後，确認完整的測試對象的功能：确認外部接口提供給使用這些接口的外部使用者什麼樣的功能，外部使用者真正需要什麼樣的功能。此兩個功能一定要準确詳細，用例的設計要嚴格按照測試對象功能設計才是正确的用例。

         最後當出發點、對象、功能都确定了，就可以真正設計用例了。

2.2測試用例設計原則

         通常，設計接口測試用例需要考慮以下幾個方面：

1.是否滿足前提條件。有些接口需要滿足前置條件，才可以成功擷取資料。

2.是否攜帶預設參數值。帶預設值的參數都不填寫，必填參數都填寫正确，其他不填寫。

3.業務規則、功能需求。根據實際的業務規則和需求進行用例設計。

4.參數是否必填。異常情況，參數為空的測試。

5.參數之間是否存在關聯。若參數之間存在限制關系，則要設計相關用例進行測試。

6.參數資料類型限制。參數值限制了資料類型，則輸入非該類型進行測試。

7. 參數資料類型自身的資料範圍值限制。根據邊界範圍設計邊界值進行測試。