1）在測試策略中要包括產品的背景信息。在測試策略文檔的第一段回答- stakeholder（項目利益相關者）為什么要開發這個產品？回答這個問題會幫助你更好更快地理解項目，並為所做的事情優先級排序。
2）測試環境，它應該包括你在那個操作系統平台上做測試，系統是基於那些補丁和安全更新。例如，一個測試環境可能必須包含Window XP SP2
3）列出你將要測試的所有重要特征。如果你認為有些特征不屬於本次發布的一部分，那么就標注“不會被測試的特征”。
4）寫下在此項目測試中將應用到的測試方法。清楚的列出你將以那些類型的測試作為測試引導。例如：功能測試，用戶交互界面測試，集成測試，壓力測試，安全測試等等。
5）回答以下問題：你如何進行功能測試？手動還是自動化？測試工具是什么？你將執行在測試管理工具中的所有測試用例嗎？
6）用什么作為測試錯誤報告跟蹤工具？當測試人員發現一個新的bug之后，流程應該是什么？
7）測試進入和結束的標准分別是什么？
8）如何去跟蹤測試進度？什么度量可以用來記錄測試結束？
9）任務分布 – 定義每個組員的角色和職責，包括測試組長，測試員，項目經理等。測試戰略將由開發人員review，確保測試的覆蓋率全面且沒有重疊處。測試經理和部門經理都要同意測試策略之后，測試工作才能展開。測試小組的划分及分工。
10）有哪些風險會阻礙測試的完成？例如，代碼的依賴性，測試工具的局限性等等。要提前想到風險發生的解決辦法。
11）測試日程表- 每個測試計划都應該包含一個預估時間來估計完成測試所需要的時間。這需要幾個階段：一，測試人員必須至少完成一次的執行全部用例。二，如果一個錯誤被測試人員發現，開發人員將修復此錯誤。測試員重新測試此用例，直到其功能正確為止。最后，但很重要的一點是測試員必須對修改過的地方執行回歸測試以保證開發人員在修復一個錯誤的時候沒有引入另外的代碼錯誤。測試日程表要包含每個測試部分涉及的測試人員。時間往往很難估計，因為測試中有很多不確定性的事情發生。其中一個比較好的辦法是參照前一個發布來估計。
12）回歸測試的方法- 一個錯誤被修復后，必須要保證產品功能按用例標准運行。回歸測試是為了在修復一個問題時不引入另外的錯誤。因此相關的測試用例要在被執行一次，從而確保沒有特殊的東西被引進。在這個階段，就要定義回歸測試的方法。有的公司講相關模塊的單元測試用例全部遍歷一遍，從而確保產品的質量。 弄清楚這些問題，你就可以寫一個詳細的測試策略出來了。