:在 origin 倉庫中編寫、運行與結(jié)構(gòu)化組織擴展測試)
測試云原生質(zhì)量保障【免費下載鏈接】originConformance test suite for OpenShift項目地址https://gitcode.com/gh_mirrors/or/origin點擊查看免費下載在 originOpenShift 的 Conformance 測試套件倉庫中test/extended/目錄承載著一套基于 Ginkgo/Gomega 的功能級擴展測試extended tests。這些測試通過程序化調(diào)用ocCLI 和 Kubernetes/OpenShift 客戶端來驗證構(gòu)建、鏡像、OAuth、路由等核心功能。讀完本文你將掌握 extended 測試的運行方式、測試標簽規(guī)范、目錄組織結(jié)構(gòu)、獨立測試組啟動器的創(chuàng)建方法以及如何用exutil.CLI在 Ginkgo 用例中精確模擬oc命令并斷言結(jié)果。一、前置條件按照 test/extended/README.md 的說明開發(fā) extended 測試前需要滿足兩個前提在倉庫中同時編譯oc與openshift-tests兩個命令行工具$ make WHATcmd/openshift-tests設置環(huán)境變量KUBECONFIG使其指向你要測試的目標集群$ export KUBECONFIG/path/to/kubeconfigopenshift-tests的入口源碼位于 cmd/openshift-tests/openshift-tests.go其子命令實現(xiàn)分散在pkg/cmd/openshift-tests/下例如run、list、monitor、disruption等目錄覆蓋了運行測試、列出套件、監(jiān)控測試、擾動測試等場景。二、運行 Extended 測試按全名運行單個測試$ openshift-tests run-test FULL_TEST_NAME查看可用套件列表$ openshift-tests help run具體的測試前置依賴prerequisites會寫在各測試的描述文字中運行前先閱讀被測用例的 Description。用正則過濾子集運行官方推薦的做法是先把全量測試列表以 dry-run 方式打印出來再用grep -E過濾后通過-f -從標準輸入喂給運行器$ openshift-tests run all --dry-run | grep -E REGEX | openshift-tests run -f -這種方式適合在本地只跑與某功能相關的測試子集而不改動 CI 配置。三、測試標簽Test Labels規(guī)范extended 測試的標簽體系與 Kubernetes e2e 測試的標簽約定一致README 中引用了 k8s 社區(qū)的 e2e-tests 標簽說明文檔。核心規(guī)則如下標簽含義與使用條件無標簽測試應快速完成5 分鐘內(nèi)、可并行運行且結(jié)果一致[Serial]不能與其他測試并行例如占用大量資源或重啟節(jié)點必須作為獨立套件串行運行[Slow]單獨或并行運行超過 5 分鐘。把慢測試分到獨立分區(qū)可以讓絕大多數(shù)測試快速并行跑完。特別注意凡是涉及構(gòu)建builds的 OpenShift extended 測試都應標記[Slow][Conformance]覆蓋集群核心關鍵功能且不與其它 conformance 測試重復覆蓋的用例才算有效。README 給出的正例是“構(gòu)建能否工作Do builds work”反例是“設置 forcePull 標志后構(gòu)建能否工作”——后者屬于特殊配置不屬于 conformance[local]需要訪問測試機本地資源例如使用 docker socket的測試原則上 extended 測試應避免訪問本地宿主無法避免時才打此標簽四、Extended 測試的目錄結(jié)構(gòu)擴展測試統(tǒng)一位于 test/extended/ 目錄其組織結(jié)構(gòu)為test/extended/util提供 extended 測試共用的輔助函數(shù)與工具。它封裝了對 OpenShift CLI 的易用接口前文提到的exutil同時提供對 Kubernetes E2E framework 的訪問以及跨多個測試用例共享的 OpenShift 輔助邏輯讓測試用例保持 DRY。其核心文件 test/extended/util/client.go 定義了CLI類型。test/extended/testdata存放 extended 測試用到的 JSON/YAML 等 fixture 文件當前約 400 個 manifest 文件。test/extended/[images,builds,...]每個 Go 包包含一組相關聯(lián)的 extended 測試。例如images目錄存放驗證容器鏡像使用場景的用例builds存放構(gòu)建相關用例。從當前倉庫實際目錄看除了util與testdata還有apiserver、authentication、authorization、builds、etcd、networking、oauth、operators、router、storage等數(shù)十個功能包每個包對應一類被測功能域。五、包Package與測試組Group的區(qū)別README 給出的組織原則是每一類功能測試都應當放在自己的 Go 包里但如果你的測試包需要以不同于標準路徑的方式專門配置服務端則要在test/extended目錄下創(chuàng)建一個與包同名的 launcher 腳本shell 啟動器。典型的例子是 LDAP 認證測試你需要先把 OpenShift server 配置成啟用 LDAP 認證才能測認證流程。做法是新建測試組ldap并提供 shell 啟動器./test/extended/ldap.sh用于以所需配置啟動 OpenShift把測試源碼放到對應功能包的 Go 目錄下例如./test/extended/ldap在頂層 suite 上給你的用例加組前綴var _ g.Describe([ldap] Authenticate using LDAP, func() { # ... })創(chuàng)建新的測試組 Runner如果你的測試需要與其它 extended 用例不同的配置應在test/extended下新建執(zhí)行腳本并注意用 Ginkgo 的 focus 機制只選中你自己的測試。如果你的測試無法作為默認組的一部分運行務必確保該包不被test/extended的默認入口包含。當前倉庫中仍保留了這種 shell runner 的范例——test/extended/cmd.sh。它演示了一個完整的組 runner 生命周期source $(dirname ${BASH_SOURCE})/../../hack/lib/init.sh os::util::environment::setup_time_vars os::build::setup_env # 以默認配置啟動 OpenShift server無 registry/router os::util::environment::use_sudo os::cleanup::tmpdir os::util::environment::setup_all_server_vars os::start::configure_server os::start::server export KUBECONFIG${ADMIN_KUBECONFIG} # 注冊 junit suite 并執(zhí)行 oc 命令斷言 os::test::junit::declare_suite_start extended/cmd/new-app os::cmd::expect_success oc new-app test/scratchimage~https://github.com/openshift/ruby-hello-world.git --strategydocker ... os::test::junit::declare_suite_end可以看到 launcher 腳本負責環(huán)境準備setup_env、use_sudo、服務端配置與啟動configure_server、server并用os::test::junit::declare_suite_start/end向 JUnit 報告注冊測試套件測試斷言則大量使用os::cmd::expect_success_and_text、os::cmd::try_until_text等對oc命令輸出做正則驗證的封裝。Bash 輔助函數(shù)README 指出 extended 測試的通用函數(shù)位于./hack/util.sh環(huán)境設置腳本位于 hack/lib/util/environment.sh主要函數(shù)包括函數(shù)作用ginkgo_check_extended()檢查 Ginkgo 二進制是否已安裝compile_extended()將 Go 測試編譯為測試二進制test_privileges()校驗是否有權(quán)限啟動 OpenShift serveros::util::environment::setup_all_server_vars()設置 OpenShift server 所需的全部環(huán)境變量os::start::configure_server()生成 OpenShift server 的所有配置文件os::start::server()啟動 OpenShift master 與 nodeos::start::router()安裝 OpenShift 路由服務os::start::registry()安裝 OpenShift 容器鏡像 registry 服務create_image_streams_extended()為所有 OpenShift 鏡像創(chuàng)建 ImageStream從源碼結(jié)構(gòu)看os::util::environment::setup_all_server_vars的實際定義在 hack/lib/util/environment.shos::start::configure_server與os::start::server定義在 hack/lib/start.sh——configure_server會生成 master 證書、node 配置與 OpenShift 配置server則啟動服務并等待端點可用。編寫 launcher 時直接source這些庫即可復用整套啟動流程。六、CLI 接口在測試中模擬 oc 命令extended 測試的核心能力是通過exutil.CLI包路徑 test/extended/util/client.go調(diào)用 OpenShift CLI 與 Kubernetes/OpenShift 客戶端從而在 Ginkgo 用例中模擬oc命令。頂層 Describe 中創(chuàng)建 CLI 實例要在測試套件中模擬oc命令必須先創(chuàng)建 CLI 實例且應放在頂層 GinkgoDescribe容器中。頂層 Describe 的標簽需要同時給出測試所屬的 bucket 與簡短描述其它全局可訪問變量如 fixtures也在此聲明package extended import ( g github.com/onsi/ginkgo/v2 o github.com/onsi/gomega ) var _ g.Describe([test bucket] Testing scenario, func() { defer g.GinkgoRecover() var ( oc exutil.NewCLI(test-name) testFixture filepath.Join(testdata, test.json) ) })測試套件應進一步組織為更下層的Describe容器用消息描述測試目標每個下層容器內(nèi)用單個It承載具體 specIt共享上下文并說明如何達成測試目標var _ g.Describe([default] STI build, func() { defer GinkgoRecover() var ( stiBuildFixture filepath.Join(testdata, test-build.yaml) oc exutil.NewCLI(build-sti, kubeConfigPath()) ) g.Describe(Building from a template, func() { g.It(fmt.Sprintf(should create a image from %q template, filepath.Base(stiBuildFixture)), func() { ... } } }源碼層面NewCLI() 會基于給定的 namespace 名稱初始化 CLI 及 Kube framework 輔助結(jié)構(gòu)并注冊g.BeforeEach(cli.SetupProject)在每條用例前創(chuàng)建項目、g.AfterEach(cli.TeardownProject)在用例后回收項目因此測試用例無需自行管理項目生命周期。從 NewCLIWithoutNamespace() 的實現(xiàn)看底層framework.Framework默認使用ClientQPS: 20、ClientBurst: 50的客戶端限流參數(shù)execPath固定為ockubeconfig 路徑取自KubeConfigPath()——這與前置條件中要求設置KUBECONFIG環(huán)境變量相呼應。命令動詞與參數(shù)Run / Args / Template模擬oc命令時先用Run()指定命令動詞get、create、start-build等再用Args()追加參數(shù)方法可以自由鏈式調(diào)用oc oc.Run(create)oc oc.Run(create).Args(-f, testFixture)Template()方法可給 CLI 命令附加 Go 模板參數(shù)但前提是Run()中指定了get動詞oc oc.Run(get).Args(foo).Template({{ .spec }})它等價于命令行執(zhí)行$ oc get foo -o template --template{{ .spec }}執(zhí)行與斷言Execute / Output / By / Expect執(zhí)行命令有兩種方式Execute()執(zhí)行命令并返回過程中發(fā)生的錯誤Output()除返回錯誤外還返回命令輸出err : oc.Run(create).Args(-f, testFixture).Execute()buildName, err : oc.Run(start-build).Args(test).Output()用 Ginkgo 的By函數(shù)打印下一組命令的意圖使測試日志可讀g.By(starting a test build) buildName, err : oc.Run(start-build).Args(test).Output()用 Gomega 的Expect語法對錯誤做斷言err oc.Run(create).Args(-f, stiEnvBuildFixture).Execute() o.Expect(err).NotTo(o.HaveOccurred())CLI類型本身的字段設計也印證了這一接口語義從 client.go 中的結(jié)構(gòu)體定義看CLI分別維護verb命令動詞、globalArgs、commandArgs、finalArgs最終拼接參數(shù)、stdin/stdout/stderr進程標準流以及adminConfigPathkubeconfig等字段Run()/Args()只是往這些字段累積狀態(tài)真正的進程執(zhí)行發(fā)生在Execute()/Output()調(diào)用時源碼中對應Run于 L984、Args于 L1032、Output于 L1048、Execute于 L1158 的實現(xiàn)。此外CLI還提供了KubeFramework()訪問 Kubernetes framework 助手、SetupProject()/TeardownProject()管理項目以及NewCLIWithFramework()、NewHypershiftManagementCLI()等針對不同場景綁定已有 framework、Hypershift 管理集群的構(gòu)造方式編寫特殊場景測試時可按需選用。七、小結(jié)一個新 Extended 測試的完整流程綜合以上內(nèi)容向 origin 倉庫提交一個新 extended 測試的標準路徑是確認測試歸屬的功能域?qū)⒂美湃雽?Go 包如test/extended/builds/fixture 放入 test/extended/testdata若需要特殊服務端配置在test/extended/下新增同名 launcher 腳本復用hack/lib中的環(huán)境與服務啟動函數(shù)并用 Ginkgo focus 圈定本組用例在頂層Describe中聲明 bucket 前綴并創(chuàng)建exutil.NewCLI實例按Run/Args/Template構(gòu)造命令用Execute/Output執(zhí)行、o.Expect斷言按標簽規(guī)范決定是否加[Serial]、[Slow]、[Conformance]、[local]標簽避免慢測試拖慢并行分區(qū)本地用openshift-tests run-test FULL_TEST_NAME或正則過濾子集驗證通過后再提交。贊分享測試云原生質(zhì)量保障【免費下載鏈接】originConformance test suite for OpenShift項目地址https://gitcode.com/gh_mirrors/or/origin點擊查看免費下載相關推薦OrcaSlicer 測試套件實戰(zhàn)指南Catch2 測試的組織、編寫與構(gòu)建運行全解析OrcaSlicer 測試套件實戰(zhàn)指南Catch2 測試的組織、編寫與構(gòu)建運行全解析 本篇技術(shù)指南以 OrcaSlicer 倉庫 tests/ 目錄下的測試工桌面應用3D渲染圖形學Quick 測試組織指南用 Example 與 Example Group 編寫結(jié)構(gòu)化測試Quick 測試組織指南用 Example 與 Example Group 編寫結(jié)構(gòu)化測試 本文是 QuickSwift / Objective C 行為驅(qū)測試開發(fā)工具Johnny-Five 擴展測試Extended Tests機制解析時間敏感測試的隔離、編寫與運行Johnny Five 擴展測試Extended Tests機制解析時間敏感測試的隔離、編寫與運行 導讀 Johnny Five 是面向 ArduinoIoT機器人嵌入式上一篇Wayback Machine 擴展上手指南3 步裝好找回消失的網(wǎng)頁下一篇open-vela packages 快應用示例源碼導讀Chart圖表與Player播放器完整拆解指南創(chuàng)作聲明:本文部分內(nèi)容由AI輔助生成(AIGC),僅供參考