V模型
1980年，Paul Rook（保罗·洛克）提出，旨在改进瀑布模型的开发效率和效果。
“V”的左端表示传统的瀑布开发模型，而“V”的右端表明相应的测试阶段
V模型大体可以划分为以下几个不同的阶段步骤：需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。
需求分析
即首先要明确客户需要的是什么，需要软件做成什么样子，需要有那几项功能，这一点上比较关键的是分析师和客户沟通时的理解能力与交互性。要求分析师能准确的把客户所需要达到的功能，实现方式，等表述出来，给出分析结果，写出需求规格说明书。
概要设计
主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。
详细设计
对概要设计中表述的各模块进行深入分析，对各模块组合进行分析等，这一阶段要求达到伪代码级别，已经把程序的具体实现的功能，现象等描述出来。其中需要包含数据库设计说明。
软件编码
按照详细设计好的模块功能表，编程人员编写出实际的代码。
单元测试
按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译，单元的具体划分根据不同的单位与不同的软件有不同，比如有具体到模块的测试，也有具体到类，函数的测试等。
集成测试
经过了单元测试后，将各单元组合成完整的体系，主要测试各模块间组合后的功能实现情况，以及模块接口连接的成功与否，数据传递的正确性等，其主要目的是检查软件单位之间的接口是否正确。根据集成测试计划，一边将模块或其他软件单位组合成系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。
系统测试
经过了单元测试和集成测试以后，我们要把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞，等。
验收测试
主要就是用户在拿到软件的时候，在使用现场，会根据前面提到的需求，以及规格说明书来做相应测试，以确定软件达到预期的效果。
对应关系
一般来讲：单元测试所对应的是详细设计环节，也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也就把测试用例写了出来；集成测试对应概要设计，在做模块功能分析及模块接口，数据传输方法的时候，就把集成测试用例根据概要设计中模块功能及接口等实现方法编写出来，以备以后作集成测试的时候可以直接引用；而系统测试，就是根据需求分析而来，在系统分析人员作系统分析，编写需求说明书的时候测试人员就根据客户需求说明书，把最后能实现系统功能的各种测试用例写出来，为做最后系统测试做准备。
验收测试与用户需求对应，是非设计流程。
缺陷及解决
V模型仅仅把测试过程作为在需求分析、系统测试及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。
解决的思路是，当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。
适用范围
V模式是一种传统软件开发模型，一般适用于一些传统信息系统应用的开发，而一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。
W模型
W模型，由Evolutif公司提出，相对于V模型，W模型增加了软件开发各阶段中同步进行的验证和确认活动。
如图所示，由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
W模型强调
测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等开发输出的文档同样要测试（这里针对设计文档，一般可以划分为需求设计文档、概要设计文档、详细设计文档和代码文档）， 也就是说，测试与开发是同步进行的。
从这个角度来说，一个完整合格的测试人员对软件各方面把握程度应该比开发人员更高，一个测试人员要能胜任软件研究任何一个岗位。
W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求文档的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试，加快项目进度。
局限性
但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。
优点
测试的活动与软件开发同步进行
测试的对象不仅仅是程序，还包括需求和设计
尽早发现软件缺陷可降低软件开发的成本