開發自測？開發與測試的戰爭

作測試的都會遇到過：開發提交的版本質量太差！開發人員提交測試後發現大部分主要功能都不通，後續告知修復完成，測試人員又去驗證，結果仍是大部分功能不通，這樣的效率實在讓人沒法忍受。

開發自測天然在測試人員心中出現！質量的提高不僅是測試團隊的事情，這句話貌似都在說，跟在喊口號同樣，並不能帶來實際的效果。開發自測，也是在質量提高方面佔着重要的一環。

開發自測，按照比較理想的狀況下，開發人員寫完一個功能模塊都會去作自測。然而，理想和現實總有一些差距，實際的狀況是開發提交的版本，經常BUG較多，極端一點就是文章開始提到的例子，也是比較極端的狀況，主要功能流程都跑不通。相似的狀況作測試稍微長一點的人估計都會遇到。這樣的狀況會影響效率，若是提交的質量不好，在測試階段發現BUG較多，最後上線的質量不會太好，或者影響上線時間。APP質量的提高很重要的一點就是提升研發人員提交版本的質量。

創建一個能夠度量的指標，研發提交測試後主功能流程測試經過，若是主功能流程都有問題的話，那麼，是能夠打回的。或者時間容許按照用例執行結果BUG較多，也可打回修改。

那麼是開發自測能夠發現的BUG？如何斷定？在主功能流程上BUG或顯而易見的BUG。還有就是給開發提供一些自測用例，那麼在自測用例裏面的BUG就屬於開發人員自測能夠發現的BUG，這種方式更明確一些。

大部分的開發人員仍是很是但願本身作出的產品有比較好的質量的。不少開發人員也都會在作完項目提測以前進行基本的驗證，相對比較零散，所以也有部分開發人員參考測試人員的用例。那麼測試人員設計出的測試用例量較大，考慮各類異常場景，各類複雜的狀況。用例量比較大開發執行不方便，花費時間太長。因此，只要提供一份主功能流程的核心用例給開發人員作自測使用，提交測試時一併反饋自測結果。以上這些方法要討論獲得開發負責人的承認。

開發人員自測所發現BUG數量和比例有沒有降低？有沒有認真執行？測試階段有哪些BUG應該經過自測用例發現的，可是被測試人員在測試階段發現。對於這種BUG頗有必要拿出來能夠一塊兒討論下，爲何沒有在自測階段發現？找出沒有發現的緣由來。任何一個質量提高的流程，要有度量反饋機制，這樣才能達到相應的效果。

從測試人員的角度看，要作出高質量的好產品，開發自測環節必不可少，不論是APP測試仍是手遊測試有開發自測的步驟都會對產品質量的整體提手有很大幫助。