建站
咨詢
售后
建站咨詢
新聞中心
審校 | 孫淑娟
創(chuàng)新互聯(lián)公司專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都做網(wǎng)站、成都網(wǎng)站建設(shè)、無為網(wǎng)絡(luò)推廣、微信小程序開發(fā)、無為網(wǎng)絡(luò)營銷、無為企業(yè)策劃、無為品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供無為建站搭建服務(wù)，24小時(shí)服務(wù)熱線：028-86922220，官方網(wǎng)址：www.cdcxhl.com
如果說質(zhì)量保證（QA）是確定產(chǎn)品或服務(wù)是否滿足特定要求的系統(tǒng)過程，那么質(zhì)量保證系統(tǒng)則是研發(fā)過程中不可或缺的一部分，它起到了確保產(chǎn)品質(zhì)量的作用。
在本文中，我將向您介紹在開發(fā)Milvus矢量數(shù)據(jù)庫（Vector Database）時(shí)所采用的QA框架，并涵蓋Milvus中的主要測試模塊、以及可用于提高QA測試效率的方法和工具。
一、Milvus QA系統(tǒng)概述
鑒于系統(tǒng)架構(gòu)對于QA測試的重要性，QA工程師只有對系統(tǒng)越熟悉，才越有可能制定出合理、有效的測試計(jì)劃。
Milvus架構(gòu)
Milvus 2.0采用的是云原生、分布式的分層架構(gòu)。其中，SDK是數(shù)據(jù)在Milvus中流動的主要入口。通過對被頻繁使用的SDK開展功能性測試，我們將能夠檢測出Milvus系統(tǒng)內(nèi)部的問題。除了功能測試之外，我們還應(yīng)該對矢量數(shù)據(jù)庫進(jìn)行單元測試、部署測試、可靠性測試、穩(wěn)定性測試、以及性能測試。
云原生和分布式架構(gòu)為QA測試帶來了便利和挑戰(zhàn)。與本地部署運(yùn)行的系統(tǒng)不同，在Kubernetes集群上部署和運(yùn)行的Milvus實(shí)例，可以確保在與軟件開發(fā)相同的環(huán)境下，進(jìn)行軟件測試。然而，其缺點(diǎn)在于分布式架構(gòu)的復(fù)雜性，會帶來更多的不確定性，這會導(dǎo)致系統(tǒng)QA測試的繁瑣。例如，Milvus 2.0使用不同組件的微服務(wù)，會導(dǎo)致服務(wù)和節(jié)點(diǎn)數(shù)量的增加，系統(tǒng)出錯幾率的增大。因此，我們需要更加全面的QA計(jì)劃，來提高測試的效率。
二、QA測試和問題管理
Milvus的QA需要對軟件開發(fā)過程中出現(xiàn)的問題予以測試和管理。
1.QA測試
如下圖所示，我們應(yīng)當(dāng)根據(jù)Milvus的特性和用戶需求，按照優(yōu)先級的順序，開展不同類型的QA測試。
QA測試和優(yōu)先級
在Milvus中，QA測試主要針對如下幾個方面進(jìn)行：
- 功能：驗(yàn)證功能和特性能否按照最初的設(shè)計(jì)工作。
- 部署：檢查用戶是否可以通過不同的方式（如：Docker Compose、Helm、APT、以及YUM等）部署、重裝、升級Milvus的單機(jī)版和集群。
- 性能：測試Milvus中數(shù)據(jù)的插入、索引、向量搜索和查詢性能。
- 穩(wěn)定性：檢查Milvus在正常工作負(fù)載水平下，能否穩(wěn)定運(yùn)行5-10天。
- 可靠性：如果出現(xiàn)某個系統(tǒng)錯誤時(shí)，測試Milvus是否仍然可以部分運(yùn)行。
- 配置：驗(yàn)證Milvus在特定配置下，能否按照預(yù)期工作。
- 兼容性：測試Milvus是否兼容不同類型的硬件或軟件。
2.問題管理
軟件在開發(fā)過程中可能會出現(xiàn)許多問題。這些問題可能源于QA工程師本人，也可能來自開源社區(qū)的Milvus用戶。不過，QA團(tuán)隊(duì)?wèi)?yīng)負(fù)責(zé)找出這些問題。
Milvus中問題管理的工作流程
在創(chuàng)建問題時(shí)，他們首先需要進(jìn)行分類。在分流的過程中，被檢查出的新問題應(yīng)確保帶有足夠多的問題詳細(xì)信息，以便開發(fā)人員的確認(rèn)、接受、以及嘗試修復(fù)。而在修復(fù)完成之后，問題屬主則需要驗(yàn)證其修復(fù)，判斷是否可以最終關(guān)閉該問題。
三、什么時(shí)候需要QA？
一種常見的誤解是：QA和開發(fā)是相互獨(dú)立的。而事實(shí)是為了確保系統(tǒng)的質(zhì)量，開發(fā)人員和QA工程師都需要通力協(xié)作，將QA貫穿整個生命周期。
將QA引入整個軟件研發(fā)的生命周期如上圖所示，一個完整的軟件研發(fā)生命周期包括三個階段：
- 在初始階段，開發(fā)人員發(fā)布設(shè)計(jì)文檔，QA工程師據(jù)此制定測試計(jì)劃、定義發(fā)布標(biāo)準(zhǔn)、并分配QA任務(wù)。開發(fā)人員和QA工程師需要熟悉設(shè)計(jì)文檔和測試計(jì)劃，以便在兩個團(tuán)隊(duì)之間共享對于發(fā)布目標(biāo)、功能、性能、穩(wěn)定性、錯誤收斂等方面的相互理解。
- 在研發(fā)期間，開發(fā)和QA測試通過持續(xù)交互，以對開發(fā)出的特性和功能進(jìn)行驗(yàn)證，并修復(fù)來自開源社區(qū)報(bào)告的錯誤和問題。
- 在最后階段，他們可以發(fā)布那些滿足發(fā)布說明和標(biāo)簽的新版Milvus的Docker鏡像。同時(shí)，QA團(tuán)隊(duì)還會發(fā)布關(guān)于此版本的測試報(bào)告。
四、Milvus中的測試模塊
下面，讓我們來詳細(xì)說明Milvus中的六個測試模塊：
1.單元測試
單元測試
單元測試可以協(xié)助盡早地識別軟件錯誤，并為代碼的重組提供驗(yàn)證標(biāo)準(zhǔn)。根據(jù)Milvus的拉式請求（pull request，PR）驗(yàn)收標(biāo)準(zhǔn)，代碼單元測試的覆蓋率應(yīng)達(dá)到80%。
2.功能測試
在Milvus中，功能測試的主要目的是為了驗(yàn)證接口是否可以按照設(shè)計(jì)進(jìn)行運(yùn)行。通過圍繞著PyMilvus和SDK開展，功能測試會涉及到如下兩個方面：
- 測試SDK在傳遞正確參數(shù)時(shí)，是否可以返回預(yù)期結(jié)果。
- 測試SDK可否處理錯誤，并在傳遞錯誤參數(shù)時(shí)，能否返回合理的錯誤消息。
下圖描繪了目前基于主流pytest的功能測試框架。該框架為PyMilvus添加了一個包裝器（wrapper），并通過自動化測試接口進(jìn)行測試。
Milvus中的功能測試框架
考慮到測試方式在共享時(shí)，部分功能需要復(fù)用，因此我們可以采用上述測試框架，而無需直接使用PyMilvus接口。此外，該框架還包含了一個“校驗(yàn)（check）”模塊，為期望值和實(shí)際值的校驗(yàn)帶來便利。
其tests/python_client/testcases目錄中包含了多達(dá)2700個功能測試用例，并完全覆蓋了幾乎所有的PyMilvus接口。而且功能測試能夠嚴(yán)格地監(jiān)督每一個PR的質(zhì)量。
3.部署測試
由于Milvus有standalone和cluster兩種模式，因此我們可以使用Docker Compose或Helm兩種重要的方法，對其進(jìn)行部署。同時(shí)，在部署了Milvus之后，用戶可以采取重啟或升級測試兩種類別。其中，重啟測試是指測試數(shù)據(jù)持久性的過程，即重啟后的數(shù)據(jù)是否仍然可用。升級測試則是指測試數(shù)據(jù)地兼容性，以防止在Milvus中插入不兼容的數(shù)據(jù)格式的過程。如下圖所示，兩種類型的部署測試可以共享相同的工作流程：
部署測試工作流程
在重啟測試中，兩個部署會使用相同的Docker鏡像。但是，在升級測試中，首個部署會使用前一個版本的Docker鏡像，而第二個部署使用的是更高版本的Docker鏡像。測試的結(jié)果和數(shù)據(jù)會被保存在Volumes文件或持久卷聲明中。
首個測試在運(yùn)行時(shí)會創(chuàng)建多個集合，并且會對每個集合進(jìn)行不同的操作。而在第二個測試運(yùn)行時(shí)，它會重點(diǎn)驗(yàn)證已創(chuàng)建的集合是否仍可用于CRUD操作，以及是否可以進(jìn)一步創(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é)點(diǎn)的宕機(jī)場景。
- Pod failure：測試在有一個worker節(jié)點(diǎn)的pod出現(xiàn)故障時(shí)，整個系統(tǒng)能否繼續(xù)工作。
- Memory stress：模擬來自worker節(jié)點(diǎn)對大量內(nèi)存和CPU資源的消耗。
- Network partition：由于Milvus能將存儲與計(jì)算分離，因此系統(tǒng)會嚴(yán)重依賴各個組件之間的通信。為了測試不同的Milvus組件之間的相互依賴關(guān)系，我們需要模擬不同pod之間的通信被分區(qū)的場景。
? ?
Milvus 中的可靠性測試框架
上圖展示了Milvus中可進(jìn)行自動化混沌測試的可靠性測試框架。其流程為：
- 首先，通過部署配置來讀取初始化Milvus集群。
- 集群準(zhǔn)備就緒后，運(yùn)行test_e2e.py以測試Milvus的各項(xiàng)功能是否可用。
- 運(yùn)行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ù)期成功運(yùn)行。
- 使用Chaos Mesh解析定義故障的yaml文件，將系統(tǒng)故障引入Milvus。例如，每五秒“殺”一次查詢節(jié)點(diǎn)。
- 引入系統(tǒng)故障時(shí)進(jìn)行第二次斷言——判斷在系統(tǒng)故障期間，Milvus操作返回的結(jié)果是否符合預(yù)期。
- 通過Chaos Mesh消除故障。
- 當(dāng)Milvus服務(wù)恢復(fù)（即所有pod都準(zhǔn)備就緒）后，做出第三次斷言——所有操作都符合預(yù)期。
- 運(yùn)行test_e2e.py，以測試Milvus功能是否可用。在混沌消除之后，一些操作可能會被繼續(xù)阻塞，進(jìn)而阻礙第三次斷言。因此，該步驟旨在促進(jìn)第三次斷言，并作為檢查Milvus服務(wù)是否恢復(fù)的標(biāo)準(zhǔn)。
- 運(yùn)行hello_milvus.py，以加載創(chuàng)建的集合，對集合進(jìn)行CRUP操作。然后，檢查系統(tǒng)故障前存在的數(shù)據(jù)，在恢復(fù)后是否仍然可用。
- 收集日志。
5.穩(wěn)定性和性能測試
下表描述了穩(wěn)定性和性能測試的目的、測試場景和指標(biāo)。
穩(wěn)定性測試和性能測試會共享同一組工作流程：
穩(wěn)定性測試和性能測試的工作流程
- 解析和更新配置，并定義指標(biāo)。server-configmap對應(yīng)Milvus的單機(jī)或集群配置，而client-configmap對應(yīng)測試用例的各項(xiàng)配置。
- 配置服務(wù)器和客戶端。
- 準(zhǔn)備數(shù)據(jù)。
- 請求服務(wù)器和客戶端之間的交互。
- 報(bào)告和顯示各項(xiàng)指標(biāo)。
五、提高QA效率的工具和方法
從模塊測試部分可以看出，大部分測試的流程其實(shí)都差不多，主要是修改Milvus服務(wù)端和客戶端的配置，傳遞API參數(shù)。當(dāng)有多種配置時(shí)，不同配置的組合越是多樣化，實(shí)驗(yàn)和測試可以覆蓋的場景也就越廣。因此，代碼和程序的重用，對于提高測試效率顯得非常關(guān)鍵。
1.SDK測試框架
SDK測試框架
為了加快測試進(jìn)程，我們可以在原始測試框架中添加一個API_request包裝器，并將其按照API網(wǎng)關(guān)進(jìn)行設(shè)置。此類API網(wǎng)關(guān)將負(fù)責(zé)收集所有API請求，然后將它們傳遞給Milvus，以便集體接收響應(yīng)，并傳遞回客戶端。這樣的設(shè)計(jì)能夠使得捕獲諸如參數(shù)和返回結(jié)果等日志信息，變得更加容易。此外，SDK測試框架中的checker組件也可以驗(yàn)證和檢查Milvus的結(jié)果。所有的檢查方法都可以在該checker組件中被定義。
使用SDK測試框架，我們也可以將一些關(guān)鍵性的初始化過程，封裝到一個函數(shù)中，以削減大量繁瑣的代碼。還值得注意的是，每個單獨(dú)的測試用例都與其獨(dú)特的集合相關(guān)，從而確保了數(shù)據(jù)的相互隔離。例如，在執(zhí)行測試用例時(shí)，pytest-xdist可以利用pytest的擴(kuò)展,并行執(zhí)行所有單獨(dú)的測試用例，從而大幅提高效率。
2.GitHub Action
GitHub Action
GitHub Action會因?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)和版本。
- 它擁有一個提供豐富擴(kuò)展和開箱即用功能的市場。
- 其矩陣能夠支持并發(fā)作業(yè)，并可重用相同的測試流程，來提高效率。
除了上述特點(diǎn)，采用GitHub Action的另一個原因在于部署測試和可靠性測試需要獨(dú)立的隔離環(huán)境，而GitHub Action非常適合對小規(guī)模數(shù)據(jù)集進(jìn)行日常檢查。
3.基準(zhǔn)測試
工具為了使QA測試更加有效，我們可以使用多種工具。
基準(zhǔn)測試工具概覽
- Argo：是一套開源的Kubernetes工具，可用于運(yùn)行工作流，并通過調(diào)度任務(wù)來管理集群。同時(shí)，它也可以并行啟用多個任務(wù)。
- Kubernetes儀表板：提供基于Web的Kubernetes用戶界面，可用于可視化server-configmap和client-configmap。
- 網(wǎng)絡(luò)附加存儲是一種文件級數(shù)據(jù)存儲服務(wù)器，可用于保存常見的ANN-benchmark數(shù)據(jù)集。
- InfluxDB和MongoDB：可用于保存基準(zhǔn)測試結(jié)果的數(shù)據(jù)庫。
- Grafana：可用于監(jiān)控服務(wù)器資源指標(biāo)，和客戶端性能指標(biāo)的開源分析和監(jiān)控解決方案。
- Redash：是一項(xiàng)能夠可視化數(shù)據(jù)，并為基準(zhǔn)測試創(chuàng)建圖表的服務(wù)。
網(wǎng)頁名稱：?一文搞懂開放源碼軟件（OSS）質(zhì)量保證
當(dāng)前地址：http://www.dlmjj.cn/article/dhpiced.html
