測試生存指南！如何在快速迭代的專案中減少返工？

 

1、概述

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

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

 

2、立項後

專案目標要明確，最好有量化指標。

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

 

3、需求分析階段

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

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

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

 

4、設計階段

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

 

5、編碼階段

測試驅動開發

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

 

6、程式碼走讀

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

 

7、提測後

現在是測試人員發揮的時間了

大家會開導，在測試執行階段浪費的工時，被我們大大的拉到專案前期去了。還是那句話 “測試儘量往前走，越早暴露問題越好”。bug越晚修復，付出的成本越高，代價越大 。