软件测试过程管理实践.doc

软件测试过程管理实践.doc

《软件测试过程管理实践.doc》由会员分享，可在线阅读，更多相关《软件测试过程管理实践.doc（6页珍藏版）》请在冰豆网上搜索。

软件测试过程管理实践

关键词

测试过程模型测试管理理念可持续改进

1测试过程概述

1．1软件测试过程概述

   软件测试过程是一种抽象的模型，用于定义软件测试的流程和方法。

众所周知，开发过程的质量决定了软件的质量，同样的，测试过程的质量将直接影响测试结果的准确性和有效性。

软件测试过程和软件开发过程一样，都遵循软件工程原理，遵循管理学原理。

   随着测试过程管理的发展，软件测试专家通过实践总结出了很多很好的测试过程模型。

这些模型将测试活动进行了抽象，并与开发活动有机的进行了结合，是测试过程管理的重要参考依据。

1．2软件测试过程模型介绍

Ｖ模型

   V模型最早是由PaulRook在２０世纪８０年代后期提出的，旨在改进软件开发的效率和效果。

Ｖ模型反映出了测试活动与分析设计活动的关系。

在图1-1中，从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。

图1-1　软件测试V模型

   V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。

但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。

Ｗ模型

W模型由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。

如图1-2所示，W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

   W模型强调：

测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。

W模型有利于尽早地全面的发现问题。

例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。

同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

   但W模型也存在局限性。

在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。

这样就无法支持迭代的开发模型。

对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

  图1-2　软件测试W模型

Ｈ模型

   V模型和W模型均存在一些不妥之处。

如前所述，它们都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上，这些活动在大部分时间内是可以交叉进行的，所以，相应的测试之间也不存在严格的次序关系。

同时，各层次的测试（单元测试、集成测试、系统测试等）也存在反复触发、迭代的关系。

为了解决以上问题，有专家提出了H模型。

它将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来，如图1-3所示。

图1-3　软件测试H模型

   这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。

图中标注的其他流程可以是任意的开发流程。

例如，设计流程或编码流程。

也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以（或者说需要）进行了。

    H模型揭示了一个原理：

软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。

H模型指出软件测试要尽早准备，尽早执行。

不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。

其他模型

   除上述几种常见模型外，业界还流传着其他几种模型，例如X模型、前置测试模型等。

X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。

前置测试模型体现了开发与测试的结合，要求对每一个交付内容进行测试。

这些模型都针对其他模型的缺点提出了一些修正意见，但本身也可能存在一些不周到的地方。

所以在测试过程管理中，正确选取过程模型是一个关键问题。

1．3软件测试过程模型选取策略

   前面介绍的测试过程模型中，V模型强调了在整个项目开发中需要经历的不同的测试级别，但忽视了测试的对象不应该仅仅是程序。

而W模型在这一点上进行了补充，明确指出应该对需求、设计进行测试。

但是V模型和W模型都没有将一个完整的测试过程抽象出来，成为一个独立的流程，这并不适合当前软件开发中广泛应用的迭代模型。

H模型则明确指出测试的独立性，也就是说只要测试条件成熟了，就可以开展测试。

   在实际测试工作中我们应该尽可能地去应用各模型中对项目有实用价值的方面，不能强行的为使用模型而使用模型。

在测试实践中，我们采用的方法是：

以W模型作为框架，及早的、全面的开展测试。

同时灵活运用H模型独立测试的思想，在达到恰当的就绪点时就应该开展独立的测试工作，同时将测试工作进行迭代，最终保证完成测试目标。

2测试过程管理理念

   生命周期模型为我们提供了软件测试的流程和方法，为测试过程管理提供了依据。

但实际的测试工作是复杂而烦琐的，可能不会有哪种模型完全适用于某项测试工作。

所以，我们应该从不同的模型中抽象出符合实际现状的测试过程管理理念，依据这些理念来策划测试过程，以不变应万变。

当然测试管理牵涉的范围非常的广泛，包括过程定义、人力资源管理、风险管理等等，本节仅介绍几条从过程模型中提炼出来的，对实际测试有指导意义的管理理念。

2．1尽早测试

   “尽早测试”是从W模型中抽象出来的理念。

我们说测试并不是在代码编写完成之后才开展的工作，测试与开发是两个相互依存的并行的过程，测试活动在开发活动的前期已经开展。

   “尽早测试”包含两方面的含义：

第一，测试人员早期参与软件项目，及时开展测试的准备工作，包括编写测试计划、制定测试方案以及准备测试用例；第二，尽早的开展测试执行工作，一旦代码模块完成就应该及时开展单元测试，一旦代码模块被集成成为相对独立的子系统，便可以开展集成测试，一旦有BUILD提交，便可以开展系统测试工作。

   由于及早的开展了测试准备工作，测试人员能够于早期了解测试的难度、预测测试的风险，从而有效提高了测试效率，规避测试风险。

由于及早的开展测试执行工作，测试人员尽早的发现软件缺陷，大大降低了BUG修复成本。

但是需要注意，“尽早测试”并非盲目的提前测试活动，测试活动开展的前提是达到必须的测试就绪点。

2．2全面测试

   软件是程序、数据和文档的集合，那么对软件进行测试，就不仅仅是对程序的测试，还应包括软件“副产品”的“全面测试”，这是W模型中一个重要的思想。

需求文档、设计文档作为软件的阶段性产品，直接影响到软件的质量。

阶段产品质量是软件质量的量的积累，不能把握这些阶段产品的质量将导致最终软件质量的不可控。

   “全面测试”包含两层含义：

第一，对软件的所有产品进行全面的测试，包括需求、设计文档，代码，用户文档等等。

第二，软件开发及测试人员（有时包括用户）全面的参与到测试工作中，例如对需求的验证和确认活动，就需要开发、测试及用户的全面参与，毕竟测试活动并不仅仅是保证软件运行正确，同时还要保证软件满足了用户的需求。

   “全面测试”有助于全方位把握软件质量，尽最大可能的排除造成软件质量问题的因素，从而保证软件满足质量需求。

2．3全过程测试

   在W模型中充分体现的另一个理念就是“全过程测试”。

双V字过程图形象的表明了软件开发与软件测试的紧密结合，这就说明软件开发和测试过程会彼此影响，这就要求测试人员对开发和测试的全过程进行充分的关注。

   “全过程测试”包含两层含义：

第一，测试人员要充分关注开发过程，对开发过程的各种变化及时做出响应。

例如开发进度的调整可能会引起测试进度及测试策略的调整，需求的变更会影响到测试的执行等等。

第二，测试人员要对测试的全过程进行全程的跟踪，例如建立完善的度量与分析机制，通过对自身过程的度量，及时了解过程信息，调整测试策略。

   “全过程测试”有助于及时应对项目变化，降低测试风险。

同时对测试过程的度量与分析也有助于把握测试过程，调整测试策略，便于测试过程的改进。

2．4独立的、迭代的测试

   我们知道，软件开发瀑布模型只是一种理想状况。

为适应不同的需要，人们在软件开发过程中摸索出了如螺旋、迭代等诸多模型，这些中需求、设计、编码工作可能重叠并反复进行的，这时的测试工作将也是迭代和反复的。

如果不能将测试从开发中抽象出来进行管理，势必使测试管理陷入困境。

   软件测试与软件开发是紧密结合的，但并不代表测试是依附于开发的一个过程，测试活动是独立的。

这正是H模型所主导的思想。

“独立的、迭代的测试”着重强调了测试的就绪点，也就是说，只要测试条件成熟，测试准备活动完成，测试的执行活动就可以开展。

   所以，我们在遵循尽早测试、全面测试、全过程测试理念的同时，应当将测试过程从开发过程中适当的抽象出来，作为一个独立的过程进行管理。

时刻把握独立的、迭代测试的理念，减小因开发模型的繁杂给测试管理工作带来的不便。

对于软件过程中不同阶段的产品和不同的测试类型，只要测试准备工作就绪，就可以及时开展测试工作，把握产品质量。

3测试过程管理实践

   本节以一个实际项目系统测试过程（不对单元测试和集成测试过程进行分析）的几个关键过程管理行为为例，来阐述上节中提出的测试理念。

在一个构件化ERP项目中，由于前期需求不明确，开发周期相对较长，为了对项目进行更好的跟踪和管理，项目采用增量和迭代模型进行开发。

整个项目开发共分三个阶段完成：

第一阶段实现进销存的简单的功能和工作流；第二阶段：

实现固定资产管理、财务管理，并完善第一阶段的进销存功能；第三阶段：

增加办公自动化的管理（OA）。

该项目每一阶段工作是对上一阶段成果的一次迭代完善，同时将新功能进行了一次叠加。

3．1策划测试过程

   依据传统的方法，将系统测试作为软件开发的一个阶段，系统测试执行工作将在三个阶段完成后开展，很明显，这样做不利于BUG的及时暴露。

有些缺陷可能会埋藏至后期发现，这时的修复成本将大大提高。

我们依据“独立和迭代”的测试理念，在本系统中，对测试过程进行独立的策划，找出测试准备就绪点，在就绪点及时开展测试。

该系统的三个阶段具有相对的独立性，在每一阶段完成所提交的阶段产品具有相对的独立性，可以作为系统测试准备的就绪点。

故而，在该系统开发过程中，系统测试组计划开展三阶段的系统测试，每个阶段系统测试具有不同的侧重点，目的在于更好的配合开发工作尽早发现软件BUG，降低软件成本。

软件开发与系统测试过程的关系如图3-1所示。

   实践证明，这种做法起到了预期的效果，与开发过程紧密结合而又相对独立的测试过程，有效的于早期发现了许多系统缺陷，降低了开发成本，同时也使基于复杂开发模型的测试管理工作更加清晰明了。

3．2把握需求

   在本系统开发过程中，需求的获取和完善贯穿每个阶段。

对需求的把握很大程度上决定了软件测试是否能够成功。

系统测试不仅仅确认软件是否正确实现功能，同时还要确认软件是否满足用户的需要。

依据“尽早测试”和“全面测试”原则，在需求的获取阶段，测试人员参与到了对需求的讨论之中。

测试人员与开发人员及用户一起讨论需求的完善性与正确性，同时从可测试性角度为需求文档提出建议。

这些建议对开发人员来说，是从一个全新的思维角度提出的约束。

同时，测试组结合前期对项目的把握，很容易制定出了完善的测试计划和方案，将各阶段产品的测试方法及进度、人员安排进行了策划，使整个项目的进展有条不紊。

实践证明，测试人员早期参与需求的获取和分析中，有助于加深测试人员对需求的把握和理解，同时也大大促进需求文档的质量。

在