软件测试模型

正如软件开发有开发过程模型一样,软件测试也有模型。软件测试模型是软件测试工作的框架,它描述了软件测试过程中所包含的主要活动以及这些活动间的相互关系。通过测试模型,软件测试工程师以及相关人员可以了解测试何时开始,何时结束,测试过程中主要包含哪些活动以及需要哪些资源等。

软件测试模型

1.V-模型

在传统的瀑布型软件开发过程中,仅仅将测试过程作为需求分析,设计,实现后的一个阶段,对软件测试过程没有进一步的描述。V模型针对瀑布模型对软件测试过程进行了补充和完善。在该模型中,测试过程将被加在开发过程中的后半部分,如图所示:
在这里插入图片描述
V模型反映出测试活动与分析设计活动的关系。从左到右描述了基本的开发过程和测试行为,非常明确地标注了测试过程中存在的不同类型的测试,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
在V模型中的测试执行阶段一侧,先进行单元测试,然后进行集成测试,系统测试,最后进行验收测试,这些测试形成了软件测试的不同层次(级别),并与开发过程的相应阶段对应。各级测试的目的主要有:
(1)单元测试:检测最小的软件设计单元模块是否符合详细设计的要求,是否存在编码错误,确保产生符合要求的,运行可靠的程序单元。单元测试是最低层次的测试,但却是最有效的测试,在性能价格比上最优。
(2)集成测试:检测此前已经检验过的各个模块(单元)是否能够完好地结合在一起,是否在接口等方面存在错误,确保各单元(模块)以正确,稳定和一致的方式进行交互。
(3)系统测试:检测已集成在一起的产品是否符合需求规格说明书的需求。主要验证系统的功能性续需求和非功能性需求,为下一阶段的验收测试奠定基础。
(4)验收测试:检测产品是否符合最终用户的要求,并在软件正式交货前确保系统能够正常工作且可用。
简单来说,单元测试和集成测试主要检测程序的执行是否满足软件设计的要求;系统测试应检测系统性能,性能的质量特性是否到达系统要求的指标;验收测试确定软件的实现是否满足用户需要或合同的要求。
但V模型存在一定的局限性,它仅仅把测试作为在编码之后的一个阶段,是针对程序进行的寻找错误的活动,而忽视了测试活动对需求分析,系统设计等活动的验收和确认。
主要不足有:
(1)软件测试执行时在编码实现之后才进行,容易导致从需求,设计等阶段隐藏的缺陷一直到验收测试才被发现,这将导致发现和消除这些缺陷的代价非常高。
(2)将开发和测试过程划分为固定边界的不同阶段,是的相关人员很难跨过这些边界来采集测试所需要的信息。
(3)容易让人形成“测试是开发之后的一个阶段”,“测试的对象就是程序”等误解。

2.W模型

在V模型中,软件测试执行是在编码实现之后才进行,容易导致从需求,设计等阶段隐藏的缺陷一直到验收测试才被发现。由于软件缺陷的发现和解决的成本具有放大性,如在需求阶段遗留的确信啊在成品交付后才发现和解决,其代价是在需求阶段发现和解决代价的40~1000倍。因此,软件测试工作越早进行,其发现和解决错误的代价越小,风险也越小。根据这个观点:Systeme Evolutif公司在V模型的基础上提出了W模型,如下所示:
在这里插入图片描述
在该模型中,W模型是由两个“V”重叠而成。其中一个表示开发过程,另外一个表示测试过程。软件测试中的各项活动与开发过程各个阶段的活动相对应。软件开发过程中各阶段可交付产品(文档,代码和可执行程序)都要进行测试,以尽可能将各阶段产生的缺陷在该阶段发现和消除。
W模型使我们树立了一种新的观点,及软件测试并不等于程序的测试,不应仅仅局限于程序测试的狭小范围内,而应贯穿与整个软件开发周期。也就是说,测试与开发是同步进行的。W模型有利于尽早地,全面地发现问题。例如,需求分析完成后,测试人员就应该参与到需求的验证和确认活动中,以尽早地找出需求方面的缺陷。同时,对需求的测试也有利于及时了解项目难度和测试风险,及早制定应对措施,这将显著减少总体测试时间,加快项目进度。
但W模型也存在局限性。在W模型中,需求,设计,编码等活动被视为串行的,同时,测试和开发活动也保持则一种线性的前后关系,上一阶段完全结束,才可以正式开始下一阶段工作。这样就无法支持迭代的开发模型。对于当前软件复杂多变的情况,W模型并不能解除测试管理面临的困惑。

3.X模型

X模型的基本思想是由Marick提出的,Robin F.Goldsmith采用了Marick的部分想法并可以经过重新组织,形成了X模型。改模型并不是为了和V模型相对应而选择该名称,而是X通常代表未知。X模型如下所示:
在这里插入图片描述
X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试,伺候将进行频繁的交接,通过集成最终合成为可执行的程序。图中右上半部分这些可执行程序还需要进行测试,已通过集成测试成品若达到发布标准,则可以提交给用户,也可以作为更大规模和范围内集成的一部分。多条并行的曲线表示软件变更可以在各个部分发生。在图中右下方,X模型还定位了探索性测试,这是不进行事先计划的特殊类型的测试,这种探索性测试往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
X模型的主要不足为:X模型从没有被文档化,其内容一开始就需要从V模型的相关内容中进行,而且X模型没有明确的需求角色确认。

4.H模型

V模型和W模型均存在一些不足之处,如它们都把软件的开发视为需求,设计,编码等一系列串行活动,而事实上,这些活动在大部分时间被是可以交叉进行的,所以相应的测试层次之间也不存在严格的次序关系。
为了解决以上问题,有专家提出了H模型,如下图所示:
在这里插入图片描述
它将测试活动完全独立出来,形成了一个完全独立的流程,将测试准备活动和测试活动清晰地体现出来。
上图演示了在整个生产周期中某个层次上的一次测试“微循环”。图中所涉及的测试流程及开发流程可以根据项目需要选择任意开发测试模型中的流程。
由H模型可知:
(1)软件测试不仅仅指测试的执行,还包括很多其他的活动。
(2)软件测试是一个独立的流程,贯穿与产品整个生命周期,与其他流程并发地进行。
(3)软件测试要尽早准备,尽早执行。
(4)软件测试是根据被侧件的不同而分层次进行的。不同的层次的测试活动可以是按照某个次序先后进行的,但也可能是反复的。
H模型揭示了一个原理:软件测试是一个独立的流程,以独立完整“微循环”流程,参与产品生命周期的各个阶段,与其他流程并发地进行。H模型指出软件测试要尽早准备,尽早执行,只要某个测试达到准备就绪点,测试执行活动就可以开展,并且不同的测试活动可按照某个次序先后进行,但也可以是反复进行的。

  • 3
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

散一世繁华,颠半世琉璃

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值