這幾天一直都在思考新項目中，如何促使公司能夠最終真正使用上單元測試。前幾天和我的微軟同學聊起微軟的自動化測試的時候，他向我提到了幾個概念BVT(Build Verification Test)和Smoke Test，這讓我注意到一個問題，TDD中并沒有解決好復雜系統的全面測試問題。要知道大多數人的單元測試概念，是有KENT BECK的測試驅動開發中帶來的。但是，要讓單元測試完整應用起來，是需要相當的組織結構保障的。
在聊天的過程中，有一點非常值得關注，那就是微軟的Software Design Engineer in Test (SDET)角色。據他講，在微軟，SDET和開發的待遇是一樣的。顯然，微軟是非常重視測試的。
在開篇提到的另一篇同名稱的文章中，也對單元測試做了詮釋，而且從文章來看，他應該是一位咨詢師。我這里不說其他，但從單元測試需要咨詢，就說明了一個問題，單元測試不是只靠技術和理念的認識就能簡單做起來的。
從很多公司的嘗試未果，就可以看出，我們相對于微軟這類成功應用了自動化測試的公司相比，我們并沒有很好的組織保障。讓公司里的開發來做測試，一來會感覺實在浪費，二來重復性工作和創造性工作的不一樣，會讓很多人止步。
這兩年，我一直被領導困擾著。他們在思考問題的時候，總是說什么組織結構。而我卻更重視技術解決問題。想想看，如果能完全靠技術解決問題，那么就不需要管理那么麻煩了。我相信很多人也會和我有同樣的觀點。
可是，不要忘了，單元測試的主體是人。大凡是人，就必須有管理。我這里所說的管理，不是領導的管理，而是組織結構的保障。在最近的工作過程中，我逐步意識到了保障的力量。忽視組織保障，團隊的工作會變得松散而無方向；反之，大家會知道做什么會得到鼓勵，做什么會得到批評。
因此，相對于大講那些測試理論，最先要解決的是組織結構。這才是保障單元測試成功實施的重要措施。我這里主要是從推動單元測試的工作入手的。因此考慮其組織結構，可以由公司的技術高手成立，輔助項目開發。這個組織在項目相對獨立，直接對項目經理負責，而不對項目進度負責。
在組織結構問題中，我重點說明一下進度和質量的問題。大家很容易明白，項目中對進度的反應是如何的強烈。事實上，由于質量的衡量標準相對比較復雜和不明確，導致質量在進度面前，經常容易被犧牲。反過來，我們現在的單元測試就是要從質量入手，因此其組織機構一定要相對獨立于保障進度的組織。這樣，我們的工作才容易進行下去。
以前單元測試往往是開發的Leader提出來的，但是，Leader往往需要對進度負責，單單從這點來看，單元測試往往會以失敗告終是不足為怪的。
在建立了單元測試機構之后，就是建立測試流程規范。在推廣初期，并不一定需要建立完備的流程。只需要考慮好幾個關鍵點，讓單元測試工作起來。好多機制就是越轉越好！否則，再完備的機制也容易因為磨合不好而最終失敗。
重要的是，建立單元測試報告的優先處理機制。對于單元測試的失敗，應該有考核機制來保障必須在第一時間得到處理。在初期，細節的處理，并沒有那些測試理論中講得那么重要。關鍵要與你的現有組織磨合順利。
等到你的項目中的單元測試成功運作之后，再重新考慮如何優化流程。流程和組織一般來說是相輔相成的�？赡茉趦灮鞒痰臅r候，再修改組織結構。
文章來源于領測軟件測試網 http://www.kjueaiud.com/