2．明確測試的目標和任務
軟件測試的任務就是驗證軟件是否準確地實現了用戶需求，檢驗需求和軟件之間是否一致。好的測試用例能發現軟件中潛在的新缺陷，糟糕的測試用例在目標及任務尚不明確的情況下盲目進行評測，不僅效率低下，而且毫無效果。
3．分階段製訂測試計劃方案
測試計劃方案不是從頭到尾一成不變的，應根據企業應用軟件項目所處的不同階段製訂，不同的項目階段所需的測試方法是不一致的。可以借鑒RBT理論關於基於需求的測試方法的最佳實踐（參見鏈接）。
4．設計基於需求的複合測試用例
在很多情況下，單一的測試方法很難實現軟件缺陷或錯誤的全麵檢查，在軟件工程中使用最多的往往是組合多種測試方法的複合測試用例。例如黑盒測試和白盒測試兩者的功能作用就可以互相彌補，實踐中可以將兩種測試方法組合起來設計複合測試用例。
5．妥善處理測試和設計之間的關係
測試是“破壞性”的，而開發卻是“建設性”的。從行為學角度看，開發與測試是對立的。如果測試人員對開發人員的錯誤批評指責過多，容易導致雙方的關係對立隔閡；如果測試人員對開發人員的錯誤疏忽怠慢，容易導致軟件質量的隱形下降，實踐中需要找到一個平衡點。
6．建立測試報告審批通報製度
建立測試報告審批通報製度對於提升軟件質量具有明顯作用。作為一名優秀的測試工程師，要養成書麵起草測試工作報告的好習慣。將已經定位發現的缺陷或錯誤進行分析彙總，用統計數字、圖表等方式說明缺陷或錯誤的根源，及時將測試工作報告提交上級主管領導審議，並通知研發設計人員，使設計人員做到對缺陷心中有數、控製有道，以防患於未然。
鏈接
基於需求的測試理論的五項最佳實踐
1．轉變“編碼後進行測試”的傳統觀念。在軟件編碼開始之前的設計階段就根據需求文檔和設計文檔開發出90％以上的測試用例，盡早發現和排除絕大部分的缺陷。
2．根據各項應用功能的優先級、重要性製訂不同等級的測試方案、測試用例。重要的模塊投入較多的測試資源（人力、時間、物資），次要的模塊投入較少的測試資源。
3．盡早測試，頻繁測試。測試進行得越早，缺陷發現越早，修複缺陷的代價越小；測試進行得越晚，缺陷發現越遲，修複缺陷的代價越大。
4．摒棄“經驗至上”的想法。設計係統、嚴謹、合理的測試用例才能使測試達到實效。
5．加強對測試過程的監控跟蹤。當用戶需求發生變更時，軟件需求文檔和設計文檔都隨之發生變更，相應測試用例也應發生變更。要隨時監控需求的變化，保證測試用例和用戶需求的雙向追溯統一。