1.明確需求範圍和重點
在開需求會的時候，明確本次需求作用的是那個模塊，可能會影響到哪些模塊。之前有沒有類似的需求，測試的重點是什麼，需求模塊之間的優先級是什麼。將這些問題提前處理掉
2.設計高效的測試用例
- 畫流程圖，梳理流程和數據流轉
- 畫狀態轉換圖，因果圖等分析流程
- 編寫測試用例，去重（異常測試等價類，測試數據等價類，測試步驟等價類，測試結果等價類）
![在這裏插入圖片描述]()
3.測試用例評審，技術評審
4.核心用例開發自測
5.不做無效的測試
如果需求的冒煙測試質量比較低，由多個較爲嚴重的BUG，甚至可能阻塞測試流程，測試可以將需求打回，讓開發重新自測。一方面是因爲功能阻塞，下游的功能無法完成測試，另一方面，新的問題可能還是由於已存在的BUG引起的。
6.不做重複的測試
熟悉整個項目的架構，相互的關係。很多看似不同的測試點，實際只是一個測試點，僅僅是外面的包裝不同。
當一個測試點出現問題時，那麼其他的測試點也可能有問題，其他的可暫時先不用測試了。提BUG的時候可以列出核心問題所在，並將其他涉及的點提出來。等驗證的時候，再把涉及的測試點都過一遍，這樣就減少了很多重複的工作，只是在驗證的同時把測試點覆蓋全。
7.不同測試版本的測試重點
對於測試來講，基本上一個需求要驗證三個版本，（test 環境，beta環境，product環境）。如果每個需求都要詳細的過一遍，遇到大需求的話，測試估計會累死。
如果針對三個環境，進行一個合理的分配和取捨，測試也會減少很多工作量。
結合日常的工作，提供一個思路：
test環境：驗證BUG，全面測試，儘可能找出所有的BUG。
beta環境：驗證上一輪的bug;
prod環境：驗證全部bug，並全面細測。
這樣其實只是第一輪和最後一輪需要全面測試，這樣對於測試輪數多的情況下又能節約很多測試時間。另外一般beta環境的數據庫和線上的數據庫是一個，數據不可以隨便增刪改，風險較高，對數據的操作更多的集中在test環境。即使生成髒數據也沒有關係。
8.優化測試順序
先接口，後功能；先異常情況，後正常情況。
冒煙測試的時候，開發基本會把正向工作流程走一遍，沒有問題纔會提測，這個無疑給我們節省了時間，那麼接下來，作爲測試，我們拿到一個產品，可以先從接口開始測試。
執行接口測試時候，可以先進行單接口測試，校驗單接口的輸入輸出參數是否符合要求。如果接口有傳入新的參數，可以從：合法但不符合要求的參數，不合法也不符合要求的參數等，然後再簡單過一下正合法的參數。對於輸出參數，也是同理。當單個接口麼有問題，可以考慮將接口進行串聯，流程性測試。
當接口測試通過，說明後端的處理邏輯基本符合要求，接下來就進行功能的測試，不關注產品內部如何交互，進行黑盒測試。再進行測試的時候，也可以優先考慮異常流程，
這裏藉助一個例子：
就拿註冊功能來說，一般會分爲3個步驟，註冊，驗證，登錄，一般正常情況都是先測試正常註冊，正常驗證，正常登錄，然後測試異常註冊，異常驗證，異常登錄。但這樣有一個缺點，會有重複無用的操作：
當完成正常測試後再測試異常之前，需要從登錄狀態退出，然後再點擊註冊入口進行註冊。
當測試異常驗證的時候，需要再次測試正常註冊，不然就進入不了驗證的步驟。
當測試異常登錄的時候，又需要再次測試正常驗證，不然就進入不了登錄的步驟。就這3點也許大家覺得最多浪費幾十秒的時間，但如果註冊信息要填很多呢，如果驗證郵件或者短信要延遲很久才收到呢，這樣就是浪費了幾分鐘吧。如果有其中有bug，那可能要測試多次來定位問題，那就可能浪費了10分鐘，而這僅僅是一個並不複雜的測試，如果涉及到更復雜的關聯，可能會浪費更多的時間在於無效和重複的測試中。
那麼問題來了，這麼調整測試順序呢?
先測試異常註冊，輸入各種錯誤的註冊信息，如果沒有bug的情況下是跳不到驗證界面的
然後測試正常註冊，可以正常跳到驗證界面
接着測試異常驗證，如果沒有bug的情況下是跳不到登錄界面的
再測試正常驗證，可以正常跳到登錄界面
再測試異常登錄，如果沒有bug的情況下是無法正常登錄的
最後測試正常登錄，可以登錄完成這樣其實覆蓋的測試點一個沒少，但卻沒有無效和重複的測試，調整順序之後可以減少不必要的操作，積少成多的節約測試時間。
9.他山之石可以攻玉
對於實在無法避免的重複勞動，可以藉助自動化測試技術取解決，這一點需要基礎的編程能力，同時也需要適合的工具，