概述

介面自動化概述

眾所周知，介面自動化測試有著如下特點：

• 低投入，高產出。

• 比較容易實現自動化。

• 和UI自動化測試相比更加穩定。

如何做好一個介面自動化測試專案呢？

我認為，一個“好的”自動化測試專案，需要從“時間”、“人力”、“收益”這三個方面出發，做好“取捨”。

不能由於被測系統發生一些變更，就導致花費了幾個小時的自動化指令碼無法執行。同時，我們需要看到“收益”，不能為了總想看到100%的成功，而少做或者不做校驗，但是校驗多了維護成本一定會增多，可能每天都需要進行大量的維護。

所以做好這三個方面的平衡並不容易，經常能看到做自動化的同學，做到最後就本末倒置了。

提高ROI

想要提高ROI（Return On Investment，投資回報率），我們必須從兩方面入手：

1. 減少投入成本。

2. 增加使用率。

針對“減少投入成本”

我們需要做到：

• 減少工具開發的成本。儘可能的減少開發工具的時間、工具維護的時間，儘可能使用公司已有的，或是業界成熟的工具或元件。

• 減少用例錄入成本。簡化測試用例錄入的成本，儘可能多的提示，如果可以，開發一些批量生成測試用例的工具。

• 減少用例維護成本。減少用例維護成本，儘量只用在頁面上做簡單的輸入即可完成維護動作，而不是進行大量的程式碼操作。

• 減少用例優化成本。當團隊做用例優化時，可以通過一些統計資料，進行有針對性、有目的性的用例優化。

針對“增加使用率”

我們需要做到：

• 手工也能用。不只是進行介面自動化測試，也可以完全用在手工測試上。

• 人人能用。每一個需要使用測試的人，包括一些非技術人員都可以使用。

• 當工具用。將一些介面用例當成工具使用，比如“生成訂單”工具，“查詢表單資料”工具。

• 每天測試。進行每日構建測試。

• 開發的在構建之後也能觸發測試。開發將被測系統構建後，能自動觸發介面自動化測試指令碼，進行測試。

所以，我開發了Lego介面測試平臺，來實踐自己對自動化測試的一些想法。先簡單瀏覽一下網站，瞭解一下大概是個什麼樣的工具。

首頁：

用例維護頁面：

自動化用例列表：

線上執行結果：

用例數量統計：

Lego的組成

Lego介面測試解決方案是由兩部分組成的，一個就是剛剛看到的“網站”，另一個部分就是“指令碼”。

下面就開始進行“指令碼設計”部分的介紹。

指令碼設計

Lego的做法

Lego介面自動化測試指令碼部分，使用很常見的Jenkins+TestNG的結構。

相信看到這樣的模型並不陌生，因為很多的測試都是這樣的組成方式。

將自動化測試用例儲存至MySQL資料庫中，做成比較常見的“資料驅動”做法。

很多團隊也是使用這樣的結構來進行介面自動化，沿用的話，那在以後的“推廣”中，學習和遷移成本低都會比較低。

測試指令碼

首先來簡單看一下目前的指令碼程式碼：

public class TestPigeon {
    String sql;    int team_id = -1;    @Parameters({"sql", "team_id"})    @BeforeClass()    public void beforeClass(String sql, int team_id) {        this.sql = sql;        this.team_id = team_id;
        ResultRecorder.cleanInfo();
    }    /**
     * XML中的SQL決定了執行什麼用例, 執行多少條用例, SQL的搜尋結果為需要測試的測試用例
     */
    @DataProvider(name = "testData")    private Iterator<Object[]> getData() throws SQLException, ClassNotFoundException {        return new DataProvider_forDB(TestConfig.DB_IP, TestConfig.DB_PORT, 
            TestConfig.DB_BASE_NAME,TestConfig.DB_USERNAME, TestConfig.DB_PASSWORD, sql);
    }    @Test(dataProvider = "testData")    public void test(Map<String, String> data) {        new ExecPigeonTest().execTestCase(data, false);
    }    @AfterMethod
    public void afterMethod(ITestResult result, Object[] objs) {...}    @AfterClass
    public void consoleLog() {...}
}

有一種做法我一直不提倡，就是把測試用例直接寫在Java檔案中。這樣做會帶來很多問題：

• 修改測試用例需要改動大量的程式碼；

• 程式碼也不便於交接給其他同學，因為每個人都有自己的編碼風格和用例設計風格，這樣交接，最後都會變成由下一個同學全部推翻重寫一遍；

• 如果測試平臺更換，無法做用例資料的遷移，只能手動的一條條重新輸入。

所以“測試資料”與“指令碼”分離是非常有必要的。

網上很多的範例是使用的Excel進行的資料驅動，我這裡為什麼改用MySQL而不使用Excel了呢？

在公司，我們的指令碼和程式碼都是提交至公司的Git程式碼倉庫，如果使用Excel的話，每次進行自動化測試用例的維護，都需要將修改好的程式碼和Excel檔案推送到程式碼平臺上，需要進行一些列的Add、Commit、Push等操作，很顯然不方便日常經常修改測試用例的情況。

使用MySQL就沒有這樣的煩惱了，由於資料與指令碼的分離，只需對資料進行修改即可，指令碼每次會在資料庫中讀取最新的用例資料進行測試。同時，還可以防止一些操作程式碼時的誤操作。

這裡再附上一段我自己寫的DataProvider_forDB方法，方便其他同學使用在自己的指令碼上：

import java.sql.*;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;

/**
 * 資料來源 資料庫
 *
 * @author yongda.chen
 */
public class DataProvider_forDB implements Iterator<Object[]> {

    ResultSet rs;
    ResultSetMetaData rd;

    public DataProvider_forDB(String ip, String port, String baseName, 
        String userName, String password, String sql) throws ClassNotFoundException, SQLException {

        Class.forName("com.mysql.jdbc.Driver");
        String url = String.format("jdbc:mysql://%s:%s/%s", ip, port, baseName);
        Connection conn = DriverManager.getConnection(url, userName, password);
        Statement createStatement = conn.createStatement();

        rs = createStatement.executeQuery(sql);
        rd = rs.getMetaData();
    }

    @Override
    public boolean hasNext() {
        boolean flag = false;
        try {
            flag = rs.next();
        } catch (SQLException e) {
            e.printStackTrace();
        }
        return flag;
    }

    @Override
    public Object[] next() {
        Map<String, String> data = new HashMap<String, String>();
        try {
            for (int i = 1; i <= rd.getColumnCount(); i++) {
                data.put(rd.getColumnName(i), rs.getString(i));
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
        Object r[] = new Object[1];
        r[0] = data;
        return r;
    }

    @Override
    public void remove() {
        try {
            rs.close();
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }
}

配置檔案

上面圖中提到了“配置檔案”，下面就來簡單看一下這個XML配置檔案的指令碼：

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd"><suite name="Pigeon Api測試" parallel="false">

    <test name="xxx-xxx-service">
        <parameter name="sql"
                   value="SELECT * FROM API_PigeonCases 
                   WHERE team_id=2
                   AND isRun=1
                   AND service='xxx-xxx-service'
                   AND env='beta';"/>
        <classes>
            <class name="com.dp.lego.test.TestPigeon"/>
        </classes>
    </test>

    <listeners>
        <listener class-name="org.uncommons.reportng.HTMLReporter"/>
        <listener class-name="org.uncommons.reportng.JUnitXMLReporter"/>
    </listeners></suite>

對照上圖來解釋一下配置檔案：

• SQL的話，這裡的SQL主要決定了選取哪些測試用例進行測試。

• 一個

  標籤，就代表一組測試，可以寫多個標籤。

• “listener”是為了最後能夠生成一個ReportNG的報告。

• Jenkins來實現每日構建，可以使用Maven外掛，通過命令來選擇需要執行的XML配置。

這樣做有什麼好處呢？

使用SQL最大的好處就是靈活

如上面的這個例子，在資料庫中會查詢出下面這56條測試用例，那麼這個標籤就會對這56條用例進行逐一測試。

多標籤時，可以分組展示

使用多個標籤來區分用例，最大的好處就是也能在最後的報告上，達到一個分組展示的效果。

報告更美觀豐富

由於使用了ReportNG進行報告的列印，所以報告的展示要比TestNG自帶的報告要更加美觀、並且能自定義展示樣式，點開能看到詳細的執行過程。

如果有執行失敗的用例，通常報錯的用例會在最上方優先展示。

支援多團隊

當兩個團隊開始使用時，為了方便維護，將基礎部分抽出，各個團隊的指令碼都依賴這個Base包，並且將Base包版本置為“SNAPSHOT版本”。使用“SNAPSHOT版本”的好處是，之後我對Lego更新，各個業務組並不需要對指令碼做任何改動就能及時更新。

當更多的團隊開始使用後，比較直觀的看的話是這個樣子的：

每個團隊的指令碼都依賴於我的這個Base包，所以最後，各個業務團隊的指令碼就變成了下面的這個樣子：

可以看到，使用了Lego之後：

• 沒有了Java檔案，只有XML檔案

• xml中只需要配置SQL。

• 執行和除錯也很方便。

• 可以右鍵直接執行想要執行的測試配置。

• 可以使用maven命令執行測試：

  • mvn clean test -U -Dxml=xmlFileName 。

  • 通過引數來選擇需要執行的xml檔案。

• 也可以使用Jenkins來實現定時構建測試。

由於，所有測試用例都在資料庫所以這段指令碼基本不需要改動了，減少了大量的指令碼程式碼量。

有些同學要問，有時候編寫一條介面測試用例不只是請求一下介面就行，可能還需要寫一些資料庫操作啊，一些引數可能還得自己寫一些方法才能獲取到啊之類的，那不code怎麼處理呢？

下面就進入“用例設計”，我將介紹我如何通過統一的用例模板來解決這些問題。

用例設計

一些思考

我在做介面自動化設計的時候，會思考通用、校驗、健壯、易用這幾點。

通用

• 簡單、方便

  • 用例資料與指令碼分離，簡單、方便。

  • 免去上傳指令碼的動作，能避免很多不必要的錯誤和維護時間。

  • 便於維護。

• 模板化

  • 抽象出通用的模板，可快速拓展。

  • 資料結構一致，便於批量操作。

  • 專人維護、減少多團隊間的重複開發工作。

  • 由於使用了統一的模板，那各組之間便可交流、學習、做有效的對比分析。

  • 如果以後這個平臺不再使用，或者有更好的平臺，可快速遷移。

• 可統計、可拓展

  • 可統計、可開發工具；如：用例數統計，某服務下有多少條用例等。

  • 可開發用例維護工具。

  • 可開發批量生成工具。

校驗

在寫自動化指令碼的時候，都會想“細緻”，然後“寫很多”的檢查點；但當“校驗點”多的時候，又會因為很多原因造成執行失敗。所以我們的設計，需要在保證充足的檢查點的情況下，還要儘可能減少誤報。

• 充足的檢查點

  • 可以檢查出被測服務更多的缺陷。

• 相關推薦

  Lego：美團點評介面自動化測試實踐

  概述 介面自動化概述 眾所周知，介面自動化測試有著如下特點： 低投入，高產出。 比較容易實現自動化。 和UI自動化測試相比更加穩定。 如何做好一個介面自動化測試專案呢？ 我認為，一個“好

  美團接口自動化測試實踐

  接口測試 生成 [] mage except 一個數據庫 分享 同一行 解釋 一、概述 1.1 接口自動化概述 眾所周知，接口自動化測試有著如下特點： 低投入，高產出。 比較容易實現自動化。 和UI自動化測試相比更加穩定。 如何做好一個接口自動化測試項目呢？

  Logan：美團點評的開源移動端基礎日誌庫

  前言 Logan是美團點評集團移動端基礎日誌元件，這個名稱是Log和An的組合，代表個體日誌服務。同時Logan也是“金剛狼”大叔的名號，當然我們更希望這個產品能像金剛狼大叔一樣犀利。 Logan已經穩定迭代了一年多的時間。目前美團點評絕大多數App已經接入並使用Logan進行日誌收集、上傳、分析。近日，我

  企業級負載均衡解決方案之二：美團點評四層負載均衡解決方案MGW

  一、前言在網際網路廠商業務不斷擴充套件之後，多種服務的入口會導致接入流量的劇增，所以多數基於IPVS或者Nginx等初級負載均衡技術的早期方案都會面臨故障或者失效，所以就像google開發meglev一樣，許多網際網路服務提供商也都紛紛開發自己的分散式軟體負載均衡系統作為對外

  前端黑科技：美團網頁首幀優化實踐

  前言 自JavaScript誕生以來，前端技術發展非常迅速。移動端白屏優化是前端介面體驗的一個重要優化方向，Web 前端誕生了 SSR 、CSR、預渲染等技術。在美團支付的前端技術體系裡，通過預渲染提升網頁首幀優化，從而優化了白屏問題，提升使用者體驗，並形成了最佳實踐。 在前端渲染領域，主要有以下幾種方式

  領域驅動設計（DDD）在美團點評業務系統的實踐

  點選上方藍字訂閱，不錯過下一篇好文章本文轉自美團點評技術公眾號：meituantech前言至少3

  來看看大資料的實戰魅力：美團大資料平臺架構實踐

  今天給大家介紹的內容主要包括以下四個部分首先是介紹一下美團大資料平臺的架構，然後回顧一下歷史，看整個平臺演進的時間演進線，每一步是怎麼做的，以及一些挑戰和應對策略，最後總結一下，聊一聊我對平臺化的看法。 美團大資料平臺架構實踐 給大家介紹的內容主要包括以下四個部分首先是介紹一下美團大資料平

  美團點評：打造微服務自動化測試與持續集成工具鏈實踐

  選擇 rift moc 完成 軟件 用戶 seo bee png 本文內容節選自第六屆全球軟件案例研究峰會，時任美團點評酒旅質量團隊工具鏈負責人王鵬老師分享的《微服務架構下的自動化測試和持續集成工具鏈實踐》實錄，重點分享：微服務架構下解決自動化測試、開發聯調、測試環境、

  美團點評：打造微服務自動化測試與持續整合工具鏈實踐

  本文內容節選自第六屆全球軟體案例研究峰會，時任美團點評酒旅質量團隊工具鏈負責人王鵬老師分享的《微服務架構下的自動化測試和持續整合工具鏈實踐》實錄，重點分享：微服務架構下解決自動化測試、開發聯調、測試環境、持續整合方面遇到的問題及解決方案。（PPT+文稿）。 王鵬老師時任美

  美團點評： 網格走法數目

  題目連結: 網格走法數目 dfs,朝下和朝右兩個方向搜尋就可以了。 #include<iostream> #include<algorithm> using namespace std; const int maxn = 12; int map[maxn][m

  最新美團點評Java團隊面試題：Spark+JDK ZGC+演算法+HashMap+Redis

  技術面（一、二、三面） Java 有什麼鎖型別? 有了解Spark嗎？Spark為什麼比Hadoop要快？ 談談poll和epoll，epoll是同步還是非同步 JMM、老年代在什麼情況下會觸發GC、對老年代的GC會不會導致程式卡頓？（最優吞吐量和最短停頓時間）

  介面自動化測試：用 JMeter 實測一個案例

  Jmeter 介紹 Jmeter 是一款使用Java開發的，開源免費的，測試工具， 主要用來做功能測試和效能測試（壓力測試/負載測試）. 而且用Jmeter 來測試 Restful API, 非常好用。 如何學好Jmeter 如果你用Jmeter去對Web進行功能

  智慧運維：美團SQL Advisor的自動化SQL優化實現

  2017年10月19日，網際網路+生活服務平臺美團點評宣佈完成新一輪40億美元融資，投後估值300億美元。 在技術上，美團點評技術團隊以及成為業界一流的研發組織，形成了比較完整的技術體系。在2017第七屆資料技術嘉年華大會上，我們有幸邀請了美團點評的技術專家龍雪剛進行主題分享，將全面介紹和解讀他們獨

  美團點評運維總監鍾紅軍：美團運維的工具化、產品化、運營化

  本次分享嘉賓是美團點評運維中心高階總監鍾紅軍，他向我們詳細介紹了美團點評近3年來在大規模運維的理念和實踐方面的探索，尤其是在運維自動化和資料運營方面的工作和效果。 鍾紅軍 / 美團點評運維中心高階總監 美團點評集團運維中心高階總監，此前曾工作於百度，騰訊，PPTV等網際網路公司，熟悉系統、網路、運

  美團點評2017春招筆試真題：運維工程師（A卷）

  1、資料庫索引可以明顯提高哪一操作的效率？ 正確答案: A A SELECT B INSERT INTO … VALUES … C UPDATE D DELETE 2、資料庫：以下哪種鎖定方式能提供最佳的並行訪問效能？ 正確答案: D A 列鎖定 B 表鎖定 C 塊鎖定 D 行鎖定 3、從DELE

  美團點評2017春招筆試真題：運維工程師（B卷）

  1、資料庫：以下哪項不是HASH索引的特徵？ 正確答案: C A MySQL不能確定在兩個值之間大約有多少行 B 不能使用hash索引來加速ORDER BY操作 C 只用於使用“>”或“<”操作符的比較 D 只能使用整個關鍵字來搜尋一行 2、使用者JANKO 想在有三個列: empid

  介面自動化測試：mock server之Moco工具

  什麼是mock server mock：英文可以翻譯為模仿的，mock server是我們用來解除依賴（耦合），假裝實現的技術，比如說，前端需要使用某些api進行除錯，但是服務端並沒有開發完成這些api，那麼前端的工作就被服務端阻塞了，那麼就可以使用mo

  Robot Framework與Web介面自動化測試學習筆記：簡單例子

  一、自動化測試 與 人工測試 在開始編寫用例之前，我們先來思考下自動化測試和人工測試的區別。對於web頁面的人工測試，我們想下，如果去測試，怎麼操作呢？不外乎如下的基本動作： 1）開啟瀏覽器 2）輸入url （前提web伺服器要正常啟動執行著） 3）等待頁面顯示出

  介面自動化測試：apiAutoTest使用re 處理資料依賴

  [toc] # 廢話 目前在工作中寫指令碼的時候發現了一些之前開源的apiAutoTest的可優化項，後面應該也是會慢慢的繼續優化了 # 2020/11/19 截止到寫這篇文章的時間是，2020/11/19 00:53 現在也是把該項優化了，那優化了什麼尼？ # 引數依賴 我理解的引數依賴/介面依

  組委會正在為美團點評CodeM大賽的決賽設計新賽制

  通過 隨機 space 個數字 數字 範圍 class 包括 bound 比賽有 n 個人參加（其中 n 為2的冪），每個參賽者根據資格賽和預賽、復賽的成績，會有不同的積分。比賽采取錦標賽賽制，分輪次進行，設某一輪有 m 個人參加，那麽參賽者會被分為 m/2 組，每組恰好