?譯者 | 陳峻
審校 | 孫淑娟
如果說(shuō)質(zhì)量保證(QA)是確定產(chǎn)品或服務(wù)是否滿足特定要求的系統(tǒng)過(guò)程,那么質(zhì)量保證系統(tǒng)則是研發(fā)過(guò)程中不可或缺的一部分,它起到了確保產(chǎn)品質(zhì)量的作用。
在本文中,我將向您介紹在開(kāi)發(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開(kāi)展功能性測(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í)例,可以確保在與軟件開(kāi)發(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ì)軟件開(kāi)發(fā)過(guò)程中出現(xiàn)的問(wèn)題予以測(cè)試和管理。
1.QA測(cè)試
如下圖所示,我們應(yīng)當(dāng)根據(jù)Milvus的特性和用戶需求,按照優(yōu)先級(jí)的順序,開(kāi)展不同類(lèi)型的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是否兼容不同類(lèi)型的硬件或軟件。
2.問(wèn)題管理
軟件在開(kāi)發(fā)過(guò)程中可能會(huì)出現(xiàn)許多問(wèn)題。這些問(wèn)題可能源于QA工程師本人,也可能來(lái)自開(kā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)行分類(lèi)。在分流的過(guò)程中,被檢查出的新問(wèn)題應(yīng)確保帶有足夠多的問(wèn)題詳細(xì)信息,以便開(kāi)發(fā)人員的確認(rèn)、接受、以及嘗試修復(fù)。而在修復(fù)完成之后,問(wèn)題屬主則需要驗(yàn)證其修復(fù),判斷是否可以最終關(guān)閉該問(wèn)題。
三、什么時(shí)候需要QA?
一種常見(jiàn)的誤解是:QA和開(kāi)發(fā)是相互獨(dú)立的。而事實(shí)是為了確保系統(tǒng)的質(zhì)量,開(kāi)發(fā)人員和QA工程師都需要通力協(xié)作,將QA貫穿整個(gè)生命周期。
將QA引入整個(gè)軟件研發(fā)的生命周期如上圖所示,一個(gè)完整的軟件研發(fā)生命周期包括三個(gè)階段:
- 在初始階段,開(kāi)發(fā)人員發(fā)布設(shè)計(jì)文檔,QA工程師據(jù)此制定測(cè)試計(jì)劃、定義發(fā)布標(biāo)準(zhǔn)、并分配QA任務(wù)。開(kāi)發(fā)人員和QA工程師需要熟悉設(shè)計(jì)文檔和測(cè)試計(jì)劃,以便在兩個(gè)團(tuán)隊(duì)之間共享對(duì)于發(fā)布目標(biāo)、功能、性能、穩(wěn)定性、錯(cuò)誤收斂等方面的相互理解。
- 在研發(fā)期間,開(kāi)發(fā)和QA測(cè)試通過(guò)持續(xù)交互,以對(duì)開(kāi)發(fā)出的特性和功能進(jìn)行驗(yàn)證,并修復(fù)來(lái)自開(kā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開(kāi)展,功能測(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è)試兩種類(lèi)別。其中,重啟測(cè)試是指測(cè)試數(shù)據(jù)持久性的過(guò)程,即重啟后的數(shù)據(jù)是否仍然可用。升級(jí)測(cè)試則是指測(cè)試數(shù)據(jù)地兼容性,以防止在Milvus中插入不兼容的數(shù)據(jù)格式的過(guò)程。如下圖所示,兩種類(lèi)型的部署測(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)故障真正開(kāi)始造成危害之前予以修復(fù)。在Milvus的混沌測(cè)試中,我們可以選擇Chaos Mesh作為創(chuàng)建混沌的工具,來(lái)創(chuàng)建如下故障類(lèi)型:
- 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)重依賴(lài)各個(gè)組件之間的通信。為了測(cè)試不同的Milvus組件之間的相互依賴(lài)關(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è)置。此類(lèi)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等常用的軟件開(kāi)發(fā)工具。
- 它支持包括Ubuntu、MacOs、以及Windows-server在內(nèi)的多種操作系統(tǒng)和版本。
- 它擁有一個(gè)提供豐富擴(kuò)展和開(kāi)箱即用功能的市場(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:是一套開(kāi)源的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ù)器,可用于保存常見(jiàn)的ANN-benchmark數(shù)據(jù)集。
- InfluxDB和MongoDB:可用于保存基準(zhǔn)測(cè)試結(jié)果的數(shù)據(jù)庫(kù)。
- Grafana:可用于監(jiān)控服務(wù)器資源指標(biāo),和客戶端性能指標(biāo)的開(kāi)源分析和監(jiān)控解決方案。
- Redash:是一項(xiàng)能夠可視化數(shù)據(jù),并為基準(zhǔn)測(cè)試創(chuàng)建圖表的服務(wù)。
原文鏈接:https://dzone.com/articles/open-source-software-oss-quality-assurance-a-milvu