下载掌阅APP，畅读海量书库
立即打开
软件测试和软件开发一样，都遵循软件工程原理，遵循管理学原理。测试专家通过实践总结出了很多很好的测试模型。这些模型将测试活动进行了抽象，明确了测试与开发之间的关系，可以更好地指导软件测试的全部过程、活动和任务，是测试管理的重要参考依据。
软件测试生命周期是指软件从进入测试到退出测试的过程中，所要经历的引入程序错误、通过测试发现错误和清除程序错误的几个阶段。
当前最常见的软件测试模型有V模型、W模型、H模型、X模型和前置测试模型。
V模型最早是由Paul Rook在20世纪80年代后期提出的。V模型是基于瀑布模型的，V模型描述了基本的开发过程和测试行为。软件测试的V模型以编码为黄金分割线，将整个过程分为开发和测试，并且开发和测试之间是串行的关系。
V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程的对应关系。如图1-14所示，组件测试阶段依据组件测试计划执行测试用例，检测程序内部结构是否正确；集成测试阶段依据集成测试计划检测程序是否满足概要设计的要求，重点测试不同模块的接口；系统测试检测系统的功能、性能及软件运行的软硬件环境是否达到系统设计要求；验收测试确认软件的实现是否满足用户需求。总体来说，V模型实现了开发过程与测试阶段的集成，符合测试尽早介入的原则；每个开发过程，有对应的测试级别以支持测试的尽早介入；每个测试级别的测试执行是顺序进行的，有时候也会出现重叠。
图1-14 V模型
V模型清楚地标识了开发和测试的各个阶段，每个阶段分工明确，便于整体项目的把控。V模型有一个缺点，就是将测试放在整个开发的最后阶段，没有让测试尽早介入开发，没有在需求分析阶段就引入测试，忽视了测试活动对需求分析、系统设计等开发活动的验证和确认功能。
软件测试的W模型由Evolutif公司提出，W模型是V模型的发展。W模型是由两个V模型组成的，一个是开发阶段，一个是测试阶段。在W模型中，开发和测试是并行的关系，如图1-15所示，图中的“V&V”代表验证（Verification）和确认（Validation）。
W模型强调测试伴随整个软件开发周期，测试的对象不仅仅是程序，需求、功能和设计同样要测试。例如，需求分析完成后，测试人员参与需求的验证和确认活动，并进行系统测试的设计，开发组输出软件需求规格说明书，测试组输出的系统测试计划书成为系统测试阶段的依据文档。又如，详细设计阶段结束后，测试人员参与详细设计的验证和确认活动，进行组件测试设计，在开发完成编码后，依据组件测试计划和测试用例执行组件测试。
图1-15 W测试模型
测试与开发并行，让测试尽早介入开发环节，使测试尽早发现问题、尽早解决问题。同时，开发阶段的测试有利于及时了解项目的难度、设计结构和代码结构，及早识别测试风险，及早制定应对措施。
虽然开发与测试是并行的，但是在整个研发阶段仍然是串行的，上一阶段未完成无法进入下一阶段，不支持敏捷模式的开发。开发和测试的线性关系导致需求变更的不便。如果没有文档，就无法执行 W 模型。W 模型对整个项目组成员的技术要求更高。
W模型和V模型都把软件开发视为需求、设计、编码等一系列串行的活动，无法支持迭代、自发性以及变更调整。为了解决以上问题，专家提出了更多改进模型。
H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早地进行，并且可以根据被测对象的不同而分层次进行。
图1-16演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的“其他流程”可以是任意的开发流程（如设计流程或编码流程）。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了。例如，整个项目进行到编码阶段时，测试人员准备好了组件测试计划和测试用例，开发人员完成了一个模块的编码（即测试就绪点具备），此时，就可以启动测试流程对此模块执行测试。
图1-16 H模型
H模型揭示了软件测试除测试执行外，还有很多工作。测试完全独立，贯穿整个生命周期，且与其他流程并发进行；软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；测试可以根据被测试对象的不同而分层次、分阶段、分次序地执行，同时也是可以被迭代的。
H模型对管理、技能及整个项目组的人员要求都很高。管理方面，由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制。技能上，H模型要求能够很好地定义每个迭代的规模，不能太大也不能太小。测试就绪点分析是困难的，因为很多时候并不知道测试准备到什么程度是合适的，就绪点在哪里，就绪点的标准是什么，这就给后续测试执行的启动带来很大困难。对于整个项目组的人员要求非常高，在很好的规范制度下，大家都能高效地工作，否则容易造成混乱。
X模型的基本思想是由Marick提出的，Robin F Goldsmith引用了Marick的一些想法并经过重新组织形成了X模型。如图1-17所示，X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成，最终成为可执行的程序，之后对这些可执行程序进行测试。X模型左边是组件测试和单元模型之间的集成测试，右边是功能的集成测试，通过不断的集成最后成为一个系统，如果整个系统测试没有问题，就可以封版发布。已通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多条并行的曲线表示变更可以在各个部分发生。
由图可见，X模型还引入了探索性测试，即不进行事先计划的特殊类型的测试，这样可以帮助有经验的测试工程师发现测试计划之外更多的软件错误，避免把大量时间花费在编写测试文档上，导致真正用于测试的时间减少。
X模型有一个很大的优点，那就是它呈现了一种动态测试的过程，测试处于一个不断迭代的过程中，这更符合企业实际情况，而其他模型更像一个静态的测试过程。
图1-17 X模型
前置测试模型是由Robin F Goldsmith等人提出的，是一个将测试和开发紧密结合的模型。该模型提供了轻松的方式，可以使项目加快速度。接下来，结合图1-18来详细分析模型的特点。
图1-18 前置测试模型
1.开发和测试相结合
前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为。例如，图中在开发生命周期的验收测试阶段，依据系统分析结果和基本测试的需求来制定验收标准，制订验收测试计划，而后执行验收，进行验收测试，之后进入开发生命周期的运行与维护阶段。
2.对每一个交付内容进行测试
每一个交付的开发结果都必须通过一定的方式进行测试。源程序代码并不是唯一需要测试的内容。其他一些要测试的对象包括可行性报告、业务需求说明以及系统设计文档等。这与V模型中开发和测试的对应关系是一致的，并且在其基础上有所扩展，变得更为明确。
3.在设计阶段进行测试计划和设计
设计阶段是做测试计划和设计的最好时机。图中，在系统设计阶段输出设计文档，依据系统设计结果和设计文档制订技术测试计划。如果仅仅在即将开始执行测试之前才完成测试计划和设计，那么测试只是验证了程序的正确性，而不是验证整个系统应该实现的内容。
4.测试和开发结合在一起
前置测试模型将测试执行和开发结合在一起，并在开发阶段以编码—测试—编码—测试的方式体现。也就是说，程序片段一旦编写完成，就会立即进行测试。图中，开发编码某功能、调试并进行非正式走查后，依据测试计划执行正式走查、组件测试、集成测试及系统测试等一系列测试活动。依次开发、测试完成其他程序片段。
5.让验收测试和技术测试保持相互独立
验收测试应该独立于技术测试，这样可以提供双重保险，以保证设计及程序编码能够符合最终用户的需求。验收测试既可以在实施阶段的第一步执行，也可以在开发阶段的最后一步执行。
软件测试模型对指导测试工作的进行具有重要的意义，但任何模型都不是完美的，实际工作中应灵活地运用各种模型的优点。比如，可以在W模型的框架下，运用H模型的思想进行独立的测试，同时将测试与开发紧密结合，寻找恰当的就绪点开始测试并反复迭代测试，最终保证按期完成预定目标。