V模型
在传统的开发模型中，比如瀑布模型。模型人们通常把测试过程作为在需求分析概要设计详细设计和编码全部完成之后的一个阶段，尽管优势测试工作会占用整个项目周期一半的时间，但是有人依旧认为测试只是一个收尾工作，而不是主要的过程。V模型的推出就是对这种认识的改进，V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系，从左到右描述了基本的开发过程和测试行为，非常明确的标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
图中的箭头代表了时间方向，左边下降的是开发过程各阶段，与此对应的是右边上升的部分，即各测试过程的各个阶段。
V模型的软件测试策略既包括低层测试，又包括高层测试。低层测试是为了源代码的正确性，高层测试是为了使整个软件系统满足用户的需求。
V模型指出，单元和集成测试是验证的程序设计，开发人员和测试组成检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特征是否达到系统设计的指标；由测试人员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确保软件的实现是否满足用户需求或合同的要求。V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后一个阶段，主要是针对程序进行寻找错误，而需求分析阶段隐藏的问题一直到后期额额验收测试才被发现。
W模型
V模型的局限性在于没有明确的说明早期的测试，不能体现尽早的不断的进行软件测试原则。在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型。因为实际上开发是V，测试也是与此相并行的V。基于“尽早地不断地进行测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEE std 1012-1998《软件验证和确认》的原则。
W模型由Evolutif公司提出，相对于V模型，W模型更科学。W模型可以说是V 模型自然而然的发展。它强调:测试伴随着整个软件开发周期，而且测试的对象不仅仅 是程序，需求、功能和设计同样要测试。这样，只要相应的开发活动完成，我们就可以 开始执行测试，可以说，测试与开发是同步进行的，从而有利于尽早地发现问题。以需 求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需 求的验收测试。
如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些文档还可用 于评估开发文档。另外还有一个很大的益处是，测试者可以在项目中尽可能早地面对规 格说明书的挑战。这意味着测试不仅仅是评定软件的质量，测试还可以尽可能早地找出 缺陷所在，从而帮助改进项目内部的质量。参与前期工作的测试者可以预先估计问题和 难度，这将可以显著地减少总体测试时间，加快项目进度。
根据W模型的要求，一旦有文档提供,就要及时确定测试条件，以及编写测试用例， 这些工作对测试的各级别都有意义。当需求被提交后，就需要确定高级别的测试用例来 测试这些需求。当概要设计编写完成后，就需要确定测试条件来查找该阶段的设计缺陷。 W模型也是有局限性的。W模型和V模型都把软件的开发视为需求、设计、编码 等一系列串行的活动。同样的，软件开发和测试保持一种线性的前后关系，需要有严格 的指令表示上一阶段完全结束，才可正式开始下一个阶段。这样就无法支持迭代、自发 性以及变更调整。对于当前很多文档需要事后补充，或者根本没有文档的做法下(这已 成为一种开发的文化)，开发人员和测试人员都面临同样的困惑。
H模型
V模型和W模型均存在一些不要之处。首先，如前所述，它们都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上,虽然这些活动之间存在互相牵制的关系，但在大部分时间内，它们是可以交叉进行的。虽然软件开发期望有清晰的需求、设计和编码阶段，但实践告诉我们，严格的阶段划分只是一种理想状况。 试问，有几个软件项目是在有了明确的需求之后才开始设计的呢?所以，相应的测试之间也不存在严格的次序关系。同时，各层次之间的测试也存在反复触发、迭代和增量关系。其次，V模型和w模型都没有很好地体现测试流程的完整性。
为了解决以 上问题，有专家提出了H模型。它将测试活动完全独立出来，形成个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
这个示意图仅演示了在整个生产周期中某个层改上的一次测试“微循环”。图中的其他流程可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非开发流程，例如，SQA流程，甚至是测试流程自身。也就是说，只要测试条件成熟了，测试备活动完成了，测试执行活动就可以(或者说需要)进行了。
概括地说，H模型揭示了:
- 软件测试不仅仅指测试的执行，还包括很多其他的活动。
- 软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。
- 软件测试要尽早准备，尽早执行。
- 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。
在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
X模型
x模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后，将进行频繁的交接，通过集成最终合成为可执行的程序。这一点在图的右上方得以体现，而且这些可执行程序还需要进行测试，已通过测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。
同时，X模型还定位了搜索性测试。这是不进行事先计划的开发步骤，诸如“我这么测一下，结果会怎么样”，这一方式往往能帮组有经验的测试人员在测试计划之外发现更多的软件错误。
前置测试模型
开发和测试相结合:前置测试模型将开发和测试的生命周期整合在起，标识了项目生命周期从开始到结束之间的关键行为。并且标识了这些行为在项目用期中的价值所在。如果其中有些行为没有得到很好的执行，那么项目成功的问能性就会因此而有所降低。如果有业务需求，则系统开发过程将更有效率。我们认为在没有业务需求的情况下进行开发和测试是不可能的。而且，业务需求最好在设计和开发之前就被正确定义。
对每一个交付内容进行测试:每一个交付的开发结果都必须通过一定的方式进行测试。源程序代码并不是惟一需要测试的内容。图中的椭圆框表示了其他一些要测试的对象，包括可行性报告、业务需求说明，以及系统设计文档等。这同V模型中开发和测试的对应关系是一致的，并且在其基础上有所扩展，变得更为明确。
在设计阶段进行测试计划和测试设计:设计阶段是作测试计划和测试设计的最好时机。很多组织要么根本不作测试计划和测试设计，要么在即将开始执行测试之前才飞快地完成测试计划和测试设计。在这种情况下，测试只是验证了程序的正确性，而不是验证整个系统本该实现的东西。
测试和开发结合在一起:前置测试将测试执行和开发结合在起，并在开发阶段以编码一测试一编码一测试的方式来体现。也就是说，程序片段一旦编写完成，就会立即进行测试。一般情况下，先进行的测试是单元测试，因为开发人员认为通过测试来发现错误是最经济的方式。但也可参考X模型，即一一个程序片段也需要相关的集成测试，甚至有时还需要一些特殊测试。 对于一个特定的程序片段，其测试的顺序可以按照v模型的规定，但其中还会交织一些程序片段的开发，而不是按阶段完全地隔离。
让验收测试和技术测试保持相互独立:验收测试应该独立于技术测试，这样可以提供双重的保险，以保证设计及程序编码能够符合最终用户的需求。验收测试既可以在实施阶段的第一步来执行，也可以在开发阶段的最后一步执行。前置测试模型提倡验收测试和技术测试沿循两条不同的路线来进行，每条路线分别地验证系统是否能够如预期设想的那样进行正常工作。这样，当单独设计好的验收测试完成了系统的验证时，我们即可确信这是一个正确的系统。
