現(xiàn)代Kubernetes測試的五大挑戰(zhàn)
從容器化到微服務(wù),我們采用了遠(yuǎn)程工作、敏捷團(tuán)隊,以及云原生使我們能夠管理更快的開發(fā)和發(fā)布周期。

但我們錯過了開發(fā)周期中的一個關(guān)鍵環(huán)節(jié):測試。畢竟,當(dāng)你每天(或每小時、每分鐘……)部署時,還有多少時間測試?而測試對產(chǎn)品交付至關(guān)重要,每次都要做好。
當(dāng)我們開始用Kubernetes時,很快就發(fā)現(xiàn)集成測試面臨著重大挑戰(zhàn),尤其是在持續(xù)集成/持續(xù)交付(CI/CD)管道中配置測試以遵循GitOps方法時。讓我們仔細(xì)地看看測試人員在云原生中面臨的五大挑戰(zhàn)。
1.緊耦合
緊耦合的架構(gòu)有很多優(yōu)點(diǎn),尤其是在處理大量數(shù)據(jù)和許多源的情況下。但它限制了開發(fā)人員和測試人員對測試的自由。
測試和測試執(zhí)行活動與CI/CD和構(gòu)建工作流緊耦合,所以你最終不得不在構(gòu)建的同時運(yùn)行測試。但是當(dāng)你需要運(yùn)行與構(gòu)建不同步的測試時會發(fā)生什么呢?假設(shè)你已經(jīng)更新了一個組件,只想重新運(yùn)行測試套件的特定部分?或者,當(dāng)編排與GitHub Actions或Jenkins等CI/CD工具綁定時,你是否需要運(yùn)行特定的測試?
2.GitOps
GitOps讓你可以隨時了解集群的狀態(tài),并可以使用完善的工作流與它們一起工作。如果你使用的是成熟的DevOps方法,再加上堅實(shí)的GitOps框架,那么每天都可以在生產(chǎn)中部署數(shù)量驚人的代碼。但是,測試究竟是在哪里進(jìn)行的,又是如何進(jìn)行的呢?
如何將測試和測試相關(guān)工件與使用git管理所有集群狀態(tài)的想法聯(lián)系起來?你用同樣的方式管理測試嗎?將它們應(yīng)用于每個集群?當(dāng)你的GitOps CI/CD管道已經(jīng)在愉快地編寫代碼時,測試如何融入其中?
3.測試工具多樣化
今天,我們可以選擇自己的語言和工具,甚至是團(tuán)隊中的個人用不同的語言和工具,這很好。我們可以為每項工作選擇合適的工具,測試也不例外。我們已經(jīng)看到團(tuán)隊為了不同的目的使用不同的測試工具——API測試(SoapUI、Postman)、端到端功能UI測試(Cypress、Selenium)、負(fù)載測試(JMeter、k6),更不用說用于自動化和集成測試的內(nèi)部框架了。
缺點(diǎn)是,這會導(dǎo)致不同的測試框架、工具和庫以不同的格式生成結(jié)果。一些組織甚至建立了一個特定的框架,可以在一種語言上進(jìn)行特定的測試,這是非常棒的,直到團(tuán)隊中知道它如何工作的那個人離開。
作為一名測試人員,你不可能樣樣精通。但由于測試涉及堆棧的很多部分,因此需要一種易于運(yùn)行和監(jiān)控的標(biāo)準(zhǔn)化方法,無論你的語言或工具偏好如何。
4.測量和監(jiān)控
在你看到結(jié)果之前,你是否有過第六感,知道為什么構(gòu)建出現(xiàn)了問題?當(dāng)你的主要關(guān)注點(diǎn)是測試時,很容易培養(yǎng)出對這些事情的敏感度,但組織日益增長的異步性越來越成為一個障礙,就像由獨(dú)立團(tuán)隊管理的微服務(wù)一樣,它們都可能有自己的構(gòu)建管道。這種異步性還揭示了人們不理解測試結(jié)果中的模式的問題,使得在事情朝著錯誤的方向發(fā)展時更難檢測。
在使用大量不同類型的組件和服務(wù)的組織中,一致跟蹤QA和測試通過/失敗率的指標(biāo)非常重要。畢竟,沒有標(biāo)桿,團(tuán)隊如何衡量成功?
5.訪問限制
我們都遇到過這些問題——當(dāng)部署到Kubernetes時,這些令人討厭的網(wǎng)絡(luò)訪問和安全限制,更不用說基于角色的訪問控制了,可能會限制你在集群中訪問或執(zhí)行的操作。這些限制也不容易解決。當(dāng)然,我們中的一些人有幸擁有慷慨的DevOps同事,他們會在你需要時為您提供訪問權(quán)限,但情況肯定并非總是如此。另外,在具體的測試環(huán)境中,你可能需要集群訪問來運(yùn)行功能或性能測試,這些測試遠(yuǎn)遠(yuǎn)超出了你通常獲得的權(quán)限。



























