測試影響分析的崛起

建立套件和標籤

單元、服務和功能性 UI 的主要群組。在單元測試中，有意義的子群組標籤，包括一個「快速」標籤，用於抽樣其他標籤的子集。

在執行「購物車」測試後，所有測試都通過，只有一個除外。在此處。

這種方法適用於遞迴建置技術，例如 Ant、Maven、MSBuild、Rake 等。

過去，團隊會放棄讓他們的測試無限快，並使用套件或標籤一次針對測試的子集。透過建立套件和標籤，可以口頭描述測試的子集。例如「購物車的 UI 測試」。標籤或套件可以暗示應用程式的業務領域，或技術或分層群組。定義標籤和套件需要專家的人為設計創意。至少為了朝向最佳群組化邁進。這意味著它們也可能群組不足、不精確和不正確，這很常見，即使人類很難確定。一次執行太少或太多的測試，很有可能只執行一個套件，這會浪費運算資源和時間，也可能導致錯誤被忽略。團隊可能會選擇使用每個提交較小套件的 CI 工作，然後再使用執行所有測試的夜間建置工作。顯然，這會延遲壞消息，並破壞持續整合的目標。

然而，套件和標籤是大多數軟體開發界組織其測試程式碼庫的方式。

來源與測試的預先計算圖表

276 個測試及其名義上的「大小」標示。

針對特定提交執行的測試，導致兩個失敗。事實上，其中一些變小了，一些變中等，一些變大了。我僅描繪樹狀圖/分形圖，因為它有助於解釋概念（實際上並非如此）。

Google 傳奇的內部建置系統 Blaze 多年來已複製到一些開源技術中。最著名的是 Facebook 的 Buck 和 Google 的 Bazel。Twitter、Foursquare 和 Square 的 Pants。Google 內部的 Blaze 會在整個單一儲存庫中導覽單一的有向圖。Blaze 有一種機制，可將測試直接關聯到製作程式碼。該機制是製作來源和關聯測試來源的精細目錄樹。它透過 BUILD 檔案（也已簽入）具有明確的相依性宣告。開發人員可以維護和演進這些 BUILD 檔案，但也可以透過自動化工具驗證其正確性或不正確性。隨著時間推移，重複該程序有助於使有向圖正確且有效率。

重要的是，該工具可以指出關於相依性的重複宣告。因此，對於給定的目錄/套件/名稱空間，開發人員可以很輕鬆地啟動測試子集，但僅透過 BUILD 檔案中的有向圖可行的測試。對於開發人員 預先整合 和整合基礎架構來說，最終的省時方法是規模化的 CI 基礎架構「Forge」（後來的 TAP），它是根據此內建智慧自動化測試子集，以便針對每次提交執行。

在 Taming Google-Scale Continuous Testing 中有一堆令人驚嘆的統計資料。在我看來，這些東西讓 Google 花費了數千萬美元，但多年來卻讓他們賺進了數十億美元。或許遠遠超過了收益：工資比率。

Microsoft 的廣泛 TIA 工作

Microsoft 已投入最長期的協同努力，將測試影響分析概念商品化，並賦予該概念名稱及其縮寫。

截至目前，他們有一系列的部落格文章，時間橫跨 2017 年 3 月至 8 月：使用測試影響分析加速持續測試 - 第 1 部分、第 2 部分、第 3 部分，以及 第 4 部分。

他們較早關於這方面的文章可回溯至八年前

1. Visual Studio 2010 中的測試影響分析 (2009)
2. 使用測試影響分析簡化測試流程) (2010)
3. 自上次建置以來，應該執行哪些測試？ (2010)
4. 如何：收集資料以檢查在程式碼變更後應該執行哪些測試 (2010)
5. 測試影響分析 (2011)

Microsoft 的 Pratap Lakshman 詳細說明了他們的實作演進。關於其 TIA 技術的目前演進，Pratap 表示：[1]

        Testcasemethod1 <--> a.cs, b.cs. d.cs
        Testcasemethod2 <--> a.cs, k.cs, z.cs 

關於 TIA 在 TFS 和 Visual Studio 的最初幾年，他說

透過傳統程式碼覆蓋率工具和腳本進行測試影響分析

我在 HedgeServ 工作時，有一個想法，要將現代的現成程式碼覆蓋率工具納入相同的影響分析。從這個想法中，我寫了兩篇概念驗證部落格文章（並在 Github 上提供相關程式碼）：一篇是關於 Maven 和 Java[2]，另一篇是關於 Python[3]。當然，就像一個 eejit，我認為自己有新穎的發明，但我當時不知道這個領域已經有很多先例（如上述的 Microsoft）。我展示的技術在您的工具鏈中開發成本低廉，即使在 CI 基礎架構中執行可能需要成本。

測試影響分析的想法的簡單實作要求您有一個事前的活動

1. 執行單一測試並收集其程式碼覆蓋率
2. 從測試觸及的生產來源檔案中，建立一個臨時的生產來源對應（鍵）到測試路徑/名稱（值）
3. 更新包含主對應的來源檔案，取代該測試的所有先前項目
4. 將變更的對應來源檔案提交到 VCS（只有相關的 CI 工作才有權限執行此動作）
5. 清除覆蓋率資料（以免將每個測試的覆蓋率報告糾纏在一起）
6. 回到 #1 進行下一個測試（最近變更的來源/測試優先？）

在一次執行所有測試後，您會有一個全面的對應，將生產程式碼連接到涵蓋它們的測試。

然後，當您稍後對某些產品程式碼進行變更時，您可以找出哪些測試執行該程式碼，因此在執行時可能會提供資訊。產生的任何測試失敗都可能證明是因變更而發生的唯一測試失敗。上述兩個概念驗證包含少量的 Python 程式碼，用於嘗試

• 計算 TIA 地圖以預先滿足需求
• 在預先整合情況下使用 TIA 地圖（稍加修改後，也可以用於 CI 作業）

HedgeServ 的測試基礎由常規快速單元測試組成，後跟整合測試，這些整合測試是 Microsoft Excel 試算表，而這些試算表又間接呼叫 Python。其中有 12,000 個。這些測試是數小時的廣泛且進階演算法測試，在沒有「執行較少測試」策略的情況下，不可能在 CI 基礎架構中逐次整合執行。他們的 DevOps 團隊將概念驗證操作化為「測試減少器」（我最初給予此技術的名稱），而最快的排列組合現在為十分鐘。這是一個極大的進步。開發人員和測試工程師可以在預先整合時執行這些測試，而 CI 基礎架構也可以執行相同的操作。HedgeServ 的軟體開發執行董事 Kevin Loo 告訴我：「開發人員依賴更快的測試執行，而由於信心增加，開發速度也因此提升。」

由於使用一般性的程式碼覆蓋率工具，因此 TIA 面向必須一次執行一個測試，這會產生前期成本。因此，分析產生的地圖會檢查到原始碼控制中並逐步更新。因此，它必須是文字，且具有順序性，以便差異可以簡潔且具有一些意義。將地圖檢查到原始碼控制中也有利於 CI 基礎架構和個別開發人員在整合（和程式碼檢閱）之前執行較少的測試。

此 TIA 設計因程式碼覆蓋率工具的性質而有其限制：一次只能執行一個測試，才能計算出準確的影響圖。為了使用對應資料，需要執行「git status」（或 git show >hash>），然後解析輸出，找出「已變更/已新增/已刪除」的製作程式碼來源。這些是影響對應的關鍵，會產生要執行的測試清單。只有資料收集 CI 工作有「一次一個測試」的限制，這也是你或多或少會認為它持續執行的緣故。

如你所見，測試技術可能與你用於製作程式碼的主要語言選擇完全不同。就 HedgeServ 的案例而言，他們的演算法測試在受原始碼控制的 Microsoft Excel 檔案中（甚至連 BA 都參與其中）。如果這樣可行，那麼 SmartBear 的 TestComplete、HP 的 Unified Functional Testing（UFT，前身為 QTP）以及 Selenium 當然也可以。唯一的需求是測試可以編寫成一次執行一個（在你建立 TIA 對應時）。在最初建立對應後，你還必須承諾定期更新對應，請使用你的 CI 基礎架構。

接著，你必須決定將對應資料儲存在哪裡。你可以選擇檔案分享、文件儲存或關聯式架構。我選擇（並建議）將文字檔案儲存在與製作來源本身位於相同儲存庫/分支的目錄中。至少這樣可以讓分支運作（無論你的分支模式為何），並讓不同的影響對應反映出程式碼不同的性質。

最近，我為一位客戶檢視一個專案，該專案使用 KDB 和 Q 作為其系統，並試著建議他們如何縮短測試時間。這些語言沒有程式碼覆蓋率技術，所以那次對話就到此結束。

VectorCAST/QA - 應用程式

NCrunch for VisualStudio