如何进行测试管理？想必每位测试管理者都有这个疑惑，我也不例外。
经过了2个公司的测试管理经历，其实总的来说不外乎测试计划、测试用例、测试执行、测试跟踪和测试总结。
今天说一下测试计划。
测试计划，首先顾名思义，应该是为测试的所有工作进行全局的计划安排，测试计划中包括了所有的测试工作，比如说测试背景、测试目的、测试范围、测试策略、测试方法、测试阶段、测试完成标准、测试工作量、测试资源、测试环境、测试进度等等。测试进度是上至管理者、下至项目经理都会关心的一件事情，并且是仅此一件事情，由此可见测试之外的人员的肤浅，当然，不能称之为肤浅，因为你得理解，他们也只能关心到这一层面了。
有几个方面稍作记录，供大家参考。
1、测试工作量的估算
测试工作如同项目工作一样，都需要进行估算，且不说成本的估算，那是第三方测试关心的事情，一般公司内都是作集成测试和系统测试，而任何人都知道测试不是无休止的。所以我们需要对测试进度进行估算，但是首先我们需要估算测试的工作量。通常来说，测试人员在项目开始便介入项目，开展相应的测试工作，而并不是到了项目测试阶段才参与项目。
测试的工作量是根据测试范围和测试阶段、测试方式来确定的，主要因素是测试范围，所以我们需要确定测试范围。测试范围又是通过项目需求或者产品需求规格说明而来，因此这就是我们提取测试范围和测试需求的一个好方式。
通常来说，建议对测试工作进行细化，对每项工作都进行工作分解，分解的粒度可以自己定义，以可以把分解后的工作量准确的估算出为准。WBS之后，那么可以粗略的将所有工作的工作量求和，得出最终的测试工作量，当然，一般来说回归测试的遍数可以认为是3次，那么最后制定出调整因子，可以选择20%用以浮动的工作量。
如果项目能力成熟度比较高，需求文档写得比较完整和详细，那么也可以采取另外一种方法，就是根据需求文档进行推导测试工作量，这个方法是从网上找来的，在实际中试用过2次，呵呵，试用结果证明，某些参数需要根据以往的经验值调整。
以系统测试为例：
（1）由需求文档的页数计算出系统测试用例的页数（推荐比例为1.5）
（2）由系统测试用例页数计算编写系统测试用例时间（推荐比例为1）
（3）由系统用例计算执行系统测试时间（推荐比例为2）
（4）用执行系统测试计算回归测试时间（推荐比例为0.5）
2、测试进度的制定
测试工作量制定出之后，根据测试的资源对测试进度进行估计，当然，估计的最终结果要跟项目的测试进度相对比，我本人认为可以参考COCOMO方法，进行测试工期的估算，当然，也可以根据每个公司的以往经验值进行类推估算。
3、测试进度的更新
一般情况下，测试计划不会被严格的执行，通常伴随着都是项目的延期、测试阶段的压缩，如此一来，测试进度的更新是经常发生的事情。所以需要注意的一点是，测试进度估算完毕后，排定时最好不要以具体的时间点到时间点的方式，而是采用工作量和工期天数来表示，这样在开发阶段影响了测试计划后，不需要频繁的调整。
另外，在测试时间被压缩后，如果测试计划制定的详细，包括了各项测试需求和他们的优先级，那么此时可以利用测试需求的优先级，跟项目经理协商，调整测试范围和测试需求，在短的时间内优先测试重要的功能点，而一些不常用的和级别低的测试需求可以转移到用户现场或者后期进行。
对于项目中计划的更改或者需求、设计的更改，项目组一定要注意及时通知测试人员，其实就是项目的干系人，所有的干系人都需要及时通知到，这也是项目中配置管理的重要职责。需求或设计发生变动时，测试人员需要及时调整测试计划和测试用例，其中尤属测试用例的调整工作量较大，这种情况的频繁发生要求我们制定测试用例时，需要保证测试用例的条理性和通用性，避免具体数据的及早设入。
另外，关于测试的更新管理应在测试计划中规定好，明确更新周期和暂停测试的原则。例如，小版本的产品更新不能大于每天三次，一个相对大的版本不能每周大于1次，规定紧急发布产品仅限于何种类型的修改或变更，由谁负责统一维护和同步更新测试环境。测试暂停可以表现在产品错误发布或者服务器数据更新等情况，是比较有必要的一个方面，有利于测试管理者有效安排测试资源的合理运用。