序

近期看到阿里云性能測試 PTS 接口測試開啟免費公測，本著以和大家交流如何實現(xiàn)高效的接口測試為出發(fā)點，本文包含了我在接口測試領域的一些方法和心得，希望大家一起討論和分享，內容包括但不僅限于：

• 服務端接口測試介紹
• 接口測試自動化介紹
• 接口測試自動化實踐
• 關于接口測試自動化的思考和總結

服務端接口測試介紹

什么是服務端？

一般所說的服務端是指為用戶在 APP 或 PC 使用的互聯(lián)網(wǎng)功能提供數(shù)據(jù)服務的背后的一切。以天貓精靈智能音箱系列的產(chǎn)品鏈路為例，服務端便是網(wǎng)關（包括網(wǎng)關在內）之后的鏈路。

什么是接口？

官方點說，是計算機系統(tǒng)中兩個獨立的部件進行信息交換的共享邊界。通俗點說，就是服務端對外提供數(shù)據(jù)服務最常用的信息交換方式。提供數(shù)據(jù)服務的服務端是個可大可小的機構，做的事大多不止一件，它做了這么多事，最終的目標是給 APP 或其它調用方使用，于是服務端就派出了幾個代表，比如 API 1 負責提供用戶信息，API 2 負責提供設備信息，API 3 負責提供播放的音頻信息等等。同事，服務端規(guī)定好跟 API 1 通訊的接頭暗號是 param1，param2…，跟 API 2 通訊的接頭暗號是 param3，param4…，而 params 就是接口參數(shù)，就是用來告訴服務端你要什么服務，具體的要求是什么。接口一般由三個部分組成：協(xié)議、地址及參數(shù)。

什么是接口測試？

一般講的接口測試指的是對某個給定接口進行功能測試，輸入不同的參數(shù)時，接口返回值是否正確。下圖是經(jīng)典的測試金字塔模型。

在這個模型中，越往下比例會占的越高，也就是說在一個產(chǎn)品測試中，單元測試比例是最高的，依次是接口測試和UI自動化測試，最頂端是人工測試部分。服務端接口測試在中部，承上啟下，由此可見其重要性。

為什么要做接口測試？

一般做接口測試有如下原因：

• 接口是服務端對外提供數(shù)據(jù)服務最常用的信息交換方式，接口大部分內容都是數(shù)據(jù)，通過數(shù)據(jù)對比我們可以推測到系統(tǒng)的邏輯，測接口其實也就是測邏輯。
• 接口測試相對容易實現(xiàn)自動化，也容易實現(xiàn)持續(xù)集成，且相對 UI 自動化也比較穩(wěn)定，可以減少人工回歸測試人力成本與時間，縮短測試周期，支持后端快速發(fā)版需求。

如何做接口測試？

前面提到，接口是由這幾個組成部分：接口地址、請求協(xié)議、請求參數(shù)和預期結果。測試接口的步驟一般步驟是：發(fā)送請求->解析結果->驗證結果。

簡單來說，接口測試就是參照接口文檔，調用接口，看結果的返回是否跟文檔說明一致；另外，再測試一下接口對異常邏輯的處理比如非法參數(shù)或邊界值。

深入來說，接口測試的關注重點在于：

一、接口的數(shù)據(jù)邏輯是否正確。我們需要充分理解接口的功能，內部是什么樣的數(shù)據(jù)邏輯，它與上下游交換了那些信息或資源，不單純地停留在參數(shù)調用和程序返回的表象數(shù)據(jù)。通俗地說，就是要知道這個接口是干什么用的，用到哪里，每次調用會發(fā)生什么，然后去檢驗改發(fā)生的有沒有發(fā)生。

二、接口對于異常參數(shù)的處理機制與上下游服務的容錯。如下圖所示，被測接口 A 依賴上游服務 A，那么服務 A 異常的時候被測接口是否很好的容錯就很重要，否則服務掛起或宕掉都是有可能的。另外，作為服務提供方接口 B，應當要充分兼容不同的使用場景、或不同版本的調用方的使用，不能為了服務 E 做的需求，除了 E 其它的服務使用者都用不了了?？偟膩碚f，原則就是“上游不可靠，下游要兼容”。

現(xiàn)在我也找了很多測試的朋友，做了一個分享技術的交流群，共享了很多我們收集的技術文檔和視頻教程。
如果你不想再體驗自學時找不到資源，沒人解答問題，堅持幾天便放棄的感受
可以加入我們一起交流。而且還有很多在自動化，性能，安全，測試開發(fā)等等方面有一定建樹的技術大牛
分享他們的經(jīng)驗，還會分享很多直播講座和技術沙龍
可以免費學習！劃重點！開源的！！！
qq群號：110685036【暗號：csdn888】

接口測試自動化介紹

什么是接口測試自動化？

接口測試自動化，簡單來講就是功能測試用例腳本化，然后執(zhí)行腳本，產(chǎn)生一份可視化測試報告。

為什么要做接口測試自動化？

不管什么樣的測試方式，都是為了驗證功能與發(fā)現(xiàn) bug。那為什么要做接口測試自動化呢？一句話概括就是是為了節(jié)省人力成本。具體來說，包括以下幾點：

• 減輕自己工作量，把測試從枯燥的重復勞動的人工測試中解放出來；
• 協(xié)助手工測試完成很難模擬或無法模擬的的工作；
• 提高工作效率，比如測試環(huán)境的自動化編譯、打包、部署、持續(xù)集成甚至持續(xù)交付等。
• 協(xié)助定位問題，比如接口層發(fā)現(xiàn)問題了，可以通過添加的 traceID 定位到日志錯誤或錯誤代碼行，
• 盡早發(fā)現(xiàn) Bug，自動通知測試人員。一旦發(fā)現(xiàn)問題，立即通知測試人員，快速高效。

接口測試自動化的規(guī)范

這里結合我平常在做接口測試時的一些經(jīng)驗，總結了一些接口測試自動化的規(guī)范，拋磚引玉，歡迎大家補充。

• 文檔準備

磨刀不誤砍柴工，準備好分詳細的接口相關文檔能夠幫助后續(xù)接口自動化測試工作的高效展開。相關文檔包括但不限于一下內容：

1、《需求文檔》，明確定義了：接口背后的業(yè)務場景，即該接口是干什么用的，用到哪里，每次調用會發(fā)生什么等；

2、《接口文檔》，明確定義了：接口名，各個入?yún)⒅?#xff0c;各個返回值，和其他相關信息；

3、《UI 交互圖》，明確定義了：各單頁面需展示的數(shù)據(jù)；頁面之間的交互等；

4、《數(shù)據(jù)表設計文檔》，明確定義了：表字段規(guī)則、表 N 多 N 關系（一對一、一對多、多對多）等；

務必和相關需求方確認好文檔中的信息是可靠且最新的，只有依賴可靠的文檔才能設計出正確詳盡的接口用例，才能得到最正確的結果。

• 明確接口測試自動化需要的功能

1、校驗（斷言）

測試斷言是自動化測試中的測試通過條件，用于判斷測試用例是否符合預期。所以支持對返回值校驗是一個必須的功能。

2、數(shù)據(jù)隔離

數(shù)據(jù)隔離就是指具體的請求接口、參數(shù)、校驗等數(shù)據(jù)做到與代碼相隔離，便于維護，一旦需要調整接口用例、新增接口用例時可很快速的找到位置。隔離的另一個好處就是可復用，框架可以推廣給其他團隊，使用者可以使用相同的代碼，只需要根據(jù)要求填寫各自用例即可測試起來。

3、數(shù)據(jù)傳遞

做到數(shù)據(jù)隔離可維護后，數(shù)據(jù)傳遞是另外一個更重要的需求。接口測試時，首先我們會實現(xiàn)單接口解耦，后續(xù)按照業(yè)務場景組合多個接口。而數(shù)據(jù)傳遞是則是組合多個接口的必要條件，它讓接口用例之間可以做到向下傳參。舉個例子，我們通過設備信息查詢接口查詢到當前天貓精靈音箱的設備信息，該接口會返回一個 UUID，接下來我們要通過用戶信息查詢接口去查詢當前設備綁定的用戶信息，此時第二個接口的請求數(shù)據(jù)是需要從第一個接口用例中的返回中提取的。

4、功能函數(shù)

實際的業(yè)務場景測試會需要各種輔助功能的支持，比如隨機生成時間戳，請求 ID，隨機的手機號碼或位置信息等等，此時我們就需要代碼可以支持做到識別對應關鍵字時可以執(zhí)行對應的功能函數(shù)進行填充。

5、可配置

目前測試環(huán)境包括但不限于日常、預發(fā)一、預發(fā)二、線上等等，因此用例不單單只能在一個環(huán)境上執(zhí)行，需要同一份接口用例可以在日常、預發(fā)、線上等多個環(huán)境都可以執(zhí)行。所以框架需要做到可配置，便于切換，調用不同的配置文件可以在不同的環(huán)境執(zhí)行。

6、日志

日志包含執(zhí)行的具體執(zhí)行接口、請求方式、請求參數(shù)、返回值、校驗接口、請求時間、耗時等關鍵信息，日志的好處一來是可以便于在新增用例有問題時快速定位出哪里填寫有問題，二來是發(fā)現(xiàn) bug 時方便向開發(fā)反饋提供數(shù)據(jù)，開發(fā)可以從觸發(fā)時間以及參數(shù)等信息快速定位到問題所在。

7、可視化報告

用例執(zhí)行后，就是到了向團隊展示結果的時候了，一個可視化的報告可以便于團隊成員了解到每次自動化接口用例執(zhí)行的成功數(shù)、失敗數(shù)等數(shù)據(jù)。

8、可持續(xù)集成

對于已經(jīng)有測試用例并測試完成的接口，我們希望能夠形成回歸用例，在下一個版本迭代或上線之前，通過已有用例進行一個回歸測試，確保新上線的功能不影響已有功能。因此，這就需要接口自動化測試是可持續(xù)集成的而不是一次性的。

• 接口測試自動化框架選型

結合我們對接口測試自動化框架的需求及目前市場上的很多測試工具的特點，總結成下表：

這里簡單列舉一下：

1、fiddler

fiddler 是一個 HTTP 協(xié)議調試代理工具，Web 和手機測試都會用到，同時也支持接口測試。它能夠記錄并檢查所有你的電腦和互聯(lián)網(wǎng)之間的 http 通訊，設置斷點，查看所有的“進出”Fiddler 的數(shù)據(jù)（指 cookie,html,js,css 等文件）。

2、postman

它是 Google 開發(fā)的一個插件，安裝在 Chrome 瀏覽器上，能支持不同接口測試請求，可以管理測試套件和自動化運行。弱點是自動化斷言功能不強大，不能和 Jenkins、代碼管理庫進行持續(xù)集成測試。

3、wireshak

這是一款抓包工具，支持 TCP、UDP、HTTP 等協(xié)議。如果做底層網(wǎng)絡數(shù)據(jù)測試，一般都需要用到它，但是用作接口測試，它就有點不友好。因為刷新數(shù)據(jù)太快，不好定位每個操作對應的接口。

4、soupUI

soapUI 是一個開源測試工具，通過 soap/http 來檢查、調用、實現(xiàn) Web Service 的功能/負載/符合性測試。該工具既可作為一個單獨的測試軟件使用，也可利用插件集成到 Eclipse，maven2.X，Netbeans 和 intellij 中使用。把一個或多個測試套件（TestSuite）組織成項目，每個測試套件包含一個或多個測試用例（TestCase），每個測試用例包含一個或多個測試步驟，包括發(fā)送請求、接受響應、分析結果、改變測試執(zhí)行流程等。該工具能夠支持接口自動化測試和接口性能測試，也支持和 Jenkins 做持續(xù)集成測試。

5、Java 代碼做接口測試

為什么要用代碼做接口自動化測試呢？一些工具功能是有限制，很多公司需要一些特定的功能，工具不支持，只好用代碼進行開發(fā)。一般用 Java 做自動化測試，主要利用 httpclient.jar 包，然后利用 JUnit 或者 TestNG 這樣的單元測試工具，進行測試用例的開發(fā)，接著在 Jenkins 或我們的 aone 上創(chuàng)建一個 job，進行持續(xù)集成測試。

6、Python 代碼做接口測試

和 Java 一樣，用 Python 做接口測試，可以利用一個功能強大的第三方庫 Requests，它能方便地創(chuàng)建接口自動化用例。Python 下的單元測試框架，一般采用 unittest。生成測試報告，一般選擇 HTMLTestRunner.py。同樣，可以結合 Jenkins 做持續(xù)集成測試。

接口測試自動化實踐

TestNG 與 Junit 對比

• 綜合性對比

我在日常測試工作中，使用的比較多的自動化測試工具是 Java 代碼做接口測試，這里先介紹下我對單元測試工具 TestNG 和 Junit 的對比。先用一張表格總結一下他們的特點對比。

TestNG 與 JUnit 的相同點如下：

1、都有注解，即都使用 annotation，且大部分 annotation 相同；

2、都可以進行單元測試（Unit test）；

3、都是針對 Java 測試的工具；

TestNG 與 JUnit 的不同點如下：

1、TestNG 支持的注解更豐富，如@ExpectedExceptions、@DataProvider 等；

2、JUnit 4 中要求@BeforeClass、@AfterClass 方法聲明為 static，這就限制了該方法中使用的變量必須是 static。而 TestNG 中@BeforeClass 修飾的方法可以跟普通函數(shù)完全一樣；

3、JUnit 只能使用 IDE 運行，TestNG 的運行方式有：命令行、ant 和 IDE；

4、JUnit 4 依賴性非常強，測試用例間有嚴格的先后順序。前一個測試不成功，后續(xù)所有的依賴測試都會失敗。TestNG 利用@Test 的 dependsOnMethods 屬性來應對測試依賴性問題。某方法依賴的方法失敗，它將被跳過，而不是標記為失敗。

5、對于 n 個不同參數(shù)組合的測試，JUnit 4 要寫 n 個測試用例。每個測試用例完成的任務基本是相同的，只是方法的參數(shù)有所改變。TestNG 的參數(shù)化測試只需要一個測試用例，然后把所需要的參數(shù)加到 TestNG 的 xml 配置文件中或使用@DataProvider 方式注入不同的參數(shù)。這樣的好處是參數(shù)與測試代碼分離，非程序員也可以修改參數(shù)，同時修改無需重新編譯測試代碼。

6、JUnit 4 的測試結果通過 Green/Red bar 體現(xiàn)，TestNG 的結果除了 Green/Red bar，還有 Console 窗口和 test-output 文件夾，對測試結果的描述更加詳細，方便定位錯誤。

• 詳細特性對比

下面詳細介紹一下 TestNG 與 Junit 特性對比：

1、框架整合：

Spring+TestNG+Maven 整合：

• pom.xml 中增加 testng 依賴：

<dependency><groupId>org.testng</groupId><artifactId>testng</artifactId><version>6.8.8</version><scope>test</scope>
</dependency>

• 測試類增加 1 條注解@ContextConfiguration(locations = "classpath:applicationContext.xml")并繼承 AbstractTestNGSpringContextTests，范例如下

@ContextConfiguration(locations = "classpath:applicationContext.xml") 
public class BaseTest extends AbstractTestNGSpringContextTests{     @Testpublic void testMethods()     {         ......     } 
}

Spring+Junit+Maven 整合：

• pom.xml 中增加 junit 依賴：

<!--Junit版本-->
<dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>4.4</version><scope>test</scope>
</dependency>

• 測試類增加 2 條注解

@RunWith(SpringJUnit4ClassRunner.class)

@ContextConfiguration(locations = "classpath:applicationContext.xml"),如下：

@RunWith(SpringJUnit4ClassRunner.class) 
@ContextConfiguration(locations = "classpath:applicationContext.xml") 
public class BaseTest{     @Test     public void testMethods()     {         ......     } 
}

2、注解支持

主要區(qū)別以下兩點：

1、在 JUnit 4 中，我們必須聲明“@BeforeClass”和“@AfterClass”方法作為靜態(tài)方法。TestNG 在方法聲明中更靈活，它沒有這個約束。

2、在 JUnit 4 中，注釋命名約定有點混亂，例如“Before”，“After”和“Expected”，我們并不真正了解“Before”和“After”之前的內容，以及要測試中的“預期” 方法。TestiNG 更容易理解，它使用類似“BeforeMethod”，“AfterMethod”和“ExpectedException”就很明了。

3、異常測試

“異常測試”是指從單元測試中拋出的異常，此功能在 JUnit 4 和 TestNG 中都可實現(xiàn)。JUnit 4

@Test(expected = ArithmeticException.class) public void divisionWithException() {   int i = 1/0; }

TestNG

@Test(expectedExceptions = ArithmeticException.class) public void divisionWithException() {   int i = 1/0; }

4、忽略測試

忽略測試意思是在單元測試哪些是可以被忽略的，這個特性在兩個框架都已經(jīng)實現(xiàn)。

JUnit 4

@Ignore("Not Ready to Run")  @Test public void divisionWithException() {      System.out.println("Method is not ready yet"); }

TestNG

@Test(enabled=false) public void divisionWithException() {      System.out.println("Method is not ready yet"); }

5、超時測試

時間測試意思是如果一個單元測試運行的時間超過了一個指定的毫秒數(shù)，那么測試將終止并且標記為失敗的測試，這個特性在兩個框架都已經(jīng)實現(xiàn)。

JUnit 4

@Test(timeout = 1000)  public void infinity() {      while(true);  }

TestNG

@Test(timeOut = 1000)  public voi

6、套件測試

“套件測試”是指捆綁幾個單元測試并一起運行。此功能在 JUnit 4 和 TestNG 中都可實現(xiàn)。然而，兩者都使用非常不同的方法來實現(xiàn)它。

JUnit 4

“@RunWith”和“@Suite”用于運行套件測試。下面的類代碼表示在 JunitTest3 執(zhí)行之后，單元測試“JunitTest1”和“JunitTest2”一起運行。所有的聲明都是在類內定義的。

@RunWith(Suite.class) @Suite.SuiteClasses({         JunitTest1.class,         JunitTest2.class }) public class JunitTest3 { }

TestNG

XML 文件用于運行套件測試。以下 XML 文件表示單元測試“TestNGTest1”和“TestNGTest2”將一起運行。

<suite name="My test suite">   <test name="testing"><classes><class name="com.fsecure.demo.testng.TestNGTest1" /><class name="com.fsecure.demo.testng.TestNGTest2" /></classes>   </test>
</suite>

TestNG 可以做捆綁類測試，也可以捆綁方法測試。憑借 TestNG 獨特的“分組”概念，每種方法都可以與一個組合相結合，可以根據(jù)功能對測試進行分類(分組)。例如，

下面是一個有四個方法的類，三個組(method1，method2 和 method3)

@Test(groups="method1") public void testingMethod1() {   System.out.println("Method - testingMethod1()"); } 
@Test(groups="method2") public void testingMethod2() {   System.out.println("Method - testingMethod2()"); } 
@Test(groups="method1") public void testingMethod1_1() { System.out.println("Method - testingMethod1_1()"); } 
@Test(groups="method4") public void testingMethod4() { System.out.println("Method - testingMethod4()"); }

使用以下 XML 文件，可以僅使用組“method1”執(zhí)行單元測試。

<suite name="My test suite">   <test name="testing">       <groups>       <run>         <include name="method1"/>       </run>     </groups>     <classes>        <class name="com.fsecure.demo.testng.TestNGTest" /></classes>   </test> 
</suite>

7、參數(shù)化測試

“參數(shù)化測試”是指單位測試參數(shù)值的變化。此功能在 JUnit 4 和 TestNG 中都實現(xiàn)。然而，兩者都使用非常不同的方法來實現(xiàn)它。

Junit4 參數(shù)化測試：

• 步驟如下：

1.通過@Parameters 標識靜態(tài)參數(shù)構造方法

2.通過測試類構造方法引入?yún)?shù)

3.測試方法使用參數(shù)

@RunWith(value = Parameterized.class) 
public class JunitTest {       private int number;       public JunitTest6(int number) {         this.number = number;      }     @Parameters      public static Collection<Object[]> data() {        Object[][] data = new Object[][] { { 1 }, { 2 }, { 3 }, { 4 } };        return Arrays.asList(data);      }      @Test      public void pushTest() {        System.out.println("Parameterized Number is : " + number);      } 
}

• 缺點：

1. 一個測試類只能有一個靜態(tài)的參數(shù)構造方法；
2. 測試類需要使用@RunWith(Parameterized.class)，無法兼容 spring-test 的 runner
3. @RunWith(SpringJUnit4ClassRunner.class)，會導致無法通過注解注入待測服務
4. 需要在測試類中添加一個構造方法（一種冗余設計）

TestNG 參數(shù)化測試：

• 步驟如下：

1.通過@dataProvider 注解標識參數(shù)構造方法

2.測試方法在注解@Test 中通過 dataProvider 屬性指定參數(shù)構造方法，便可在測試方法中使用參數(shù)

@Test(dataProvider = "Data-Provider-Function")     
public void parameterIntTest(Class clzz, String[] number) {       System.out.println("Parameterized Number is : " + number[0]);       System.out.println("Parameterized Number is : " + number[1]);     
}

除此之外，TestNG 還支持通過 testng.xml 構造參數(shù)：

public class TestNGTest {  @Test @Parameters(value="number") public void parameterIntTest(int number) {        System.out.println("Parameterized Number is : " + number);     } 
}

XML 文件的內容如下

<suite name="My test suite">   <test name="testing">     <parameter name="number" value="2"/>     <classes>        <class name="com.fsecure.demo.testng.TestNGTest" />     </classes>   </test> 
</suite>

8、依賴測試

“參數(shù)化測試”表示方法是依賴性測試，它將在所需方法之前執(zhí)行。如果依賴方法失敗，則所有后續(xù)測試將會被跳過，不會被標記為失敗。

JUnit 4

JUnit 框架著重于測試隔離; 目前它不支持此功能。

TestNG

它使用“dependOnMethods”來實現(xiàn)依賴測試如下

@Test public void method1() {    System.out.println("This is method 1"); 
}
@Test(dependsOnMethods={"method1"}) 
public void method2() {     System.out.println("This is method 2"); 
}

TestNG 接口自動化實踐

• 參數(shù)化測試示例

以 DeviceStatusHSFService 為例，測試類如下：

public class DeviceStatusHSFServiceTest {private DeviceStatusHSFService deviceStatusHSFService;@BeforeTest(alwaysRun = true)public void beforeTest() {String envName = System.getProperty("maven.env");  //運行環(huán)境可配置SwitchENV switchEnv = new SwitchENV(envName);    //運行環(huán)境可配置deviceStatusHSFService = HsfRepository.getConsumer(DeviceStatusHSFService.class, switchEnv.getEnv(),"HSF", switchEnv.getHsfVersion(), "aicloud-device-center", switchEnv.getTargetIp()).getTarget();}@Test(dataProvider = "updateDeviceStatus", dataProviderClass = DeviceStatusHSFServiceTestDataProvider.class)public void updateDeviceStatusTest(Long userId, String uuid, DeviceStatus deviceStatus){Result<Boolean> result = deviceStatusHSFService.updateDeviceStatus(userId, uuid, deviceStatus);System.out.println("traceId:"+EagleEye.getTraceId()+result.toString());Boolean res = result.getResult();assertTrue(res);}
}

其中通過 SwitchENV 類實現(xiàn)運行環(huán)境可配置：

/*** 自定義環(huán)境配置*/
public class SwitchENV {/*** 運行環(huán)境*/private Env env;/*** hsf環(huán)境*/private String hsfVersion;/*** 目標機器*/private String targetIp;/*** 環(huán)境名稱*/private String envName;public SwitchENV(String envName) {Properties prop = new Properties();// TODO: 本地自動化測試切換環(huán)境專用if (envName == null) {envName = "pre1";}switch (envName) {case "online": {InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream("config/application-online.properties");try {prop.load(in);} catch (IOException e) {e.printStackTrace();}env = Env.ONLINE;break;}case "pre1": {InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream("config/application-pre1.properties");try {prop.load(in);} catch (IOException e) {e.printStackTrace();}env = Env.PREPARE;break;}case "pre2": {InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream("config/application-pre2.properties");try {prop.load(in);} catch (IOException e) {e.printStackTrace();}env = Env.PREPARE;break;}case "pre3": {InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream("config/application-pre3.properties");try {prop.load(in);} catch (IOException e) {e.printStackTrace();}env = Env.PREPARE;break;}default:try {throw new Exception("環(huán)境變量輸入錯誤！");} catch (Exception e) {e.printStackTrace();}break;}hsfVersion = prop.getProperty("hsfVersion").trim();targetIp= prop.getProperty("targetIp").trim();this.envName = envName;}public Env getEnv() {return env;}public String getHsfVersion() {return hsfVersion;}public String getTargetIp() {return targetIp;}public String getEnvName() {return envName;}}

測試參數(shù)全部放在 DeviceStatusHSFServiceTestDataProvider 類中，實現(xiàn)具體的請求接口、參數(shù)、校驗等數(shù)據(jù)做到與代碼相隔離。

/*** 自定義環(huán)境配置*/
public class SwitchENV {/*** 運行環(huán)境*/private Env env;/*** hsf環(huán)境*/private String hsfVersion;/*** 目標機器*/private String targetIp;/*** 環(huán)境名稱*/private String envName;public SwitchENV(String envName) {Properties prop = new Properties();// TODO: 本地自動化測試切換環(huán)境專用if (envName == null) {envName = "pre1";}switch (envName) {case "online": {InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream("config/application-online.properties");try {prop.load(in);} catch (IOException e) {e.printStackTrace();}env = Env.ONLINE;break;}case "pre1": {InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream("config/application-pre1.properties");try {prop.load(in);} catch (IOException e) {e.printStackTrace();}env = Env.PREPARE;break;}case "pre2": {InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream("config/application-pre2.properties");try {prop.load(in);} catch (IOException e) {e.printStackTrace();}env = Env.PREPARE;break;}case "pre3": {InputStream in = SwitchENV.class.getClassLoader().getResourceAsStream("config/application-pre3.properties");try {prop.load(in);} catch (IOException e) {e.printStackTrace();}env = Env.PREPARE;break;}default:try {throw new Exception("環(huán)境變量輸入錯誤！");} catch (Exception e) {e.printStackTrace();}break;}hsfVersion = prop.getProperty("hsfVersion").trim();targetIp= prop.getProperty("targetIp").trim();this.envName = envName;}public Env getEnv() {return env;}public String getHsfVersion() {return hsfVersion;}public String getTargetIp() {return targetIp;}public String getEnvName() {return envName;}}

思考與總結

對于接口自動化測試，從用例設計到測試腳本實現(xiàn)，總結起來，需要我們具備如下思想：

• 模塊化思想
• 數(shù)據(jù)驅動思想
• 關鍵字驅動思想

模塊化思想

對于我們的接口自動化測試工程而言，需要能夠創(chuàng)建小而獨立的可以描述的模塊、片斷以及待測應用程序的腳本。這些樹狀結構的小腳本組合起來，就能組成能用于特定的測試用例的腳本。

數(shù)據(jù)驅動思想

簡而言之，就是測試腳本與測試數(shù)據(jù)分離。讓測試數(shù)據(jù)獨立于測試腳本單獨存在，解除腳本與數(shù)據(jù)之間的強耦合。測試腳本不再負責管理測試數(shù)據(jù)，而測試數(shù)據(jù)在數(shù)據(jù)驅動測試中會以文件或者數(shù)據(jù)庫的形式存在。腳本每次執(zhí)行會機械的從數(shù)據(jù)文件或者數(shù)據(jù)庫中讀入測試數(shù)據(jù)，根據(jù)測試數(shù)據(jù)的不同走進不同的測試路徑。在整個測試中，測試腳本是一成不變的，它一直機械的執(zhí)行它本身的代碼，而活著的是我們的測試數(shù)據(jù)集，我們通過不同的數(shù)據(jù)控制測試腳本中代碼的走向。這個思想能夠避免測試數(shù)據(jù)雜糅在測試腳本中，方便測試數(shù)據(jù)的擴展。再者，在自動化測試中，為了維持回歸測試的穩(wěn)定一致，測試腳本應當盡量避免更改。在非數(shù)據(jù)驅動的情況下，恰恰違背了這一原則。自動化測試中，隨著項目的深入，測試腳本將會持續(xù)增多，測試數(shù)據(jù)和腳本揉在一起？維護起來將會是一件恐怖的事情，出錯在所難免，所以這時不要這樣做，讓數(shù)據(jù)和腳本分離，堅持死的代碼，活的數(shù)據(jù)，維護的大部分工作將只面向數(shù)據(jù)。

關鍵字驅動思想

這是一種更為高級的數(shù)據(jù)驅動測試，核心思想是將測試用例的每個步驟單獨封裝成一個函數(shù)，以這個函數(shù)名作為關鍵字，將函數(shù)名及傳參寫入文件中，每個步驟映射一行文件。通過解析文件的每行內容，將內容拼成一個函數(shù)調用，調用封裝好的步驟函數(shù)，就可以一步步執(zhí)行測試案例。在一個關鍵字驅動測試中，待測應用程序的功能和每個測試的執(zhí)行步驟將被一起寫到一個表中。這一個思想通過很少的代碼來產(chǎn)生大量的測試用例。同樣的代碼在用數(shù)據(jù)表來產(chǎn)生各個測試用例的同時被復用。

當我們的測試思想越靠近上述三種類型的思想，接口測試的實現(xiàn)將越自動化。隨著人工智能的不斷發(fā)展，AI浪潮下也將誕生更多的自動化測試工具，比如采用人工智能技術，通過某種自適應的算法來迭代我們的測試用例，生成測試腳本。這意味著，未來測試人員的努力方向將在設計出更加可靠、高效的自動化用例生成工具、腳本構建工具與測試執(zhí)行工具，而原先那些重復勞動的人工測試工作就讓聰明的機器幫我們做吧。

END，今天的分享就到此結束了！點贊關注不迷路！