代碼覆蓋優化

Question

目前我有一堆針對我的C++項目的單元測試，但是我沒有（還）測試代碼覆蓋率。我正在用-O3優化標誌編譯測試，以揭示潛在的細微錯誤，但似乎如果我想用gcov等工具收集覆蓋率信息，則必須禁用任何優化標誌。我應該建立兩次測試（一個是-O3，另一個沒有）？這個問題通常如何處理？

Answer 1

通常會有多種測試來確保軟件的質量，以及針對哪些編譯器選項的不同標準。

通常，構建系統提供了建立兩個或更多的選擇，例如：

調試：-O0（沒有優化）與斷言

發佈： 「更高的優化」（ - O2，-Os或-O3取決於什麼是您的項目的「最佳」）沒有斷言。這通常是您向客戶提供代碼的模式。

有時會出現「Release + Asserts」，因此您仍然可以在運行代碼的同時檢查代碼中的正確性。

這裏有一些類，我認爲測試可以分成：

1. 功能的正確性（又名「積極試驗」）。這是您檢查「代碼在正常情況下正常工作」的地方。運行調試和發佈。

2. 負面測試。檢查錯誤條件是否正常工作 - 傳遞應該給出錯誤的垃圾值（「不存在的文件」應該給出E_NO_SUCH_FILE）。典型的是調試和發佈。

3. 壓力測試 - 運行嚴酷的測試，檢查軟件在長時間運行時，以及大量線程等情況下是否正常運行。通常，調試模式 - 也許都是這樣。

4. 覆蓋範圍。運行一系列測試以確保您「覆蓋所有路徑」（通常具有「未覆蓋」的程度，例如您應覆蓋95％的功能和85％的分支機構），因爲某些條件可能非常難以實現無需手動測試代碼 - 只有在磁盤完全滿或者操作系統無法創建新進程時纔會出現錯誤）。通常編譯爲Debug。

5. 容錯測試。一種「負面測試」的形式，爲存儲器分配和類似內容插入一個「模擬」功能，可以按順序或隨機地模擬失敗，以發現錯誤未被檢測到且代碼失敗的情況，作爲後續結果更早的錯誤，而不是在正確的地方產生正確的錯誤。同樣，通常使用Debug運行 - 但它也可能值得在Release中運行。

6. 性能測試。在哪裏測量程序的性能 - 每秒生成的幀數，編譯器每秒的行數或文件下載系統中的每小時千兆字節數等等。這應該按照發行版進行編譯，因爲「未優化」代碼中的運行性能是幾乎總是毫無意義。

對於複雜的軟件產品，你經常有「跑一切」和「花費的時間」之間的妥協 - 例如，運行在這兩種調試和發佈模式下，所有4000個的功能測試可能需要12小時，運行只有調試模式需要7個小時，所以最好。這種妥協是通常的「工程決策」 - 「在理想的世界中，你會這樣做，但在現實世界中，我們必須妥協，這就是爲什麼我認爲這種測試配置是正確的」。例如，許多測試系統都在對源代碼進行每次更改（例如，「我認爲這適用於工程師本人」）之後進行燈光測試，每晚更重的測試以及更多的測試。這樣可以在運行所有測試所需的時間和一名工程師進行小改動所需的時間之間達成折中。