软件测试模型

软件测试模型

软件测试模型

常见的软件测试模型包括V模型、W模型、H模型、X模型和前置模型。

V模型是最具有代表意义的测试模型。V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系 。

• 从左到右，描述了根本的开发过程和测试行为，非常明确地标明了测试过程中存在的

不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系 。

• 左边依次下降的是开发过程各阶段，与此相对应的是右边依次上升的局部，即各测试

过程的各个阶段。

用户需求 验收测试

需求分析和系统设计 确认测试和系统测试

概要设计 集成测试

详细设计 单元测试

编码

1、V模型

1 / 9

. . . . .

在软件测试方面，V模型是最广为人知的模型，尽管很多富有实际经验的测试人员还是不太熟悉V模型，或者其它的模型。V模型已存在了很长时间，和瀑布开发模型有着一些共同的特性，由此也和瀑布模型一样地受到了批评和质疑。V模型中的过程从左到右，描述了根本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现.

V模型问题：

1. 测试是开发之后的一个阶段。

2. 测试的对象就是程序本身。

3. 实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。

2 / 9

. . . . .

4. 整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心，而且

上一步的结果必须是充分和正确的，如果任何一个环节出了问题，那么必将严重的影响整个工程的质量和预期进度

仅仅把测试过程作为在需求分析、系统设计与编码之后的一个阶段

无视了测试对需求分析,系统设计的验证，一直到后期的验收测试才被发现。

现代化的V模型依托计算机辅助控制系统设计〔CACSD：Computer-Aided Control System Design〕，将计算机支持工具贯穿于控制系统开发测试的全过程。计算机不仅可以辅助控制系统设计，进展方案设计和离线仿真，还用于实时快速控制原型、产品代码生成和硬件在回路测试。这里“V〞代表着“Verification〞和“Validation〞，这样就形成一套严谨完整的系统开发方法

第一阶段 功能需求定义和控制方案设计

在传统方法中，这一过程的产物就是几千字甚至几万字的文字说明。在现代方法中为了防止文字说明的模糊性与理解性错误，详细说明将采用模型方式，可以用信号流图的方式〔Simulink模型〕进展定义。 控制方案的设计也不再采用过去的那种先将对象模型简化成手工可以处理的形式，再根据经验进展手工设计的方式，而是用诸如

MATLAB/SIMULINK等计算机辅助建模与分析软件建立对象尽可能准确的模型，并进展离线仿真，从而防止了传统设计过程中，对象过于简化带来的设计方案无法满足实际对象要求的尴尬局面。

第二阶段 快速控制原型〔RCP〕

3 / 9

. . . . .

按现代设计方法，方案设计完毕后，无须等待软件工程师的编程和随后的代码硬件集成，而是利用计算机辅助设计工具自动将控制方案框图转换为代码并自动下载到硬件开发平台，从而快速实现控制系统的原型。原型中包括实际系统中可能的各种I/O，软件与硬件中断等实时特性。之后，就可以利用计算机辅助试验测试管理工具软件进展各种测试，以检验〔Validation〕控制方案对实际对象的控制效果，并在线优化控制参数。此时即使模型需要大规模修改，重新形成测试原型也只需要几分钟的时间。这样在最终实现控制方案之前，就可根本确认最终方案和效果，防止过多的资源浪费和时间消耗。

第三阶段 生成代码

传统的人工编程很容易引入缺陷，速度较慢；现代开发方法那么不同，产品代码的大局部由机器自动生成。对大多数工程师而言，如果能够加快开发速度，损失代码的局部实时运行效率是可以承受的，而且机器自动编码，很容易防止人为的各种错误。

第四阶段 硬件在回路仿真〔HILS〕

有了控制产品的初样，还必须对其进展全面综合的测试，以对照确认〔Verification〕产品与实际指标要求，特别是故障情况和极限条件下的测试。但如果用实际的控制对象进展测试，很多环境条件无法实现的，抑或要付出高昂的代价。 现代开发方法中计算机辅助设计工具〔软件/硬件〕将再次发挥作用，可以用HILS的方法和工具进展各种条件下的测试，特别是故障和极限条件下的测试。这是传统开发方法所不具备的。

第五阶段 系统集成测试/标定

产品型控制器制造完成后，需要与其它子系统连接起来，构成完整闭环进展全面、详

4 / 9

. . . . .

细的测试，以确认产品符合各项设计指标和需求定义。这一阶段的主要困难是，并行开发过程中，其它子系统局部未能就绪，无法集成。HILS应用可以替代闭环系统当中那些尚未就位或者不易获取的局部，用数学模型模拟它们的特性，并通过I/O端口为控制器提供相应的反应信号。这样，开发过程中各个子系统之间不必等待对方完成，就可以开展集成测试，与时的完成系统性能确认和调整。集成测试后期，产品需要根据具体的使用条件需要，调整成品控制器中的控制参数，即标定过程。

W模型[编辑]

W模型由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进展的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

W模型中测试与开发对应关系如下：

开发：需求分析、概要设计、 详细设计、 编码、 软件集成、系统集成、部署

↑ ↑ ↑ ↑ ↑ ↑ ↑

测试：需求评审、概要设计评审、详细设计评审、单元测试、集成测试、系统测试、验收测试

W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进展的。W模型有利于尽早地全面的发

5 / 9

. . . . .

现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于与时了解项目难度和测试风险，与早制定应对措施，这将显著减少总体测试时间，加快项目进度。 但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全完毕，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

2、W模型

V模型的局限性在于没有明确地说明早期的测试,无法表达“尽早地和不断地进展软件测试〞的原那么。在V模型中增加软件各开发阶段应同步进展的测试，演化为W 模型〔如下列图〕。在模型中不难看出，开发是“V〞，测试是与此并行的“V〞。基于“尽早地和不断地进展软件测试〞的原那么，在软件的需求和设计阶段的测试活动应遵循IEEE1012-1998《软件验证与确认〔V&V〕》的原那么。

W模型由Evolutif公司提出，相对于V模型，W模型更科学。W模型是V模型的开展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进展的，从而有利于尽早地发现问题。

6 / 9

. . . . .

W模型也有局限性。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，无法支持迭代、自发性以与变更调整。

7 / 9

. . . . .

H模型[编辑]

在H模型中，软件测试的过程活动完全独立，形成了一个完全独立的流程，贯穿于整个产品的周期，与其他流程并发进展，某个测试点准备就绪后就可以从测试准备阶段进展到测试执行阶段；软件测试可以根据被测产品的不同分层进展。

4、H模型

H模型中, 软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进展,某个测试点准备就绪时,就可以从测试准备阶段进展到测试执行阶段。软件测试可以尽早的进展,并且可以根据被测物的不同而分层次进展。

这个示意图演示了在整个生产周期中某个层次上的一次测试“微循环〞。图中标注的其它流程可以是任意的开发流程,例如设计流程或者编码流程。也就是说, 只要测试条件成熟了,测试准备活动完成了,测试执行活动就可以进展了。

H模型揭示了一个原理:软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流

8 / 9

. . . . .

程并发地进展。H模型指出软件测试要尽早准备, 尽早执行。不同的测试活动可以是按照某个次序先后进展的,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展

3、X模型

X模型也是对V模型的改良,X模型提出针对单独的程序片段进展相互别离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。

X模型的左边描述的是针对单独程序片段所进展的相互别离的编码和测试，此后将进展频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进展测试。己通过集成测试的成品可以进展封装并提交给用户，也可以作为更大规模和围集成的一局部。多根并行的曲线表示变更可以在各个局部发生。由图中可见，X模型还定位了探索性测试，这是不进展事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比拟高。

9 / 9