我们来了解软件测试的模型吧,这个模型决定了我们工作将在何时开展以及如何开展。我们简单来介绍下软件产品,辅助我们理解模型。软件产品最初的模样或许只是一个idea,经过判断,决定要使它成为某一样能够被实践的物品。由idea到这个能够被实践的物品,是一定要经过一个过程的,那么,这个过程如何进行的或者这个能够被实践的物品是怎样被做出来的,期间需要经过的步骤就是模型。

先来了解下v模型:

软件测试模型—软件测试入门_白箱测试
从上图的v模型中,我们可以了解到,测试过程的开展是被放在开发结束之后的。

我们针对图中的单元测试、集成测试、系统测试、验收测试分别做一些说明。

(1)单元测试所检测代码的开发是否符合详细设计的要求。(单元测试一般是由程序员自检的。对于那些没有开发经验的小伙伴来说,其实不用太过于担心。我们所需要的就是能够看懂。)

(2)集成测试所检验此前测试过的各组成部分是否能完好的结合到一起。(举例来说明,就是将自行车的零件组合好。)

(3)系统测试所检验已集成在一起的产品是否符合系统规格说明书的要求。(这部分,就是看自行车所可以实现的是否与最初的设计要求是否一致。)

(4)验收测试则检验产品是否符合最终用户的需求。(就是将自行车成品提交给当初需要创造自行的人,进行验收。)

v模型的特点是仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段。

优点是:

1、既有底层的测试(单元测试)又有高层的测试(系统测试)。

2、将开发清楚的表现出来,便于控制开发的过程,当所有的阶段都结束时,软件开发就借结束了。

缺点是会伴随的:

1、因为v模型的自身顺序性导致若忽视了测试对需求分析,系统设计的验证,一直到后期的验收测试才被发现。这加大了测试发现重大缺陷的风险,不容易找到缺陷的根源。(用比较直白的话来解释,意思就是,因为测试工作的开展是被放在开发结束之后的,前面的阶段参与就会比较少,当东西被制作出来时,你才会检测,无疑,当有缺陷的时候,你很难定位具体产生问题的原因,因为不熟悉被制造的过程。)

2、当需求变更会导致阶段反复,都要重复设计、编码、测试、返工量大,灵活度低。(可以理解为,当制造一个东西的初衷发生改变的时候,那么就需要进行修改,而原有的初衷,或者被创造的东西就需要进行修改,由于阶段是层层执行的,因此,当一个阶段发生改变的时候,下属的阶段就得跟着进行改变。)

软件测试模型—软件测试入门_软件测试_02
w模型的特点:

1、测试伴随着整个软件开发周期;

2、测试的对象不仅仅是程序,需求、设计等同样要测试;

3、测试与开发时同步进行的;

优点:w模型有利于尽早地全面的发现问题,有利于降低开发成本;

特点2 :

1、需求、设计、编码等活动被视为串行的;

2、测试和开发活动也保持着一种线性的前后关系,上一阶段完全结束,才可正式开始下一阶段工作。

局限性:

1、无法支持迭代的开发模型;

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

下图是v模型和w模型的比较说明,帮互助我们更好的区分这两者:

软件测试模型—软件测试入门_软件工程师_03
在了解敏捷模型之前我们先来了解一下,敏捷开发,制造过程有助于我们消化敏捷模型。

敏捷开发:

最大特点是高度迭代,有周期性,并且能够及时、持续的响应客户的频繁反馈。

敏捷测试:

不断修正质量指标,正确建立测试策略,确认客户的有效需求能够得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。

敏捷开发的核心思想:

适应变化和以人为中心。

敏捷宣言:

个体与交互 重于 过程和工具

可用的软件 重于 完备的文档

客户协作 重于 合同谈判

响应变化 重于 遵循计划

敏捷测试是遵循敏捷宣言的一种测试实践:

1、强调从客户的角度,即从使用系统的用户角度,来测试系统。

2、重点关注持续迭代地测试新开发的功能,而不再是强调传统测试过程中的严格的测试阶段。

3、建议尽早开始测试。

敏捷测试与普通测试区别:

传统测试:

测试是质量的保护者;

严格的变更理;

预先的计划和细节的准备;

重量级的文档;

敏捷测试:

开发和测试人员是紧密合作,大家都有责任对软件负责;

变更是可接受的,拥抱变更;

计划随进展时常调整;

只需要绝对必要的文档;

大爆炸模型:

这种模型通俗来讲是一种创作,灵感降临并发生,在最终完成之前,你并不清楚它究竟是怎样的,因此,软件测试人员在这个模型中需要完成的工作任务就是在创作结束之后,撰写一份用户手册,以及报告发现的缺陷。

可能在实际的工作中并没有完全按照以上某种模型来,但很多都是以上模型的衍生,因此,我们要了解这个模型,以及其中想要传达的思想,这样在进入工作的时候,更能明白自己要怎样发挥自己,更好的完成工作。