從容器化到微服務，我們采用了遠程工作、敏捷團隊，以及云原生使我們能夠管理更快的開發和發布周期。

但我們錯過了開發周期中的一個關鍵環節：測試。畢竟，當你每天(或每小時、每分鐘……)部署時，還有多少時間測試?而測試對產品交付至關重要，每次都要做好。

當我們開始用Kubernetes時，很快就發現集成測試面臨著重大挑戰，尤其是在持續集成/持續交付(CI/CD)管道中配置測試以遵循GitOps方法時。讓我們仔細地看看測試人員在云原生中面臨的五大挑戰。

1.緊耦合

緊耦合的架構有很多優點，尤其是在處理大量數據和許多源的情況下。但它限制了開發人員和測試人員對測試的自由。

測試和測試執行活動與CI/CD和構建工作流緊耦合，所以你最終不得不在構建的同時運行測試。但是當你需要運行與構建不同步的測試時會發生什么呢?假設你已經更新了一個組件，只想重新運行測試套件的特定部分?或者，當編排與GitHub Actions或Jenkins等CI/CD工具綁定時，你是否需要運行特定的測試?

2.GitOps

GitOps讓你可以隨時了解集群的狀態，并可以使用完善的工作流與它們一起工作。如果你使用的是成熟的DevOps方法，再加上堅實的GitOps框架，那么每天都可以在生產中部署數量驚人的代碼。但是，測試究竟是在哪里進行的，又是如何進行的呢?

如何將測試和測試相關工件與使用git管理所有集群狀態的想法聯系起來?你用同樣的方式管理測試嗎?將它們應用于每個集群?當你的GitOps CI/CD管道已經在愉快地編寫代碼時，測試如何融入其中?

3.測試工具多樣化

今天，我們可以選擇自己的語言和工具，甚至是團隊中的個人用不同的語言和工具，這很好。我們可以為每項工作選擇合適的工具，測試也不例外。我們已經看到團隊為了不同的目的使用不同的測試工具——API測試(SoapUI、Postman)、端到端功能UI測試(Cypress、Selenium)、負載測試(JMeter、k6)，更不用說用于自動化和集成測試的內部框架了。

缺點是，這會導致不同的測試框架、工具和庫以不同的格式生成結果。一些組織甚至建立了一個特定的框架，可以在一種語言上進行特定的測試，這是非常棒的，直到團隊中知道它如何工作的那個人離開。

作為一名測試人員，你不可能樣樣精通。但由于測試涉及堆棧的很多部分，因此需要一種易于運行和監控的標準化方法，無論你的語言或工具偏好如何。

4.測量和監控

在你看到結果之前，你是否有過第六感，知道為什么構建出現了問題?當你的主要關注點是測試時，很容易培養出對這些事情的敏感度，但組織日益增長的異步性越來越成為一個障礙，就像由獨立團隊管理的微服務一樣，它們都可能有自己的構建管道。這種異步性還揭示了人們不理解測試結果中的模式的問題，使得在事情朝著錯誤的方向發展時更難檢測。

在使用大量不同類型的組件和服務的組織中，一致跟蹤QA和測試通過/失敗率的指標非常重要。畢竟，沒有標桿，團隊如何衡量成功?

5.訪問限制

我們都遇到過這些問題——當部署到Kubernetes時，這些令人討厭的網絡訪問和安全限制，更不用說基于角色的訪問控制了，可能會限制你在集群中訪問或執行的操作。這些限制也不容易解決。當然，我們中的一些人有幸擁有慷慨的DevOps同事，他們會在你需要時為您提供訪問權限，但情況肯定并非總是如此。另外，在具體的測試環境中，你可能需要集群訪問來運行功能或性能測試，這些測試遠遠超出了你通常獲得的權限。