《單元測試之道C#版——使用NUnit》測試哪些內容 Right-BICEP

文章目錄

• 1、Right——結果是否正確？
• 2、B——是否所有的邊界條件都是正確的？
• 3、I——能查一下反向關聯嗎？
• 4、C——能用其他手段交叉檢查一下結果嗎？
• 5、E——你是否可以強制錯誤條件發生？
• 5、P——是否滿足效能要求？

1、Right——結果是否正確？

       對於測試而言，首要的也是最明顯的任務就是查看所期望的結果是否正確——驗證結果。

       對於許多有大量測試資料的測試，考慮用一個獨立的資料來儲存測試資料，然後讓單元測試讀取該檔案。不過需要多注意一下測試資料。不管是檔案中的還是代碼中的測試資料，都很有可能是不正確的。實際上，經驗告訴我們，測試資料比代碼更有可能是錯的，特別是人工計算的，或者來自原有系統計算結果的測試資料。因此，當測試資料顯示有錯誤發生的時候，你應該在懷疑代碼前線對測試資料檢查兩三遍。

2、B——是否所有的邊界條件都是正確的？

       找邊界條件助記短語CORRECT

       Conformance（一致性）——值是否和預期的一致

       Ordering（順序性）——值是否如應該的那樣，是有序或者無序的。         Range（區間性）——值是否位於合理的最小值和最大值之內

       Reference（依賴性）——代碼是否引用了一些不在代碼本身控制範圍之外的外部資源。

       Existence（存在性）——值是否存在（例如，是否是非null，非0，在一個集合中等等）。

       Cardinality（基數性）——是否恰好有足夠的值？

       Time（相對或者絕對的時間性）——所有事情的發生是否是有序的？是否在正確的時刻？是否恰好及時？

3、I——能查一下反向關聯嗎？

       例如，可以用對結果進行平方的方式來檢查一個計算平方根的函數，然後測試結果是否和原資料很接近。

4、C——能用其他手段交叉檢查一下結果嗎？

       通常而言，計算一個量會有一種以上的演算法。我們可能會基於運行效率或者其他的特性來選擇演算法。那是我們要在產品中使用的；但是在測試用的系統中，可以使用剩下演算法中的一個來交叉測試結果。

       另一種方法就是：使用類本身不同組成部門的資料，並且確信它們能“合起來”。例如，圖書館的資料系統，借出數加上躺在架子上的庫存數應當永遠等於總藏書量。這些就是資料的兩個分開的不同組成部門（借出數和庫存數），它們甚至可以由不同類的對象來彙報它們，但是它們仍然必須遵循上面約束（總數恒定）。

5、E——你是否可以強制錯誤條件發生？

       搞一個無效參數之類的做法是小菜一碟，但是不拔網線要類比網路錯誤就需要一些特殊的技術了，使用Mock對象可以解決此類問題。

       以下是常見的環境方面的因素：

•   記憶體耗光
•   磁碟用滿
•   時鐘出問題
•   網路不可用或有問題
•   系統過載
•   受限的調色盤
•   顯示解析度過高或者過低

5、P——是否滿足效能要求？

        一個檢查起來會很有益處的部分是效能特性，而不是特性效能本身。然後效能特性卻又一種類似“隨著輸入尺寸慢慢變大，問題慢慢變複雜”的趨勢。

        我們想要的是一個效能特性的快速迴歸測試。很多時候，也許我們發布的第一個版本工作正常，但是第二個版本不知道為何變得很慢。我們不知道為什麼，也不知道改變了什麼，或者什麼時候誰敢的，幾乎一切都是未知的。