基于TMap的软件测试模型的分析研究
摘要：针对传统软件测试模型不能满足软件开发过程需要的状况，分析传统软件测试模型不够灵活和完备的现状，提出一种改进的基于TMap的软件测试模型。该结构化的软件测试模型改善了传统测试模型的限制和不足，并能以一种可控制的方式，使软件测试者对软件系统的状态和相关风险有持续的认识。
关键词：TMap软件测试管理方法；V模型；W模型；X 模型；软件测试
TP311 A 1009-3044（2016）10-0113-03
Abstract： In view of the situation that the traditional model of software testing can not meet the health needs of the software development process， and traditional software testing model is not flexible enough and complete. So the article puts forward an improved TMAP software testing model. The structured software testing model improves the limitation and deficiency of the traditional test model， and it enables software testers on the state of the software system and the risks associated with a continued awareness.
Key words： TMap software test management method； V model； W model； X model； software testing life cycle
1 背景
近年来，以测试为驱动的软件质量保障技术在软件开发中得到广泛的应用。测试是保证软件产品正确性和提高软件可靠性的最基本和最重要的手段之一，它已不仅仅是软件产品开发成型之后的附加行为而是伴随在整个软件开发生命
周期中的重要过程。软件的失效可能造成巨大的经济损失。例如，1996年Ariane5运载火箭的发射失败都是由软件故障引起的[1-2]。
在测试中，如何更早地发现缺陷，用最小的成本、彻底的、有效地完成测试任务，以减少软件发布后的成本支持，这就需要建立一个良好可靠的测试模型。于是各种软件测试模型被提出，主要有V模型、X模型和W模型，这些传统的测试模型都有自己的优点但也存着着一些限制和不足，还不能完全满足软件测试的需要，为了弥补传统测试模型的不足，TMap（Test Management Approach，软件测试管理方法）应运而生。目前，这个过程已被ISTQB（International Software Testing Qualification Board，国际软件测试资本认证委员会）所采用，成为了测试过程的标准。为了提供更加灵活的测试模型，本文对TMap软件测试管理方法进行归纳总结，抽象出适合当今软件开发需要的基于TMap的软件测试模型。
2 传统的软件测试模型缺陷分析
软件测试模型起到指导软件测试过程框架的作用[3]。著名的V模型是20世纪80年代后期Paul Rook提出的著名的软件测试模型，旨在改进软件开发的效率和效果[4]。它在传统的瀑布模型软件开发过程中增加了测试活动，并把它作为编码之后的一个阶段，但对测试的过程没有进一步描述。其主要针对瀑布模型对测试过程进行了补充，它的价值就在于它非常明确的阐明了测试过程中所存在的不同级别，并且很清楚地描述了这些级别和开发过程中各个阶段的一一对应关系。但V模型也存在许多不足之处：容易导致在需求阶段就存在的错误一直到最后测试时才被发现，无形中增加了软件开发的成本；V模型没有明确的指出测试的时机和规划，越来越多的开发案例说明越早的进行测试设计，就越能避免软件开发初期的问题扩散到整个系统当中，V模型违背了越早发现错误越有利的原则[5]。
W模型是Evolutif公司针对V模型的缺陷提出的一种改进的测试模型。它强调测试过程和开发过程同时开始同时结束，并且开发和测试相互依赖。前期，测试过程更多的依赖开发过程，后期，开发过程更多的依赖测试过程。W模型，尽管已经改善了V模型存在的一些不足，但不论是W模型还是V模型，都只适用于那些需求非常明确且已经文档化了的项目，测试人员需要根据严格定义好的需求和设计来进行工作。但是在实际开发过程中，开发中因为需求变化等原因，开发人员实际上并没有按照文档的要求来工作，也就是说文档没有根据需求的变化及时更新，更或者有时候在一些开发流程不规范的公司，根本就没有文档。在上述情况下，V模型和W模型在实施起来都是很困难的。此外，这两种模型都把软件的开发过程看作计划、设计、编码、测试等一系列的串行活动。但事实上，大部分时间这些活
动是互相独立的，也就是说这些活动是可以并发进行的。虽然软件开发流程期望有清晰的设计和编码等阶段，但实际的软件开发经验告诉我们，清晰的阶段之分只是一种理想的状况。
X模型也是一种对V模型的改进方法，其缺陷在于：没有明确指出在软件测试的每个阶段都应该进行测试；没有像V 模型那样有明确的需求角确认；X模型并不要对每一段程序都进行单元测试，也不像V模型那样有很明确的固定的边界，但是X模型没能提供不进行单元测试的判断准则；X模型过于关注低级别的即程序级别的行为，而没有形成一个系统的模型。
3 TMap测试管理模型的提出及应用
TMap测试管理模型，改善了传统软件测试模型的弊端，提出了一个完整的、一致的、灵活的方法。可以根据特定环境创建量身定制的测试方法，以及在不同的特定环境中可以采用的通用方法，从而适合于各种行业以及各种规模的组织。  3.1 TMap的测试生命周期
TMap描述的软件测试生命周期共分为五个阶段：计划和控制阶段、准备阶段、说明阶段、执行阶段和完成阶段。其生命周期模型如图1所示。
<E>图1 TMap描述的生命周期模型
3.1.1 计划和控制阶段
计划和控制阶段涉及测试计划的创建，定义了测试活动的相关内容。计划阶段中的活动是建立易于管理和高质量的测试过程的基础。这是一个非常重要的测试阶段，然而在实际测试过程中它的重要性却总是被低估。在这个阶段，需要根据风险分析过程来制定测试策略、测试估算和策划。接下来需要确定所使用的测试技术，以便选择适当的测试覆盖率并尽量使其达到最优。然后，可以对测试组织人员和测试基础设施进行初始规划。
通常一些测试过程很少能够按照计划被执行。因此，必要时必须对测试计划的执行进行监控和调整。这就是控制阶段的工作。在控制阶段所有测试活动的目的是以最优的方式控制和报告测试过程，以测试人员能够对测试过程的进度和质量以及测试对象的质量有深入的了解和良好的控制。
软件测试过程中测试人员需要对测试过程、基础设施和测试产品进行管理，并使用测试过程中收集到的数据进行趋势分析。同时，也要确保能够及时获得与测试相关的开发过程信息，如开发中的延迟、将要进行的较大规模变更以及项目调整等。
3.1.2 准备阶段
测试依据的可测试性评审是在准备阶段中完成的。这一阶段的目标是使测试依据的质量能够满足测试设计的要求。此外，在项目早期对测试依据进行可测性评审能够提高质量，并减少后期发现缺陷而付出的高额代价。因为，开发人员要基于系统文档（测试依据的一部分）进行系统开发，而这些系统文软件测试app
档可能会存在一些错误，如果这些错误没有被及时发现的话，将会导致大量修正工作（通常需要付出高额
代价）。在开发过程中，错误越早被发现，修复的工作越容易（代价越小）。
3.1.3 说明阶段
说明阶段涉及定义测试用例和构建基础设施。这样做的目的是尽可能的多做准备，从而当开发团队提供测试对象后，可以尽可能快地执行测试。一旦测试依据的可测试性评审结束后，这阶段的活动便可以开始进行。测试说明活动可以与软件的实现同时进行或者在差不多的时间段内进行。
3.1.4 执行阶段
执行阶段的目的是通过执行已商定的测试用例来深入了解测试对象的质量。真正的测试执行是在测试对象交付到测试团队的时间点开始的。首先要对测试对象的完整性进行检查。然后，将测试对象安装在测试环境中来评估其功能是否满足需求。
上述的活动通常可以由第一轮测试进行确认，即所谓的预测试。预测试是结合测试基础架构，对被测对象进行的一个整体检查，以确认被测对象的质量是否达到进行深入测试的要求。进行预测试之前要满足主测试前置条件，接下来可以依据在设计阶段建立的测试脚本来执行测试，并且本测试活动执行
之前需要满足执行测试脚本所需的前置条件。测试执行阶段还包括对测试结果的验证，通常以缺陷报告的形式记录预期结果和实际结果之间的差异。
3.1.5 结束阶段
在重复进行的过程中应用TMap结构化测试方法可以带来许多好处。它可以促进测试成果物在后续测试过程中的复用以及加速一些测试活动。测试产品可以是有形的东西――测试件，如测试用例或测试环境，也可以无形的东西――过程评估，如对经验的总结。
当保存测试件时，需要从大量测试件中选择适合的内容进行保存。测试件主要包括测试用例、测试脚本和测试基础架构说明等。在测试过程中，要保证测试用例与测试依

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。