逐步分解，為測試執行制定路線圖，以根據應用程序的演變擴展您的測試。

譯自A 5-Step Framework for Test Execution，作者 Ole Lensmar。

在我們之前的文章中，我們指出將測試執行與 CI/CD 流水線耦合存在一些缺點，這些缺點隨著應用程序或部署基礎設施的復雜性和規模的增加而變得明顯。現在讓我們退一步，看看CI/CD在此背景下解決的初始需求：運行您的測試，也稱為測試執行。與許多事情一樣，在構建基礎設施時對測試執行進行一些額外的思考和關注，可以為您帶來多倍的回報。讓我們來分解一下。

STLC 中的測試執行

軟件測試生命周期 (STLC) 是軟件開發生命周期 (SDLC) 中測試活動的分步分解，它是一個成熟的流程。從高層次來看，STLC 包括以下步驟：

• 需求分析: 了解需要測試的內容。
• 測試計劃: 計劃如何測試需求。
• 測試用例開發: 編寫實際的測試用例。
• 測試環境設置: 準備您的測試環境。
• 測試執行: 在您的測試環境中執行您的測試。
• 測試周期結束: 確保所有測試活動都已完成。

Source:https://www.boardinfinity.com/blog/introduction-to-stlc-software-testing-life-cycle/

如您所見，測試執行是此生命周期中的一個特定步驟，它本身就是一個值得深入研究的領域。讓我們來做一下。

測試執行的 5 步框架

隨著組織中測試工具、CI/CD 系統、工程師和應用程序數量的增長，以可擴展且高效的方式執行測試并管理執行結果變得越來越復雜。讓我們首先將測試執行分解為五個步驟，以幫助您決定如何以可擴展的方式執行測試。

1. 定義: 您將如何定義測試的執行？
2. 觸發: 您將如何觸發測試執行？
3. 擴展: 您對測試執行有哪些可擴展性需求或限制？
4. 故障排除: 您如何有效地排除（失敗的）測試執行的故障？
5. 報告: 您需要哪些報告來計劃（未來）測試活動？

圖片

讓我們更詳細地探討每個步驟，以幫助您了解您可能需要在團隊中回答哪些問題。

• 定義– 您將如何以一致的方式運行您的測試，考慮到：

您現有的（和未來的）測試工具和版本

用于數據驅動測試的輸入數據

測試編排：例如，以協調的方式執行多個測試，可能跨多個/遠程環境

• 觸發– 您將如何觸發測試的執行？

來自 CI/CD 工具，作為構建和部署流程的一部分？

定期計劃執行？（例如，“每天運行我們的安全測試。”）

基于外部/內部異步事件觸發器或 Webhook？（“每當這些組件在我們基礎設施中更新時，重新運行端到端測試。”）

臨時或手動？

通過 API/CLI 的自定義集成？

• 擴展– 當您擴展測試活動時，請確保您已評估：

您需要模擬多少負載？

您能使用您現有的/內部基礎設施嗎？

您如何與其他（測試）活動協調？

并行化以縮短執行時間？

異步調度而不是每次構建都運行？

您預計在“峰值測試時間”運行多少測試？

您是否有跨測試共享的/有狀態的基礎設施？您是否需要相應地限制測試執行？

您是否有運行時間很長的測試，需要：

測試應該在您的基礎設施內部和/或外部運行（或兩者）？

專門針對負載測試：

• 故障排除– 在復雜的應用程序基礎設施中，排除失敗測試的故障可能很痛苦：

您測試工具的日志和工件是否足夠，或者您還需要測試中應用程序的日志和指標？

相關人員是否有權訪問日志/基礎設施進行故障排除？

所有故障排除都可以在一個地方完成，還是有多個訪問點？

您需要保留結果多長時間？

日志或工件是否包含敏感信息？它們是否需要安全存儲？

• 報告– 問問自己：

您需要隨著時間的推移跟蹤哪些指標，以及以什么粒度？例如，通過/失敗比率、測試總數等。

您是否可以或應該將來自不同測試執行和測試工具的結果聚合到通用報告中？

訪問控制：相關人員是否有權訪問報告？

報告/指標是否可以按所需維度進行分析，例如團隊/應用程序等？

測試執行結果是否需要推送到外部系統？例如：報告、事件管理、問題跟蹤

報告應該如何內部分發并隨著時間的推移進行訪問——短暫/長期 URL？PDF？等等。

測試執行評估標準

除了上面概述的測試執行的戰術方法之外，我們還可以定義一些需要評估和規劃的標準，以便根據您的團隊和應用程序的需求進行相應擴展。

• 一致性– 獲得一致的測試結果是建立對質量指標和下游活動的信任的關鍵，為此，您的測試執行環境應盡可能同質，前提是您的應用程序的上下文。
• 解耦– 測試執行不應與基礎設施中的任何其他特定框架或流水線緊密耦合。隨著時間的推移，運行測試的需求將在戰略和戰術上發生變化，您的測試應該隨時可用以執行。
• 集中化– 雖然您的測試可能在基礎設施中的多個地方執行，但在一個地方管理這些執行及其結果可以為您提供測試活動的整體視圖，從而使您能夠隨著應用程序和基礎設施的擴展，始終如一地評估、分析和控制測試執行。
• 集成– 測試執行通常需要與您現有的工作流程和流水線集成——但不要緊密耦合！- 測試的執行需要從各種來源觸發。

• 測試執行或失敗的通知需要集成到協作平臺和事件/問題跟蹤中。
• 測試結果或指標可能需要由外部監控或報告工具捕獲。

• 可擴展性– 大規模運行測試是采用主動測試執行方法的團隊面臨的最常見挑戰之一。
• 需要水平擴展單個測試以提高執行時間或涵蓋更多測試場景
• 多個團隊需要使用受限資源（基礎設施、共享數據庫等）運行其測試
• 需要擴展負載測試以生成所需的負載，以確保應用程序和基礎設施的性能和穩定性
• 安全和訪問控制– 這有幾個方面：
  
• 誰應該能夠運行測試、查看結果等？
• 如果您的基礎設施需要專門為測試執行進行配置，這是否會對安全造成任何影響？

為測試執行制定路線圖

以上兩個部分都不是要窮盡或最終確定它們各自的方法。每個應用程序基礎設施都是獨一無二的，因此您的團隊對如何運行測試的需求也將是獨一無二的。要點是讓您思考測試執行，而不是“在 Jenkins 中運行我的 playwright 測試”——因為這肯定會遇到死胡同，并阻止您根據應用程序的演變來擴展測試活動。

一種動手的方法可能是：

• 將您的測試活動分解為 STLC 的不同步驟。您是如何執行這些步驟的？誰負責？您有什么需求？
• 將測試執行分解為上述五個步驟，并再次問問自己：您的需求是什么，誰負責等等。
• 將上面概述的測試執行評估標準納入您的測試執行策略。確保您至少討論了所有這些標準，即使您的行動方針是“忽略”。
• 確保合適的人員參與所有這些討論（無特定順序）：

QA 負責人/經理

DevOps/平臺工程

系統架構（如果需要/適用）

產品所有權（如果需要/適用）

Testkube 用于測試執行

也許并不奇怪，我寫這篇文章不僅是為了分享對測試執行的見解，也是為了向您展示Testkube如何提供幫助。

簡而言之，Testkube 是一個用于測試執行的編排平臺，符合上面討論的許多（但不是全部）要點。上面概述的用于測試執行的五個步驟是如何使用 Testkube的基石：

• 定義使用強大的測試工作流程語法定義您的測試執行，該語法支持您可能使用的任何測試工具或腳本。
• 觸發您的測試，無論您可能需要什么；CI/CD、事件/webhook、CLI、API 等。
• 擴展任何測試工具，水平或垂直擴展，以確保您的應用程序始終如一地進行測試，并大規模擴展。
• 排查使用 Testkube 結果和日志分析功能排查測試結果。
• 報告隨著時間的推移報告測試結果，以指導您的測試工作和活動。

雖然 Testkube 無法解決上面討論的所有問題，但它提供了一個扎實的起點。請訪問testkube.io/get-started試用。有開源版本和免費版本可用。