在互聯網產品中，每個產品的迭代速度越來越快，項目中的測試同學面臨著前期需求搖擺不定，后面發布時間卡在那里，項目的前期階段似乎總是在壓榨著測試的執行時間。

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

　　在說下面內容前，我必須感慨下，測試是個偉大的職業，是技術上的全才，是項目中的大管家。什么編碼能力，測試技能，產品思想，設計架構等十八般武藝樣樣都會。       

　　Ø  立項前

　　項目目標要明確，最好有量化指標。產品需求是否為項目目標服務？有些項目，目標定的很好，但是需求列表，經不住推敲，與項目目標關聯不強。特別是很多東西是基于假設，而這種假設是站不住腳的。可以在項目前期，果斷的拒絕這類項目，或砍掉部分不現實的需求。減少項目后期的需求變更。這樣做，還可以減少上線后不必要的修復、N次迭代和解釋工作。

　　Ø  需求階段

　　需求一定是有優先級和重要程度的。對于嘗試性的需求，在保障質量的同時，盡量少的投入工作量。對重要程度高的功能，優先保障自動化覆蓋，無論是在本次項目中，還是下幾個版本的迭代中可以不斷的進行重復測試，保障最核心功能的質量。測試人在需求分析階段盡可能的分解需求，通過場景法及各種異常情況下，產品的功能是否完善，提前發現問題。

　　同時，在這個階段，測試可以發揮自己的邏輯性強的優勢，幫助產品經理和開發們理清細節邏輯，讓產品更豐滿清晰，而不是干癟癟主流程，這樣會讓項目后期更可控，減少后面不必要的產品經理、開發、交互、測試之間的細節確認時間，減少后面的需要變更次數。

　　不合理的需要可以大膽的去砍掉。有多少上線后就無人問津的生僻功能，這些產品的功能如果能在需求階段就砍掉，不知要省多少人工成本。測試同學可以更自信些，敢于挑戰不合理的需求。

　　Ø  設計階段  

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

　　Ø  編碼階段

　　保障自動化的覆蓋率

　　一定程度的自動化覆蓋率，可以減少項目過程中不斷的修復，迭代提交測試的重復測試。

　　測試驅動開發    

　　這里的測試驅動開發不是嚴格意義上的。因為在短平快的項目中，在一個未發展完全的團隊中，我們還不能在編寫某個功能代碼前，先編寫測試代碼。至于為什么不能，就不在這里贅述了。我想說的測試驅動開發是指利用測試的邏輯嚴密性，邏輯完善性，來指導開發編碼代碼。具體做法，在UC產出后，測試人員第一時間產出TC，并完成TC評審。這里指的評審是開發和測試、PD都在的外審。確保大家對需求的理解一致，產品功能的處理方式理解一致，這一點非常重要。之后，開發在編碼時，可以參考測試TC盡可能完善的考慮各種場景，異常流等。減少后期發現bug、提交bug、修復bug、再重復驗證bug等一系列返工。

　　代碼走讀

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

　　Ø  提測后 

　　基本上還是常規做法。

　　大家會看到，在測試執行階段減少的工時，被我們大大的拉到項目前期去了。也是永遠不變的那句話“測試往前走，越早發現問題越好”。