程序員應該如何測試自己的程序代碼

　　開發自測被多個團隊實踐，開發自測的效果也是不一而足的，具體怎么樣的開發自測方式是更好的，每個人都有自己的觀點和看法，這里說說自己對開發自測的方法的一些探討。

　　一、傳統研發流程的弊病

　　在討論開發自測之前，我們先看看未進行開發自測的研發流程

　　從這個流程可以看出

　　1. 開發和測試處于兩條線，開發實現功能，測試確保開發實現功能是正常的。

　　2. 對于項目質量的保證工作都在開發編碼完成后進行，雖然有時候可能開發完成一部分編碼后測試就可以進行測試了。

　　3. 項目質量的保證完全由測試負責，開發只管實現功能

　　這個流程最容易出現的問題是

　　1. 測試介入時間較晚，bug修復成本大。

　　2. 開發提測的版本不穩定，Bug多，因為開發不對質量負責，開發自認為實現了功能或者說修改了bug，至于實現或者修復bug是否有影響開發并不關心，導致一個功能或者bug反復修改，反復測試，溝通成本高，容易導致項目延期

　　3. 如果開發延期提交測試，測試時間被壓縮， 項目上線質量不高，事實上，在產品過程中這種情況經常出現。

　　4. 測試和開發對立，開發認為測試做的都是低級工作卻總是找自己麻煩，而測試覺得開會沒有做好產品，代碼質量低。

　　不論從測試效率還是項目質量來說，開發不參與測試對產品/項目來說是沒有好處的，于是經歷過這些痛苦之后，開始強調開發自測。

　　二、開發自測的不同需求

　　通常情況下，我們要求開發自測，開發會同意自測，他們的做法是在提交測試代碼之前，本地的程序調通，主線流程可以走通，然后告訴測試說，已經做過測試了，沒有任何的測試設計，沒有任何的測試結果，這樣的開發自測，雖然可以降低一部分顯而易見的bug數量，但是對于產品的質量或者風險并沒有降低多少。

　　理想中的開發自測，希望開發對于編寫的每個方法都有測試方法，對于每個uc都有正常流程，異常流程的測試，希望開發可以像測試一樣去思考，可以像測試一樣的耐心細致，發散思維，有明確的測試過程和結果，并且能夠對產品的質量負責?？墒情_發并不這么想，他們認為，系統設計，技術架構，追求高技術的代碼才是他們的首要工作，他們實現了產品的需求，他們的工作算是完成了，他們會寫點單元測試，或者他們想了解測試是怎么做的， 也會去做一些測試的工作，這些或許只是他們的業余工作或者愛好而已。當測試要求他們寫單元測試，接口測試，寫測試報告的時候，他們會表現的非常的反感，為了不擴大事態，測試只好對開發自測的結果不做評定，依然還按照既有的方式進行測試。

　　測試期望的開發自測和開發自認為的自測是完全不同的，也可以說，會有對立的一面，但是我們都知道bug越早發現，解決的成本越低，風險也越小。如果都在測試過程中測試，都有測試去測試，那么測試發現的bug要確認，提到缺陷管理庫中，開發看到bug再模擬場景，查看代碼，修復，然后再提交測試，驗證，通過后再關閉bug，這個過程中的溝通，確認，還有打開一系列系統的時間是非常浪費的，而且開發也不希望自己在專心做事情的時候被打擾。

　　三、不同類型的開發自測探討

　　了解了測試和開發對開發自測不同的需求后，對于測試，還需要了解測試的種類，通俗的來說，測試可以分為單元測試，接口測試，系統測試，單元測試主要是針對單個方法的測試，接口測試更多的是集成測試，而系統測試，則是站在用戶使用場景，對整個系統進行測試，而無論是單元測試，接口測試，還是系統測試，都可以進行自動化測試。

　　針對不同的測試類型，開發自測的方法也是不同的，下面逐一探討。

　　一般的研發流程是這樣的

　　1. 需求分析

　　針對一個需求，開發考慮的是如何實現這個需求，或許這個需求可能不合理，但是，測試首先要考慮的是，這個需求是否符合用戶的習慣，然后再考慮如何去測試這個需求，在需求評審階段，針對某個需求，要進行充分的交流，確保開發和測試對需求的理解是一致的，并且這個需求是有必要實現的，重復的需求討論對理解整個需求實現的目的，實現的方法都有重要的價值，這也算是一種開發自測。

　　2. 分析設計

　　分析設計其實就是UC設計及技術方案設計，在這個階段，測試完全可以參與UC設計，技術方案設計，了解開發的設計思路，根據UC及設計進行測試策略的設計，比如項目需要用到哪些測試類型，不同的測試類型具體怎么做，是否需要針對特定的測試類型進行測試框架的開發，有哪些測試場景，這些測試場景的測試是否需要特定的測試數據。當測試參與分析設計并且將針對這個需求的測試思路和開發進行溝通，那么開發不但對如何實現需求有了清晰的思路，對如何測試需求也有了清晰的思路，這樣開發在實現需求的時候，就會考慮會有哪些業務場景，會有哪些異常情況，會有哪些測試點，談不上是測試驅動開發，但是對于業務場景的全面性，對于程序代碼的可測性都是非常好的幫助，而且對于后面具體測試類型的開發自測展開也是非常有好處的。

　　3. 單元測試

　　技術方案確定后，開發完全進入了編碼階段，這個時候，開發最煩思路被打斷，但是，我們通常都會要求開發寫單元測試，理由是，首先，一個方法有測試代碼證明這個方法是按照預期方式進行的，其次也需要確保這個方法被其他方法調用時能夠正常調用，開發會認同單元測試由開發編寫，也會對對一些的簡單方法，寫一個正常流程的測試方法，但是往往開發寫了測試代碼，準備了測試數據，只保證在測這個方法的時候，測試代碼是可運行的，而一旦測試數據被改動了，或者程序有改動，測試方法便無法執行了，而對于那些需要依賴外部環境或者第三方接口的方法，開發幾乎是不會去寫測試代碼的，這樣，開發雖然寫了單元測試代碼，但是單元測試代碼是不可用的，對開發來說是浪費時間，對測試來說，讓開發做單元測試，結果卻沒有效果。

原文轉自：http://www.anti-gravitydesign.com