如果你是一個測試項目的負責人，給你一個測試項目，你如何制定測試策略？
我僅站在個人立場，很粗淺的說一下自己的觀點，我將通過如下的四個方面進行策略的分析與制定：
1、確定測試目標與測試范圍
要弄清楚你要測試的是什么？這里測什么指的是測試范圍、重點和測試目標。
先說測試范圍，難道不是需求寫什么我們就測什么嗎？不是，作為一個測試負責人，這里的測試范圍需要一個更高層次與更多角度的考量。更高的層次指的是除了最終的產品功能質量需要我們進行測試外，其過程文檔、與過程的質量保證也是需要考量進來的（例：產品需求文檔的邏輯，如與其它項目有一定的交互，是否綜合考量）。多角度的考量，其系統架構如何，涉及依賴的服務，如何交付等....既要清清楚楚、明明白白的了解你要測試的是什么。
再說說測試重點，一個產品或是一個版本的測試周期會因為各種因素的影響，總會差上那么幾天，在那種進度緊張的前提條件下，如何盡可能的保證產品質量，保證哪塊的產品質量就是一個值得思考的事項，比如哪些是產品的賣點，哪些是用戶最經常在意的點，那些是當前版本主推的點等等。
最后說說測試目標，整個過程出來功能外，是不是還需要其它測試，如兼容性測試、卸載安裝測試、性能測試等等，這些根據具體的項目來進行制定....
2. 確定過程測試策略
首先，要了解整體研發團隊的工作模型是什么，瀑布還是敏捷，這將對測試節奏以及過程策略產生直接的影響。
其次，根據項目組組織模式，拆分並制定過程測試策略，BVT、FT、IT、ST、RPT等。
A、BVT(Build Verification test), 構建驗證測試也可以成為冒煙測試，版本構建測試是一個版本進入測試流程的入口，這部分的策略制訂就是制訂一個快捷的checklist，檢測合格了就可以進入測試，有不合格的就拒絕測試（當然這需要和項目團隊進行提前溝通）。一個沒有版本打回策略的測試是一種糟糕的體驗。
B、FT（Feature Test），組件（子功能模塊）測試，對於一些團隊來說，並不一定所有的功能都是放在一起研發的，他們可能分布在部分的子團隊與分支上。這個地方的測試策略就是保持和產品與研發的溝通順暢，保證每一次提測都是合並了最新的主干代碼並盡可能細致的覆蓋整個子功能模塊的各個功能點。
C、IT（Integrate Test），集成測試，和TF的合並主干代碼到FT分支正好相反，這個地方是合並FT分支代碼到主干代碼上，驗證的策略重點由新功能轉移到對現有功能的影響上。
D、ST（System test），對於最后一個版本的系統性測試。沒什么好說的，這個就是大部分人天天在做的測試，全功能，全覆蓋而已。
E、PRT（PreRelease Test），預發布測試、灰度測試，既正式發布多渠道市場之間的小批量用戶測試，這個階段及時跟進反饋。
3. 確定可用工具
首先，現有哪些測試管理工具（如測試管理、用例管理、持續集成、BUG管理等）以及現有哪些可用測試工具（APP/API自動化測試工具或框架、性能測試經驗或工具等）。
其次，根據測試范圍判斷本次測試所需要哪些工具，如需要APP UI回歸自動化可以選擇哪些現有技術，需要API接口測試需要選擇寫技術等。
最后，綜合兩個工具列列表確定可用工具列表和需要補充工具列表，並有無需要特殊類型的測試工具，如代理工具，數據庫調試工具等
4. 確認可用測試資源
測試資源可以分為人與物兩個部分：
人的部分，就是本次項目將有幾個人員參與，其中全程參與幾個，中途進入或退出的幾個，每個人都持有哪些測試技能與項目經驗。
物的部分，就是確認測試過程中所需設備、服務的排期，是否需要申請或采購。確保在測試開始時所需資源都是可用的。