開發自測被多個團隊實踐，開發自測的效果也是不一而足的，具體怎么樣的開發自測方式是更好的，每個人都有自己的觀點和看法，這里說說自己對開發自測的方法的一些探討。
一、傳統研發流程的弊病
在討論開發自測之前，我們先看看未進行開發自測的研發流程
從這個流程可以看出：
1、開發和測試處于兩條線，開發實現功能，測試確保開發實現功能是正常的。
2、對于項目質量的保證工作都在開發編碼完成后進行，雖然有時候可能開發完成一部分編碼后測試就可以進行測試了。
3、項目質量的保證完全由測試負責，開發只管實現功能
這個流程最容易出現的問題是：
1、測試介入時間較晚，bug修復成本大。
2、開發提測的版本不穩定，Bug多，因為開發不對質量負責，開發自認為實現了功能或者說修改了bug，至于實現或者修復bug是否有影響開發并不關心，導致一個功能或者bug反復修改，反復測試，溝通成本高，容易導致項目延期
3、如果開發延期提交測試，測試時間被壓縮， 項目上線質量不高，事實上，在產品過程中這種情況經常出現。
4、測試和開發對立，開發認為測試做的都是低級工作卻總是找自己麻煩，而測試覺得開會沒有做好產品，代碼質量低。
不論從測試效率還是項目質量來說，開發不參與測試對產品/項目來說是沒有好處的，于是經歷過這些痛苦之后，開始強調開發自測。
二、開發自測的不同需求
通常情況下，我們要求開發自測，開發會同意自測，他們的做法是在提交測試代碼之前，本地的程序調通，主線流程可以走通，然后告訴測試說，已經做過測試了，沒有任何的測試設計，沒有任何的測試結果，這樣的開發自測，雖然可以降低一部分顯而易見的bug數量，但是對于產品的質量或者風險并沒有降低多少。
理想中的開發自測，希望開發對于編寫的每個方法都有測試方法，對于每個uc都有正常流程，異常流程的測試，希望開發可以像測試一樣去思考，可以像測試一樣的耐心細致，發散思維，有明確的測試過程和結果，并且能夠對產品的質量負責。可是開發并不這么想，他們認為，系統設計，技術架構，追求高技術的代碼才是他們的首要工作，他們實現了產品的需求，他們的工作算是完成了，他們會寫點單元測試，或者他們想了解測試是怎么做的， 也會去做一些測試的工作，這些或許只是他們的業余工作或者愛好而已。當測試要求他們寫單元測試，接口測試，寫測試報告的時候，他們會表現的非常的反感，為了不擴大事態，測試只好對開發自測的結果不做評定，依然還按照既有的方式進行測試。
測試期望的開發自測和開發自認為的自測是完全不同的，也可以說，會有對立的一面，但是我們都知道bug越早發現，解決的成本越低，風險也越小。如果都在測試過程中測試，都有測試去測試，那么測試發現的bug要確認，提到缺陷管理庫中，開發看到bug再模擬場景，查看代碼，修復，然后再提交測試，驗證，通過后再關閉bug，這個過程中的溝通，確認，還有打開一系列系統的時間是非常浪費的，而且開發也不希望自己在專心做事情的時候被打擾。
三、不同類型的開發自測探討
了解了測試和開發對開發自測不同的需求后，對于測試，還需要了解測試的種類，通俗的來說，測試可以分為單元測試，接口測試，系統測試，單元測試主要是針對單個方法的測試，接口測試更多的是集成測試，而系統測試，則是站在用戶使用場景，對整個系統進行測試，而無論是單元測試，接口測試，還是系統測試，都可以進行自動化測試。
針對不同的測試類型，開發自測的方法也是不同的，下面逐一探討。
一般的研發流程是這樣的：
1、需求分析
針對一個需求，開發考慮的是如何實現這個需求，或許這個需求可能不合理，但是，測試首先要考慮的是，這個需求是否符合用戶的習慣，然后再考慮如何去測試這個需求，在需求評審階段，針對某個需求，要進行充分的交流，確保開發和測試對需求的理解是一致的，并且這個需求是有必要實現的，重復的需求討論對理解整個需求實現的目的，實現的方法都有重要的價值，這也算是一種開發自測。
2、分析設計
分析設計其實就是UC設計及技術方案設計，在這個階段，測試完全可以參與UC設計，技術方案設計，了解開發的設計思路，根據UC及設計進行測試策略的設計，比如項目需要用到哪些測試類型，不同的測試類型具體怎么做，是否需要針對特定的測試類型進行測試框架的開發，有哪些測試場景，這些測試場景的測試是否需要特定的測試數據。當測試參與分析設計并且將針對這個需求的測試思路和開發進行溝通，那么開發不但對如何實現需求有了清晰的思路，對如何測試需求也有了清晰的思路，這樣開發在實現需求的時候，就會考慮會有哪些業務場景，會有哪些異常情況，會有哪些測試點，談不上是測試驅動開發，但是對于業務場景的全面性，對于程序代碼的可測性都是非常好的幫助，而且對于后面具體測試類型的開發自測展開也是非常有好處的。
3、單元測試
技術方案確定后，開發完全進入了編碼階段，這個時候，開發最煩思路被打斷，但是，我們通常都會要求開發寫單元測試，理由是，首先，一個方法有測試代碼證明這個方法是按照預期方式進行的，其次也需要確保這個方法被其他方法調用時能夠正常調用，開發會認同單元測試由開發編寫，也會對對一些的簡單方法，寫一個正常流程的測試方法，但是往往開發寫了測試代碼，準備了測試數據，只保證在測這個方法的時候，測試代碼是可運行的，而一旦測試數據被改動了，或者程序有改動，測試方法便無法執行了，而對于那些需要依賴外部環境或者第三方接口的方法，開發幾乎是不會去寫測試代碼的，這樣，開發雖然寫了單元測試代碼，但是單元測試代碼是不可用的，對開發來說是浪費時間，對測試來說，讓開發做單元測試，結果卻沒有效果。
單元測試是最基本的，也是最容易執行的，更是成本最低的一種測試方法，讓開發做好單元測試，可以說是有了開發自測。開發不討厭寫代碼，而且還擅長寫代碼，但是開發厭惡搭建測試環境準備測試數據，而這恰恰是測試擅長的，那么，可以考慮針對單元測試可以為開發做些什么。就單元測試來說，除了xunit，Mock是最好的單元測試工具，讓開發掌握了mock技術，然后讓開發了解單元測試思路，開發會愛上單元測試的，開發也希望自己寫的代碼有測試代碼保證。關于單元測試，衡量的最常用的標準就是持續集成和代碼覆蓋率，讓開發寫單元測試代碼，還要讓開發能夠對單元測試有成就感，當開發的單元測試代碼每天都被構建并且將測試結果發送給開發，當有代碼變動引起了單元測試構建，構建結果發現了bug，開發會認識到單元測試的價值，會熱衷于進行單元測試，如果開發寫的代碼覆蓋率很高，對開發來說，也是一種成就感。
4、代碼review
開發完成了單元測試，組織開發進行代碼review也是非常有必要的，代碼review不完全是為了找出代碼中的錯誤，更重要的是可以讓有經驗的開發對代碼的設計進行審查，降低代碼的復雜度，耦合性，減少重復無用的代碼，能夠使得代碼更好的和其他系統進集成，同時，測試參與代碼review，可以對代碼的可測性提出建議。
代碼review看起來很美好，但是執行起來卻絕非易事，因為開發實現了某個功能，review的時候卻發現這種實現方式不是很美好，開發會覺得反正功能是可用的，等后面有時間再進行修改，這樣的理由也無可厚非，但是，現在的修改可能只是一兩個小時，后面的修改卻是一兩個日常，讓開發或者開發TL意識到這種時間的差別，可能對代碼review的接受程度會更高。
5、集成測試
我們做的接口測試，無論是service的接口測試還是web層的接口測試其實就是集成測試，因為都需要依賴一定的外部環境，比如數據庫，比如其他系統提供的接口，接口測試一般是在開發編碼完成以后進行，要進行開發自測，接口測試可以提前進行，在開發進行設計的時候，產品/項目需要幾個接口，這些接口需要哪些參數，實現什么功能其實已經是確定好了的，那么根據接口的定義，測試可以提前進行接口測試的準備，比如接口測試用例的設計，測試環境搭建，測試數據準備，根據這些內容看是否需要為產品，項目的接口測試開發新的接口測試的框架，這些都可以在開發進行編碼的時候完成。
開發編碼完成后，或者開發一兩個接口提測后，測試可以先行進行接口測試，理順測試環境，等開發編碼都完成后，集中開發/測試的力量，一鼓作氣將接口測試完成，編碼對開發來說不是什么難事，如果開發準備好了測試環境，有測試用例，有測試框架，開發完成接口測試的速度還是相當快的。
這里需要說明的是，開發可能會覺得單元測試做了，怎么還要做接口測試，單元測試和接口測試關注的重點不一樣，所以并沒有重復之說，而且，單元測試和接口測試是最底層，成本最低，且最容易自動化的測試手段，而且也是以開發最擅長的編碼方式進行。
開發寫接口測試，并不是說接口測試的工作也完全由開發來做，接口測試應該是開發和測試共同配合來完成，分別發揮各自的優勢又能分別學習各自的優勢。通過接口測試，開發可以學習測試思維，測試技巧，而開發也可以從開發那邊學習到開發技巧，更重要的是，做好了接口測試，在后續系統測試階段，就算是發現了bug，修改了代碼，通過跑單元測試和接口測試代碼，完全可以第一時間回歸到改動是否影響了其他代碼，而不用非要等功能測試的時候才能驗證。
6、頁面自動化
進入系統測試階段，開發的主要工作變成了修改bug，工作變得相對輕松了，而傳統意義上的測試工作真正開始了，測試的工作開始繁重，如果前期的單元測試，接口測試做的出色的話，這個階段發現的bug可能更多的集中于前端bug或者就是需求變更，前端bug的預防減少，涉及到前端測試的內容，暫時不進行討論，真正功能性的bug是相對較少的，這個時候開發可以做什么，可以做頁面自動化的腳本編寫。編碼是開發擅長的，只要開發掌握了自動化測試框架，知道哪些用例需要寫自動化腳本，開發寫自動化腳本是非常快速的。至于開發自動化框架的培訓可以在項目需求階段進行，自動化測試用例的抽取可以在測試設計階段完成。
這樣，在項目測試階段，單元測試，接口測試在持續的進行，可以快速發現，定位代碼變化引起的問題，降低溝通成本，增加開發空余時間用來寫自動化腳本，等項目測試完成后，頁面自動化腳本又可以基本完成，立體的一套自動化測試體系初步構建完成，在這個過程中，開發和測試密切配合降低了無謂的溝通成本，提高了產出效率，增強了項目的質量。
7、項目維護
產品發布了，并不意味著產品的結束，各種新的需求都會以日常的形式來進行，日常有大有小，而針對日常的測試也應該視日常大小而進行，一些小的，簡單的日常完全可以由開發自己開發并測試完成，通過前面在項目中的自測過程，開發對測試流程非常的屬性了，小日常完全可以應付，并且當開發認為沒有測試去測試的時候，自測會更加認證，而對于一些大日常的測試，則可以參考前面整個的流程進行開發自測的展開。其實，在項目維護階段，針對不同的子應用或者模塊，可以形成模塊開發負責制，每個模塊，應用都有一個開發進行負責，負責人對自己負責模塊的需求，開發，質量保證都需要了解，這樣可以增加開發的質量意識，降低變化引起的風險。
開發自測看起來很美好，但是實施起來卻存在，首先，開發會排斥進行測試，其次，開發做測試會比較隨意喜歡一次性的測試，第三，開發會認為自己的測試不專業，還需要測試進行測試浪費資源。因為這些原因，開發自測不是一蹴而就的，需要不斷的推進，為開發自測提供基礎支持，讓開發養成自測的習慣，并且意識到自測對于保證項目質量，提高效率的重要性，只有開發從心底愿意進行自測，開發測試才算是真正運行有效的。
開發自測的目的并不是增加開發的工作量，降低測試的工作量，而是要弱化開發/測試的角色，降低開發/測試的對立，通過開發和測試的共同努力，揚長避短，形成一套立體的質量保證體系。