软件测试过程的监控方法(2)

　　图2：测试监理过程

　　1. 首先依据自己的经验，问讯项目组的相关人员，看看项目的过程是否符合通常的测试规范。

　　2. 通过问讯，记录发现的问题或者疑问

　　3. 通过询问不同的项目组成员或查阅相关的文档，核实发现问题或疑问的真实性

　　4. 汇总所有问题，评估各个问题的影响和风险，列出优先级

　　5. 给出可能的解决方案。注意，这里的解决方案不是指具体的解决方法，而是指激发项目组成员行动的可行的方案，如建议项目组开会讨论可能的处理方式等。

　　6. 跟踪解决方案，验证问题是否真正得到解决。

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

　　对测试工作监控的方法，依据项目所处的不同阶段我们分为三个部分进行阐述。

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

　　测试初始期

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

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

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

　　l 测试工作有没有明确的工作范围

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

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

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

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

　　l 被测系统有无明确的性能指标?

　　对性能要求比较高的系统，需要在前期明确具体指标到底是多少?用何种手段进行确认?用户是否认可这个指标的描述以及确认的方法。

　　性能指标一般从需求中对一些敏感的数字的描述中来，如：必须保证能处理30个在线用户同时操作，主要业务系统响应时间不能大于1.5秒等。

　　针对这些数据，测试人员一定要细化数据背后的含义，使这些数据变得可验证。如在规划这些性能指标的验证方式时，首先需要明确软硬件的环境是什么?在此基础上，还需知道什么叫30个在线用户同时操作?都操作什么?这个场景应该怎么模拟?只有和这个指标相关的所有验证方法都可行，而且得到了认可，在后续的测试活动中我们才能相信这条性能指标能够进行测试。

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

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

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

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

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

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

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

　　是否有足够的单元测试用例?可以对照详细设计规定单元测试用例的数量，这是个量化的方法。

　　单元测试用例的通过率必须达到90%以上。

　　测试人员还可以抽样执行开发人员编写的单元测试用例，抽样执行的单元测试用例的一次通过率必须在90%以上。这也是一个量化的方法，同时检查了测试用例书写的质量和单元测试执行的质量。

　　以上是一些常用的方式，而且这只是非常少的一部分，当给出确实可行的方法和可以量化的指标后，我们发现，评估一个产品是否达到了预计的质量要求就会变得相对容易很多，而且也避免了人为主观判断的尴尬。

　　l 最终的交付验收有无和客户确认通过的验收标准和范围?上线、割接和维护期有无明确的成功、失败判定标准?

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

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