做測試的都會遇到過：開發提交的版本質量太差！開發人員提交測試後發現大部分主要功能都不通，後續告知修復完成，測試人員又去驗證，結果還是大部分功能不通，這樣的效率實在讓人無法忍受。
開發自測自然在測試人員心**現！質量的提公升不只是測試團隊的事情，這句話貌似都在說，跟在喊口號一樣，並不能帶來實際的效果。開發自測，也是在質量提公升方面佔著重要的一環。
建立乙個可以度量的指標，研發提交測試後主功能流程測試通過，如果主功能流程都有問題的話，那麼，是可以打回的。或者時間允許按照用例執行結果bug較多，也可打回修改。
那麼是開發自測可以發現的bug？如何判定？在主功能流程上bug或顯而易見的bug。還有就是給開發提供一些自測用例，那麼在自測用例裡面的bug就屬於開發人員自測可以發現的bug，這種方式更明確一些。
大部分的開發人員還是非常希望自己做出的產品有比較好的質量的。很多開發人員也都會在做完專案提測之前進行基本的驗證，相對比較零散，因此也有部分開發人員參考測試人員的用例。那麼測試人員設計出的測試用例量較大，考慮各種異常場景，各種複雜的情況。用例量比較大開發執行不方便，花費時間太長。所以，只要提供乙份主功能流程的核心用例給開發人員做自測使用，提交測試時一併反饋自測結果。以上這些方法要討論得到開發負責人的認可。
開發人員自測所發現bug數量和比例有沒有下降？有沒有認真執行？測試階段有哪些bug應該通過自測用例發現的，但是被測試人員在測試階段發現。對於這種bug很有必要拿出來可以一起討論下，為什麼沒有在自測階段發現？找出沒有發現的原因來。任何乙個質量提公升的流程，要有度量反饋機制，這樣才能達到相應的效果。
開發自測的原則
我是一名開發 在咱們開發的時間中,其實coding的時間所佔比例大概為30 大部分時間都在自測和改bug 但是許多新人覺得coding才是最重要的,而且把大部分精力花在coding上,其他的 自測,改bug,重構 不太重視 自測和改bug,歸根結底就是解決問題.解決問題的第一步,就是了解問題的現象,...
Android APP開發自測點
功能完成後，自測時的檢查點 1.思考某些情況下，某個變數是否會造成空指標問題 2.把手機橫屏，檢查布局是否有bug 3.在不同解析度的機型上，檢查布局是否有bug 4.切換到英文等外文本型下，檢查外文是否能完整顯示 5.從低版本公升級上來，會不會有問題，比如可能會出現資料庫不相容的問題 6.按下ho...
開發自測模式實踐
背景 長期以來業務線測試有這種困擾 業務線傳統的專案流程把開發 測試兩個階段分得比較明顯，導致開發趕時間寫 提測階段測出一些低階bug 重新返工不僅測試時間延長，也導致開發 測試同學都累。在天彤的支援下，本人今年3月份來到c2b市場團隊輪崗開發，實踐了開發自測的專案模式。這是乙個新產品團隊，新模式比...