这是IBM的测试模型，V模型，关键特点就是强调测试的早期介入。
大写的V字母有2条分支，从图中可以看出也是有2条分支，左边一条是从“系统分析， 分解， 设计，编码”的过程，而右边是“组件测试，系统测试，系统集成测试，用户可验收测试，部署”的过程。
V的左右同一高度都有一定的关系，当项目在做需求分析和设计阶段，都有相应的测试人员参与其中，一般都是经验比较多的测试同事去。测试人员要早期介入项目阶段，也许项目在分析和设计阶段就会出现错误和风险，这个时候如果测试人员能够提出这些问题，这将很珍贵的，因为一个缺陷发现得越早，修复的成本越低，bug造成的损失也越小。测试人员早期介入项目的各个阶段，也是为了让测试人员早点接触到这个项目，了解到更多的项目细节，更多的准备和设计。有时候是有测试人员全程跟踪项目的需求分析和设计阶段，也有时候是需求阶段快结束的时候和设计阶段快结束的时候才由测试人员跟进。
项目在测试的过程中，也就是V的右边分支，测试的结果反应的是项目在V的左边分支的质量成果，比如右边的“组件测试”反应的是同一高度左边的“组件需求/设计”的情况，左边的“组件需求/设计”的情况由同一高度右边的“组件测试”来测试。如果测试团队按照测试测试阶段分成几个小团队，那么用户验收测试团队中的某些测试人员将会早期的介入到项目的“业务目标/需求”这个分析阶段。
我在一次面试过程中，被人问到过这个V模型是否跟他们的敏捷开发相冲突。这是一个测试模型，一种基本的测试理论和过程，适用于任何的项目管理过程（比如RUP、CMMI、Agile）和软件开发模型（比如瀑布模型、迭代模型），他们是属于不同范围内的概念，他们可以自由组合。这也仅仅是理论，实际项目中需要测试人员和项目经理做一些约定和修改。从这套理论里面学习了这些基本概念和模型后，就比较容易理解和适应实际项目。
我一直没去区分系统确认和系统验证的关系和不同，英文应该是“system validation”和“system verification”，我也懒得去区分，反正就是去看看被测系统是否满足需求。
在我的博文《游戏测试流程简介》中也有关于测试流程的介绍，其实那里面介绍的测试流程也有“测试早期介入”的关键特点。游戏的新功能的idea刚刚出现的时候到最后交付给测试团队进行测试的整个过程，都会有测试人员跟踪，一般情况下游戏里面的每个功能都有相关的测试人员负责。这就是让测试人员早点熟悉游戏功能，了解游戏功能的实现过程和细节，当然也希望测试人员参与到功能策划的讨论中，也可以早点提出此功能的不足和会产生的相关风险。好的游戏团队应该是人人都是策划人员，策划人员、开发人员、美术人员、测试人员等人员都应该参与到游戏的创作中去。如果游戏团队仅仅是流程化的，策划人员策划游戏，开发人员接到任务进行开发，美术人员接到任务进行美术创作，测试人员只是接到任务进行测试，这样的游戏团队肯定不是好团队，不是一个成功的团队。
相关链接：
