?譯者 | 陳峻

審校 | 孫淑娟

如果說質量保證（QA）是確定產品或服務是否滿足特定要求的系統過程，那么質量保證系統則是研發過程中不可或缺的一部分，它起到了確保產品質量的作用。

在本文中，我將向您介紹在開發Milvus矢量數據庫（Vector Database）時所采用的QA框架，并涵蓋Milvus中的主要測試模塊、以及可用于提高QA測試效率的方法和工具。

一、Milvus QA系統概述

鑒于系統架構對于QA測試的重要性，QA工程師只有對系統越熟悉，才越有可能制定出合理、有效的測試計劃。

Milvus架構

Milvus 2.0采用的是云原生、分布式的分層架構。其中，SDK是數據在Milvus中流動的主要入口。通過對被頻繁使用的SDK開展功能性測試，我們將能夠檢測出Milvus系統內部的問題。除了功能測試之外，我們還應該對矢量數據庫進行單元測試、部署測試、可靠性測試、穩定性測試、以及性能測試。

云原生和分布式架構為QA測試帶來了便利和挑戰。與本地部署運行的系統不同，在Kubernetes集群上部署和運行的Milvus實例，可以確保在與軟件開發相同的環境下，進行軟件測試。然而，其缺點在于分布式架構的復雜性，會帶來更多的不確定性，這會導致系統QA測試的繁瑣。例如，Milvus 2.0使用不同組件的微服務，會導致服務和節點數量的增加，系統出錯幾率的增大。因此，我們需要更加全面的QA計劃，來提高測試的效率。

二、QA測試和問題管理

Milvus的QA需要對軟件開發過程中出現的問題予以測試和管理。

1.QA測試

如下圖所示，我們應當根據Milvus的特性和用戶需求，按照優先級的順序，開展不同類型的QA測試。

QA測試和優先級

在Milvus中，QA測試主要針對如下幾個方面進行：

• 功能：驗證功能和特性能否按照最初的設計工作。
• 部署：檢查用戶是否可以通過不同的方式（如：Docker Compose、Helm、APT、以及YUM等）部署、重裝、升級Milvus的單機版和集群。
• 性能：測試Milvus中數據的插入、索引、向量搜索和查詢性能。
• 穩定性：檢查Milvus在正常工作負載水平下，能否穩定運行5-10天。
• 可靠性：如果出現某個系統錯誤時，測試Milvus是否仍然可以部分運行。
• 配置：驗證Milvus在特定配置下，能否按照預期工作。
• 兼容性：測試Milvus是否兼容不同類型的硬件或軟件。

2.問題管理

軟件在開發過程中可能會出現許多問題。這些問題可能源于QA工程師本人，也可能來自開源社區的Milvus用戶。不過，QA團隊應負責找出這些問題。

Milvus中問題管理的工作流程

在創建問題時，他們首先需要進行分類。在分流的過程中，被檢查出的新問題應確保帶有足夠多的問題詳細信息，以便開發人員的確認、接受、以及嘗試修復。而在修復完成之后，問題屬主則需要驗證其修復，判斷是否可以最終關閉該問題。

三、什么時候需要QA？

一種常見的誤解是：QA和開發是相互獨立的。而事實是為了確保系統的質量，開發人員和QA工程師都需要通力協作，將QA貫穿整個生命周期。

將QA引入整個軟件研發的生命周期如上圖所示，一個完整的軟件研發生命周期包括三個階段：

• 在初始階段，開發人員發布設計文檔，QA工程師據此制定測試計劃、定義發布標準、并分配QA任務。開發人員和QA工程師需要熟悉設計文檔和測試計劃，以便在兩個團隊之間共享對于發布目標、功能、性能、穩定性、錯誤收斂等方面的相互理解。
• 在研發期間，開發和QA測試通過持續交互，以對開發出的特性和功能進行驗證，并修復來自開源社區報告的錯誤和問題。
• 在最后階段，他們可以發布那些滿足發布說明和標簽的新版Milvus的Docker鏡像。同時，QA團隊還會發布關于此版本的測試報告。

四、Milvus中的測試模塊

下面，讓我們來詳細說明Milvus中的六個測試模塊：

1.單元測試

單元測試

單元測試可以協助盡早地識別軟件錯誤，并為代碼的重組提供驗證標準。根據Milvus的拉式請求（pull request，PR）驗收標準，代碼單元測試的覆蓋率應達到80%。

2.功能測試

在Milvus中，功能測試的主要目的是為了驗證接口是否可以按照設計進行運行。通過圍繞著PyMilvus和SDK開展，功能測試會涉及到如下兩個方面：

• 測試SDK在傳遞正確參數時，是否可以返回預期結果。
• 測試SDK可否處理錯誤，并在傳遞錯誤參數時，能否返回合理的錯誤消息。

下圖描繪了目前基于主流pytest的功能測試框架。該框架為PyMilvus添加了一個包裝器（wrapper），并通過自動化測試接口進行測試。

Milvus中的功能測試框架

考慮到測試方式在共享時，部分功能需要復用，因此我們可以采用上述測試框架，而無需直接使用PyMilvus接口。此外，該框架還包含了一個“校驗（check）”模塊，為期望值和實際值的校驗帶來便利。

其tests/python_client/testcases目錄中包含了多達2700個功能測試用例，并完全覆蓋了幾乎所有的PyMilvus接口。而且功能測試能夠嚴格地監督每一個PR的質量。

3.部署測試

由于Milvus有standalone和cluster兩種模式，因此我們可以使用Docker Compose或Helm兩種重要的方法，對其進行部署。同時，在部署了Milvus之后，用戶可以采取重啟或升級測試兩種類別。其中，重啟測試是指測試數據持久性的過程，即重啟后的數據是否仍然可用。升級測試則是指測試數據地兼容性，以防止在Milvus中插入不兼容的數據格式的過程。如下圖所示，兩種類型的部署測試可以共享相同的工作流程：

部署測試工作流程

在重啟測試中，兩個部署會使用相同的Docker鏡像。但是，在升級測試中，首個部署會使用前一個版本的Docker鏡像，而第二個部署使用的是更高版本的Docker鏡像。測試的結果和數據會被保存在Volumes文件或持久卷聲明中。

首個測試在運行時會創建多個集合，并且會對每個集合進行不同的操作。而在第二個測試運行時，它會重點驗證已創建的集合是否仍可用于CRUD操作，以及是否可以進一步創建新的集合。

4.可靠性測試

云原生分布式系統的可靠性測試，通常采用的是混沌工程（Chaos Engineering）方法，其目的是要將錯誤和系統故障扼殺在萌芽狀態。換句話說，在混沌工程測試中，我們有目的地創建系統故障，以識別壓力測試中的問題，并在系統故障真正開始造成危害之前予以修復。在Milvus的混沌測試中，我們可以選擇Chaos Mesh作為創建混沌的工具，來創建如下故障類型：

• Pod kill：模擬節點的宕機場景。
• Pod failure：測試在有一個worker節點的pod出現故障時，整個系統能否繼續工作。
• Memory stress：模擬來自worker節點對大量內存和CPU資源的消耗。
• Network partition：由于Milvus能將存儲與計算分離，因此系統會嚴重依賴各個組件之間的通信。為了測試不同的Milvus組件之間的相互依賴關系，我們需要模擬不同pod之間的通信被分區的場景。

? ?

Milvus 中的可靠性測試框架

上圖展示了Milvus中可進行自動化混沌測試的可靠性測試框架。其流程為：

• 首先，通過部署配置來讀取初始化Milvus集群。
• 集群準備就緒后，運行test_e2e.py以測試Milvus的各項功能是否可用。
• 運行hello_milvus.py，以測試數據的持久性。即創建一個名為“hello_milvus”的集合，用于數據插入、刷新、索引構建、向量搜索和查詢。此合集在測試期間不會被釋放或丟棄。
• 創建一個監控對象，該對象將啟動六個線程（如下代碼段所示），分別執行創建、插入、刷新、索引、搜索和查詢操作。

checkers = {
Op.create: CreateChecker（）,
Op.insert: InsertFlushChecker（）,
Op.flush: InsertFlushChecker（flush=True）,
Op.index: IndexChecker（）,
Op.search: SearchChecker（）,
Op.query: QueryChecker（）
}

• 做出第一個斷言——所有操作都能按照預期成功運行。
• 使用Chaos Mesh解析定義故障的yaml文件，將系統故障引入Milvus。例如，每五秒“殺”一次查詢節點。
• 引入系統故障時進行第二次斷言——判斷在系統故障期間，Milvus操作返回的結果是否符合預期。
• 通過Chaos Mesh消除故障。
• 當Milvus服務恢復（即所有pod都準備就緒）后，做出第三次斷言——所有操作都符合預期。
• 運行test_e2e.py，以測試Milvus功能是否可用。在混沌消除之后，一些操作可能會被繼續阻塞，進而阻礙第三次斷言。因此，該步驟旨在促進第三次斷言，并作為檢查Milvus服務是否恢復的標準。
• 運行hello_milvus.py，以加載創建的集合，對集合進行CRUP操作。然后，檢查系統故障前存在的數據，在恢復后是否仍然可用。
• 收集日志。

5.穩定性和性能測試

下表描述了穩定性和性能測試的目的、測試場景和指標。

穩定性測試和性能測試會共享同一組工作流程：

穩定性測試和性能測試的工作流程

• 解析和更新配置，并定義指標。server-configmap對應Milvus的單機或集群配置，而client-configmap對應測試用例的各項配置。
• 配置服務器和客戶端。
• 準備數據。
• 請求服務器和客戶端之間的交互。
• 報告和顯示各項指標。

五、提高QA效率的工具和方法

從模塊測試部分可以看出，大部分測試的流程其實都差不多，主要是修改Milvus服務端和客戶端的配置，傳遞API參數。當有多種配置時，不同配置的組合越是多樣化，實驗和測試可以覆蓋的場景也就越廣。因此，代碼和程序的重用，對于提高測試效率顯得非常關鍵。

1.SDK測試框架

SDK測試框架

為了加快測試進程，我們可以在原始測試框架中添加一個API_request包裝器，并將其按照API網關進行設置。此類API網關將負責收集所有API請求，然后將它們傳遞給Milvus，以便集體接收響應，并傳遞回客戶端。這樣的設計能夠使得捕獲諸如參數和返回結果等日志信息，變得更加容易。此外，SDK測試框架中的checker組件也可以驗證和檢查Milvus的結果。所有的檢查方法都可以在該checker組件中被定義。

使用SDK測試框架，我們也可以將一些關鍵性的初始化過程，封裝到一個函數中，以削減大量繁瑣的代碼。還值得注意的是，每個單獨的測試用例都與其獨特的集合相關，從而確保了數據的相互隔離。例如，在執行測試用例時，pytest-xdist可以利用pytest的擴展,并行執行所有單獨的測試用例，從而大幅提高效率。

2.GitHub Action

GitHub Action

GitHub Action會因為其以下特點，被用于提高QA效率：

• 它是與GitHub深度集成的原生CI/CD工具。
• 擁有統一配置的機器環境，并預裝了包括Docker、Docker Compose等常用的軟件開發工具。
• 它支持包括Ubuntu、MacOs、以及Windows-server在內的多種操作系統和版本。
• 它擁有一個提供豐富擴展和開箱即用功能的市場。
• 其矩陣能夠支持并發作業，并可重用相同的測試流程，來提高效率。

除了上述特點，采用GitHub Action的另一個原因在于部署測試和可靠性測試需要獨立的隔離環境，而GitHub Action非常適合對小規模數據集進行日常檢查。

3.基準測試

工具為了使QA測試更加有效，我們可以使用多種工具。

基準測試工具概覽

• Argo：是一套開源的Kubernetes工具，可用于運行工作流，并通過調度任務來管理集群。同時，它也可以并行啟用多個任務。
• Kubernetes儀表板：提供基于Web的Kubernetes用戶界面，可用于可視化server-configmap和client-configmap。
• 網絡附加存儲是一種文件級數據存儲服務器，可用于保存常見的ANN-benchmark數據集。
• InfluxDB和MongoDB：可用于保存基準測試結果的數據庫。
• Grafana：可用于監控服務器資源指標，和客戶端性能指標的開源分析和監控解決方案。
• Redash：是一項能夠可視化數據，并為基準測試創建圖表的服務。

原文鏈接：https://dzone.com/articles/open-source-software-oss-quality-assurance-a-milvu