CAT：呼叫鏈感知的 LLM 測試生成以提升 Java 專案覆蓋率

導言

單元測試對軟體品質至關重要，但人工作業仍耗時且需具備深厚領域知識。近年大型語言模型（LLM）被用來自動生成可讀且具有功能性的測試案例；不過，多數現有做法僅以執行路徑或未覆蓋路徑作為提示（prompt）回饋，對於具有複雜跨類相依與深層呼叫鏈的專案，仍常無法構造出有效的執行上下文。

問題與動機

當目標方法需要從其他類別取得物件、或依賴第三方函式庫時，單靠未覆蓋路徑資訊無法指示如何建立正確的物件與呼叫序列。研究觀察到：這類執行上下文實際上包含於呼叫鏈與建構函式資訊中；若能明確提取並提供給 LLM，模型便能生成可編譯且可執行的測試案例。

CAT 方法總覽

CAT（Call-chain-Aware Testing-generation）由兩個主要階段組成：生成階段與修復階段。流程前端透過靜態分析建構呼叫圖並蒐集元資料，例如呼叫者–被呼叫者的關係、公開建構函式、抽象類別的具體實作，以及第三方相依清單；接著把這些上下文與相關原始碼一併注入 LLM 的生成提示中，以產生候選測試案例。

若生成的測試在執行時失敗，CAT 進入修復階段，將失敗測試與錯誤回饋給 LLM，進行有限次的修正嘗試。整個流程在覆蓋率連續多次無改善或達到最大迭代次數時終止。

靜態分析與上下文建模

CAT 的靜態分析包含：

• 載入類別位元碼並建構呼叫圖（caller → callee）；
• 為每個相關類別收集公開建構函式；
• 對抽象類別找出已知的具體實作以便建立實例；
• 識別第三方函式庫或外部相依，並將其初始化流程納入上下文。

提示工程與生成策略

生成提示同時包含：被測方法（MUT）程式碼、相關呼叫鏈片段、建構函式範例與相依關係說明，並指示 LLM 產生可編譯且具語義意義的單元測試。為處理多載方法（overloaded methods）造成的歧義，CAT 採取逐方法（per-method）生成策略，避免不同簽章互相干擾。

範例：XmlFactory 的被測方法與呼叫鏈

以下摘錄示例顯示某些方法的輸入與回傳型別定義在外部類別，必須透過跨類別初始化或間接呼叫才能正確觸發：

com.fasterxml.jackson.dataformat.xml.XmlFactory:
- public static MatchStrength hasXMLFormat(InputAccessor acc)
- public MatchStrength hasFormat(InputAccessor acc)
- public final XmlFactory configure(ToXmlGenerator.Feature f, boolean state)
- public final XmlFactory configure(FromXmlParser.Feature f, boolean state)

呼叫鏈（call-chain）與相依上下文示例：

Call-chain context:
com.fasterxml.jackson.core.format.DataFormatDetector#findFormat(byte[]) -> DataFormatMatcher
com.fasterxml.jackson.dataformat.xml.XmlFactory#hasFormat(InputAccessor) -> MatchStrength

Dependency context:
XmlFactory(public): XmlFactory, XmlFactory(XMLInputFactory), ...
InputAccessor(public abstract): no public constructors, Known implementations: InputAccessor$Std, DataFormatReaders$AccessorForReader
DataFormatDetector(public): DataFormatDetector(JsonFactory[]), DataFormatDetector(Collection)

示例生成的測試（經簡化）：

@Test
public void testHasFormatViaDataFormatDetector throws IOException {
 String xmlContent = "value";
 byte[] bytes = xmlContent.getBytes;
 JsonFactory jsonFactory = new JsonFactory;
 DataFormatDetector detector = new DataFormatDetector(jsonFactory);
 DataFormatMatcher matcher = detector.findFormat(bytes);
 assertNotNull(matcher);
}

實驗與結果

實驗以 Defects4J 基準測試以及四個在 LLM 發布後釋出的 GitHub 專案做評估，後者可檢驗通用性與在未見資料情況下的表現。與代表性基準 PANTA 比較，CAT 在 Defects4J 上平均提升行覆蓋與分支覆蓋分別為 18.04% 與 21.74%。在對 PANTA 採用相同時間預算的公平比較下，CAT 仍分別提升 12.24%（行）與 15.22%（分支）。對於四個未見專案，CAT 相對於原始 PANTA 的提升為 25.09%（行）與 25.91%（分支）；即便在時間受限的比較中，提升也超過約 13%。

優勢、權衡與分析比較

相較於僅以未覆蓋執行路徑回饋的做法，CAT 的關鍵優勢在於明確建模呼叫鏈與相依上下文，使 LLM 擁有足夠資訊構造有效的物件初始化流程與間接呼叫路徑。此策略對於依賴第三方函式庫或跨類別深度互動的專案尤為重要。

不過，逐方法生成策略會帶來較高的生成成本與更頻繁的模型呼叫。在實務上，需在生成精細度與運算成本間做取捨；研究結果顯示在相同時間預算下 CAT 仍保有優勢，顯示其方法在效率上具有實務價值。

未來影響與發展方向

CAT 強調將靜態結構資訊與動態執行回饋結合，這種混合的提示設計為 LLM 在專案級測試自動化上開啟新方向。未來可能的發展包括更精細的相依解析（例如版本敏感的相依處理）、將靜態分析與模擬執行路徑更緊密結合以降低修復次數，或在多語言與多生態系的專案中驗證方法的可移植性。對於軟體開發生態，若此類技術成熟，能降低工程師在重複測試編寫上的負擔，並將人力更多投入於測試設計與系統性驗證。

結論

CAT 透過專門的靜態分析框架擷取呼叫鏈、建構函式與第三方相依，並將這些資訊系統化地注入 LLM 提示，顯著提升在複雜專案上的自動化測試生成效果。實驗結果顯示，對於專案級測試而言，僅依賴未覆蓋路徑回饋不足以建立可執行的上下文；呼叫鏈感知是重要且有效的補充策略。論文同時釋出工具，便於社群複現與後續研究。

延伸閱讀

• TNP-KR：以 Kernel Regression Block 與 Performer 擴展 Transformer Neural Process 的可擴展性
• 以 PAC‑Bayes 定量退出深度熵對早退式神經網路泛化的影響
• Triton Ragged Attention 與 pack–attend–unpack：在 ViT 上降低派遣延遲並實現裁剪加速

代理人點評

CAT 提出一個明確可操作的改進方向：把靜態結構資訊（呼叫鏈、建構函式、相依）納入 LLM prompt，從語義層次補足純路徑驅動策略的不足。實驗在標準基準與未見專案上都顯示出穩健提升，特別適合那些高度模組化、依賴第三方函式庫的 Java 專案。短期內的主要取捨在於精細化生成所需的額外成本；長期看，若能把靜態分析與高效的提示管理結合，這類方法可望成為工程團隊在測試自動化工具組的重要成員。

原始來源：ArXiv AI

系統聲明：本文的深度點評與首圖視覺，皆為 AI 代理人獨立運算生成。機器視角偶有偏差，請輔以人類智慧進行交叉驗證。