生產系統中的每一次變更都會產生超出變更組件範圍的影響。例如，對共享函數的修改會破壞依賴其先前行為的呼叫者。資料庫模式的變更會悄無聲息地使所有引用已更改列的查詢失效。 COBOL 程式碼庫的更新需要重新編譯所有包含它的程序，其範圍可能涵蓋數十個作業流程中的數百個程序，所有這些程序都需要在生產環境切換之前進行測試。影響分析所要解答的問題並非變更是否會產生影響，而是究竟哪些元件會受到影響，它們與變更元素之間有何關聯，以及在安全部署變更之前必須進行哪些全面的驗證。
如果沒有影響分析，這個問題只能靠猜測來解答：詢問做出更改的開發人員、運行完整的測試套件並寄希望於故障集中在正確的位置，或者在用戶報告故障後部署並發現受影響的組件。影響分析工具用結構化的證據取代了猜測：它們解析原始程式碼、映射依賴關係，並產生建議變更將影響的每個元件的枚舉清單。本指南涵蓋的工具包括靜態分析平台、測試選擇引擎和企業依賴關係映射器，每種工具都涵蓋了影響分析問題的不同面向。
軟體工程中的影響分析是什麼？
軟體工程中的影響分析是指識別系統中所有直接或間接受到建議變更影響的組件的過程。它回答的問題是：如果我更改此元件，還有哪些元件會變更？影響分析在實施之前進行，即在規劃、設計和變更審批階段，而不是在事後測試或事件回應階段。
這個術語涵蓋幾個相關但不同的活動，這些活動在分析的內容和時間上有所不同：
變更影響分析用於在實施程式碼變更之前確定其範圍。它能辨識出哪些模組、函數、資料庫表和依賴系統會因建議的變更而需要修改或重新測試。
測試影響分析 (TIA)是變更影響分析的特定應用，它用於識別哪些現有測試與給定的程式碼變更相關。 TIA 不會運行整個測試套件，而是選擇覆蓋變更程式碼及其相依性的最小測試子集，從而在保持對受影響範圍覆蓋的同時，減少測試執行時間。
需求影響分析用於識別需求變更時哪些需求、設計元素和下游交付物會受到影響。在受監管行業中，這可以確保所有依賴變更需求的下游工件都已更新和重新驗證。
這三者都具有共同的基礎：一個表示組件之間相互關係的依賴模型，以及一個從起點（已更改的組件）遍歷該模型以枚舉其可達所有內容的機制。
影響分析的三種類型
影響分析技術根據其收集依賴關係資訊的方式進行分類：
| 類型 | 選項 | 它發現了什麼 | 何時使用 |
|---|---|---|---|
| 靜態衝擊分析 | 解析原始碼而不執行它 | 所有語法引用：函數呼叫、匯入、欄位存取、模式引用 | 在實施之前，變更規劃期間；適用於任何程式碼庫 |
| 動態影響分析 | 使用儀器運行程式碼以觀察實際執行路徑 | 僅在測試運行期間實際運行的組件 | 運行時特定依賴項；識別靜態分析可能遺漏的路徑。 |
| 基於需求的（語意） | 追蹤需求、設計和程式碼之間的可追溯性鏈接 | 受需求變更影響的上游和下游工件 | 受監管產業；系統工程；安全關鍵型軟體 |
靜態影響分析應用最為廣泛，因為它僅針對原始程式碼進行操作，無需運行中的系統或測試基礎設施。本指南中的工具以及其他相關技術均採用此方法。 SMART TS XL 用於企業程式碼庫分析。動態分析是靜態分析的補充，它能夠捕獲運行時行為，例如動態構建的查詢或後期綁定的函數調用，而這些行為僅憑原始程式碼無法解析。實際上，大多數生產影響分析程序都會將兩者結合起來：靜態分析提供基線依賴關係圖，而動態分析則根據觀察到的運行時行為進行驗證。
靜態衝擊分析與動態衝擊分析：主要差異
靜態影響分析較為保守：它可能會高估受影響的範圍，因為它包含了程式碼中存在但實際上從未執行過的依賴項。動態影響分析對於其觀察到的內容而言非常精確，但並不完整，它僅捕獲在檢測會話期間實際運行的內容，而遺漏了在不同輸入或配置下執行的路徑。對於生產系統而言，完整性比精確性更重要，因此靜態分析是更安全的預設選擇。
影響分析流程：逐步指南
結構化的影響分析流程遵循一致的步驟，與所使用的工具無關：
第一步：定義變更。明確指出要變更的具體內容：是具體的函數、欄位、類別、模組、副本或資料庫列。這一步驟的精確性決定了後續所有步驟的準確性。模糊的變更定義（例如「我們正在修改支付模組」）會導致影響評估結果也模糊不清。
步驟 2：建置或查詢依賴關係模型。依賴關係模型表示系統中所有組件之間的關係。對於自動化工具，該模型透過解析原始程式碼建構。對於小型系統的手動分析，可以將其作為文件進行維護。此模型必須保持最新：過時的依賴關係文件會導致影響評估不準確。
步驟 3：從變更點遍歷依賴關係圖。從變更元件開始，追蹤所有入依賴邊（依賴變更元件的元件）和出依賴邊（變更元件所依賴的元件，這些元件在變更後可能會表現不同）。以傳遞的方式繼續，直到枚舉出所有可達的依賴元件。
步驟 4：依風險對受影響組件進行分類。並非所有受影響組件的風險都相同。直接呼叫已更改函數的元件比相隔五個依賴等級的元件風險更高。根據鄰近性、嚴重性和測試覆蓋率對發現的問題進行分類，以便集中修復工作。
步驟 5：定義測試範圍。影響集（即受影響組件的完整清單）定義了最小測試範圍。影響集中任何缺少自動化測試覆蓋的組件都代表著風險，必須透過添加測試或手動驗證來解決。
步驟 6：記錄和審查。將影響評估報告提交給變更諮詢委員會 (CAB) 或相關利害關係人，作為變更批准的依據。列舉的影響範圍及風險分類以結構性證據取代了開發商的估算。
測試影響分析：它在 CI/CD 中的工作原理
測試影響分析 (TIA) 將影響分析專門應用於測試問題：給定程式碼變更，需要執行哪些測試？如果沒有 TIA，持續整合 (CI) 管線會在每次提交時執行完整的測試套件。在一個包含 50,000 個測試且測試套件運行時間為 45 分鐘的程式碼庫中，這意味著每個拉取請求都會阻塞 45 分鐘，這就是為什麼開發人員會繞過它，在不等待結果的情況下推送多個提交，從而失去測試本應提供的反饋循環。
TIA 透過追蹤程式碼和測試之間的映射關係來解決這個問題：哪些程式碼行被哪些測試覆蓋。當提交更改了特定程式碼行時，TIA 只選擇覆蓋這些程式碼行及其相依性的測試。例如，如果更改涉及 50,000 個文件中的 3 個，則可能只需要 200 個測試，而不是 50,000 個。流水線的運行時間也從幾分鐘縮短到了幾秒鐘。
此映射是透過對測試執行進行插樁來記錄覆蓋率數據，然後將這些覆蓋率數據按其覆蓋的程式碼進行索引來建構的。每次提交新程式碼時，TIA：
- 識別哪些檔案和函數發生了變更（來自 git diff）
- 尋找哪些測試涵蓋了這些文件和函數
- 新增測試，以覆寫已變更程式碼的靜態依賴關係圖中的任何元件。
- 運行選定的子集；其餘測試全部通過，假定未受影響。
支援測試影響分析 (TIA) 的工具包括 Microsoft Visual Studio 中的測試影響分析、Parasoft 的 TIA 引擎、Gradle 的測試選擇功能，以及多個整合在 CI 中的 Jest、pytest 和其他測試運行器的插件。 TIA 的準確性取決於依賴模型的準確性。如果工具僅追蹤直接程式碼覆蓋率而不遍歷依賴關係，則會遺漏覆蓋距離變更點三層之隔的元件的測試。
TIA實踐：前後對比
在典型的企業後端服務中，啟用 TIA 可以將平均每個拉取請求的測試執行時間縮短 60-80%。但缺點是，對於涉及共享工具、基類或廣泛使用的配置等非常大的變更，仍然可能觸發大量的測試子集。 TIA 最適用於變更局部化的功能開發和錯誤修復。對於框架升級或共享模式修改等跨領域變更，執行完整的測試仍然是更穩健的選擇。
需求和變更管理中的影響分析
在系統工程和受監管軟體開發中，影響分析的範圍不僅限於程式碼，還包括整個工件鏈：需求、設計規格、測試案例、風險評估和驗證證據。需求變更不僅影響程式碼，還會影響實現該需求的每個設計元素、驗證該需求的每個測試案例、基於該需求的每個風險評估，以及引用該需求的每個合規性文件。
基於需求的分析利用可追溯性連結來列舉下游範圍。可追溯性矩陣將每個需求與其實現的設計元素、測試案例和驗證證據連接起來，從而可以確定任何需求變更所需的重新驗證的完整範圍。在受監管的行業中，例如受 FDA 21 CFR Part 11 監管的醫療器材、受 DO-178C 監管的航空軟體以及受 ISO 26262 監管的汽車軟體，這種重新驗證範圍是監管要求，而非可選的品質實踐。
需求影響分析與程式碼影響分析之間的關聯在於可追溯性：當需求追溯到特定的軟體元件，並且該元件在程式碼層級影響分析中被識別出來時，影響分析結果可用於將重新驗證工作集中在驗證該元件的特定測試案例上。包括 Jama Connect 和 IBM DOORS 在內的現代需求管理平台支援這種可追溯性，並在需求層級提供內建的影響分析功能。
大型遺留程式碼庫的影響分析
大型程式碼庫（尤其是歷經數十年發展而來的企業系統）的影響分析與僅有 10,000 萬行程式碼的服務的影響分析有著本質差異。這種規模差異不僅體現在數量上。大型遺留程式碼庫的依賴關係結構複雜，任何團隊成員都很難完全理解：成千上萬個程式透過共享資料集進行隱式耦合，數百個程式同時包含相同的副本，以及包含複雜條件執行邏輯的 JCL 作業流，這些邏輯會創建僅在運行時才會產生的依賴關係。
大型程式碼庫的幾個特點使得人工影響分析變得不可靠：
隱式依賴。在 COBOL 系統中，一個被 300 個程式包含的副本檔案會造成一種依賴關係，這種依賴關係對於任何不了解它的開發人員來說都是不可見的。對副本檔案中某個成員的變更（看起來像是欄位重新命名）可能需要重新編譯和重新測試所有 300 個程式。如果沒有自動化分析，這種依賴關係的影響範圍會逐步顯現，每次出現新的故障都會揭示另一個被忽略的依賴關係。
跨語言依賴關係。一個 COBOL 程式寫入 DB2 表。一個 Java 服務從同一張表中讀取資料。一個 Python 管道處理 Java 服務的輸出。 DB2 模式的任何變更都會影響所有這三個層。任何單一語言的靜態分析工具都無法追蹤這種跨語言依賴鏈；它需要一種能夠理解並將所有三種語言連接起來，形成統一依賴模型的工具。
透過數據產生的間接依賴關係。兩個從未相互調用的程式仍然可能透過共享檔案相互耦合。程式 A 寫入資料集 X；程式 B 從資料集 X 讀取資料。資料集 X 的佈局變更會影響兩者，但這種依賴關係並非函數調用，而是透過 JCL DD 語句和 COBOL FD 定義表達的資料契約。僅追蹤函數呼叫的結構分析完全忽略了此類依賴關係。
死代碼和可達性。大型程式碼庫會累積大量已定義但從未呼叫的程式碼、已移除功能遺留的函數以及已被取代但未被刪除的預存程序。如果影響分析將死程式碼也納入受影響範圍，則會高估變更範圍，並將測試工作浪費在生產環境中永遠不會被呼叫的元件上。
針對這些環境的遺留系統現代化分析解決方案必須處理所有這些情況：它必須解析實際使用的語言（包括 COBOL、JCL、PL/I、RPG、彙編語言和 DB2），透過共享資料結構解析隱式依賴關係，追蹤跨語言鏈，並區分可達程式碼和不可達程式碼。
影響分析工具：它們之間的比較
以下工具涵蓋了軟體開發中影響分析的主要類別。每種工具都根據其分析內容、支援的語言以及最擅長解決的影響分析問題類型進行評估。
| 工具 | 主要方法 | 語言 | 最適合 |
|---|---|---|---|
| SMART TS XL | 靜態 + 跨語言依賴關係映射 | COBOL、JCL、Java、Python、.NET、RPG、SQL | 企業及大型主機多語言影響分析 |
| 透過 SciTools 理解 | 靜態分析、呼叫圖、依賴關係視覺化 | 超過70種語言 | 多語言代碼理解和影響集 |
| 結構101 | 架構分析、相依性圖 | Java、C#、JVM/.NET | Java/C# 企業應用程式的結構性影響 |
| 演員 AIP | 應用智能、技術債、影響 | Java、.NET、COBOL、SQL | 投資組合層面的業務與技術影響分析 |
| Axivion 套件 | C/C++的語意依賴圖 | C，C ++ | 安全關鍵系統、MISRA合規性、嵌入式 |
| 帕拉軟體 | 測試影響分析、CI/CD 集成 | Java、C/C++、.NET | TIA 在受監管行業和安全關鍵測試中的應用 |
| Jama Connect | 需求可追溯性、工件影響 | 與語言無關（需求層次） | 系統工程、受監管產業、DO-178C/ISO 26262 |
| 聲納 | 程式碼質量，語言內部的依賴分析 | 超過30種語言 | 代碼品質門禁；有限的跨系統影響分析 |
| IntelliJ IDEA / Eclipse | IDE呼叫層次結構、引用分析 | Java、Kotlin、Python | 專案內部的開發商層面在地影響分析 |
Understand by SciTools是針對使用現代程式語言的軟體團隊的最全面的專用影響分析工具。其影響集功能可計算受特定變更影響的所有程式碼實體的傳遞閉包，包括從起始點透過依賴關係圖可達的每個函數、類別和變數。它支援 70 多種語言，並產生詳細的呼叫圖、資料流程圖和實體關係圖。
Structure101是用於 Java 和 C# 架構層級影響分析的最強大工具。它以互動式地圖的形式視覺化套件和類別依賴關係結構，並識別出擬議變更中哪些地方違反了架構邊界，或在依賴關係圖中創建了新的循環。
CAST AIP在投資組合層面運行，分析包括 COBOL、Java、.NET、SQL 和其他語言在內的完整應用環境，在進行技術影響分析的同時，產生業務影響評分。它常用於併購盡職調查和投資組合優化項目。
Axivion Suite針對安全關鍵型 C 和 C++ 開發，其中影響分析必須滿足監管要求（ISO 26262、DO-178C、MISRA），並產生分析完整性的正式證據。
Parasoft是受監管行業最強大的 TIA 解決方案，它整合了 CI/CD 測試選擇引擎，可以追蹤語句層級的覆蓋率，並根據精確的依賴關係遍歷選擇測試子集。
SonarQube提供專案內部依賴關係分析和程式碼異味偵測，但並非設計用於跨系統或跨語言的影響分析。它在影響分析系統中的價值在於作為品質門控，識別哪些變更的組件引入了新的品質或安全問題，而不是作為依賴關係映射器。
基於整合開發環境 ( IDE) 的工具（例如 IntelliJ 呼叫層次結構、Visual Studio 引用分析、Eclipse 呼叫圖）提供開發人員的本機專案影響分析。它們能夠有效地了解變更對模組的影響，但無法追蹤跨專案、跨語言或大型主機依賴關係。
SMART TS XL 進行影響分析
SMART TS XL 透過解析環境中的每個原始檔案（包括 COBOL 程式、JCL 作業流程、副本、SQL 模式、Java 類別、Python 模組、RPG 程式等），並建立一個統一的依賴關係模型來執行影響分析。此模型表示所有語言之間的所有結構關係。影響分析的基礎是針對此模型的查詢，從任意元件開始，遍歷依賴關係圖，列舉所有受影響的內容。
當一個團隊提議更改 COBOL 副本簿成員時， SMART TS XL“ 影響分析 答案：哪些程式包含此副本？在這些程式中，哪些由哪些 JCL 作業步驟呼叫？這些程式讀取或寫入哪些 DB2 表？哪些 Java 服務使用這些表格？哪些測試用例涵蓋了這些程序？答案並非估算值，而是一個完整的列舉列表，它基於實際程式碼結構，包含檔案名稱、程式名稱、作業名稱和行號。
應用程式依賴關係映射功能會產生以變更元件為中心的依賴關係圖，並使用顏色編碼來區分直接依賴和間接依賴，同時突出顯示風險最高的連結。這些圖表既可作為變更諮詢委員會 (CAB) 審查的證據基礎，也可作為測試計畫的路線圖。
JCL擴展功能會在分析之前解析 PROC 中的符號參數替換，從而確保依賴模型反映的是實際的運行時執行情況，而不是未解析的模板引用。對於根據符號參數呼叫不同程序的 PROC，JCL 會解析為其所有呼叫者實際呼叫的所有程序，從而實現符號感知工具無法覆蓋的完整覆蓋範圍。
對於進行技術盡職調查、規劃遺留系統現代化改造或管理跨多種語言和平台系統變更的企業團隊而言， SMART TS XL“ 企業搜索 此功能使依賴模型可查詢：在幾秒鐘內，可以在任何大小的程式碼庫中找到特定欄位的每次使用、呼叫特定函數的每個程式、產生特定資料集的每個 JCL 作業。
影響分析最佳實踐
影響分析應該在編寫程式碼之前進行，而不是之後。影響分析的目的是為變更決策提供依據，並確定後續工作的範圍，而不是在部署後解釋哪裡出了問題。在變更進行過程中才進行的影響評估是事後解釋，而不是規劃工具。
明確定義影響評估的邊界。大型系統的影響圖可能幾乎涵蓋所有內容。在執行分析之前，必須定義分析邊界、最大依賴深度、排除的無效程式碼以及超出範圍的系統。無約束的遍歷會產生技術上正確但實際操作中毫無用處的結果。
區分必須重新測試和應該監控的問題。並非影響集中的每個組件都需要相同的測試響應。直接呼叫熱路徑中已更改函數的元件必須重新測試。透過五層很少執行的程式碼到達已更改函數的元件可以在生產環境中進行監控。風險分類可以將影響清單轉換為測試計劃。
保持依賴模型最新。基於過時或不完整的依賴模型進行的影響分析比不進行影響分析更糟糕，因為它會讓人對錯誤的範圍產生錯誤的信心。每次程式碼庫發生重大變更時，都必須重新產生依賴模型，或透過 CI/CD 整合進行增量更新，該整合會自動重新分析已變更的檔案。
將影響分析與變更控制結合。只有當影響分析的輸出結果能夠納入正式的變更控制流程時，其價值才能充分體現。一份記錄範圍、風險分類和測試要求的變更報告，能夠為變更諮詢委員會提供必要的結構性證據，使其能夠基於實際系統而非開發人員的估算做出授權決策。
對於遺留系統，必須考慮隱式資料耦合。任何僅追蹤函數呼叫的遺留系統依賴性分析都是不完整的。在大型主機環境中，程式之間透過共用檔案、資料集、資料庫和訊息佇列進行耦合的情況很常見，而這些耦合對於僅基於函數呼叫的分析來說是不可見的。依賴性模型必須考慮資料級耦合，才能得出完整的影響範圍。
對影響分析基礎設施的投資，無論是透過專門的工具，例如 SMART TS XL例如，像 Parasoft 這樣的測試影響分析引擎，或者像 Jama 這樣的需求追溯平台，其成本可以透過那些未導致意外故障的變更、無需運行完整測試套件的測試以及未引發事故的部署來彌補。這種彌補並非假設。每一個由未偵測到的依賴項導致的生產事故，都是在變更發生前未進行分析的直接成本。
