一千萬個為什麽

搜索

如何避免持續集成 - 測試環境中引起的不穩定?



假設您正在使用經常更新某些目標環境的持續集成過程,以便每次發生一些變更時,您都可以立即測試您的更改。這是CI的目標的一部分,不是嗎?

但是,也假定您有其他人參與您的測試周期,例如經理或客戶。讓其他人參與試圖檢查(打破?)即將發生的變化是否有意義,不是嗎?

但是,如果你持續不斷地在其他人所處的環境中發生變化,認真地試圖對其進行測試,那麽可能會出現多種問題,例如:

  • they might waste their time in reporting issues which, by the time they save the (in depth) report, they cannot even reproduce the issue themselves anymore (e.g because accidently you also ran into the same issue, and already fixed it in their environment).
  • you might not be able to reproduce issues they reported, since the environments in which they ran into some issue, is no longer identical (you (!!!) might have overlayed their environment).

那麽你可以做什麽(如何配置事物?)以避免這種(令人沮喪的)情況?

轉載註明原文: 如何避免持續集成 - 測試環境中引起的不穩定?

一共有 5 個回答:

我會在這一點上給我的經驗,主要是因為它展示了為什麽有些答案不總是適用。

一些上下文開始:

  • 我們有7個環境來托管大約80個應用程序,其中大多數應用程序通過Web服務或db2-iSeries上的共享表來彼此依賴。
  • 無論好壞,iSeries都是我們的DB系統參考。
  • 最後一點使任何將應用程序依賴於應用程序的想法都視為孤立的環境,因為為每個應用程序創建一個AS400會花費太多,並且我們也不會有硬件來運行它。

我們正在做的不是一個完整的自動化持續交付,我們有一個發布時間表來為一般操作提供連貫的大量應用程序。除此之外,每個測試團隊都可以在他們正在測試的應用程序的某個Q/A環境中觸發發布,並且可以鎖定某些應用程序版本以避免另一個團隊請求中斷測試。

在發布之前檢查應用程序的依賴關系,因此如果其他應用程序無法更新或不匹配其所需的依賴關系,系統將不會發布某些內容。 主要思想是在不影響某人的情況下允許更新,如果沒有計劃測試,則應該從先前的環境中流出(並且我們的目標是在中期內移除5個第一環境中的預定版本驗證了這種“按需”方法系統)。

簡短的版本是在環境中的應用程序周圍有一個'信號量'系統,一個團隊應該能夠在手動測試時鎖定其目標應用程序及其依賴關系(和傳遞依賴關系)。
這個信號量的實現高度依賴於你的自動化系統,所以我不會在這方面擴展。

正如其他人提到的那樣,簡單的方法是為具有所有依賴性的應用程序創建一個全新的環境,以避免上述的信號量。

聽起來就像你在談論一個測試環境,該環境在每次測試執行時都不會被可靠重新初始化而不斷被重用。這使得這種測試不可靠。類似的,從可靠性的角度來看,如果你想的話,還可以手動測試。

恕我直言,您不應該在您的CI/CD資格認證目的內使用此類測試,因為這將有效地使您的認證過程失效(至少在該領域)。如果軟件通過了測試X而沒有為每個交付的軟件版本實際執行測試X,或者沒有確定獲得的 pass 結果不是偶然的(由於誤報),這將侵蝕測試的置信度。假陰性不是可信度的損害,但它們也是不受歡迎的,因為它們產生了不必要的“噪音”。

在您的CI/CD認證過程之外執行此類測試很好。但是,您會像對待客戶發現的錯誤一樣對待這種測試中的失敗結果:您需要可靠地重現問題,以便能夠為其修復問題並確認修復程序正在工作。如果測試不可靠,你不可能那樣做。

如果你打算解決這個問題,那麽理想情況下,你首先要開發一個自動化的,可靠的測試用例來重現問題。您可以使用它來開發修復程序並確認其有效性(測試結果應該從FAIL過渡到PASS)。如果需要,您可以(應該)將此測試用例放入您的CI/CD認證過程中,以防止未來再次發生 - 以提高您的整體軟件發布質量水平。

通常的做法是創建不同的環境:

DEV--這是開發團隊搞亂事情的地方。這裏是創建所有更改調音,部署新版本等。這裏是CI完全集成的地方。

PREPROD/QA - 這是“玩”QA /測試/驗證團隊進行測試的地方。這種環境通常在測試過程中凍結。 CI與此環境的整合只是為了提供新版本的產品,配置等。

生產 - 是否需要解釋:)?

如果您正在進行CI/CD,這意味著在部署之前有一些自動化測試(CI)(CD)。如果您在測試環境中發現很多問題,這意味著它們不會被部署前運行的測試所捕獲;這表明自動化測試不足。如果開發人員在測試環境中出現缺陷,他們需要改進自動化測試套件以防止這種情況發生。這也將整體提高質量和可靠性,一直貫穿到生產中。

要添加到Romeo Ninov的答案中,在內部環境中,您需要嘗試盡可能多地分離出應用程序。這部分是為什麽碼頭在開發/測試中如此成功的原因。它讓你幾乎假裝你沒有共享一個環境。

另一種選擇是擁有非常清晰定義的服務器,應用程序在該服務器上運行,與構成環境的其他基礎架構分開。 IE瀏覽器。所有的環境管理或啟用機器都是獨立的,長期存在的服務器。然後,您將基於已知圖像的新短期服務器掛鉤以測試應用程序,如果對基本圖像進行了任何更改,則需要對每個新組件應用所有地方的更改。這意味著要針對所有方面進行測試。

如果一個appdev團隊要求改變打破別人的應用程序,那麽運氣不好,他們需要在他們的代碼中內部創建一個緩解措施,並將他們的特定要求與環境提供分開。