软件开发项目的成败，很大程度上取决于三方面的配合：过程、人、技术，三方面相互制约，又相互促进。为了能更加有效的管理软件开发项目，规划软件开发过程，近年来国内引入了不少软件开发模型，如：CMM/CMMI，RU 。

　　软件开发项目的成败，很大程度上取决于三方面的配合：过程、人、技术，三方面相互制约，又相互促进。为了能更加有效的管理软件开发项目，规划软件开发过程，近年来国内引入了不少软件开发模型，如：CMM/CMMI，RUP，XP等，每一种都体现了一种思想，都希望能在最大限度内，协调上述三者之间的关系，最大程度的减少软件开发过程中的风险，能按照既定的计划，交付出合格的软件产品。

　　对于软件测试工作，国内大多数企业采用V模型作为测试的标准模型，来规划和情设计软件测试流程，指导日常的测试工作，模型如下图所示：

　　V模型带给我们一个理想的开发方式，帮助我们理解软件开发活动中各个阶段之间的相互关系。

　　V模型的左侧是以瀑布模型为基础的开发活动，自上向下开展。V模型的右侧是测试活动，以左侧完成的活动为工作输入，自下向上开展，最终通过验收测试，交付给用户合格的软件产品。

　　通过这个模型，我们发现按照理想情况，如果需求获取人员完成了需求分析工作，测试人员就可以按照需求分析的结果规划我们的系统测试工作，设计系统测试用例，等待到系统测试阶段执行测试用例，验证系统是否实现了设计的所有功能和性能要求。

　　当概要设计人员完成了概要设计工作，测试人员或者开发人员（不同的公司可能会要求不同的角色完成这一工作）就可以规划集成测试工作，设计集成测试用例，等待集成测试阶段执行测试用例，验证系统是否可以组装成功，是否可以交付到下一个阶段进行系统测试。

　　当详细设计人员完成了详细设计工作，开发人员就可以规划单元测试工作，编写单元测试用例，等待编码完成后进行单元测试工作，验证单个模块或者类等（各个公司规划的单元测试颗粒度不尽相同）内部的逻辑是否有问题，整个系统是否可以进入到集成测试阶段。

　　通过分析我们发现，按照V模型来设计测试工作，测试人员可以在前期（需求获取阶段）就介入到整个开发过程中，设计测试用例规划测试工作。这样，有许多工作就可以并行开展，而且很多问题可以在开发的前期被发现，极大的规避了开发工作的风险，降低了改正缺陷的成本。

    但是我们目前的实际情况是什么那？我们的需求总在变更，概要设计做的不够好，而且变化频繁，详细设计不够详细或者根本不做，单元测试覆盖率不够或者根本不做，这样造成测试工作步履维艰，质量难以控制。我们上面谈到的几种软件过程改进模型，也是想在方法的高度上，尽量的改变这种现状。

　　不管我们打算采用何种模型作为我们过程改进的基础，对于软件测试工作来讲V模型都是我们很好的一盏路灯，它提供给我们一个软件测试工作提前介入的思路，以测试或者说以质量保证为前提的软件开发方法，只有这样做，我们才有可能生产出高质量的软件产品。

　　本文并不打算一一探讨上述几种过程改进模型的测试监控方法，而是参考V模型的架构，从软件项目管理的角度谈一谈，如何对软件测试工作进行监控，具体的监控手段都有那些，在平时的工作过程中我们应该怎样使用。