08年针对以上的六个问题，做了一些调整。主要思路是解决测试思路的整合以及测试计划信息延展性。

　　分别解释一下这两块内容：

　　1）测试思路的整合：主要的工作是加入了针对功能模块的测试策略分解，核心观点的是整合思路。比如说：我们尝试使用Freemind或者MindMangaer的技术对被测试对象进行分解和推演。特别对于异常分支和各种条件假设分析效果分析非常好，这个分析过程也可以辅助开发来进一步了解系统的结构。其次，是通过归类分析的技巧将新变动部分及继承部分内容分开，从而能够较为准确的估计工作量、评估变动范围。

　　2）测试计划信息延展性：主要的工作是使原测试计划信息交互性更强，在项目测试过程中发挥的用处更大。也就是说，在两个过程组之间需要通过测试计划来做连接。其核心是要将计划中指导过程，延续在实际项目测试过程中，为项目经理、PMO委员会、QA以及其它干系人提供更丰富的项目过程信息。

　　通过精简和集成08年测试计划修改为以下框架：

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

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

　　3）测试方案：模块测试策略、测试框架、测试风险等；

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

　　新加入：需求列表、测试指标、结束标准、用例目标、质量目标，主要强调阶段性；

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

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

　　新修改：项目组织结构、接口人（需求、协调）、干系人的期望，主要强调职责部分；

　　7）交付物清单：里程碑交付物，主要强调监控时机；

　　8）测试时间进度表：里程碑时间轴。（删除，放入Project中管理）

　　经过09年10个月使用和评估，我们觉得第二版本的测试计划主要解决过程指导的问题。项目经理对于测试计划的认知度更高，约束力更强。如果项目经理没有意识去看测试计划，可能会导致他自身的工作分配不合理。这一点是非常值得欣慰的。至少测试计划不在是个摆设了，项目团队对于它有一定依赖关系了。下一步改进的动力在哪里呢？来看看我们遇到的问题吧：

　　1）第一个问题：需求跟踪矩阵（责权和关联）；

　　08年公司引入新的需求管理方式，即需求跟踪矩阵。但是，由于测试计划是Word版本的。其测试需求是嵌入在内的，这样就导致了更新测试计划非常麻烦。这样，原本引入测试需求跟踪和计划本身脱离开来，需求到了后期同样会出现不一致的情况。如何才能解决这个问题呢？其核心是要考虑一种整体变更方法和流程，从需求入手由变更来控制项目的范围以及成本和质量。

　　2）第二个问题：进度紧张资源分配不合理；

　　分析Project中的一些项目计划，可以看出对于人员分配有些及不合理。比如：一些项目中可能出现单个人员单天工时超过500%的情况。如何才能有效平衡时间、成本、质量三者的关系呢？交付时间紧张的时候，什么是我们必须要保证的部分，哪些部分能够申请不测试或者需要一定介入条件。这就是范围管理部分，没有约束清楚的、界定模糊所致。这里还包括如何去做估算，估算的约束条件、影响因数等等。

　　3）第三个问题：缺少整体变更机制；

　　这个问题其实提出来是在09年年初的时候。以前我们认为整体变更是需要QA参与的，必须由质量部门发起这种过程改进。但是，随着项目历程不断深入，在没有QA参与整体管理的时候，管理成本越来越高。整体变更机制，是第三版计划核心要考虑问题之一。怎么变，按什么变？变化后怎么全盘控制。

　　4）第四个问题：阶段目标定义过粗；

　　实际这个问题一直都存在包括在第一个定义的版本中。通过对PMP2008版本的深入学习和公司组织内部培训。这个问题得到很好的答复，首先阶段目标与活动定义一样都需要一个渐进明细的过程。不是项目一开始，就能将其厘清的。很多项目，特别是公司的自研产品或者需求不确定的电信产品，更多时候是被迫是走这个过程的。问题的关键在两方面，首先是国内的用户普片技术程度不高，不能提供精细化需求描述，想法不清楚；第二点，是我们能控制的部分，但是往往又控制不好的部分，即质量标准。项目范围边界在哪里？怎么才算达到了质量标准，往往项目前期客户期望太高，市场或项目经理过渡承诺，没有定义明确验收标准。后期客户的想法越来越多，最终导致项目无法验收或超出成本预算。