成都四方公司测试同行写的博客，里面有一篇非常有深度的文章，关于测试管理方面http://blog.csdn.net/nilxin/archive/2009/11/06/4777446.aspx
读后颇多感想，也想谈谈。
本人也是测试业界人士，热衷测试工作，但看了楼主的文章后，也许是太强大了，所以觉得自己很“渺小”.
楼主的精神是将PMP 9大知识域的管理思想和方法融入到测试管理中去，时至今日，最新改版的测试管理计划内容很强悍很完备。
实际上，测试计划的制订，不同的公司会有不同的做法。当然，过程、制度的成熟度不同的公司自然做法不一样。就以本人为例来谈下。
首先，功能测试计划和性能测试计划是分开做的，不会合在一起。主要原因是：
1、测试人手少，功能测试的人同时也做性能测试的人，所以功能测试用例与性能测试用例的设计不可能同时展开。必然先专注功能用例的设计。
2、软件需求变更频繁，本人所在公司还没有成熟先进的需求管理手段，获取需求的途径一般是利用界面原型去引导用户提，或是拿一套同类产品给用户用，哪些地方照着做，哪些地方需要改，前期获取的需求有可能进入到开发阶段还会变，变得厉害的有可能会引起系统设计上大变动。所以，在系统测试前期，我们不敢做太多的工作，就怕日后变成杨白劳。而通过实践发现，性能测试用例最好是在功能测试进行到中期的时候展开，因为这个时候的需求基本上稳定下来，而性能测试的执行，最好是在功能测试进行到后期的时候展开，这个时候比较严重的功能性缺陷基本得到修复。
其次是内容。对比我写的测试计划和楼主的测试计划，其实核心内容相差不大，只是在组织上，格式上有所不同，楼主制订的诸多表格感觉很复杂，呵呵。
内容中有两个部分，我很欣赏，因为是自身所欠缺的：项目剪裁和需求方面的管理（包括需求分解管理和变更管理）。先说项目剪裁，有的项目要做的事情未必会在每个项目都做，有了一个过程清单，可以标明哪些是要做的，哪些是不做的（本人才疏学浅，理解程度这般，不够深入还请指教）；其次是需求方面的管理，我不太理解需求分解管理，但我懂得需求变更管理非常重要。需求变，测试需求自然也跟着变，测试需求的更新是否及时和全面，取决于需求变更管理的手段，不知道楼主所提的 需求跟踪矩阵是什么原理？
