1）對架構的反思：架構是否按照分層開發，業務邏輯是否全部在邏輯層實現而非ui實現，這些對
單元測試都很重要。雖然現在提供了一些從ui開始的單元測試工具，但推薦方式或說單元測試的重點仍然在邏輯層。
2）對自我開發技能的反思：開發不做單元測試而直接做黑盒測試不利於鍛鍊自己邏輯思維能力，**靜態分析技能。通過進行單元測試，進行分支和覆蓋分析，可以加強**的可測試性，促進**的重構。
3）單元測試是整合測試的基礎，如果單元測試都沒有做好，那就會把單元，子程式的問題遺留到系統測試的時候才發現。
4）不使用單元測試工具或框架也可以自己寫相關**或其它方式進行單元測試，不能單純理解單元測試就是使用junit，nunit等相關工具。
單元測試是檢查程式中的最小單位（函式，過程，類，子程式，包）有無錯誤，一般在編碼完成後由開發人員進行。
單元測試的目標是檢查編碼是否符合設計，而不能檢查設計是否正確。
單元測試的一些方法：
靜態方法：
**走讀：可開發人員間相互走讀**，可設計人員走讀開發人員**，比較隨意些。
**的靜態分析對開發人員的技能要求很高，在沒有實際執行程式時候就能夠清楚的知道程式潛在存在的漏洞和缺陷需要多年的程式設計的積累和經驗的總結。
靜態測試方法關注的重點是
1）編碼的規範性
2）資源是否釋放
3）資料結構是否完整和正確
4）是否有死**和死迴圈
5）**本身是否存在明顯的效率和效能問題
6）**本身方法，類和函式的劃分是否清晰，易理解
7）**本身是否健壯，是否有完善的異常處理和錯誤處理
通過工具進行單元測試
1）靜態分析工具（purifyplus）
2）**規範審核工具 （fxcorp）
3）記憶體和資源檢查工具（purifyplus，memorychecker）
4）測試資料生成工具
5）測試框架工具（junit nunit）
驅動和打樁（test driver & stub）
執行乙個單元測試通過三個步驟完成：模擬輸入->執行單元->檢查驗證輸出，這就是單元測試的驅動。當我們採用從頂向下執行單元測試的時候，底層執行單元及其子單元可能根本還沒有開發完成，這個時候需要模擬一些資料輸出來替代實際的單元和子單元。所以打樁乙個是對單元的模擬，乙個是對單元的替代。
關於單元測試提出的思考
對於開發者來說，軟體測試，特別是單元測試，也是在開發過程中的重要組成部分。對於負責的系統 功能模組來說，做好單元測試，對保證產品質量有非常重要的作用。此外，做好單元測試，還能提高開發者開發思維的嚴謹性 啟發功能模組解耦 測試驅動開發 以下提出單元測試常見的問題和提供使用的解決方案。待完善 有的時候做...
對 單元測試 UT 的理解
1 單元測試與敏捷開發的衝突點 現在很多公司都推行敏捷開發 與 邏輯不同步的ut沒有意義 而ut 維護是需要成本的 參考 2 從專案的長期角度來看 好的ut對團隊整體開發效率有比較大的提公升，同時可以提高 質量 減少程式缺陷 最大限度地規避線上故障。但過大的ut成本佔比，可能是專案接受不了的。建議 ...
單元測試 單元測試文章收藏
前言 前段時間公司計畫做自動化測試，自己也打算圍繞幾個點做相關調研，現在想想呢？其實對自動化測試的概念都還不是十分清晰，當時主要還是圍繞 單元測試 向qa小夥伴學習了一段時間，現由於公司重組，學習中斷，這裡簡單記錄一些單元測試好文，留待後續參考.什麼叫自動化測試？自動化測試覆蓋率？覆蓋率如何做到的？...