從容器化到微服務(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)限。