做測試的都會遇到過：開發(fā)提交的版本質(zhì)量太差链峭！開發(fā)人員提交測試后發(fā)現(xiàn)大部分主要功能都不通，后續(xù)告知修復(fù)完成疑苫，測試人員又去驗證熏版，結(jié)果還是大部分功能不通，這樣的效率實在讓人無法忍受捍掺。
開發(fā)自測自然在測試人員心中出現(xiàn)撼短！質(zhì)量的提升不只是測試團(tuán)隊的事情，這句話貌似都在說挺勿，跟在喊口號一樣曲横，并不能帶來實際的效果。開發(fā)自測，也是在質(zhì)量提升方面占著重要的一環(huán)禾嫉。
開發(fā)自測灾杰，按照比較理想的情況下，開發(fā)人員寫完一個功能模塊都會去做自測熙参。然而艳吠，理想和現(xiàn)實總有一些差距，實際的情況是開發(fā)提交的版本孽椰，常常BUG較多昭娩，極端一點就是文章開始提到的例子，也是比較極端的情況黍匾，主要功能流程都跑不通栏渺。類似的情況做測試稍微長一點的人估計都會遇到。這樣的情況會影響效率锐涯，如果提交的質(zhì)量很差磕诊，在測試階段發(fā)現(xiàn)BUG較多，最后上線的質(zhì)量不會太好纹腌，或者影響上線時間霎终。APP質(zhì)量的提升很重要的一點就是提高研發(fā)人員提交版本的質(zhì)量。
建立一個可以度量的指標(biāo)壶笼，研發(fā)提交測試后主功能流程測試通過神僵，如果主功能流程都有問題的話，那么覆劈，是可以打回的保礼。或者時間允許按照用例執(zhí)行結(jié)果BUG較多责语，也可打回修改炮障。
那么是開發(fā)自測可以發(fā)現(xiàn)的BUG？如何判定坤候？在主功能流程上BUG或顯而易見的BUG胁赢。還有就是給開發(fā)提供一些自測用例，那么在自測用例里面的BUG就屬于開發(fā)人員自測可以發(fā)現(xiàn)的BUG白筹，這種方式更明確一些智末。
大部分的開發(fā)人員還是非常希望自己做出的產(chǎn)品有比較好的質(zhì)量的。很多開發(fā)人員也都會在做完項目提測之前進(jìn)行基本的驗證徒河，相對比較零散系馆，因此也有部分開發(fā)人員參考測試人員的用例。那么測試人員設(shè)計出的測試用例量較大顽照，考慮各種異常場景由蘑，各種復(fù)雜的情況闽寡。用例量比較大開發(fā)執(zhí)行不方便，花費時間太長尼酿。所以爷狈，只要提供一份主功能流程的核心用例給開發(fā)人員做自測使用，提交測試時一并反饋自測結(jié)果裳擎。以上這些方法要討論得到開發(fā)負(fù)責(zé)人的認(rèn)可涎永。
開發(fā)人員自測所發(fā)現(xiàn)BUG數(shù)量和比例有沒有下降？有沒有認(rèn)真執(zhí)行句惯？測試階段有哪些BUG應(yīng)該通過自測用例發(fā)現(xiàn)的土辩，但是被測試人員在測試階段發(fā)現(xiàn)。對于這種BUG很有必要拿出來可以一起討論下抢野，為什么沒有在自測階段發(fā)現(xiàn)？找出沒有發(fā)現(xiàn)的原因來各墨。任何一個質(zhì)量提升的流程指孤，要有度量反饋機(jī)制，這樣才能達(dá)到相應(yīng)的效果贬堵。
從測試人員的角度看恃轩，要做出高質(zhì)量的好產(chǎn)品，開發(fā)自測環(huán)節(jié)必不可少黎做，不管是APP測試還是手游測試有開發(fā)自測的步驟都會對產(chǎn)品質(zhì)量的總體提手有很大幫助叉跛。
