精準測試：如何判斷兩次測試中哪次的質量更好？

程式碼覆蓋率分析：
在真實的程式碼中，冗餘程式碼往往大量存在，再加上測試時間非常有限，即使使用精準測試，程式碼覆蓋率也很難達到 100%。那麼，當兩次測試的程式碼覆蓋率都未達到 100% 時，我們該如何判斷哪次測試的質量更好呢？

覆蓋率不等於質量
舉個例子：

• 第一次測試的程式碼覆蓋率是 92%，但遺漏了關鍵功能的測試，測試了很多邊邊角角的功能。
• 第二次測試的程式碼覆蓋率是 89%，雖然沒有全部覆蓋，但關鍵功能全部測試完畢。

在這個例子中，儘管第二次測試的覆蓋率（89%）低於第一次測試（92%），但測試質量顯然更高。因此，測試質量不僅取決於程式碼覆蓋率，還取決於關鍵功能部分是否測試全面。從測試工程師的角度來看，除了需求或功能說明書，他們主要靠測試案例來輔助分析關鍵功能是否測試全面。然而，測試案例的完整性和優先順序難以判斷某次測試是否覆蓋了關鍵功能。那麼，是否有辦法知道關鍵功能是否測試全面呢？答案是肯定的。

測試工程師關注點與精準測試工具

在軟體工程中，開發工程師和測試工程師的關注點有所不同。開發工程師更關注程式碼，而測試工程師則更關注測試案例。API 介面是開發和測試都熟悉的領域。如果僅提供程式碼覆蓋率，測試工程師難以判斷未覆蓋程式碼是否關鍵。僅有程式碼覆蓋率，無論是包覆蓋率、類覆蓋率、分支覆蓋率還是行覆蓋率，都無法判斷未覆蓋部分的功能是否重要。

整體程式碼覆蓋率 vs API 介面維度程式碼覆蓋率

整體程式碼覆蓋率
整體程式碼覆蓋率衡量整個程式碼庫在測試過程中被執行的比例，包括所有模組、類、函式和程式碼行。它提供了一個宏觀視角，幫助瞭解整個專案的測試覆蓋情況。
覆蓋率型別：

1. 包覆蓋率：每個包（或模組）中的程式碼被測試覆蓋的比例。
2. 類覆蓋率：每個類中的程式碼被測試覆蓋的比例。
3. 分支覆蓋率：條件語句（如 if/else）的每個分支被執行的比例。
4. 程式碼行覆蓋率：實際被執行的程式碼行數佔總程式碼行數的比例。

優點：

• 提供全面的覆蓋率資訊。

缺點：

• 無法透過整體程式碼覆蓋率知曉特定功能或介面 API 的深度分析。

API 介面維度的程式碼覆蓋率
API 介面維度的程式碼覆蓋率提供了 API 介面維度的程式碼覆蓋情況，專門針對 API 相關的程式碼路徑，評估 API 在測試過程中呼叫的程式碼覆蓋情況。
覆蓋率型別：

1. API 介面的分支覆蓋率：API 請求中的條件語句每個分支被執行的比例。
2. API 介面的程式碼行覆蓋率：API 請求涉及的程式碼行數被執行的比例。

優點：

• 專注於 API 層，透過識別 API 介面的優先順序，間接獲得關鍵功能的測試情況。
• 有助於發現 API 特定路徑的測試盲點和薄弱點。
• 適用於微服務架構或基於 API 介面的應用程式。

缺點：

• 實現難度遠高於整體程式碼覆蓋率。

基於 API 介面的程式碼覆蓋率與漏測點分析
透過基於 API 介面的程式碼覆蓋率和漏測點/漏測原因分析，我們可以間接得到關鍵功能的測試情況。只要同步了 API 介面的優先等級，即可間接瞭解關鍵功能的測試情況。下面是我們實現的基於 API 介面的程式碼覆蓋率和漏測原因分析介面。

實現方法
我們有兩種方式可以實現 API 介面的程式碼覆蓋率：

1. 鏈路分析方法：基於自動鏈路跟蹤，在請求時自動新增 Trace 資訊，根據 Trace Id 關聯請求穿透的程式碼（請參考 Google 的論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》）。
2. 靜態呼叫鏈路分析：Java 透過原始碼或位元組碼進行靜態呼叫鏈路分析，涉及分析程式碼中的方法呼叫並構建方法呼叫圖。這種分析通常不需要執行時資料。 兩種方法各有不足，在實際應用中可以考慮將它們結合起來，取長補短。

上海復深藍精準測試產品 TestForce/複測高手 ( www.fucegaoshou.com ) 出品