三輪測試的流程框架在公司已經(jīng)運行了將近半年之久，從最近經(jīng)歷的項目有感而發(fā)，不知道算不算是個問題，還有待大家來評理一番，下面就先說說我的理解吧。
我們的三輪測試的指標是：第一輪是執(zhí)行完所有的測試用例；第二輪是解決完所有P1P2級的bug，第三輪就是解決完所有的bug，并要確保項目在項目測試環(huán)境下的功能是正確的。
那么我們現(xiàn)在來看看第一輪的文字含義，僅僅只是說執(zhí)行完所有的測試用例，并沒有提到需要驗證完當天fixed掉的bug，以我最近所經(jīng)歷的項目來說，在進入測試階段時，開始后的一連幾天new狀態(tài)的bug是直線上升，fixed掉的當然也是直線上升，而closed狀態(tài)的bug卻是幾乎為0，執(zhí)行TC進度也是直線上升，當然我們不能說這樣的數(shù)據(jù)是錯誤的，不符合正常的現(xiàn)象的。但是在我的理解看來，在第一輪的測試過程中，并不應該僅僅執(zhí)行完用例即可，也應該盡可能的驗證那些狀態(tài)已經(jīng)fixed掉的bug，當然在這里我并不是指所有的項目都是這個現(xiàn)象，也不能歸結(jié)為我們的三輪測試體系不合理，這應該是和測試人員的想法有關(guān)系，一方面可能項目測試時間緊張，執(zhí)行的時間都不夠，哪還有驗證的時間，反正第二輪、第三輪可以再驗證嘛。另一方面，也可能測試人員已經(jīng)在后續(xù)的執(zhí)行階段驗證過，但沒有去修改bug的狀態(tài)而已。
很多時候，開發(fā)人員認為已經(jīng)修改好的問題，并不一定就是正確的，在后續(xù)的測試過程中，我們一般不會花費很大精力去關(guān)注已經(jīng)提過bug 的功能點，可能會認為當我們執(zhí)行完第一輪后，到第二輪、第三輪的時候再去驗證在第一輪提出的問題，但這是存在一定的風險的，很有可能開發(fā)人員修改好這個問題后，卻可能引發(fā)其他問題的出現(xiàn)，而這些問題在第一輪的時候是正確的，而我們在后續(xù)的測試時間范圍內(nèi)因為考慮到之前測試時功能是正確的，而投入了極少量的精力放在上面，這很有肯能會遺漏掉很多問題所在。等到合到主干或日常下時，又發(fā)現(xiàn)一大堆的問題，很大程度上會影響我們對項目的質(zhì)量把關(guān)度。
所以最后我還是提倡在測試的過程中，當天發(fā)現(xiàn)的bug，開發(fā)人員盡量在當天解決，而測試人員盡可能的驗證完畢。這其中也有一定的優(yōu)點存在，當天驗證可以趁熱打鐵利用當初測試發(fā)現(xiàn)時的操作重新驗證，另外在印象深刻的情況下還可以引發(fā)更多的操作來驗證問題是否已經(jīng)修復好。而如果延后驗證的話，我們只會照搬缺陷描述的流程過一次，ok就pass，但還是會存在遺漏的可能性。
