OPS06-BP04 自動化測試和復原 - AWS 建構良好的架構

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

OPS06-BP04 自動化測試和復原

為了提高部署程序的速度和可靠性,請在生產前和生產環境中制定自動化測試和回復功能的策略。在部署到生產環境時自動化測試,以模擬人類與系統的互動,驗證部署的變更。自動回復以快速回復到之前已知的良好狀態。回復應該在預先定義的條件下自動啟動,例如當未達到預期成果或自動化測試失敗時。將這兩項活動的自動化可以提高部署成功率,盡可能縮短回復時間,並減少對業務的潛在影響。

預期成果:您的自動化測試和回復策略將整合至持續整合與持續交付 (CI/CD) 管道。您的監控能夠根據您的成功條件進行驗證,並在失敗時啟動自動回復。這會將終端使用者和客戶受到的任何負面影響降到最低。例如,當所有測試結果都達到標準時,您可以利用相同的測試案例,將程式碼提升至啟動自動迴歸測試的生產環境。若迴歸測試結果不符預期,則會在管線工作流程中啟動自動回復。

常見的反模式:

  • 您的系統架構並不允許以較小版本進行更新。因此,在部署失敗期間,您無法回復這些大量變更。

  • 您的部署程序包含一系列手動步驟。將變更部署到工作負載之後,即可開始部署後測試。測試之後,您會發現工作負載無法運作,且客戶中斷連線。然後您開始回復到之前的版本。所有這些手動步驟都會延遲整體系統回復,並對客戶造成長期影響。

  • 您花時間為應用程式中不常使用的功能開發自動化測試案例,因而大幅降低了自動化測試功能的投資報酬率。

  • 您的版本包含彼此獨立的應用程式、基礎設施、修補程式和組態更新。但是,您有一個 CI/CD 管道可以一次交付所有變更。一個元件故障會強迫您還原所有變更,進而使回復過程變得複雜且效率低下。

  • 您的團隊在第一個衝刺階段完成編碼,並開始衝刺兩項工作,但直到第三個衝刺階段,計畫中都不包括測試。最終,自動化測試找出第一個衝刺階段的缺漏,必須在測試第二個衝刺階段前解決,才能啟動交付項目,因此整個版本延遲,進而降低您的自動化測試效率。

  • 生產版本的自動迴歸測試案例已經完成,但您並未監控工作負載的運作狀況。由於無法查看是否已重啟服務,您不確定是否需要回復或已啟動回復。

建立此最佳實務的優勢:自動化測試可以提高測試流程的透明度,以及您在更短時間內顧及更多功能的能力。在生產環境中測試和驗證變更,可以立即識別出問題。改善自動化測試工具的一致性可以更精確地偵測問題。透過自動回復至舊版本,將對客戶的影響降至最低。自動化回復最終可減少業務影響,讓您對部署功能更有信心。整體而言,這些功能會減少 time-to-delivery,同時確保品質。

未建立此最佳實務時的曝險等級:

實作指引

自動測試已部署的環境,更快確認是否達到預期成果。當無法達成預先定義的結果時,自動還原到先前的良好狀態,以盡量縮短還原時間,並減少由手動程序引起的錯誤。將測試工具與管道工作流程整合,持續進行測試並減少手動輸入。優先處理自動化測試案例,例如減緩最高風險且需要在每次變更時經常測試的案例。此外,還可以根據測試計畫中預先定義的特定條件進行自動回復。

實作步驟

  1. 為您的開發生命週期建立測試生命週期,定義需求規劃到測試案例開發、工具配置、自動化測試和測試案例結案等每個測試程序階段。

    1. 根據您的整體測試策略建立針對特定工作負載的測試方式。

    2. 在整個開發生命週期中,考慮適當的連續測試策略。

  2. 根據您的業務需求和管道投資,選擇用於測試和回復的自動化工具。

  3. 決定您應該分別自動化和手動執行哪些測試案例。這些內容皆可以根據受測功能的業務價值優先順序來決定。使所有團隊成員隨時接收計畫最新資訊,並確認執行手動測試的權責分配。

    1. 將自動化測試功能應用於對自動化有意義的特定測試案例,例如可重複或經常執行的案例、需要重複作業的案例,或跨多個組態所需的案例。

    2. 在自動化工具中定義測試自動化指令碼和成功條件,如此一來,當特定案例失敗時,可以啟動持續的工作流程自動化。

    3. 定義自動回復的特定失敗條件。

  4. 測試案例其中複雜度和人工互動具較高的失敗風險,因此必須排定測試自動化的優先順序,透過詳盡的測試案例開發來產生一致的結果。

  5. 將您的自動化測試和回復工具整合到 CI/CD 管道。

    1. 為變更制定明確的成功條件。

    2. 監控觀察以偵測這些條件,並在符合特定回復條件時自動回復變更。

  6. 執行不同類型的自動化生產測試,例如:

    1. A/B 測試,以顯示結果比較兩個使用者測試組之間的當前版本。

    2. Canary 測試讓您能在將變更發佈給所有使用者之前,先將其發佈給一部分使用者。

    3. 功能旗標測試允許您從應用程式外部標記新版本的功能 (每次僅限一個),進而使每個新功能皆能逐一進行驗證。

    4. 迴歸測試,以現有的關聯元件驗證新功能。

  7. 透過其他應用程式和元件,監控應用程式、交易和互動的操作面向。開發報告,以便按照工作負載顯示變更成功率,讓您得以識別出能夠進一步最佳化的自動化和工作流程部分。

    1. 開發測試結果報告,協助您快速決定是否應該調用回復程序。

    2. 實施策略,允許根據一個或多個測試方法導出的預定義失敗條件進行自動回復。

  8. 開發自動化測試用例,以便在未來可重複的變更中重複使用。

實作計劃的工作量:

資源

相關的最佳實務:

相關文件:

相關範例:

相關影片: