我所在公司內目前還沒有
單元測試，前兩天測試某系統的FTP上傳功能時，發現其軟件的流程設計有問題，進而覺得單元測試對系統還是很重要的，今天又在網上查看了很多關于單元測試的
文章，發現現在做單元測試的公司還真的不是很多呀。原因之一單元測試的bug發現率太低使得公司忽視了這一塊；再就是公司內沒有一個好的單元測試流程。鑒于上面提到的兩個原因及公司現在的環境（流程的可行性），我想出了以下的
白盒測試流程。簡稱單元測試之白盒測試方法（
代碼審查）。
首先先說一下測試中需要出的文檔。
在單元測試前可以進行代碼規范性審查。注：可以對所有代碼進行規范性審查，也可以對重點代碼進行規范性審查。此步驟可裁剪。
1、單元測試申請。注明測試的功能點，時間，各功能點測試原因等。
（1）測試功能點
（2）測試進度
（3）每個功能點的測試原因
2、制定單元測試計劃。在 許多資料中定義單元測試中的單元時各不相同。有用模塊的，有用函數的，有用類的等。偶在這里為了可操作性，再就是偶測試的系統都是應用軟件，很重視界面的 操作，所以偶將單元定義為界面上的功能性操作。如添加按鈕等。當然不會是這么簡單的。偶只是將比較復雜的一些操作寫入了單元測試計劃中。單元測試的計劃模 板如下：
（1）定義單元測試功能點。如（ftp上傳功能）
（2）功能點需求規格說明書。
（3）功能點測試時間。
（4）功能點測試的組織方式及人員。
（5）功能點測試采用的方法。
（6）功能點測試的通過標準
3、單元測試設計。在單元測試設計中主要由開發人員將其程序的設計思路，即流程圖畫出。
（1）功能點需求。
（2）功能點設計流程圖
（3）功能點設計數據流圖
（4）功能點偽代碼（可裁剪的）
4、單元測試用例。這一部分主要由測試人員根據功能點需求進行測試用例的設計
（1）功能點需求
（2）測試用例設計方法
（3）測試用例
5、評審人員的bug記錄
（1）測試功能點
（2）測試bug記錄。
6、單元測試報告。這一部分由開發人員寫單元測試用例報告，包括本次單元測試發現的bug類型，單元測試中拒絕bug的原因，單元測試情況等。
然后再提一下測試的組織方式。由項目經理或者系統設計人員準備單元測試申請，單元測試計劃，單元測試設計（單元測試設計也可以由開發人員準備），準備好 以上文檔后，提交測試部門；測試人員根據上面的文檔出單元測試用例（單元測試用例也可以在需求出來以后就出，此處可以靈活變通）；然后測試人員根據上面的 文檔檢查設計中的bug，填寫bug記錄單；測試人員根據bug記錄單組織專家評審（項目經理、設計人員等），專家針對測試人員測試出的bug進行討論， 在評審中專家也可以提出新的bug記錄到bug記錄單中，最后在評審中達成協議，bug記錄單中的問題哪些修復，哪些不修復怎樣處理等，最后由開發人員修 改bug記錄單中的問題，修改完后交給測試人員，測試人員可以用黑盒測試的方法驗證bug記錄單中的問題是否修改。驗證完后，由開發人員填寫單元測試報告。單元測試完成。
累死了，終于完成了，希望大家多提寶貴意見。