软件测试过程的监控方法

发表于:2009-12-30来源:作者:点击数: 标签:
软件 测试过程 的监控方法 软件测试工具 软件 开发 项目的成败,很大程度上取决于三方面的配合:过程、人、技术,三方面相互制约,又相互促进。为了能更加有效的管理软件开发项目,规划软件开发过程,近年来国内引入了不少软件开发模型,如:CMM/ CMMI , RU

       软件测试过程的监控方法   软件测试工具 

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

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

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

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

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

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

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

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

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

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

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

  大家都知道,项目管理有三个要素,即:成本,进度,质量。

  对于软件测试经理来讲,只需要对产品的质量负责。对于整个项目来讲,项目经理作为项目组的最高领导自然要对项目整体的:成本、进度、质量负责;在这个团队中,作为主管软件测试工作的测试经理,需要协助项目经理只对质量负责,这样才能客观的对项目的质量做出评价。之所以说不用对其它两项负责,更确切的说法应该是在做质量判断的时候,不需要考虑成本和进度可能对质量造成的影响,具体的权衡工作由项目经理或者公司的高层来完成,测试经理只提供对软件产品质量的客观判断。

  既然测试经理只对质量负责,这就会衍生出来一个问题,测试经理对产品质量过于吹毛求疵,与开发人员造成对立,进而影响项目开发工作。如果这件事情发生了,有一个确切的信号已经传递了出来:测试人员和开发人员在沟通上存在问题。如何解决这个问题?首先,我们应该审视测试人员和开发人员的沟通技巧是否存在问题。其次,我们应该重新核对我们在项目开始时确定的质量目标,看看是测试人员人为拔高质量目标,提出超范围的要求,还是开发人员人为降低质量目标,生产出不符合质量要求的产品,以此作为对质量标准实施误差的一个判断。

原文转自:http://www.ltesting.net