【文章末尾給大家留下了大量的福利】

簡介：?對于接口自動化測試，從用例設計到測試腳本實現，總結起來，需要我們具備如下思想：模塊化思想、數據驅動思想、關鍵字驅動思想

作者：予慕

序

?

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

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

服務端接口測試介紹

?

什么是服務端？

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

什么是接口？

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

什么是接口測試？

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

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

為什么要做接口測試？

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

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

如何做接口測試？

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

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

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

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

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

?

接口測試自動化介紹

?

什么是接口測試自動化？

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

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

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

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

接口測試自動化的規范

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

• 文檔準備
  ?

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

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

2、《接口文檔》，明確定義了：接口名，各個入參值，各個返回值，和其他相關信息；

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

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

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

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

1、校驗（斷言）

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

2、數據隔離

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

3、數據傳遞

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

4、功能函數

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

5、可配置

目前測試環境包括但不限于日常、預發一、預發二、線上等等，因此用例不單單只能在一個環境上執行，需要同一份接口用例可以在日常、預發、線上等多個環境都可以執行。所以框架需要做到可配置，便于切換，調用不同的配置文件可以在不同的環境執行。6、日志日志包含執行的具體執行接口、請求方式、請求參數、返回值、校驗接口、請求時間、耗時等關鍵信息，日志的好處一來是可以便于在新增用例有問題時快速定位出哪里填寫有問題，二來是發現 bug 時方便向開發反饋提供數據，開發可以從觸發時間以及參數等信息快速定位到問題所在。

7、可視化報告

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

8、可持續集成

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

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

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

這里簡單列舉一下：

1、fiddler

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

2、postman

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

3、wireshak

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

4、soupUI

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

5、Java 代碼做接口測試

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

6、Python 代碼做接口測試

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

?

接口測試自動化實踐

?

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 修飾的方法可以跟普通函數完全一樣；

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

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

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

6、JUnit 4 的測試結果通過 Green/Red bar 體現，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、注解支持

主要區別以下兩點：

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

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

3、異常測試

“異常測試”是指從單元測試中拋出的異常，此功能在 JUnit 4 和 TestNG 中都可實現。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、忽略測試

忽略測試意思是在單元測試哪些是可以被忽略的，這個特性在兩個框架都已經實現。

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、超時測試

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

JUnit 4

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

TestNG

@Test(timeOut = 1000) public voi

6、套件測試

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

JUnit 4

“@RunWith”和“@Suite”用于運行套件測試。下面的類代碼表示在 JunitTest3 執行之后，單元測試“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 獨特的“分組”概念，每種方法都可以與一個組合相結合，可以根據功能對測試進行分類(分組)。例如，

下面是一個有四個方法的類，三個組(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”執行單元測試。

<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、參數化測試

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

Junit4 參數化測試：

• 步驟如下：

1.通過@Parameters 標識靜態參數構造方法

2.通過測試類構造方法引入參數

3.測試方法使用參數

@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); } }

• 缺點：

一個測試類只能有一個靜態的參數構造方法；

測試類需要使用@RunWith(Parameterized.class)，無法兼容 spring-test 的 runner

@RunWith(SpringJUnit4ClassRunner.class)，會導致無法通過注解注入待測服務

需要在測試類中添加一個構造方法（一種冗余設計）

TestNG 參數化測試：

• 步驟如下：

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

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

@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 構造參數：

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、依賴測試

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

JUnit 4

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

TestNG

它使用“dependOnMethods”來實現依賴測試如下

@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 接口自動化實踐

• 參數化測試示例
  ?

以 DeviceStatusHSFService 為例，測試類如下：

public class DeviceStatusHSFServiceTest {private DeviceStatusHSFService deviceStatusHSFService;@BeforeTest(alwaysRun = true)public void beforeTest() {String envName = System.getProperty("maven.env"); //運行環境可配置SwitchENV switchEnv = new SwitchENV(envName); //運行環境可配置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 類實現運行環境可配置：

/*** 自定義環境配置*/ public class SwitchENV {/*** 運行環境*/private Env env;/*** hsf環境*/private String hsfVersion;/*** 目標機器*/private String targetIp;/*** 環境名稱*/private String envName;public SwitchENV(String envName) {Properties prop = new Properties();// TODO: 本地自動化測試切換環境專用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("環境變量輸入錯誤！");} 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;}}

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

/*** 自定義環境配置*/ public class SwitchENV {/*** 運行環境*/private Env env;/*** hsf環境*/private String hsfVersion;/*** 目標機器*/private String targetIp;/*** 環境名稱*/private String envName;public SwitchENV(String envName) {Properties prop = new Properties();// TODO: 本地自動化測試切換環境專用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("環境變量輸入錯誤！");} 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;}}

思考與總結

?

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

• 模塊化思想
• 數據驅動思想
• 關鍵字驅動思想

模塊化思想

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

數據驅動思想

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

關鍵字驅動思想

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

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

??重點：學習資料學習當然離不開資料，這里當然也給你們準備了600G的學習資料

需要的私我關鍵字【000】免費獲取哦 注意關鍵字是：000

項目實戰：

大型電商平臺：

全套軟件測試自動化測試教學視頻

?

300G教程資料下載【視頻教程+PPT+項目源碼】

?

全套軟件測試自動化測試大廠面經

?

python自動化測試++全套模板+性能測試

?

?

聽說關注我并三連的鐵汁都已經升職加薪暴富了哦！！！！

總結

以上是生活随笔為你收集整理的关于关于接口测试自动化的总结与思考接口测试自动化的总结与思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。