【IT168 技术文章】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　1.测试初始期 

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

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

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

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

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

　　首先，原先的那种做法已经多次证明是行不通的，所以只有改变我们的做法才有可能成功，前期先弄明白我们打算做什么并不是一个过分的要求。

　　其次，开发人员实际上并不是完全不知道他们打算生产什么样的产品，而是就一些细节考虑的不够，或者不周全。作为测试人员，一定要知道如何对一件产品的功能和性能怎么验证，这实际上在帮助开发人员从使用者的角度上重新的审视一遍需求，也许这时候开发人员也说不清楚，那如果你和开发人员都非常清楚那些是明确的、那些是需要后面再补充的，也已经达到了我们的目的。

　　被测系统有无明确的性能指标？
　　对性能要求比较高的系统，需要在前期明确具体指标到底是多少？用何种手段进行确认？用户是否认可这个指标的描述以及确认的方法。
性能指标一般从需求中对一些敏感的数字的描述中来，如：必须保证能处理30个在线用户同时操作，主要业务系统响应时间不能大于1.5秒等。
针对这些数据，测试人员一定要细化数据背后的含义，使这些数据变得可验证。如在规划这些性能指标的验证方式时，首先需要明确软硬件的环境是什么？在此基础上，还需知道什么叫30个在线用户同时操作？都操作什么？这个场景应该怎么模拟？只有和这个指标相关的所有验证方法都可行，而且得到了认可，在后续的测试活动中我们才能相信这条性能指标能够进行测试。

　　测试工作有无明确的阶段划分（如单元、集成、系统、验收等）？各阶段是否有明确的交付确认条件？

　　实际过程中，我们都会将测试工作按照阶段进行划分，上面描述的是一个通常的划分方式。在做监控工作时，还需要明确一点：这些阶段的划分是不是只有时间点的描述，而没有各个阶段之间可量化、可衡量的交付确认条件？

　　如果只有时间点的划分，那我已经可以断定，这个项目势必会延期，原因是在整个生产活动过程中没有明确的阶段点交付的检验标准，问题肯定会沿着整个开发过程逐步的传递下去，终归会在某一点爆发，最不幸的爆发点是在客户处。

　　如果想尽量的避免上述的风险，就需要在开发过程中明确各个阶段点之间的交付、确认条件。而且这些条件必须可量化、可衡量，决不能是含糊的，不易操作的，否则在实际操作过程中还是会将大量的问题推入下一个阶段。

　　下面也以单元测试为例，看看怎么建立一个可量化、可衡量的单元测试阶段的交付标准。

　　首先，需要确定开发人员是否进行了单元测试。可以让开发人员提交一份单元测试总结报告，上面需要大致的描述一下进行了那些单元测试。单元测试总结报告是否提交是一个可以量化的条件。

　　其次，需要评估一下单元测试的质量，主要可以通过如下方法：

　　是否有足够的单元测试用例？可以对照详细设计规定单元测试用例的数量，这是个量化的方法。
　　单元测试用例的通过率必须达到90%以上。
　　测试人员还可以抽样执行开发人员编写的单元测试用例，抽样执行的单元测试用例的一次通过率必须在90％以上。这也是一个量化的方法，同时检查了测试用例书写的质量和单元测试执行的质量。
　　
　　以上是一些常用的方式，而且这只是非常少的一部分，当给出确实可行的方法和可以量化的指标后，我们发现，评估一个产品是否达到了预计的质量要求就会变得相对容易很多，而且也避免了人为主观判断的尴尬。

　　最终的交付验收有无和客户确认通过的验收标准和范围？上线、割接和维护期有无明确的成功、失败判定标准？
对于项目类的软件开发，上面的监控非常重要。为客户做项目的时候，一定要在前期和客户确认怎么进行验收，验收通过的标准是什么，最好能形成书面的文档，这样才能在最后交货的时候避免不必要的麻烦。而且，验收标准和范围应该是测试的一个最小测试集，要最大程度的确保正确性。

　　如果是比较大的软件开发项目，还会牵扯到：上线、割接、维护，一般会写在前期 的合同中，客户会按照上述阶段点阶段性付费，所以如果上述阶段点没有明确的成功、失败判定标准的话，对于公司尾款的收取是个挑战。

　　通过以上的详细询问，我相信，测试工作范围界定的是否有问题，测试工作是否规划的全面、细致，监控者应该比较清楚了，下面的任务就是将你的疑问记录下来，留待后面做证实。

　　2.测试实施期

　　在这个阶段，测试工作进行了一段时间，测试人员的工作应该已经步入正轨，按部就班的完成一些任务。这个阶段的特点是：开发人员和测试人员都按照日常的规范开始有条不紊的工作，有可能对一些问题已经习以为常，或者已经被同化。作为测试工作的监控者，应该在看似合理的工作中找出影响质量的问题，规避风险。

　　在这个阶段，应该关注以下问题:

　　缺陷管理流程是否规范？每个缺陷的提交和关闭是否都有复查？

　　缺陷管理是贯穿于整个软件开发过程、测试过程的关键环节，也是测试工作的根本，所以缺陷管理的流程是否规范，将是监控的重点。

　　首先，需要询问测试经理，软件开发过程中对缺陷的实际管理情况是如何的？不要让测试经理背诵公司的管理规范，而应该以一个实际缺陷为线索，追寻这个缺陷的产生直到关闭的过程是什么？期间是否有相关的记录，证明项目组的实施过程完全与描述相一致。标准的缺陷管理流程是怎样的，这里就不做叙述了，如果大家有兴趣可以查阅相关的资料。

　　在这个过程中，还需要注意一点：缺陷的提交和关闭是否都进行了复查。

　　缺陷提交和关闭的复查人可以是测试经理，或者测试经理指定的人选，一方面经过复查，可以减少缺陷的重复提交，提高缺陷报告的质量，另一方面在测试组中会有一个人对系统或一个大组件的质量情况有比较全面的了解，尤其在后期，这种了解会在很大程度上降低系统误发布的风险。还有一个好处是，在测试人员和开发人员交互的过程中，这个复查人员起到了桥梁的作用，可以有效的隔离开发与测试之间的多头沟通，在一定程度上提高了效率。这个角色可以是专职的，也可以是兼职的，关键看系统的大小。

　　配置管理工作是否规范？测试过程中涉及到的版本是否都可以完整的追溯？测试版本的发放频度是否符合测试的实际要求？

　　配置管理工作是整个软件开发过程的生命线，相比较而言，开发人员对此应该更为关心。对于测试人员来讲一方面要保证可以取到自己想要的文档版本，另一方面必须得到自己关心的程序的任意一个测试版本，以便可以在正确的版本上执行正确的测试用例。

　　在实际检查过程中可以在缺陷库中任意选择一个缺陷，查看这个缺陷是在那一个版本的程序中发现的，随即在配置库中调出该版本，看是否可以调出。随后，查阅该缺陷在那一个版本中修订正确了，随即也在配置库中调出该版本，看是否可查到。

　　在这个过程中，还需要注意开发部门提交给测试部门版本的频繁度，看是否过快或者过慢。过快或者过慢，没有一个时间上的判断。比如每2天提供一个新版本供测试人员进行测试，这个是过快还是过慢？判断的依据关键要看测试人员所处的状态，当版本提交的过快时，测试人员一直忙于对已修订好的缺陷进行反测，没有时间对新功能进行测试。当版本提交过慢的时候，测试人员的时间比较空闲。

　　在监控过程中，只需要询问测试人员的测试工作的紧张程度，一般就能够判断出版本提交的频度是否有问题了。

　　关键测试活动的关键测试资源是否如期到位？如没有到位是否进行了合理的规划来完成延误的测试工作？

　　在测试过程中，某些关键测试任务需要用到特殊的设备或者特殊人员的技能，称为关键资源。在测试实施过程中，要提前计划会用到那些关键资源，以免耽误项目进度。

　　作为测试的监控者，需要非常关心这些关键资源的使用情况，因为如果关键资源不能如期到位，势必要影响项目的整体进度。

　　如果由于某种原因，关键资源没有如期到位时，要注意测试人员是否对计划进行了修订，修订的结果是否可以弥补已经造成的损失，或者能最大程度的减少损失。

　　测试策略，测试计划，测试方案，测试用例是否都经过了正式评审？发现的问题是否都进行了更正？

　　作为测试的监控者，不可能在短时间内评估一份测试计划制定的是否合理有效，一份测试方案是否可以正确实施，并且也不必要这么做。
测试策略，测试计划，测试方案，测试用例等文档都是测试过程中的关键文档，也直接决定了测试工作的质量。监控者在评价这些文档的质量时，首先想到的一点就是我要充分的阅读这些文档，以我的经验和能力来判断这份文档的好坏。但是，作为一个项目组以外的人，很难能就所有的细节发表高质量的看法，其次，也不可能在短时间内完成所有文档的评价工作。所以这不是我们的解决方案。

　　在监控过程中，首先要相信项目组自身的能力，假定他们有能力完成这些工作，这样工作就简单了，也变得可以操作了。

　　首先，查阅这些文档，大致看看，有没有明显的问题。其次，应该检查这些文档的评审记录，看看相关的人员是否参加了该评审，都发现了什么问题，大家的意见和建议都有那些。最后，看看所有的发现的问题是否都得到了解决，文档是否按照解决的方法进行了修订。

　　在监控的过程中，默认参与评审的人员技术能力都符合要求，这样只需要关注评审的过程就可以控制质量了。但是，如果有证据证明，评审的人员或者组成不符合要求，作为监控者应该宣布该文档的评审无效，需重新进行评审，以解决问题。但是，使用这项权利的时候要小心，而且要充分论证，否则会扰乱项目组的正常次序。

　　测试的相关文档是否都按照项目目前的实际情况进行了更新，并严格遵照执行？

　　经常会听到一句话就是：计划赶不上变化，这个问题就是冲着这句话来的。我在讲课的过程中问过很多人这样一个问题：不做计划，直接做事情行不行？至今我还没有遇到一个说行的。但是，如果计划和行动不同步，这个和没有计划又有什么区别？

　　项目中有各种各样的理由告诉你，我没有同步计划是合理的，但是我们的要求一定是必须有计划，而且必须严格遵照执行，这才是降低系统风险的唯一合理方法。

　　项目先前定义的测试范围在后续的计划、方案中是否有遗漏？
　　在测试初始期我们一直强调测试范围的必要性，在测试实施阶段还需要检查前期规划的测试范围是否在后续的计划活动中覆盖完全了，只有计划中完全的覆盖了所列的测试范围，才能保证系统的质量。

　　项目的测试过程是否按照公司预计的测试过程执行？

　　在测试实施阶段，还需要了解测试人员是否按照公司要求在执行所有的测试活动，但是要在短时间内了解，手段只能是听测试经理陈述他们的测试过程，再加以判断。如果公司有SQA人员，工作就相对简单了，只需要到配置管理库中找到SQA的检查报告，这些疑问就一目了然了。 

　　3.测试结项期 

　　在这个阶段，主要的测试工作已经进行完毕，最终的发布版本也已经准备出来。测试经理开始书写最终的测试报告，申请发货。
作为测试的监控者，这个阶段的主要任务就是评估软件产品的质量，依据已有的数据评估测试工作是否做到位，产品是否可以发布。

　　在这个阶段，应该如何进行监控，问些什么问题？

　　测试中发现的缺陷趋势曲线是否处于收敛状态？各个分模块的缺陷趋势曲线是否基本一致？

　　测试完成后，判断产品是否能够发货的一个重要条件就是：缺陷趋势曲线处于收敛状态，并且持续一段时间，表示系统处于稳定状态，满足发货条件。
　　
　　那为什么还要看各个分模块的曲线是否一致？因为，有的系统比较庞大，有可能某一个局部的缺陷曲线还没有处于收敛状态，但是整个系统的缺陷趋势图已经把这个信息掩盖掉了。所以，还需要分别看一下各个模块的趋势曲线，确保系统的每一个部分都处于稳定状态，这样发货的风险才能降到最低。

　　是否有评判产品能否发货的文字性材料？

　　发货前，测试经理或者项目经理必须提交一份整个系统的整体质量说明，以文档的形式证明整个系统质量稳定，达到用户要求，可以发货。

　　在这个过程中，如果和客户有关于质量的约定，还需加入，如：用户签字认可的验收报告，用户签字认可的性能测试报告等。

　　是否召开了正式的最终评审会议？会议的参与评审人员是否有公司主管的高层？是否有用户或者能体现用户方意见的人员参与？所有的遗留问题是否都有了明确的解决方案，并且有相关的责任人负责问题的解决和跟踪？

　　在发货前，还需要召开正式的评审会议，而且会议必须有项目组以外，主管该项目的公司高层和能体现用户方意见的人员参加。因为，一般系统中或多或少都会遗留一些缺陷，这些缺陷到底应该如何处理，会给公司和客户带来多大的麻烦，都应该在这个阶段做一个评估，以决定该产品是否能够发货。

　　当一个问题确定遗留在系统中后，还需要对这个遗留问题有个明确的解决办法，如：在升级版本中修改，建议用户用以下方式绕过，或者干脆不再进行修改，都应该有一个明确的答复，而且还需要指派专门的人员跟踪问题的解决情况，并进行报告。

　　在测试初始期确定的结项条件是否都得到了满足？

　　为了能保证系统的正常交付，在前期和用户做了一些交付的约定条件，在这个阶段，需要确定这些条件是否都得到了满足，并有相关的证明。如：性能指标是否满足用户要求，用户是否签字确认。验收测试是否完成，用户是否签字确认。后续的试运行期的方案是否完成，用户是否同意，是否有明确的截至条件等。

　　4.总结

　　以上以一个测试监控者的角度，探讨了如何对软件测试工作进行监控。希望本文对大家的日常工作有些许借鉴意义。

　　笔者在本文的最后还想强调几点：
　　监控是管理部门一项日常的工作
　　这件工作要在平时不停的进行，才能有效的改善产品的质量，而不是一时心血来潮的意气之举。

　　监控的目的是为了解决问题，而不是发现问题。
　　监控的目的不是为了证明我们的能力，而是为了能够持续不断的提高软件开发的能力，能够持续改进，所以发现问题并不是目的，解决问题才是根本。

　　对问题的判断要准确，可验证
　　作为监控者，同时也代表公司对这件事情进行的判断，所以当发现问题的时一定要判断准确，而且经的起复查，这样才能避免不必要的麻烦，才能将更多的精力投入到处理事情本身的工作中。

　　质量的提高，工作的改进是一个渐进的过程，绝不能一蹴而就。
　　对于一个不太成熟的项目组，通过监控，可能发现很多的问题，这时不能太急躁，要心平气和，一点一点的改进我们的过程。

　　通过分析，要先解决重要的事情，要有总体的规划，而不是头痛医头，脚痛医脚。
　　发现的所有问题不可能都改正，这就要有个总体的策略，从大处招手，以公司的整体能力提升为要点，去区分解决问题的优先级，有节奏、有计划的将公司引入持续改进的轨迹，逐步的提升公司的核心竞争力。