一、如何保證合適的測試用例覆蓋率
測試是一個經濟學的概念，不計成本的測試最終會受到市場的懲罰和用戶的拋棄。所以為了體現這種明智，測試用例設計所追求的目標不是100%覆蓋，而應該是均勻覆蓋。讓測試用例均勻覆蓋功能點的理念，其核心是沒有重大漏測。
我們知道一個測試用例應該對應至少一個功能點，那麼要保證測試用例覆蓋率儘可能完整，首先要明確待測功能中有哪些功能點，其次才是如何用測試用例對這些功能點進行覆蓋。需求跟蹤矩陣是對功能點進行有效管理和密切跟蹤的一種工具。
在實際的項目中如果沒有時間精確跟蹤到小的功能點，對於大的功能模塊總該有一種機制去跟蹤，要不然你不管他不管，最後有大的重要的功能模塊被漏測，你就要有大麻煩了。
二、如何確保緊跟開發文檔的變化
現實生活中的開發項目，沒有一個是從一而終的，項目從最開始做起，隨著中間不停地修正，到最後的階段往往已經面目全非了。
在實施了有效管理的項目中，開發一端的任何變化，應該都能清晰及時準確地反饋到測試團隊，經過及時地更改(更新測試用例或文檔來適應新的變化)，他們不會在實際測試中誤導測試人員。此外，有效管理不僅僅針對測試人員，在這種時候，開發人員的修改流程一定要定義得非常嚴格，如果開發人員能夠隨意地更改設計，那麼對於項目的任何人來講這都是一種災難。
三、如何把測試用例的重複率限定在適度的範圍
(1)優化測試用例資料庫的結構，分類要細緻，關鍵詞要準確
(2)簡單或重要的功能點要容忍一定的冗餘(重要功能點的重複測試可以避免一個測試人員的疏忽而導致功能點漏測，雙保險)
(3)花費時間長，執行複雜的測試用例，對重複的檢查要嚴格一些
(4)誇口測試用例的數量是沒有意義的。
四、如何實現「以測養測」式的測試用例更新
測試用例不可能達到100%覆蓋，所以說自由測試是不可少的補充，在自由測試中會發現很多未考慮到的問題，這些問題在被更改的同時，測試人員也要把發現的問題以新用例的形式記錄下來。這樣就可以長期對此問題進行監控，以保證將來再測試其他項目時測試人員不會把它漏掉。
在測試用例開發完成之後，以後如果發現有什麼新的有趣的地方值得測試，需要及時把這些東西通過測試用例的形式記錄下來。
五、如何實現測試用例在不同產品間重用
需要遵循兩條原則：
(1)避免設計過於特定化的測試用例(詳細到菜單項的每個菜單名)
(2)儘量縮小單一測試用例的覆蓋範圍，把測試用例設計得短小精悍
當有些用例確實不符合新產品的描述時，需要測試團隊有統一的要求：
(1)以功能點衡量測試用例通過與否的標準，即待測的核心功能點工作正常，但測試用例中的其他描述與產品實現不符，這是我們仍舊認為此測試用例通過。當然這時需要馬上做的是更新測試用例，使下一輪測試時不需要再面對這種情況。
(2)一切以測試用例為標準，稍有不符就算此用例失敗，這能夠迫使測試團隊儘快採取行動更新測試用例，這種方式最簡單直接，但是這樣會導致測試結果無法準確地標示出軟體實際的質量水平。
職場諫言：好多人的抱怨不見得就高明，職場中90%的人是在隨波逐流和人云亦云，只有少數人有自己的思想、意志和雄心。