軟件單元測試理論知識問答
為什么需要單元測試?
徹底測試：僅依靠系統測試會存在大量未覆蓋的“死角”，單元測試可以實現代碼級徹底測試，從根本上保證代碼質量。
成本最低：排錯成本隨時間推移和范圍擴大直線上升，單元測試是最早階段的測試，且目標最小，因此，排錯成本最低。
自動回歸：單元測試將代碼功能“定格”，代碼修改后自動檢查是否引入新的錯誤，避免陷入“系統測試->修改->引入新的錯誤->新一輪系統測試->修改->引入新的錯誤”的怪圈。自動回歸也使開發過程適應頻繁變更的需求，使開發過程自動“敏捷”。
促進開發：利用單元測試還可以實現測試驅動開發和可視編程。可視編程使開發過程中程序行為可視，大幅提升開發效率、降低勞動強度。
什么是單元測試?
單元測試是針對代碼單元的獨立測試。從實用角度出發，“單元”是指函數，以類為單元則過于復雜。“獨立”是指將代碼從原始項目中隔離出來，針對各個單元單獨進行測試。
單元測試的基本方法是?
根據程序功能設定輸入、執行測試、自動判斷輸出是否符合預期。測試過程需要以下關鍵元素：驅動(用于執行測試的代碼)、用例(輸入及預期輸出)、樁(用于隔離耦合代碼、或代替未實現代碼)。
企業項目的單元測試面臨哪些難點?
測試簡單獨立的代碼是很容易的，測試復雜項目則是另一回事。企業項目的單元測試面臨以下難點：可測性問題、失真、不可控、靜態局部變量的外部控制、內部輸出的自動判斷、復雜間接輸入難于初始化、白盒覆蓋逾后逾難等等。不解決這些難題。測試將無法進行，后面的`條目將進一步闡述。
單元測試的具體目標是?
單元測試是針對代碼單元的獨立測試，“獨立”狀態下易于發現的錯誤，都是單元測試的目標;集成后才易于發現的問題，則不是單元測試的目標。
代碼單元本身的功能錯誤都是單元測試的目標，而性能問題(時間性能如執行速度，空間性能如存儲空間大小、內存泄漏)難于在最小單元內測試，不是單元測試目標。
編碼規范檢查與單元測試無關，無論是否實施單元測試，編碼規范檢查都是必不可少的工作。
靜態分析屬于全局掃描，嚴格來說也不是單元測試，提高編譯器的警告級別，就是最簡單高效的靜態分析。
單元測試是意義重大且困難的工作，目標應該具體而明確，將不屬于單元測試的工作牽扯進來，其結果往往是“揀了芝麻，丟了西瓜”。
選擇工具時不要被“功能多多”所迷惑，要首先檢查工具能否解決企業項目單元測試的難點，并用實際項目評估。“多”和“精”從來就是一對矛盾，要判斷工具是不是因為無法解決單元測試的難題，故意把其他東西牽扯進來轉移視線。
什么是測試用例?
測試用例就是程序功能的實例，對于單元測試來說，把函數功能明確化、實例化，用什么輸入應該產生什么輸出的形式記錄下來，就是測試用例。
如何設計用例?
根據功能點設定輸入，再根據設計功能設定預期的正確輸出，這樣就構成了一個測試用例。
通常，一個功能點對應一個等價類，“等價”是指測試效果上的等價，等價類中可能存在一個、多個或無數個值，取其中任何一個，如果測試通過，就表示同類中所有值都會測試通過。
所謂“徹底測試”，是指等價類劃分正確且完整，且設定了正確的預期輸出，做到了這一點，代碼可以保證不存在功能錯誤。
什么是測試驅動開發(TDD)?
首先編寫測試代碼，然后編寫產品代碼，使編譯和測試通過。
優點：編寫測試代碼是一種設計行為，將程序功能細化、明確化;編程時目標具體而明確，避免多余動作;強制實施單元測試，避免編碼后忽略測試。
缺點：手工編寫測試代碼，比較費時;過于強調測試，很多代碼是不需測試的，且往往在編寫實現時才知道是否有必要測試;對編程過程的幫助不足，很多函數，都是在代碼基本完成時，主要用例才能通過，在此過程中，TDD不能提供幫助;改變思維習慣，有些程序員難于接受。
http://www.shddsc.com/【軟件單元測試理論知識問答】相關文章：
職場問答02-07
西畫理論知識測試02-07
塑膠理論知識測試02-12
面試經典問答（雙語）08-14
英語面試經典問答04-03
英語面試的經典問答01-25
面試英語經典問答02-12
地震的知識問答02-28
管理問答三則07-16