如果你是一名測試工程師，你可能在過去一年左右聽到了更多關於微服務的資訊。這並不奇怪，因為許多軟體公司也正在轉向更“微服務”的建立軟體的方式。這不可避免地帶來了很多挑戰，特別是如何在微服務世界中實現自動化測試。

     “微服務”是軟體架構中增加的另一個術語。微服務架構風格涉及開發單個應用程式，這些應用程式可以作為一套小型服務一起工作，每個應用程式都執行在其單個程序中，並與輕量級機制（如HTTP資源API）進行通訊。這些服務需要最低限度的集中管理，使用不同的資料儲存技術，並且可以用不同的程式語言編寫。這些圍繞業務功能構建的服務也可以由支援全自動部署的機器獨立部署。

SOA與微服務

    典型的面向服務的架構（SOA）模型通常具有依賴的企業服務匯流排（ESB），微服務使用更快的訊息傳遞機制。雖然SOA專注於指令式程式設計，但微服務架構使用的程式設計風格主要以響應式角色為基礎。雖然SOA模型通常具有過大的RDBMS，但微服務經常使用可連線到傳統資料庫的NoSQL或micro-SQL等資料庫。也就是說，真正的區別在於用於建立一整套服務的體系結構方法。

    用於微服務體系結構的實踐是基於開發人員為大型企業組織建立軟體應用程式所遵循的實踐而建立的。開發人員的經驗非常便於瞭解當前終端使用者的期望，並有助於在各種裝置上建立一致而動態的體驗。對可訪問性，適應性強，模組化和可擴充套件性的基於雲的應用程式需求量很大。這導致許多開發人員改變他們的方法。

    微服務微服務體系結構包含專注於建立完整應用程式或任務的小型服務。微服務的每個例項都代表您的應用程式中的單一責任。真正的好處是，這些服務是相互獨立的，這使得它們可以獨立部署和測試。

• 單元測試
      微服務結構複雜，因為你有許多獨立的服務以很多方式與其他獨立服務進行通訊。開始測試自動化工作的好地方是直接單獨測試特定微服務的功能。通常這很容易通過使用REST API與您的服務進行交談以及某種模擬來讓您單獨測試服務，而無需與其他服務進行任何型別的整合。
      單元測試的範圍是服務的內部。就測試量而言，它們是最多的。理想情況下，單元測試應該是自動的，取決於開發語言和服務框架。但是當您更改和部署服務X時會發生什麼？它將如何影響Y或A的服務？你怎麼知道你沒有破壞什麼？您不僅應該確保您的服務本身在執行，還需要確保其他正在使用您的服務的人員不會受到您的更改的影響。
• 合同測試
      合同測試應將每項服務視為一個黑匣子，所有服務必須獨立呼叫，並且必須驗證其響應。該服務的任何依賴關係必須是允許該服務執行但不與任何其他服務互動的存根。這有助於避免可能由外部呼叫導致的任何複雜行為，並將重點放在對單個服務執行測試上。即使服務發生變化，每個消費者也必須從服務中獲得相同的結果。應該可以靈活地在後面新增更多的功能。但是，這些新增不能破壞服務功能。如果服務是以這種方式設計的，它將在更長的時間內保持健壯，並且消費者不需要修改他們的程式碼以考慮稍後做出的改變。
• 端到端測試
      由於我們知道每個微服務都是獨立的，並且可以通過多種方式獨立使用，所以“應用程式”的概念幾乎成為這種環境中的幻想。因此，採用典型的端到端測試自動化策略並不像其他軟體架構那樣有效。
      因此，提出一種涵蓋真實使用者可能執行的所有可能工作流程的傳統端到端測試方法並不真正奏效。您可以使用80/20規則來確定您認為常見的核心旅程，但您可能不希望花費精力試圖在此級別考慮所有端到端可能性。
      端到端測試驗證整個過程流程是否正常工作，包括所有服務和資料庫整合。徹底測試影響多種服務的操作可確保系統作為一個整體協同工作並滿足所有需求。多種行為驅動框架可以通過抽取使用者故事並驗證系統的行為如預期來幫助實現功能測試的自動化。
      實踐中不可能知道使用者使用你的服務的所有方式。使用使用者驅動的合同模型，使用者有責任提供一套測試，指定需要什麼型別的互動以及以何種格式。然後，您的服務將同意這份合同並確保它沒有損壞。這消除了對其他服務的依賴。這種方法還使您能夠驗證合同是否在交付時完成。
• 使用者介面UI/功能測試
      使用者介面測試是使用者使用角度最高級別的測試，這個級別的測試必須像使用者試圖與系統進行互動。所有資料庫，介面，內部和第三方服務必須無縫協作才能產生預期結果。

    在微服務世界中，需要能夠在執行時快速響應並且及時處理生產環境暴露的問題。因此，建立一個關鍵的監控和警報系統並對生產進行追蹤至關重要。如果其中一項服務出現故障或無響應，您需要立即知道。通過在監控的幫助下發現生產期間的問題，您通常可以在使用者甚至知道存在問題之前自動回滾到服務的最後一個已知的良好版本。

微服務自動化測試實踐

下面一起探討一下在工作中使用的一套標準化測試框架。

    根據已有情況，我們測試技術支撐團隊研發的一款基於Spring & TestNG的Java測試自動化程式碼開發框架，可測試範圍覆蓋dubbo service、restful api、資料庫(MySQL)、快取(Cache/Memcached)、訊息框架(Kafka/Rabbitmq)、Zookeeper等方面的內容，其目標是構建網際網路公司通用的高可用、高擴充套件測試基礎元件。特點概述：

• core : 核心基礎框架，包含上下文Context, Exception等.
• config :配置框架，制定classpath下的配置檔案讀取規範。
• tools：程式碼生成工具，一鍵生成基於gradle/maven的測試程式碼框架。
• http：http服務介面測試框架。
• rpc：dubbo服務介面測試框架。
• db：資料庫(MySQL)客戶端框架。
• cache：快取(redis/memcached)客戶端框架。
• test：基於TestNG二次開發的測試框架，並與測試用例平臺相結合。
• zkclient：基於開源Curator Framework的Zookeeper客戶端框架。
• logger：統一日誌框架，整合logback, log4j, slf4j等。
• mq : 基於kafka/rabbitmq中介軟體的訊息佇列客戶端
• plugin : 基於Spring schema擴充套件特性的測試外掛，提供環境/系統變數前置等功能。
• mocker: mocker service平臺的java sdk.
• atpclient: 自動化測試平臺java sdk。

專案實踐

接下來使用該框架對其中一個微服務實施測試。

第一步，生成maven測試專案模板
1.首先，從git倉庫將程式碼clone到工作環境。
2.解壓配置專案資訊，開啟並編輯專案目錄下的 “/bin/config.property”檔案
3.執行run.cmd檔案,在project.exportPath目錄下生成maven的測試專案
4. 將生成好的Maven專案匯入你的IDEA中。第二步 編寫測試指令碼
在第一步生成好的maven測試專案模板中，可以根據生產的demo示例檔案來定製你的測試。其中DemoTest.java檔案如下：

public class DemoTest extends TestNGBaseTest {

// Get your dubbo service from Spring Ioc container.
// Note that your service should be avaliable in current environmnet, otherwise, it will get nothing.
private IDemoService iDemoService = BeanUtil.getBean("iDemoService");

@Test(dataProvider = "ExcelDataProvider"/* , testName="id" */)
public void doDemoServiceTest(Map<String, String> testData) throws Exception {

    // Get Java Bean Model from excel & json
    DemoRequestDTO demoRequestDTO = buildJavaBeanModel(DemoRequestDTO.class, testData, this);
    DemoResponseDTO expectedDemoResponseDTO = buildJavaBeanModel(DemoResponseDTO.class, testData, this);

    // invode dubbo service
    Result<DemoResponseDTO> result = iDemoService.doD0emoService(demoRequestDTO);

    // Assert
    Assert.assertTrue(result.isSuccess());
    Assert.assertEquals(result.getResult().getId(), expectedDemoResponseDTO.getId());
    Assert.assertEquals(result.getResult().getName(), expectedDemoResponseDTO.getName());
    }
}

作者簡介：

就職於甜橙金融資訊科技部，質量平臺資深開發，致力於用最新的技術開發最好的工具。