如何在快速疊代的項目中減少測試返工

　　在網際網路産品中，産品的疊代速度越來越快，項目中的測試同學面臨着前期需求搖擺不定，中間各種開發進度死鎖，而釋出時間卻無法推遲。項目的前期階段似乎總是在壓榨着測試的執行時間。

　　如何減少測試返工，測試階段的工作量的同時，保障項目品質?

　　立項後

　　項目目标要明确，最好有量化名額。

　　産品需求是否為項目目标服務?有些項目，目标定的很好，但是需求清單，經不住推敲，與項目目标弱關聯甚至沒有關聯。乃至于很多需求都是基于假設，但這種假設卻經不起推敲。我們測試人員可以在項目前期，果斷的拒絕這類項目，或砍掉部分不現實的需求。減少項目後期的需求變更。這樣做，還可以減少上線後不必要的修複、縮減N次疊代，避免扯皮。

　　

　　

　　需求分析階段

　　需求一定要有優先級和重要程度。對于嘗試性的需求，在保障品質的同時，盡量減少投入工作量。對核心功能，優先保障自動化覆寫。無論是在本次項目中，還是後續版本的疊代中需要不斷的進行重複測試，保障最核心功能的品質。測試人在需求分析階段盡可能細的拆分需求，通過場景法及各種異常分支流，驗證産品的功能是否完善，提前發現問題。

　　在這個階段，測試需要發揮自己的邏輯性思維優勢，幫助産品經理和開發們理清細節邏輯，讓産品更豐滿清晰，而不是幹癟癟走主流程。這樣會讓項目後期風險更可控，減少後期産品經理、開發、互動、測試之間的扯皮時間，減少需要變更次數。

　　不合理的需要要大膽的砍掉。試問有多少上線後就無人問津的生僻功能在前期白白浪費了大家的時間?這些産品的功能如果能在需求階段就砍掉，不知道可以節省多少人力成本。測試同學們可以更自信些，敢于向不合理的需求說NO。

　　設計階段

　　提高可測性設計，在設計階段，除關注産品的實作外，測試人員必須關注可測性設計。一個可測性設計好的産品，在測試執行過程中，可以大大減少測試執行時間，bug原因定位時間，測試驗證時間。

　　編碼階段

　　測試驅動開發

　　這裡的測試驅動開發不是嚴格意義上的。因為在短平快的項目中，在一個未發展完全的團隊中，我們還不能在編寫某個功能代碼前，先編寫測試代碼。這裡的測試驅動開發是指利用測試的邏輯嚴密性，邏輯完善性，來指導開發編碼代碼。具體做法，測試人員第一時間産出業務邏輯導圖，并完成導圖評審。這裡指的評審是開發和測試、産品都在的外審。確定大家對需求的了解一緻，産品功能的處理方式了解一緻，這一點非常重要。之後，開發在編碼時，可以盡可能完善的考慮各種場景，異常流等。減少後期發現bug、送出bug、修複bug、再重複驗證bug等一系列返工。

　　代碼走讀

　　在開發編碼過程中，必要時進行代碼走讀，補充測試。這個過程，早期發現開發代碼級bug，又增加測試覆寫度，進而減少測試過程中反複，減少測試返工。

　　提測後