将一些自己在测试管理过程中，对测试计划的思考和整理的部分分享出来。希望能有所共鸣，特别是PMP2004版本以后对于项目成功的定义标准转变，这是促使我对这个管理计划第三版修改的直接原因。

　　最初测试计划，按照我所接触的内容大致包括以下内容：

　　1）测试范围：功能和非功能测试需求、测试需求基线、测试需求阶段、测试选择类型和模型、过程剪裁、测试需求风险评估。

　　2）测试策略：测试类型（功能测试、性能测试、安装测试、配置测试、文档测试、界面测试、数据库测试）等；

　　3）质量管理：测试类型与测试阶段；

　　4）测试准入标准及结束标准：测试通过标准、转测标准、系统测试结束标准、性能测试准入条件、性能测试完成条件、测试监控方法等；

　　5）测试组织结构：组织形式、角色和职责；

　　6）测试工作内容：测试阶段交付物；

　　7）测试交付工件列表：交付物清单；

　　8）测试时间进度表：里程碑时间轴。

　　它的主要作用是将测试范围给予界定，并通过对测试产品的分析提出合理的测试方法论指导项目团队开展测试工作。

　　第一版的计划大概是在07年年初设计的，这个时候对于管理的计划概念仅仅停留着概括性阶段，主要是将项目的资源、范围概括性进行描述。测试计划本身对测试工作指导意义不大，且内容复杂文字描述过多。

　　总体来说第一版的计划信息量是很大的，个人觉得涉及面还是基本都说到了。但是对于实际测试工作指导意义不大，特别是在测试组织结构比较复杂的时候，每个测试组和个人的操作风格很难统一。这样会导致测试分析的思路不一致、测试设计的质量决定于人员自身修炼和项目经验。如何才能将项目团队的功效发挥到最大呢？08年，这个问题一直困扰着我们。我们开始反思测试计划本身的问题：

　　1）第一个问题：测试计划缺少阅读指引；

　　07年的时候我们发现测试计划写出来也没人看，到了项目结束的时候项目经理可能连计划多少轮测试都不清楚。为什么没人看？是因为信息不够多么？信息不够全么？测试计划没有阅读指引，发给项目团队人员就成走马观花。

　　2）第二个问题：过程剪裁太粗略；

　　直接导则的问题是，刚搞管理的人。对过程剪裁一片迷糊，到底什么项目能够剪裁。剪裁到什么程度是合适的。

　　3）第三个问题：测试策略过于泛化；

　　这个问题是在与华为合作部交流以后体会到的。测试策略本身有两个作用，第一是策略是一种方法论。即是我们07年已经实现的内容，比如对于功能测试而言我们的测试重心在什么地方，怎么做测试分析和设计工作。第二层则是在交流以后感悟到的，即策略是一种思想整合。如果你需要项目团队按照统一的分析思路、设计方法去做一件事，则在测试策略上就需要在前期保持一致性。特别是对于大型产品的测试而言，尤其重要。否则，就可能出现测试粒度定义不同，测试覆盖不完全的结果。这对于测试经理来说是极其恐怖的。

　　4）第四个问题：项目整体目标、阶段目标定义不清；

　　这个问题在07年的时候是很严重的。为什么会出现如此巨大的进度偏差，在分析了07年的项目数据后发现项目整体目标（商业目标/系统目标）不清晰是导致项目进度延期最大问题。也就是说，项目计划中没有明确的告诉项目经理所要达到阶段目标是什么样的，没有Smart衡量标准、时间约束、条件约束。出了问题，没有明确的排查方案和时间计划。阶段收尾后，没有一个量化的数据为下一个启动过程提供决策素材。

　　5）第五个问题：项目责权不清；

　　这个问题也在项目中时有发生。比如说：需求没有明确的接口人，项目经理的工作也比较乱。需求到了测试后期，变的无法控制。没有定义CCB决策等级、变更审核和批准人等。责权的问题，我觉得主要暴露在接口人上。模块的负责人是谁，谁来组织去处理模块内部的事物，这一点很关键，不然我们要花很多时间在无谓的沟通上，会造成测试组的工作急剧膨胀。

　　6）第六个问题：缺少里程碑与交付物交互关系。

　　这个问题会导致QA在审计测试计划的时候，无法掌握计划的监控点。包括自己在带项目的时候，监控的频度是很难掌握的，频度太高会造成项目组工作量的增加且可能无法完成正事，造成抵触情绪。监控的频度太低，会造成项目失控，导致项目延迟或者失败。