軟件測試中的單元測試方案整理
1、為什么要做單元測試我不想多說
模塊出現問題難定位，為了更早發現bug，定位bug。
2、關于程序員的職責，強調：
不是調試不報錯就可以了，不要自信自己的程序不會出錯。
任何人都有失誤不可避免的。開發的任務是完成程序直至交付和維護。
3、實踐證明
編碼階段引入的bug多余其他階段。
系統測試發現的大多數都是編碼缺陷，又得花時間找問題·~⊙﹏⊙b汗
這樣導致的問題，測試版本頻繁，進度無休止的拖延。
4、談下我們的現狀
業界能做單元測試的都是花軟件項目周期的五分之一左右時間編碼，而我們絕大部分是百分之五十以上的時間編碼，剩下的時間就是所謂系統測試了，而稱之為系統測試，實際上都是在系統聯調環境或接口問題不斷，有效測試時間少之又少，還不斷更新版本，測試效果可想而知。
5、我們的開發充當的角色：
參與部分高層設計、承擔低層設計、程序實現和低層測試。
6、為啥開發的測試效果不好？這也是我為什么要寫這個喇
沒時間測試、不知道怎樣測試、不好組織。
結果單元測試都是堆積到系統測試階段，給測試痛苦，你們應該對我們好點，%>_<%
后果就是拖延項目發布時間，難以定位bug，奔命吖~~
附：業界標桿單位是15%編碼、25%單元測試，系統測試只需要4%，這也是為什么我們公司以前測試一個版本3天左右就能搞定�？紤]周全，質量本身就不錯，等著挑刺了。
7、單元測試原則：
● 盡早
● 保證單元測試的可重復性。
● 工具支持
8、單元測試內容，這里是我們需要重點關注的內容：
● 功能
● 接口
● 局部數據結構
● 重要執行路徑（正常數據和邊界數據以及錯誤數據都得試試）
● 錯誤處理路徑
● 邊界條件測試
9、我們的單元測試誰做
主要是開發人員做，測試人員可以針對重點模塊實施獨立單元測試。
10、對于測試過程我不想要求太多，計劃啥的不做過多要求，但要求產出符合要求的代碼。
11、對于二次開發功能可以不要求單元測試，但新模塊、核心模塊以及代碼修改量大于20%左右的模塊必須做單元測試。
12、我想列的功能覆蓋單元測試檢查點：待續
13、接口測試，測試驅動開發。。。
至少要先明確要存到哪里，哪些地方是要給別人用的。
14、單元測試可以用些工具，我也不太熟悉，推薦Junit，待姐研究后續~~。
15、一些專業的內容分享，提高可測性：
1）首先最重要的是堅持測試驅動設計（測試先于設計）的方法。
優先編寫測試代碼。這是標準的XP 方法。這不是說您應該一次性編寫全部測試代碼后，再一次性全部實現。對一些單元接口，編寫一些測試代碼，實現它們，再編寫一些測試代碼，再實現它們等等是個更好的辦法。設計以這種方式得以進展；在實現階段捕捉錯誤并在下一組測試中改正它。
2）功能分解
類：把功能分解到細粒度，提倡小類。
方法：盡量做到每個操作對應一個方法，使方法小型化。
功能分解促進：提高重用性，降低耦合度
3）分層原則。
對于顯示部分（GUI），盡量做到顯示與控制分離。把代碼移到GUI 視圖的外面。然后各種GUI 動作就能成了模型上的簡單方法調用。這樣，對GUI 測試者來說，通過方法調用測試功能比間接地測試功能容易的多。另一個好處是它使修改程序功能而不影響視圖變的更容易。
4）抽象
我們可以想出各種各樣的辦法來降低耦合程度，但是歸納起來，不外乎增加抽象的層次來隔離不同的類，這個抽象層次可以是具體的類，也可以是接口。
GOF的23種設計模式，沒有一種模式的思路不是從增加抽象層次入手來解決問題的
5）對于可能要作為參數的復雜類，可以做一個接口，用接口說明外部程序組件使得我們可以容易地在測試案例中模擬這些組件。當需要時可以實現按接口生成一個模擬類作為參數傳入。特別是當該類還沒有完全實現時，這種方法最為行之有效。
6）如果自己不負責測試工作，作為開發員在設計過程中要時刻提醒自己“我如何才能測試這些代碼？我如何才能以可測試方式編寫這些代碼”。
7）重構是提高可測試性的主要手段
測試驅動開發
編寫單元測試用例促進解除模塊之間的耦合。先編寫測試用例，強迫自己從利于調用者的角度來設計單元，關注單元的接口。為了便于調用和獨立測試，必須降低單元和周邊環境的耦合程度，單元的可測試性得到加強，模塊化程度得到提高。這樣單元的可重用性也容易被考慮和提高。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
