開發自測方法探討(2)

　　單元測試是最基本的，也是最容易執行的，更是成本最低的一種測試方法，讓開發做好單元測試，可以說是有了開發自測。開發不討厭寫代碼，而且還擅長寫代碼，但是開發厭惡搭建測試環境準備測試數據，而這恰恰是測試擅長的，那么，可以考慮針對單元測試可以為開發做些什么。就單元測試來說，除了xunit，Mock是最好的單元測試工具，讓開發掌握了mock技術，然后讓開發了解單元測試思路，開發會愛上單元測試的，開發也希望自己寫的代碼有測試代碼保證。關于單元測試，衡量的最常用的標準就是持續集成和代碼覆蓋率，讓開發寫單元測試代碼，還要讓開發能夠對單元測試有成就感，當開發的單元測試代碼每天都被構建并且將測試結果發送給開發，當有代碼變動引起了單元測試構建，構建結果發現了bug，開發會認識到單元測試的價值，會熱衷于進行單元測試，如果開發寫的代碼覆蓋率很高，對開發來說，也是一種成就感。

　　4. 代碼review

　　開發完成了單元測試，組織開發進行代碼review也是非常有必要的，代碼review不完全是為了找出代碼中的錯誤，更重要的是可以讓有經驗的開發對代碼的設計進行審查，降低代碼的復雜度，耦合性，減少重復無用的代碼，能夠使得代碼更好的和其他系統進集成，同時，測試參與代碼review，可以對代碼的可測性提出建議。

　　代碼review看起來很美好，但是執行起來卻絕非易事，因為開發實現了某個功能，review的時候卻發現這種實現方式不是很美好，開發會覺得反正功能是可用的，等后面有時間再進行修改，這樣的理由也無可厚非，但是，現在的修改可能只是一兩個小時，后面的修改卻是一兩個日常，讓開發或者開發TL意識到這種時間的差別，可能對代碼review的接受程度會更高

　　5. 集成測試

　　我們做的接口測試，無論是service的接口測試還是web層的接口測試其實就是集成測試，因為都需要依賴一定的外部環境，比如數據庫，比如其他系統提供的接口，接口測試一般是在開發編碼完成以后進行，要進行開發自測，接口測試可以提前進行，在開發進行設計的時候，產品/項目需要幾個接口，這些接口需要哪些參數，實現什么功能其實已經是確定好了的，那么根據接口的定義，測試可以提前進行接口測試的準備，比如接口測試用例的設計，測試環境搭建，測試數據準備，根據這些內容看是否需要為產品，項目的接口測試開發新的接口測試的框架，這些都可以在開發進行編碼的時候完成。

　　開發編碼完成后，或者開發一兩個接口提測后，測試可以先行進行接口測試，理順測試環境，等開發編碼都完成后，集中開發/測試的力量，一鼓作氣將接口測試完成，編碼對開發來說不是什么難事，如果開發準備好了測試環境，有測試用例，有測試框架，開發完成接口測試的速度還是相當快的。

　　這里需要說明的是，開發可能會覺得單元測試做了，怎么還要做接口測試，單元測試和接口測試關注的重點不一樣，所以并沒有重復之說，而且，單元測試和接口測試是最底層，成本最低，且最容易自動化的測試手段，而且也是以開發最擅長的編碼方式進行。

　　開發寫接口測試，并不是說接口測試的工作也完全由開發來做，接口測試應該是開發和測試共同配合來完成，分別發揮各自的優勢又能分別學習各自的優勢。通過接口測試，開發可以學習測試思維，測試技巧，而開發也可以從開發那邊學習到開發技巧，更重要的是，做好了接口測試，在后續系統測試階段，就算是發現了bug，修改了代碼，通過跑單元測試和接口測試代碼，完全可以第一時間回歸到改動是否影響了其他代碼，而不用非要等功能測試的時候才能驗證。

　　6. 頁面自動化

　　進入系統測試階段，開發的主要工作變成了修改bug，工作變得相對輕松了，而傳統意義上的測試工作真正開始了，測試的工作開始繁重，如果前期的單元測試，接口測試做的出色的話，這個階段發現的bug可能更多的集中于前端bug或者就是需求變更，前端bug的預防減少，涉及到前端測試的內容，暫時不進行討論，真正功能性的bug是相對較少的，這個時候開發可以做什么，可以做頁面自動化的腳本編寫。編碼是開發擅長的，只要開發掌握了自動化測試框架，知道哪些用例需要寫自動化腳本，開發寫自動化腳本是非?？焖俚?。至于開發自動化框架的培訓可以在項目需求階段進行，自動化測試用例的抽取可以在測試設計階段完成。

　　這樣，在項目測試階段，單元測試，接口測試在持續的進行，可以快速發現，定位代碼變化引起的問題，降低溝通成本，增加開發空余時間用來寫自動化腳本，等項目測試完成后，頁面自動化腳本又可以基本完成，立體的一套自動化測試體系初步構建完成，在這個過程中，開發和測試密切配合降低了無謂的溝通成本，提高了產出效率，增強了項目的質量。

　　7. 項目維護

　　產品發布了，并不意味著產品的結束，各種新的需求都會以日常的形式來進行，日常有大有小，而針對日常的測試也應該視日常大小而進行，一些小的，簡單的日常完全可以由開發自己開發并測試完成，通過前面在項目中的自測過程，開發對測試流程非常的屬性了，小日常完全可以應付，并且當開發認為沒有測試去測試的時候，自測會更加認證，而對于一些大日常的測試，則可以參考前面整個的流程進行開發自測的展開。其實，在項目維護階段，針對不同的子應用或者模塊，可以形成模塊開發負責制，每個模塊，應用都有一個開發進行負責，負責人對自己負責模塊的需求，開發，質量保證都需要了解，這樣可以增加開發的質量意識，降低變化引起的風險。

　　開發自測看起來很美好，但是實施起來卻存在，首先，開發會排斥進行測試，其次，開發做測試會比較隨意喜歡一次性的測試，第三，開發會認為自己的測試不專業，還需要測試進行測試浪費資源。因為這些原因，開發自測不是一蹴而就的，需要不斷的推進，為開發自測提供基礎支持，讓開發養成自測的習慣，并且意識到自測對于保證項目質量，提高效率的重要性，只有開發從心底愿意進行自測，開發測試才算是真正運行有效的。

　　開發自測的目的并不是增加開發的工作量，降低測試的工作量，而是要弱化開發/測試的角色，降低開發/測試的對立，通過開發和測試的共同努力，揚長避短，形成一套立體的質量保證體系。

原文轉自：http://www.kjueaiud.com