【IT168 技术文章】

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

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

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

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

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

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

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

　　通过分析我们发现，按照V模型来设计测试工作，测试人员可以在前期（需求获取阶段）就介入到整个开发过程中，设计测试用例规划测试工作。这样，有许多工作就可以并行开展，而且很多问题可以在开发的前期被发现，极大的规避了开发工作的风险，降低了改正缺陷的成本。
    但是我们目前的实际情况是什么那？我们的需求总在变更，概要设计做的不够好，而且变化频繁，详细设计不够详细或者根本不做，单元测试覆盖率不够或者根本不做，这样造成测试工作步履维艰，质量难以控制。我们上面谈到的几种软件过程改进模型，也是想在方法的高度上，尽量的改变这种现状。

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

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

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

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

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

　　在项目中作为对产品质量检验的负责人——测试经理工作的好坏或者对产品质量的客观评价，对公司的决策就会显现的非常重要。

　　为了能有效的降低这种风险，管理上采用的一般方式就是监控，即由第三方人员对被监控方的工作进行客观的评价。那谁是第三方人员？首先，这个人不在被监控的项目中负责具体的工作，其次，他代表公司或者所在部门，需要对项目的质量情况进行客观的评价。

　　针对一个具体的组织结构模型,可能对测试工作有监控需求的部门有：软件测试部门的主管，SQA人员或者其主管，技术或者开发部门的主管。他们的监控出于不同的目的，如：评估测试工作的有效性，了解具体项目的质量情况，了解开发的进度和效率等。不管出于什么目的，他们有一个共同的特征是：不参与项目组中具体的工作，并且需要在短时间内了解项目的实际情况，并且做出相对准确的判断。但是，不在项目组中，对项目组的实际情况不是非常了解，如何能在短时间内对项目的测试情况做出准确的判断？

　　在实际工作过程中，我们可以采用如下的方法对测试工作进行监控：

　　一般采用的手段是：问讯与查阅相结合，对关键点进行抽样审核，并询问不同的人员以进行核实。

　　具体的审查点和查阅项会在下面做详细的阐述。在监控过程中，我们一般会经历如下阶段：
      *了解情况
      *发现问题
      *核实问题
      *评估影响
      *给出方案
      *解决问题
　　1．首先依据自己的经验，问讯项目组的相关人员，看看项目的过程是否符合通常的测试规范。
　　2．通过问讯，记录发现的问题或者疑问
　　3．通过询问不同的项目组成员或查阅相关的文档，核实发现问题或疑问的真实性
　　4．汇总所有问题，评估各个问题的影响和风险，列出优先级
　　5．给出可能的解决方案。注意，这里的解决方案不是指具体的解决方法，而是指激发项目组成员行动的可行的方案，如建议项目组开会讨论可能的处理方式等。
　　6．跟踪解决方案，验证问题是否真正得到解决。

　　以上是一个通行的监控过程，这里需要强调的一点是：不管出于什么理由对测试过程进行监控，但是发现问题绝对不是我们的目标，能够有效的解决问题、降低项目的风险才是我们的目标，只有这样的监控才是有价值的，对公司整体有利的工作。 对测试工作监控的方法，依据项目所处的不同阶段我们分为三个部分进行阐述。

　　这三个部分暂且称为：测试初始期，测试实施期，测试结项期

　　1.测试初始期 

　　在这个阶段，测试工作刚刚启动或者才开始按照计划实施测试工作，测试工作的启动时间点在各个公司可能不同，有可能是：需求调研后期，集成测试期或者系统测试期等。具体在软件开发的什么阶段测试工作开始介入，并没有一个一定的说法，关键要看所在公司的软件开发活动的成熟度来灵活选择，但是这点并不影响下面的讨论。

　　作为测试工作的监控者，应该在那些重要环节上加以注意？首先请大家注意这个阶段的特征：软件开发工作已经开始，需求开发工作已经完成或者接近尾声，以测试人员为主的测试工作正式启动或者刚开始运行。

　　在以上的前提下，我们来说一说需要注意的监控点：

　　测试工作有没有明确的工作范围
　　这是在测试工作中最需要明确的，也是非常多的项目忽略的工作。在做测试工作之前，一定要非常明确准备对那些内容进行测试，预计达到的质量标准是什么，尤其是对那些不进行测试。

　　我遇到过的很多的测试经理都抱怨说：“我们不可能在前期把这些事情都弄清楚，开发人员都不知道产品将来是什么样子，我们怎么知道需要测试那些内容？”咋一听，感觉很有道理，但是情况是否真像大家说的那样？作为公司，或者项目经理都希望能将项目做好，能生产出一件令用户满意的产品，如果这个假设成立的话，这也就是我们能够改变现状的动力。