?譯者 | 陳峻

審校 | 孫淑娟

如果說質(zhì)量保證（QA）是確定產(chǎn)品或服務(wù)是否滿足特定要求的系統(tǒng)過程，那么質(zhì)量保證系統(tǒng)則是研發(fā)過程中不可或缺的一部分，它起到了確保產(chǎn)品質(zhì)量的作用。

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

一、Milvus QA系統(tǒng)概述

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

Milvus架構(gòu)

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

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

二、QA測試和問題管理

Milvus的QA需要對軟件開發(fā)過程中出現(xiàn)的問題予以測試和管理。

1.QA測試

如下圖所示，我們應(yīng)當(dāng)根據(jù)Milvus的特性和用戶需求，按照優(yōu)先級的順序，開展不同類型的QA測試。

QA測試和優(yōu)先級

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

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

2.問題管理

軟件在開發(fā)過程中可能會出現(xiàn)許多問題。這些問題可能源于QA工程師本人，也可能來自開源社區(qū)的Milvus用戶。不過，QA團隊?wèi)?yīng)負責(zé)找出這些問題。

Milvus中問題管理的工作流程

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

三、什么時候需要QA？

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

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

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

四、Milvus中的測試模塊

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

1.單元測試

單元測試

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

2.功能測試

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

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

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

Milvus中的功能測試框架

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

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

3.部署測試

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

部署測試工作流程

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

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

4.可靠性測試

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

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

? ?

Milvus 中的可靠性測試框架

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

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

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

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

5.穩(wěn)定性和性能測試

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

穩(wěn)定性測試和性能測試會共享同一組工作流程：

穩(wěn)定性測試和性能測試的工作流程

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

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

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

1.SDK測試框架

SDK測試框架

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

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

2.GitHub Action

GitHub Action

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

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

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

3.基準測試

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

基準測試工具概覽

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

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