軟件測試用例（testcase）一定要有實際意義?
最近和做無線基帶芯片驗證的一個朋友討論比較多，他提的一些問題讓我有點頭疼，雖然很多我曾經遇到過，并且自認為已經解決的。我現在不得不重新思考，而且要思考得更深入一些，因為現在不止是要自己理解，還要讓他，以及他的team里的算法工程師、設計工程師認可。確實是個很好的鍛煉。
朋友的設計簡單說就是無線基帶常見的操作，包括相關、累加、峰值搜索等，我曾經建議他多使用隨機數作為激勵，再輔以特殊的testcase，對相關器飽和、截位等操作進行驗證。在芯片輸入端用隨機數作為激勵的好處是，覆蓋比較全面，數據的產生也比較容易（即便沒有specman和vera，只用HDL語言也是如此）。在自檢查testbench(self-checking testbench)中，激勵通過施加在DUT(待測芯片)和RM(reference model,參考模型)上，通過編寫自動比較代碼，可以驗證各種數據激勵下，DUT的行為是否正確。另外再加上特殊的testcase對飽和、截位等情況進行驗證的原因在于，完全隨機的驗證可能很難擊中（hit）某些情況，例如對于相關器，只有相關上了，才會輸出一個較大的數值，如果后面有截位電路，此時截位電路才會動作，而完全隨機的驗證，相關上的可能性幾乎為0，因此需要針對性的驗證。其實，兩者之和相當于約束隨機驗證（constaints driven verification），這是用specman和VERA的工程師必定會使用的方法。
朋友提到，系統工程師說用完全隨機的12位有符號數作為激勵，因為這樣的激勵不滿足特定的相位和幅值關系，那么不就成了完全的噪聲信號么？這么做有什么實際意義呢？ 當時我不知道怎么解釋才有說服力，不知道怎么回答。
我也曾經被別人問過這個問題，要對方理解確實不容易。如果那位系統工程師把我們的驗證策略理解為“只用隨機數進行驗證，不能完全說明問題”，我是贊成的。但是如果他的意思是“所有testcase都應該是有實際意義的”，我就不完全同意了。
驗證的對象常�？梢苑譃榭刂屏鳛橹鞯脑O計，和數據流為主的設計，前者包括UART/I2C/PCI/DMA Controller等，后者主要是無線基帶、圖像、語音處理等，兩者的驗證思路有較大的不同�？刂屏鳛橹鞯脑O計要實現全面的隨機驗證是比較困難的，因為涉及很多的控制信號，時序上需要協調的事情也很多，因此可能需要結合芯片真實工作情況，加以分類，然后對各子類進行模擬和隨機驗證。數據流的驗證相對容易一些，主要是輸入數據的不同，工作狀態是基本一樣的，驗證時，在不同工作模式下，輸入盡可能多的隨機數就可以實現數據通道的驗證。舉個極端的例子，假設我們要驗證一個乘法器，那么最簡單的做法就是輸入隨機數，然后檢查輸出結果是否正確，跑上足夠多的數據之后，再加上邊界情況的測試（例如0×0等），就可以判斷設計是否正確，也不需要過多的關注輸入數據的實際意義。
假設我們要驗證一個FIR低通濾波器，大家都知道FIR濾波器內部主要是乘法和加法電路，假設這個電路是RTL工程師根據算法工程師給出的定點算法“翻譯”后設計出來的，那么我們怎樣驗證這個電路呢？簡單來說，第一個方法是輸入帶噪聲的數據，然后對輸出結果做頻譜分析，看看噪聲是否被濾除了；第二個方法是輸入隨機數到DUT和參考模型RM（當然RM要通過某種方式和定點算法鏈路進行校準，保證兩者的一致性），然后比較兩者輸出的每個bit是否一致，重復足夠多次。如果二選一，我會選后者。前者固然有直觀性，但是如果其中有幾個數據錯了，從頻譜上是看不出來的。因此，很多時候有實際意義的數據對于提高了判斷正確性的難度。
對于圖像處理，用一幅帶有噪聲點的圖像作為輸入，然后觀察處理結果，或者對無線基帶芯片，用在某具體位置有徑，然后看看芯片能否找出該位置的徑，這種驗證方法可以作為輔助手段，用于增加信心，但是不能說明設計的正確性，除非構建足夠多的這種有實際意義的數據，這個工作量往往大得驚人。而且，這樣大的工作應該在算法仿真平臺已經做過，功能驗證平臺來做這個事情，一個是速度慢，第二是重復勞動。數據通道為主的設計，我覺得要以隨機驗證為主，思路是，定點算法保證性能，功能驗證保證RTL代碼功能和定點算法鏈路一致，最后通過FPGA測試或樣片測試檢驗性能。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
