求java软件测试中v&v模型简介
v&v模型又叫双v模型,是从v模型发展起来的。
所以先说一下v模型。
v模型是最具有代表性的测试模型。
v模型最早是由paul rook在20世纪80年代后期提出的,v模型在英国国家计算中心文献中发布,旨在改进软件开发的效率和效果。
在传统的开发模型中,比如瀑布模型,通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段,尽管有时测试工作会占用整个项目周期一半的时间,但是有人仍认为测试只是一个收尾工作,而不是主要的工程。
v模型是软件开发瀑布模型的变种,它反映了测试活动与分析和设计的关系。
局限性:把测试作为编码之后的最后一个活动,需求分析等前期产生的错误直到后期的验收测试才能发现优点:强调了在整个软件项目开发中需要经历的若干个测试级别,并与每一个开发级别对应;忽略了测试的对象不应该仅仅包括程序,没有明确指出对需求、设计的测试为了解决v模型的不足,就有了v&v模型。
v&v模型又叫w模型,由evolutif公司公司提出,相对于v模型,w模型增加了软件各开发阶段中应同步进行的验证和确认活动。
w模型由两个v字型模型组成,分别代表测试与开发过程,双v图明确表示出了测试与开发的并行关系。
w模型强调:测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、设计等同样要测试,也就是说,测试与开发是同步进行的。
w模型有利于尽早地全面的发现问题。
例如,需求分析完成后,测试人员就应该参与到对需求的验证和确认活动中,以尽早地找出缺陷所在。
同时,对需求的测试也有利于及时了解项目难度和测试风险,及早制定应对措施,这将显著减少总体测试时间,加快项目进度。
如果测试文档能尽早提交,那么就有了更多的检查和检阅的时间,这些文档还可用于评估开发文档。
另外还有一个很大的益处是,测试者可以在项目中尽可能早地面对规格说明书中的挑战。
这意味着测试不仅仅是评定软件的质量,还可以尽可能早地找出缺陷所在,从而帮助改进项目内部的质量。
参与前期工作的测试者可以预先估计问题和难度,这将可以显著地减少总体测试时间,加快项目进度。
根据w模型的要求,一旦有文档提供,就要及时确定测试条件,以及编写测试用例,这些工作对测试的各级别都有意义。
当需求被提交后,就需要确定高级别的测试用例来测试这些需求。
当概要设计编写完成后,就需要确定测试条件来查找该阶段的设计缺陷。
w模型也是有局限性的。
w模型和v模型都把软件的开发视为需求、设计、编码等一系列串行的活动。
同样,软件开发和测试保持一种线性的前后关系,需要有严格的指令表示上一阶段完全结束,才可以正式开始下一个阶段。
这样就无法支持迭代、自发性以及变更调整。
对于当前很多文档需要事后补充,或者根本没有文档的做法(这已成为一种开发的文化),这样就无法支持迭代的开发模型。
对于当前软件开发复杂多变的情况,w模型并不能解除测试管理面临着困惑。
测试模型的四种经典模型
w模型由evolutif公司提出,相对于v模型,w模型更科学。
w模型是v模型的发展,强调的是测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。
测试与开发是同步进行的,从而有利于尽早地发现问题。
w模型也有局限性。
w模型和v模型都把软件的开发视为需求、设计、编码等一系列串行的活动,无法支持迭代、自发性以及变更调整。
h模型中, 软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。
软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。
这个示意图演示了在整个生产周期中某个层次上的一次测试“微循环”。
图中标注的其它流程可以是任意的开发流程,例如设计流程或者编码流程。
也就是说, 只要测试条件成熟了,测试准备活动完成了,测试执行活动就可以进行了。
h模型揭示了一个原理:软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。
h模型指出软件测试要尽早准备, 尽早执行。
不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展。
软件工程软件开发v模型有哪些基本划分
v模型是对瀑布模型的修正,强调了验证活动,由paul rook在1980年率先提出。
在瀑布模型中,由于早期的错误可能要等到开发后期的测试阶段才能发现,所以可能带来严重的后果。
v模型就是在这点上改进了瀑布模型,即在软件开发的生存期中,开发活动和测试活动几乎同时开始,这两个并行的动态的过程就会极大地减小bug和error出现的概率。
v模型是瀑布模型的变种,它反映了测试活动与分析和设计的关系
软件生命周期模型的其它几种典型的软件生命周期模型
其它几种典型的生命周期模型包括迭代模型、快速原型模型、v模型、w模型。
迭代式模型是是rup(rational unified process,统一软件开发过程,统一软件过程)推荐的周期模型。
在rup中,迭代被定义为:迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。
所以,在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:(至少包括)需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。
实质上,它类似小型的瀑布式项目。
rup认为,所有的阶段(需求及其它)都可以细分为迭代。
每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。
迭代的思想如图所示。
迭代和瀑布的最大的差别就在于风险的暴露时间上。
“任何项目都会涉及到一定的风险。
如果能在生命周期中尽早确保避免了风险,那么您的计划自然会更趋精确。
有许多风险直到已准备集成系统时才被发现。
不管开发团队经验如何,都绝不可能预知所有的风险。
” 由于瀑布模型的特点(文档是主体),很多的问题在最后才会暴露出来,为了解决这些问题的风险是巨大的。
在迭代式生命周期中,您需要根据主要风险列表选择要在迭代中开发的新的增量内容。
每次迭代完成时都会生成一个经过测试的可执行文件,这样就可以核实是否已经降低了目标风险。
快速原型(rapid prototype)模型在功能上等价于产品的一个子集。
注意,这里说的是功能上。
瀑布模型的缺点就在于不够直观,快速原型法就解决了这个问题。
一般来说,根据客户的需要在很短的时间内解决用户最迫切需要,完成一个可以演示的产品。
这个产品只是实现部分的功能(最重要的)。
它最重要的目的是为了确定用户的真正需求。
在我的经验中,这种方法非常的有效,原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河,有些观点让你都觉得非常的吃惊。
在得到用户的需求之后,原型将被抛弃。
因为原型开发的速度很快,设计方面是几乎没有考虑的,如果保留原型的话,在随后的开发中会为此付出极大的代价。
至于保留原型方面,也是有一种叫做增量模型是这么做的,但这种模型并不为大家所接受,不在我们的讨论之内。
上述的模型中都有自己独特的思想,其实软件组织中很少说标准的采用那一种模型的。
模型和实用还是有很大的区别的。
软件生命周期模型的发展实际上是体现了软件工程理论的发展。
在最早的时候,软件的生命周期处于无序、混乱的情况。
一些人为了能够控制软件的开发过程,就把软件开发严格的区分为多个不同的阶段,并在阶段间加上严格的审查。
这就是瀑布模型产生的起因。
瀑布模型体现了人们对软件过程的一个希望:严格控制、确保质量。
可惜的是,现实往往是残酷的。
瀑布模型根本达不到这个过高的要求,因为软件的过程往往难于预测。
反而导致了其它的负面影响,例如大量的文档、繁琐的审批。
因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。
例如把过程细分来增加过程的可预测性。
测试与软件开发的各个阶段有什么关系?
这个的话,要看你所采用的测试模型了。
测试模型包括v模型、w模型、x模型、h模型、前置测试模型等。
一般来讲,v模型和w模型都规定了测试和开发活动的严格对应关系。
开发活动包含用户需求、需求分析、概要设计、详细设计,编码;测试活动包含单元测试、集成测试、系统测试、确认和验收测试,是反过来对应的。
转载请注明出处百家乐凯发k8-凯发网娱乐官网下载 » 软件的v和w模型