|
|
|
|
移动端

1.18.5 分类因子C5:测试过程模型

《软件测试基础教程》第1章软件测试的基本知识,本章作为一个导引,其目的在于让读者熟悉与软件测试相关的基本概念,建立起全书的框架。在本书后续章节中将要详细阐述的问题,首先在这里被提了出来。读完这章之后,读者就能够在软件测试和软件质量方面提出一些有意义的问题。本节为大家介绍分类因子C5:测试过程模型。

作者:王峰/郭长国/陈振华 等译来源:机械工业出版社|2011-09-16 21:46

技术沙龙 | 6月30日与多位专家探讨技术高速发展下如何应对运维新挑战!


1.18.5 分类因子C5:测试过程模型

软件测试能够以多种方式集成到软件生命周期中,这就导致了表1-8中所列的不同的测试过程模型,下面将讨论这些模型。

表1-8 软件测试技术的分类

 
瀑布测试模型瀑布模型是最早也是最少使用的软件生命周期模型之一。图1-23展示了基于瀑布模型开发过程中的不同阶段。尽管对每个阶段产生的制品的验证与确认是一个基本的测试活动,但静态测试和动态测试活动直到临近开发过程结束时才出现。更进一步,因为瀑布模型要求遵循一个严格的顺序过程,缺陷引入的阶段越早、发现的阶段越晚,纠正缺陷的成本越高。在采用瀑布模型时,很少有迭代或增量开发。
 
图1-23 瀑布测试模型

箭头表示被测软件制品从某阶段“流”到下一阶段。例如,设计文档是编码阶段的输入。这种“水往低处流”的瀑布性质,就是该模型名称的由来。

V测试模型如图1-24所示,V模型清晰定义了与开发过程各阶段相关联的测试活动。这些测试活动从开发过程之初开始,一直持续到开发过程结束,测试活动与开发活动并行进行。注意,V模型包含的开发阶段与瀑布模型相同,主要区别在于图形布局以及对测试活动的明确定义。另外值得注意的一点是,一旦得到需求,就可开展设计测试。

 
图1-24 V测试模型

螺旋测试不要将术语螺旋测试与螺旋模型相混淆,尽管两者相似,因为两者都能可视化表示成螺旋活动图(如图1-25所示)。螺旋模型是个通用的开发模型,可以衍生出瀑布模型、V模型、增量开发模型等过程模型。虽然测试在螺旋模型中是个关键活动,但螺旋测试指的是一个测试策略,该策略可应用于任何增量式的软件开发过程,特别是从原型系统演化为最终应用系统的情况。在螺旋测试中,测试活动的复杂程度随着原型系统演化阶段的增加而增加。

在螺旋测试的早期阶段,采用原型系统来评估最终的应用软件应该怎样演化,人们关注的焦点在于测试策划,即如何在项目的后续阶段开展测试。基于更加准确的需求规范,后续的迭代对原型系统进行进一步的完善。随着测试策划的深入,逐渐进行单元和集成测试。在最后阶段,需求已定义好之后,测试人员关注的是系统测试和验收测试。注意,本书中描述的所有测试生成技术都适用于螺旋测试。从图1-25可以发现,测试活动的成本(纵轴方向)随着后续迭代的增加而增加。

 
图1-25螺旋测试的可视化表示。测试活动随着时间和原型系统变化而演化,
在最后的迭代中,软件可以进行系统测试和验收测试

敏捷测试到现在为止,敏捷测试过程尚未完全定义清楚。一种定义方法就是,除了常规的测试阶段(如测试策划、测试设计和测试执行)之外,再定义敏捷测试应该涉及的东西。敏捷测试推广下列思想:

1)从需求分析阶段开始就在整个项目开发中包括与测试相关的活动;

2)与客户密切合作,让他们以测试的方式定义需求;

3)测试人员与开发人员相互协作,而不是对手;

4)经常测试,小量测试。

目前存在各种各样的测试过程模型,本书中描述的测试生成与评价技术适用于所有的测试过程。当然,关注测试过程是任何软件开发过程管理的重要方面。

下面的例子说明如何将不同类型的测试技术应用于同一段软件的测试,可以很容易地根据上面介绍的一个或多个分类因子对所用到的技术进行分类。

例1.32考虑测试一种Web服务软件W。W的主要功能是将给定温度值从一种量纲转换为另一种量纲,比如从华氏温度转换为摄氏温度。不管用的是何种测试生成技术,我们将对W的测试当作Web服务测试,这种分法是采用了分类因子C4描述的测试类型。

下面,考察可以用来测试W的各种测试生成技术。

首先,假设测试人员A通过提供样例输入并检查输出来测试W,生成测试输入时未采用具体的方法。根据分类因子C1,我们说A进行了黑盒测试,并采用ad hoc或试探法来生成测试数据。根据分类因子C2,我们说A对W进行了单元测试,不妨假设W是某大型软件的一个单元。假定W通过GUI与用户交互,我们可以根据分类因子C3,说A进行了GUI测试。

现在假设另一位测试人员B用Z语言为W编写了一套形式化规范,并根据该规范来生成、使用测试用例。在这种情况下,根据分类因子C1,我们说测试人员B进行了黑盒测试,并采用一套基于规范的算法来生成测试数据。

假设还有一位聪明的测试人员C,他采用W的形式规范来生成测试,然后测试W,并采用某个代码覆盖准则来评价代码覆盖率。假设C发现代码覆盖率不到100%,即采用形式规范生成的测试用例,W中有部分代码未被覆盖,没有被测试到。为了测试W中的未覆盖部分,C然后设计并运行了附加的测试用例。我们说,C进行了黑盒和白盒两类测试,采用了基于规范的测试生成技术,为了满足某些基于控制流的代码覆盖准则,增强了所设计的测试。

最后,假设测试人员D将W当作某大型软件的一个组件来测试。测试人员D没有接触W的源代码,因此只采用W的接口以及接口变异来设计测试。根据分类因子C1,我们说测试人员D进行了黑盒测试,并用接口变异来生成测试用例(参见练习1.20)。

从上面的例子中很明显地看到,简单地采用一种分类因子来描述测试技术,并不能提供关于执行的测试细节的足够信息。为了描述应用于任何软件对象的一套测试技术,必须清晰描述下列因素:

所采用的测试生成方法;所生成的测试用例数量;执行的测试用例数量;失败的测试用例数量;通过的测试用例数量。

所采用的测试充分性评价准则;以定量方式描述的测试评价结果。

测试增强:基于输出充分性评价而设计的额外测试用例数量;执行的额外测试用例数量;发现的额外失效数量。

注意,必须将测试生成、充分性评价以及测试增强当作是一组集成的测试活动。正是这些活动的复杂性以及对活动的执行,构成了最终提交软件的质量的一个重要决定因素。

【责任编辑:云霞 TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

非常网管——网络工程案例

本书面向企业网络应用需求,详细介绍了Windows网络互联解决方案、中小企业共享上网解决方案、基于ISA Server 2006的代理服务器与防火墙解决...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊