軟件質量保證與測試——單元測試過程&斷言

單元測試過程

定義：單元測試是對軟件基礎組成單元進行的測試
時機：一般在代碼完成後由開發人員完成，QA人員輔助
對象：類、模塊、組件、單元

單元測試

1. 單元測試的依據是軟件的詳細設計描述、源程序清單、編碼標準等。
2. 單元測試一般應該由編程人員完成，有時測試人員也加入進來，但編程人員扔會起到主要作用。
3. 多個被測試模塊之間的單元測試可同時進行，以提高單元測試效率。
4. 單元測試是對軟件組成的基本單元測試。
   • 在傳統的結構化編程語言如c語言中，單元一般是模塊，也就是函數或子過程。
   • 在象c++中，單元是類和類的方法
   • 在Ada語言中，單元可爲獨立的過程、函數或Ada包
   • 在第四代語言（4GL）中，單元對應爲一個菜單或顯示界面。

單元測試的目的

• 驗證代碼是否達到詳細設計的預期要求（概要設計->集成測試）
• 發現代碼中不符合編碼規範的地方
• 準確定位發現的錯誤，以便排除錯誤

單元測試的優點

• 單元測試在編碼過程中（在所有測試前），若發現一個錯誤，不論是從做迴歸測試的角度，還是對錯誤原因理解的深刻性的角度，修復錯誤的成本遠小於集成測試階段，更小於系統測試階段（效益更優）
• 在編碼過程中考慮單元測試的問題，有助於編程人員養成更良好的編程習慣（規範），提高源代碼質量

單元測試的步驟

實施應遵循一定的步驟。

1. 計劃單元測試
2. 設計單元測試
3. 實現單元測試
4. 執行單元測試
5. 結果分析並提交測試報告

單元測試環境構成

單元測試中，單元測試一般爲編碼步驟的附屬部分，模塊不是獨立的程序，自己不能運行，要靠其他部分來驅動，要爲每個單元模塊開發來兩個軟件：

• 驅動模塊（Driver）:調用模塊的運行
• 樁模塊（Stub）:測試接口
  驅動一般少於樁，儘量避免開發樁
  若採用自底向上的方式開發，底層的單元先開發並測試，則避免了底層樁模塊的開發。

如何構建單元測試的環境

• 構造最小運行調度系統，即構造被測單元的驅動模塊
• 模擬被測單元的接口，即構造樁模塊
• 模擬相應測試集中的測試數據

單元測試的內容

• 模塊接口
• 局部數據結構測試
• 路徑測試
• 錯誤處理測試
• 邊界測試

模塊接口測試

• 調用所測試模塊的輸入參數與模塊的形式參數在個數、屬性、順序上是否匹配
• 所測試模塊調用子模塊時，它輸入子模塊的參數和子模塊的形式參數在個數、屬性、順序上是否匹配
• 是否修改了只做輸入用的形式參數
• 輸出給標準函數的參數在個數上、屬性上、順序上是否匹配
• 全局變量的定義在各模塊中是否一致
• 限制是否通過形式參數來傳送

局部數據結構測試

• 檢查不正確或不一致的數據類型說明；
• 使用尚未賦值或尚未初始化的變量；
• 錯誤的初始值或錯誤的默認值；
• 變量名拼寫錯誤或書寫錯誤；
• 不一致的數據類型。

路徑測試

1. 常見的不正確的計算有：

• 運算的優先次序不正確或誤解了運算的優先次序；
• 運算的方式錯誤（運算的對象彼此在類型上不相容）；
• 算法錯誤；
• 初始化不正確；
• 運算精度不夠；
• 表達式的符號表示不正確等。

2. 常見的比較和控制流錯誤有：

• 不同數據類型的比較；
• 不正確的邏輯運算符或優先次序；
• 因浮點運算精度問題而造成的兩值比較不等；
• 關係表達式中不正確的變量和比較符；
• “差1錯”，即不正確地多循環或少循環一次；
• 錯誤的或不可能的循環終止條件；
• 當遇到發散的迭代時不能終止循環；
• 不適當地修改了循環變量等。

錯誤處理測試（容錯）

• 出錯的描述難以理解；
• 出錯的描述不足以對錯誤定位和確定出錯的原因；顯示的錯誤與實際的錯誤不符；
• 對錯誤條件的處理不正確；在對錯誤進行處理之前，錯誤條件已經引起系統的干預；
• 如果出錯情況不予考慮，那麼檢查恢復正常後模塊可否正常工作。

邊界測試

• 在n次循環的第0次、1次、n次是否有錯誤；
• 運算或判斷中取最大最小值時是否有錯誤；
• 數據流、控制流中剛好等於、大於、小於確定的比較值時是否出現錯誤。

單元測試類型

• 邏輯單元測試；
• 集成單元測試；
• 功能單元測試。
  單元測試應試應從各個層次來對單元內部算法、外部功能實現等進行檢驗，包括對程序代碼的評審和通過運行單元程序來驗證其功能特性等內容。一般單元測試應緊接在編碼之後，當源程序編制完成並通過複審和編譯檢查，便可開始單元測試。測試用例的設計應與複審工作相結合，根據設計信息選取測試數據，將增大發現上述各類錯誤的可能性。在確定測試用例的同時，應給出期望結果。
  進行單元測試時，常用的方法是採用白盒測試，輔之以黑盒測試。

根據測試對象的其內部結構的邏輯關係、測試的方法，按照由小到大、由單一到組合、又簡單到複雜，單元測試可以邏輯單元測試、集成單元測試和功能單元測試。

斷言

定義：

簡單的方法調用，判斷一個語句、一個函數或對象的一個方法所產生的結果是否符合你期望的那個結集（爲真）。

時機：

1. 用錯誤處理代碼來處理預期會發生的狀況，用斷言來處理絕不應該發生的狀
2. 用斷言註解並驗前（置），條件和後（置）條件趕鏈的花構，應該先使用斷管再處理錯要

應用場景：

1. 在在功能代碼開發階段，可以逐步添加斷言測試是否獲取自己想要的數據結果
2. 寫單元測試時，可用到斷言，主要目的：測試這個功能片段的代碼能否返回預期的結果
3. 自己提供接口供他人使用時，可先斷言使用者傳遞過來的參數是否符合要求，如果不符合要求，將以AssertionError 的方式告知使用者。

• assertion（斷言）是軟件開發中一種常用的調試方式，很多開發語言中都支持這種機制。
• assertion 就是在程序中的一條語句，它對一個布爾表達式進行檢查，必須保證這個表達式的值爲true；如果爲false，則說明程序已經處於不正確的狀態，系統將給出警告或退出。
• assertion 用於保證程序最基本、關鍵的正確性。
• assertion 通常在開發和測試時開啓。爲了提高性能，在軟件發佈後，assertion通常是關閉的。
  -

單元測試的目的

• 驗證代碼能否達到詳細設計的預期要求。
• 發現代碼中不符合編碼規範的地方。口準確定位發現的錯誤，以便排除錯誤。

單元測試的作用

• 編寫單元測試可以幫助開發人員書寫高質量的代碼。
• 編寫單元測試可以使開發人員更有信心重構應用程序，去擁抱變化。