當單元測試浮點信號處理庫時出現錯誤界限

Question

我有一個符合規範的信號處理庫。但是，我已經確定了一些重構的好地方。我一直有意將單元測試合併到我的工作流程中一段時間​​，這看起來像是一個很好的機會來嘗試使用非平凡的代碼。這樣我就可以測試重構後的輸出接近完全相同。

我與catch試驗作爲測試框架，但是，這個細節可能是無關緊要的（從我可以收集）的所有測試框架周圍結果鉸鏈由運營商，即

REQUIRE(i_x == 2) 

然而，浮動點數據，則需要某種形式的錯誤邊界檢查。 。

const float target = 2.000f; 
const float tolerance = 0.000005f; 
const float err = target*tolerance; 
REQUIRE((f_x > target-err) && (f_x < target+err)) 

這將很快得到醜陋的人，寫的每一個測試，這樣我就可以，當然，作出這樣的返回（模板化）全局函數bool給x，target和tolerance作爲參數。

這是所有人都這樣做的方式嗎？這是最佳做法還是我錯過了一個竅門？

Answer 1

測試對上下文高度敏感。你提出的測試測試相對誤差。實質上，你聲稱在這種特殊情況下：

• 正常的，可接受的代碼更改可能會在每個結果中產生相對於結果較小的偏差。
• 錯誤可能會產生相對於結果不小的偏差。

總之，我認爲第二個斷言通常是安全的。 「隨機」代碼更改可能會在至少某些值上產生巨大差異。但是，有些應用程序可以很好地處理浮點運算，在這種情況下，小的偏差可能導致超出規範的結果。例如，假設您有一個反正弦例程，該例程返回的結果與正確的結果稍有不同：當正確結果爲1時，返回1 + 2 ^-23。稍後，此結果x用於表達式爲sqrt(1-x*x)。該表達式對於所有數學上正確的反正弦值（對於實際輸入）是真實的，但是，給定略大於1的x時，它會嘗試取負數的平方根，併發生錯誤。所以你必須決定第二個斷言是否適合你的應用程序。

第一個斷言更可疑。浮點算術中的誤差源並不總是與最終結果成比例的。例如，考慮對某些輸入信號進行離散傅立葉變換（DFT）。對於幾乎每個輸出編號，每個輸入編號都會貢獻一些部分。偶然的情況下，一些單獨的輸出數字將接近於零。但是，它們中的錯誤可能與輸入中的大數成正比。因此，對這些輸出數字應用相對誤差測試會產生錯誤的錯誤指示。相反，有必要允許輸入以某種方式縮放的錯誤。