测试策略是描述测试项目和测试任务之间的关系。它用来说明要测什么，如何测，如何协调测试资源和测试时间等。测试策略制定的是否合理高效会对测试项目的进度产生很大的影响。那么，如何制定一个好的测试策略并且能防止遗漏呢？一个好的测试策略又包含哪些方面呢？下面我给出一个平时经常使用的一个模板供大家参考。

我大致将测试策略分为了一下几个模块：
1. 测试安排、发布计划
    这个模块用来罗列测试项目本身重要的里程碑，每个里程碑都需要有明确的结束时间，这个时间可以指导我们后续的测试。如果测试时间安排不足，我们就可以在后续的测试范围中挑选优先级比较高的特性来执行测试，这样可以最大限度的保证产品的质量。
 
2. 测试范围（按优先级排列）
     这一部分分为In Scope和Out Of Scope.这一部分需要说明哪些产品模块是在测试范围中的，哪些是本阶段测试不考虑的。对于在测试范围中的模块，需要给出优先级以便相应测试时间不足的情况；对于不在测试范围中的模块，需要给出原因（为什么在本测试阶段不考虑测）。
 
3. 测试资源
     测试资源在测试策略中也是很重要的一环，它分为人力和工具两部分。人力资源主要说明参与测试的人员，当然可以包括很多的角色，如何专业测试人员，客户，产品经理等。工具主要是指可能用到其他软件（可能需要license）。
 
4. 测试环境
     测试环境主要包括推荐环境解决方案，操作系统要求，软硬件要求。

对于推荐解决方案，需要陈述的是对测试项目对其他软件的依赖，比如测试项目对.Net有依赖，这时我们可能给出的推荐版本可能就是4.5.2，在之后的测试中主要是针对4.5.2进行验证，而对其他版本进行简单验证，这样在产品文档中给出4.5.2的推荐方案，主要是为了说明4.5.2是没问题的，其他版本不保证。
操作系统主要是说明对windows或者其他操作系统的版本的支持情况。

 
5. 测试方法
    测试方法的罗列主要是为了说明针对测试项目我们要开展哪些类型的测试，功能测试是必须的，非功能测试是可选的。（相信各位童鞋对测试方法都已经倒背如流了，就不一一介绍了）
 
6. 用例设计方法
    用例设计大家也很清楚了，不再介绍了。
 
7. 文档管理
     对于一个完整的产品来说，文档是很重要的一环。它一般包括安装、升级文档，用户指南等。文档不单单是一个文件，它需要经过完整的测试才能发布给客户。差的文档很可能会误导用户，从而使他们对测试项目失去信心（虽然客户很少看文档……：））
 
8. 风险管理
    风险管理模块需要罗列出来现在已知的可能会出现不确定性的因素，这些因素可能来自技术，资源或者其他方面的。
 
9. 发布包验证
    这部分有一定的特殊性，并不适用于所有的产品。这部分主要是对测试项目安装包进行验证，防止在制作ISO文件的过程中产生变动。
 
就写这些吧，希望大家在看了这9个模块后能找到文章开头两个问题的答案。也非常欢迎大家提出改进意见。