我仅站在个人立场，很粗浅的说一下自己的观点，我将通过如下的四个方面进行策略的分析与制定：
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自动化测试工具或框架、性能测试经验或工具等）。
最后，综合两个工具列列表确定可用工具列表和需要补充工具列表，并有无需要特殊类型的测试工具，如代理工具，数据库调试工具等
4. 确认可用测试资源
测试资源可以分为人与物两个部分：
人的部分，就是本次项目将有几个人员参与，其中全程参与几个，中途进入或退出的几个，每个人都持有哪些测试技能与项目经验。
物的部分，就是确认测试过程中所需设备、服务的排期，是否需要申请或采购。确保在测试开始时所需资源都是可用的。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
