審校 | 孫淑娟

創(chuàng)新互聯(lián)公司專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都做網(wǎng)站、成都網(wǎng)站建設(shè)、無(wú)為網(wǎng)絡(luò)推廣、微信小程序開發(fā)、無(wú)為網(wǎng)絡(luò)營(yíng)銷、無(wú)為企業(yè)策劃、無(wú)為品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營(yíng)等，從售前售中售后，我們都將竭誠(chéng)為您服務(wù)，您的肯定，是我們最大的嘉獎(jiǎng)；創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供無(wú)為建站搭建服務(wù)，24小時(shí)服務(wù)熱線：028-86922220，官方網(wǎng)址：www.cdcxhl.com

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

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

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

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

Milvus架構(gòu)

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

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

二、QA測(cè)試和問(wèn)題管理

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

1.QA測(cè)試

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

QA測(cè)試和優(yōu)先級(jí)

在Milvus中，QA測(cè)試主要針對(duì)如下幾個(gè)方面進(jìn)行：

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

2.問(wèn)題管理

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

Milvus中問(wèn)題管理的工作流程

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

三、什么時(shí)候需要QA？

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

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

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

四、Milvus中的測(cè)試模塊

下面，讓我們來(lái)詳細(xì)說(shuō)明Milvus中的六個(gè)測(cè)試模塊：

1.單元測(cè)試

單元測(cè)試

單元測(cè)試可以協(xié)助盡早地識(shí)別軟件錯(cuò)誤，并為代碼的重組提供驗(yàn)證標(biāo)準(zhǔn)。根據(jù)Milvus的拉式請(qǐng)求（pull request，PR）驗(yàn)收標(biāo)準(zhǔn)，代碼單元測(cè)試的覆蓋率應(yīng)達(dá)到80%。

2.功能測(cè)試

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

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

下圖描繪了目前基于主流pytest的功能測(cè)試框架。該框架為PyMilvus添加了一個(gè)包裝器（wrapper），并通過(guò)自動(dòng)化測(cè)試接口進(jìn)行測(cè)試。

Milvus中的功能測(cè)試框架

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

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

3.部署測(cè)試

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

部署測(cè)試工作流程

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

首個(gè)測(cè)試在運(yùn)行時(shí)會(huì)創(chuàng)建多個(gè)集合，并且會(huì)對(duì)每個(gè)集合進(jìn)行不同的操作。而在第二個(gè)測(cè)試運(yùn)行時(shí)，它會(huì)重點(diǎn)驗(yàn)證已創(chuàng)建的集合是否仍可用于CRUD操作，以及是否可以進(jìn)一步創(chuàng)建新的集合。

4.可靠性測(cè)試

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

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

? ?

Milvus 中的可靠性測(cè)試框架

上圖展示了Milvus中可進(jìn)行自動(dòng)化混沌測(cè)試的可靠性測(cè)試框架。其流程為：

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

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

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

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

下表描述了穩(wěn)定性和性能測(cè)試的目的、測(cè)試場(chǎng)景和指標(biāo)。

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

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

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

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

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

1.SDK測(cè)試框架

SDK測(cè)試框架

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

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

2.GitHub Action

GitHub Action

GitHub Action會(huì)因?yàn)槠湟韵绿攸c(diǎn)，被用于提高QA效率：

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

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

3.基準(zhǔn)測(cè)試

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

基準(zhǔn)測(cè)試工具概覽

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

本文題目：?一文搞懂開放源碼軟件（OSS）質(zhì)量保證
文章網(wǎng)址：http://uogjgqi.cn/article/dhpiced.html