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