精準測試之覆蓋

原創：前京東工業 宛煜昕

程式碼覆蓋率測試與測試覆蓋率在軟體工程中，存在著對程式碼覆蓋測試和測試覆蓋測試的混淆。

•程式碼覆蓋測試是一種軟體測試技術，用於衡量在執行測試時程式原始碼中有多少被執行。這意味著程式碼覆蓋測試衡量了程式原始碼被測試的程度，它提供了關於測試期間哪些原始碼元件被執行以及哪些部分沒有被執行的詳細資訊。程式碼覆蓋測試應該與測試覆蓋測試區分開來，並且不應該互換使用。
•測試覆蓋率是軟體測試過程中執行的測試用例所覆蓋的程式碼和功能需求等比例程度。測試覆蓋率測試是一種定量的測試方法，用於衡量測試用例對被測試軟體的覆蓋程度。它通常由質量保證團隊執行，以確保測試已覆蓋多個規格文件，如功能需求規格、軟體需求規格和使用者需求規格等。與程式碼覆蓋測試相比，測試覆蓋率測試更加關注軟體功能需求的覆蓋程度，而不是程式碼執行的覆蓋程度。
下面是程式碼覆蓋和測試覆蓋之間的關鍵區別：

是一種定量的度量方式 它在大多數情況下是定性的。
是一種白盒測試方法，測試人員檢查和驗證軟體系統的內部工作方式，尤其是程式碼及其整合 是一種黑盒測試方法，測試軟體的功能，不知道軟體程式碼的內部結構及其實現方式。
一、覆蓋率與測試策略
測試策略按測試過程一般分為單元測試、整合測試、系統測試和驗收測試四大階段；按軟體內部工作過程又有白盒、灰盒、黑盒；從過程是否執行軟體又可將測試方法分為靜態和動態。這樣白盒測試對應著軟體測試過程中的單元測試，一般由開發人員完成，而灰盒測試與黑盒測試一般測試人員介入較多，對應著整合測試、系統測試和驗收測試。
•程式碼覆蓋率的測試策略主要包括：
1、選擇合適的覆蓋率標準：常見的覆蓋率標準有語句覆蓋率、分支覆蓋率、條件覆蓋率、路徑覆蓋率等，需要根據軟體測試的需求和目標選擇合適的覆蓋率標準。
2、制定測試計劃：制定測試計劃是評估程式碼覆蓋率的前提，測試計劃需要根據需求文件、功能規格說明等，設計測試用例。
3、設計測試用例：針對不同的覆蓋率標準，設計不同的測試用例，以達到對目的碼進行覆蓋的目的。
4、執行測試用例：執行設計好的測試用例，記錄測試結果。
5、計算覆蓋率：使用相應的工具對目的碼進行覆蓋率計算，得出程式碼覆蓋率並進行分析。
程式碼覆蓋率的測試策略主要是確保測試能夠覆蓋程式碼的所有執行路徑和分支，以此來保證程式碼的正確性和可靠性。其中，包括以下幾個方面：
1、語句覆蓋：確保每一條程式碼語句都被測試至少執行一次。
2、分支覆蓋：確保每個條件語句的每個分支都被測試至少執行一次。
3、條件覆蓋：確保每個條件語句的每個條件都被測試至少執行一次，包括 true 和 false。
4、路徑覆蓋：確保程式碼中每個可能的執行路徑都被測試至少執行一次，包括迴圈和遞迴等。
•測試覆蓋率的測試策略主要包括：
1、定義測試目標：根據軟體需求和設計文件，明確測試目標，確定需要覆蓋的測試區域、度量，可以基於需求、功能規格說明、用例等不同的基礎上進行度量，需要根據專案實際情況確定測試覆蓋率的度量方法。
2、制定測試計劃：制定測試計劃是評估測試覆蓋率的前提，測試計劃需要根據需求文件、功能規格說明等，設計測試用例。
3、設計測試用例：設計覆蓋測試目標的測試用例，確保每個測試點都能被覆蓋。
4、執行測試用例：執行設計好的測試用例，記錄測試結果。
5、收集和計算測試覆蓋率：收集測試覆蓋率資料，使用相應的工具對測試目標進行覆蓋率計算，得出測試覆蓋率並進行分析，找出測試覆蓋率低的地方，進行補充測試。
測試覆蓋率的測試策略則是確保測試能夠覆蓋所有的需求和功能點，以此來保證軟體的功能完整性和一致性。其中，包括以下幾個方面：
1、需求覆蓋：確保每個需求都被測試至少一次。
2、功能覆蓋：確保每個功能點都被測試至少一次，包括各種輸入、輸出、錯誤處理等。
3、介面覆蓋：確保軟體的各個介面都被測試至少一次，包括與其他系統的互動等。
4、效能覆蓋：確保軟體在各種負載和條件下的效能都被測試至少一次，包括併發、響應時間、資源利用等。

二、覆蓋率的基本應用
•使用程式碼覆蓋測試的好處是可以高效且具體的程式碼檢查，並有高質量程式碼，還能提高程式碼的清晰度和信任度。
這裡有一些不錯的技巧，如：使用自動化程式碼覆蓋率測量工具，使用自動化單元測試生成工具，編寫全面的測試用例，編寫優先測試，定期審查程式碼覆蓋率結果，將程式碼覆蓋測試整合到軟體開發週期中，注意邊界情況，持續重構程式碼。
而一些"陷阱"需要注意，如：視角不足，較高的時間成本，解釋的挑戰。
•下面主要說下使用測試覆蓋測試，
在測試時會有這樣一些擔心，如：無止境的、沒有範圍的，程式碼的改動或調整一個需求，需要全量回歸測試，程式碼中的呼叫、業務間、功能模組間的關聯關係、影響範圍不清楚，某個功能或功能點是否需要測試，測試的進展、程度如何等等的問題。
舉個例子：需求是查詢 id 與展示 id 相關資料的功能，進一步分析要做（開發）id 輸入框，【查詢】按鈕，顯示的列表，涉及 1 個查詢介面（HTTP），查庫（資料庫）的話，需要 1 條 SQL 語句。
開發後得到前端 id 輸入框，【查詢】按鈕和結果列表，

後端是透過一個查詢方法調到資料庫得到資料，顯示在前端頁面。

應用測試覆蓋率
1、建立測試範圍，這裡簡單些了，只是功能的，

2、需求分析、用例設計、執行、提 bug 等，就是執行測試的過程，
3、得到功能測試的結果。

這麼看上去沒什麼問題，雙相的追溯（需求、用例、缺陷）已經是全覆蓋了，那怕在算上介面，但也僅僅是功能上的覆蓋，可能部分邏輯會有遺漏，如：程式碼等層面上的覆蓋，
程式碼中要有對查詢 id 的判斷，可能部分判斷會有遺漏，因為僅從功能或黑盒測試來講，不知道這個判斷是否執行。
這時測試覆蓋是要由測試需求和測試用例的覆蓋或已執行程式碼的覆蓋表示。建立在對測試結果的評估和對測試過程中確定的變更請求（缺陷）的分析的基礎上。
•改善這一情況，結合程式碼覆蓋率工具，
在"2、需求分析、用例設計、執行、提 bug 等，就是執行測試的過程"中加入，彌補這一缺失，覆蓋率的表格也需要最佳化下，

表格中類名、方法名的覆蓋率結果可根據情況得出，如：覆蓋率的計算由淺入深來說一般從功能、功能點、介面、程式碼中類、方法等得到，如：兩個功能、三個功能點，以功能點為覆蓋，覆蓋率公式為（至少執行一次的功能點 / 功能點總數）* 100% = (1 / 1)*100%，查詢按鈕的覆蓋率為 100%
注：測試結果是否透過，不單是看覆蓋率，還要透過測試用例的執行，缺陷的關閉等情況來決定。

三、覆蓋率的視覺化
透過完全手工繪製已經有了初步概念，考慮些許情況，這種已經不能滿足於此。
面對複雜的業務系統，經驗已經把業務功能、邏輯關係等相關知識點深深的印在當事人的腦子裡，而要沉澱、展示於旁人，這就是一個讓人很頭疼的問題，就像告訴一個人從哪裡到哪裡一樣，講的人清楚，但聽得人卻有些一頭霧水，此時如果有個地圖就一目瞭然了。

透過一些維度的圖形展示，誰都可以直觀、更好的加深對系統的瞭解。"知識庫"中儲存著涉及到的功能、介面等資訊。簡單實現，現在有了共享表格，可以直接維護上去，形式是哪種並不重要，主要是掌握了方法。
•鏈路關係
像這樣，業務系統 - 頁面 - 功能 - 介面 - 程式碼（拓撲圖），業務系統 - 頁面 - 功能 - 介面 - 架構（拓撲圖）。

·功能層面
實現方式上比如可以像檔案目錄那樣實現一顆樹，某個頁面下有哪些功能，功能中有哪些介面，而介面中有程式碼的類、方法及覆蓋率等資訊。

或者可以採用類似知識圖譜來構建一個結構化的語義知識庫，頁面、功能、介面資訊，可視為實體 - 節點，而彼此間的關係既是連線的線。或者介面資訊也可看做是屬性值。

·程式碼關係呼叫層面
從介面下去就到了程式碼層面，可以看到某介面發起後，程式碼中各方法間的呼叫鏈路和其他資料分析結果，

這裡不僅能看到單個介面中程式碼關係圖，還能展示出不同的多個介面與程式碼的關聯關係，

當關注到程式碼層面的覆蓋後，好處很多，其中有可以更好幫助開發提高或約束程式碼質量，問題的定位找到等，比如：程式碼中有時判斷會使用常量，而不是列舉或宏/全域性變數。當然也可以看到執行的程式碼分支、關係，每條程式碼邏輯分支是否執行到等。
·應用/服務間呼叫層面
透過平臺獲取到的資料，不僅可以做功能、程式碼層面的覆蓋，系統架構也可完成視覺化的呈現，
比如：應用服務的環境模組拓撲圖

應用/服務與中介軟體呼叫鏈的拓撲圖

還是用查詢功能舉例，有時因為一些需要，該功能下使用了快取。當第一次查詢是直接從資料庫中查詢回來的資料，同時也在快取中記錄了該條資料，而在一定時間內再查詢，實則是從快取中查詢回來的。同樣的，如果只覆蓋了功能，這裡可能會有所遺漏，從功能來看，查詢後資料是返回了，而至於是從資料庫還是從快取獲取到的，就不得而知了。再有是獲取到的資料可能未必是想要的，奇怪的是，為什麼輸入/請求的資料，功能、介面都是一樣的，而返回的資料在一段時間後就發生了變化。中間發生了什麼不清楚，真的是"黑盒子"。想要知道 SQL 語句，只能費勁的從日誌、程式碼或 xml 中查詢，還有等等的不便問題。
除此之外，還可以展示不同介面與資料庫的關係

只要腦洞夠大，透過資料還可以實現出很多覆蓋，並呈現出各種視覺化圖形。

四、未來已來
使用資料驅動將抽象的字元、邏輯等等視覺化展示，從而得到想要的效果，但這種效果無論是靜態或動態產生的、主動或被動的等等，都會遇到時間的問題，而對時間有著強依賴的我們，無論採用哪種開發方式，即使在快，有著時間的限制和約束，這種苦惱始終會伴隨著，在現實世界中目前是無法解決，但有了虛擬世界，現在叫元宇宙，那就不同了，裡面有還原現實一切的 1 比 1 模型，在虛擬世界裡，可以搭建出想要的系統，每一個環節，無論是從專案或需求、產品設計、開發、測試到生產等各方環節，都可以清晰、透明、可視的關注到，無論功能與非功能均可以進行模擬，原來的專案或開發週期可能要 1 年，而現在可能半年不到的時間，透過虛擬現實和擴增實境技術進行互動，最終是透過空間換取時間從而得到這寶貴的經驗，然後這種虛擬產物可以搬到現實世界進行應用，從而避免很多試錯，也大大壓縮、節省了時間。目前這種方式已經慢慢被應用到各個行業、領域，這種虛擬與現實的結合可以更好地服務我們的生活。
而人工智慧（AI）在軟體測試領域中的應用已經逐漸增多，影響也逐漸顯現出來。
•對於程式碼覆蓋測試，AI 可以幫助測試人員更快地生成測試用例並自動執行測試。AI 可以分析原始碼並識別潛在的問題，然後自動生成測試用例。例如，可以使用 AI 來確定哪些程式碼路徑需要測試以及如何最好地測試它們。這種自動化過程可以加快軟體測試的速度並提高覆蓋率。
•對於測試覆蓋測試，AI 可以幫助測試人員更好地評估測試的效果。AI 可以分析測試結果並根據這些結果推斷哪些測試用例提供了最佳的測試覆蓋率，哪些測試用例需要進一步改進以提高覆蓋率。這種資料驅動的方法可以幫助測試人員更好地最佳化測試計劃，並在最短時間內提供最佳的測試覆蓋率。
AI 在軟體測試領域中的應用將對程式碼覆蓋測試和測試覆蓋測試產生積極的影響，幫助測試人員更好地評估軟體的質量並提高測試效率。