對于大型項目，軟件測試的執行，除了需要很好的測試范圍分析、測試計劃制定和測試資源的分配與組織之外，還是有一個容易被大家忽視的策略問題。
如何更早地發現缺陷又不增加風險?測試的本質是什么，發現缺陷還是風險評估?如何引導大家向著一個目標——產品及時高質量發布努力?
1. 首先就要向測試人員灌輸一個概念——“測試的一般工作就是發現缺陷 (detect bug)”，達成共識，這是很重要。這樣，測試人員，就知道什么是自己真正的工作。這一點，不僅在測試執行時發揮作用，而且在設計測試用例時更能發揮作用。
2. 測試執行階段可以劃分為兩個子階段，前一個階段的目的非常清楚，就是發現缺陷，督促大家就是找出缺陷。測試用例的執行，應該是幫助我們更快地發現缺陷，而不是成為“發現缺陷”的障礙——使發現缺陷的能力降低。從理論上說，如果缺陷都找出來了，質量也就有保證了。所以在這一階段，要不顧風險，就是發現缺陷，這樣不僅對開發團隊也非常有利，能盡早地修正大部分缺陷;對測試有利，測試效率高，后面的回歸測試也會穩定，信心更充分。
3. 在代碼凍結或產品發布前的稍后的子階段，目的是減少風險，增加測試的覆蓋度，這時測試的效率會低一些，以損失部分測試效率以極大降低風險、獲得更高質量的收益。
4. 在前一階段，測試用例的執行速度要低一些，測試人員多思考，多做些ad-hoc 測試，這樣又幫助提高測試用例的質量，從而對隨后的回歸測試提供了更有力的保障。
5. 測試執行要進行有效監控，包括測試執行效率(缺陷數/KTC, KTC = 1000 test cases)、Bug歷史情況和發展趨勢等。根據獲得的數據，必要時對測試范圍、測試重點等進行調整，包括對測試人員的調整、互換模塊等手段，提高測試覆蓋度，降低風險
6. 測試總是是有風險的，正是始終存在的風險，使之測試更具有藝術性。
開發一個軟件產品，會發布多個版本，伴隨著測試用例(Test case)的不斷維護, 使測試用例不斷完善并與產品功能、特性(features)的變化保持一致，所以測試用例是和產品版本相關聯的。特別是對提供軟件服務的軟件產品，多個版本常常共存，為客戶提供服務，這時多個版本的測試用例也是并存的，所以在新建、修改、刪除測試用例時要十分小心，并有相應的規則。
根據產品特性和test case一致性，分下面幾種情況分別處理：
1. 產品特性沒變，只是根據Late Discovery Bug 或 Remedy Ticket 來完善 test case，只有這時候可以修改Test case, 也就意味著當前修改的test case，對目前和以前的版本都有效。
2. 原有產品特性發生了變化，不是new feature, 而是enhanced features(功能增強), 這時候原有的 test case 只對先前版本(如version 1.0、2.0) 有效，而對新的版本(如 version 3.0)無效，這時絕不能修改 test case ，只能增加新的 test case，這一點很重要。原有的 test case 依然對原有版本有效(如version 1.0、2.0)。
3. 完全新增加的特性，大家比較清楚，增加對應的、新的測試用例。
4. 原有功能取消了，這時只要在新版本上使之對應的test case置為inactive(無效)。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
