大家做项目或产品过程中，遇到最多的，也觉得最有风险的就是测试计划。关于如何做测试计划，每个人都有自己的经验，让我们来看看国外的大师James Bach是如何制定测试计划的，希望对大家将来制定测试计划和测试策略有用。而且关于测试计划的大部分问题我想都可以在这里找到答案。

　　记得多位测试大师说过在项目前期我们需要制定测试计划，测试计划对于很多公司和团队来说，都有很多不同的模板，根据自己公司的特点定制化一份有效且完整的测试计划模板是非常重要的事情。一般情况下，是由项目的测试负责人来制定测试计划，制定测试计划的过程也是测试负责人了解和理解产品架构和设计的过程。 我们在乎的不是测试计划这样的一份文档，在乎的是制定测试计划的过程，过程让大家感觉更可靠和更完美。

　　制定一个测试计划的过程，是的确考验测试负责人的水平和全局观念，但是这里需要强调的是测试计划和测试策略不是一成不变的，在项目的开发周期过程中，测试计划可以合理的变化，测试经典可以合理的调整，从而适应不同的管理要求。下面会详细的介绍整个制定测试计划的过程，主要适用于传统软件行业，对于互联网行业，完全可以定制化一份适合自己的测试计划过程和模板。这里需要强调的是制定测试计划的一个核心就是测试范围的确定，明确的确定测试团队将测试什么，不测试什么。尤其是不测试什么的圈定，需要测试策略，管理经典，市场需求，组织决定等多个因素的衡量，也是最考验测试人员的责任心和大局观。

　　制定测试计划

　　1、分析产品

　　● 分析什么：
　　用户（他们是谁，他们做什么的）
　　操作（这个操作是干什么用的）
　　产品结构（代码，文件，等）
　　产品功能（这些功能是干什么用的）
　　产品数据（输入的，输出的，状态，等）
　　平台（外部的硬件和软件）

　　● 怎么分析
　　走一下产品/原型的主要流程
　　评审产品和项目文档
　　咨询设计人员和用户
　　与类似的产品做比较

　　……………………

　　查看全文请点击下载：http://www.51testing.com/html/13/n-241113.html

　　3、设计测试策略

　　● 基本策略
　　Domain testing（包括边界值）
　　用户测试
　　压力测试
　　回归测试
　　Sequence testing
　　State testing
　　基于文档的测试
　　结构化测试（单元测试等）

　　● 怎么计划
　　对于风险和产品功能匹配策略
　　将特殊的和实际的策略形象化
　　分析是否可用自动化的机会
　　使用原型去测试probes和harnesses
　　不要强加计划，让测试人员自己决定

　　● 可能的工作产出
　　各个类型的报告怎样应用的测试策略文档
　　风险/任务的matrix
　　已选择的策略中存在的问题或挑战列表
　　对产品覆盖比较少的部分提供的建议
　　测试用例（如果是必须的）

　　● 执行状态检查
　　设计人员对这个测试策略达成一致了吗？
　　这个策略对于项目每个参与人员以及协助人员都有用吗？
　　这个测试策略是否很基本了？是否也容易的应用到这个产品中？
　　这个测试策略是否透露了所以的重要的问题

4、计划安排

　　● 安排的内容
　　测试时间的评估和计划
　　易测性的工程分析
　　测试团队人员（详细的能力）
　　测试人员的培训和监督
　　测试人员的任务的指定
　　产品开发信息的收集和管理
　　项目会议，沟通，协调的方式
　　与其他已存在的功能之间的关系，包括开发过程中
　　测试平台的认购和配置
　　测试工具盒自动化
　　需要用到的测试桩和mock
　　测试套的管理和维护
　　建立和输出协议约定
　　测试周期管理
　　问题报告系统和约定
　　测试状态报告的约定
　　代码冻结和增量测试
　　测试后期的压力管理
　　项目阶段输出协议约定
　　测试效率的预估

　　● 可能的工作产出
　　问题列表
　　项目风险分析
　　任务和责任matrix
　　测试时间表
　　与开发之间的约定和协议

　　● 执行状态检查
　　这个项目所列的安排是否支持测试策略？
　　是否存在一些问题会阻碍测试的执行？
　　在可见性的问题面前，这些安排和策略是否适合？
　　你现在是否开始测试还是以后整理剩下的问题？

　　……………………

　　查看全文请点击下载：http://www.51testing.com/html/13/n-241113.html

　　需求变更

　　在我们的项目过程中，特别是互联网领域，项目测试过程中，不管是前期还是后期，都会存在需求变更的问题，这些需求变更如果出来不当的话，就会影响测试质量，那么如何最大限度的降低需求的变更对测试质量的影响？

　　注意看这里面的几个关键词：一个是“最大限度的降低”，另一个是“需求的变更”。最后一个是“测试质量”。我们要解决好这个问题，必须要很好的理解这个几个关键词的内在含义。我想并不是所有人都能很好的理解这些术语。

　　那什么叫需求的变更呢？顾名思义就是项目需求发生了变化与修改（先不谈什么原因），对应测试这边测试需求也就相应的变化。这里可不要忘了一个重要的时间点，那就是一旦PRD（产品需求规格说明书）评审通过后。其后任何一个时间点，不管是UC（User Case，单个特性的设计需求）设计还是测试设计或是什么，只要需求发生了变化，这都属于需求的变更。

　　那什么叫测试质量呢？这个概念比较大，一般我们讲软件质量，这个就与我们测试人员的工作职责相关的。而对于测试质量，个人认为包括两大块，一个是测试各个阶段的产出的高质量，一个是测试各个阶段的控制的高效性。解释一下第一个是各个阶段的产出的文档的高质量，这里面包括文档的规范性，完整性，正确性，统一性。第二个是各个阶段的进度控制和项目管理的高效率。包括测试目标以及发现缺陷，甚至是缺陷预防的持续改进等。

　　……