确认测试也叫有效性测试，有的也叫合格性测试。主要指针对软件系统/软件子系统的测试。一般来说，有种比较约定俗成的顺序：UT--IT--VT--ST。
但实际上并非绝对如此，严格的说，确认测试在某种情况下就属于集成测试，在某种情况下就属于系统测试。
例如，当你的被测系统由软件子系统、硬件子系统等一些子系统组成的时候，这个时候针对这个被测系统中的软件子系统的测试就属于集成测试中的“系统内集成（子系统间集成）”，由于确认测试本身就是测纯软件子系统的，所以在这个时候确认测试本身就属于集成测试阶段中的子系统集成测试了；
例如，而当你的被测系统本身就是一个纯软件系统时，这个时候针对这个系统的测试就变成了系统测试了，所以在这个时候确认测试又变成了系统测试阶段的活动了。
至于冒烟测试，它和回归测试的性质一样——只是一个测试活动，并不是一个测试阶段。也就是说，冒烟测试贯穿于测试的任何一个阶段，单元测试里会有冒烟测试、集成测试里会有冒烟测试、系统测试里也会有冒烟测试。
冒烟测试和其他所有的测试活动的目的不一样，它不是为了证明程序存在BUG，而是为了证明程序的基本功能、核心功能没有问题。
当冒烟测试发生在集成测试的子系统间集成和系统测试的时候，这个时候，人们常常把冒烟测试等同为BVT（Build Verification Testing），也就是所谓的小版本验证测试。
冒烟测试一般是由程序员来执行；冒烟测试带有一定的随机性，它不需要去设计正式的测试用例，这个活动在开发部门内开展；
系统预测试也叫“转系统测试”，一般是由Tester来实施的，也可以在开发人员的配合之下开展，如果是这种情况下，系统预测试就是敏捷开发极限编程中的“结对编程、结对测试”了；
系统预测试是个别规范的大公司才有的流程，在微软内部与之类似的有个“Buddy Test（合伙测试）”，指的是开发人员提交软件版本后申请转系统测试之前的功能性验证（可能还包括其他方面的验证），目的是确保系统的基本功能确实没有问题，使得后续的系统测试能够顺利开展，不至于出现主要功能有致命问题，大量的用例被堵塞，导致系统测试无法继续下去。
从顺序上来说，是UT--IT--Pre ST--ST。也就是说PM（或开发人员）提出转系统测试申请后，测试部门的Testers会进行系统预测试，完成后由测试主管组织测试部门人员进行这次转系统测试评审。
至于CCB，全称是Change Control Board——变更控制委员会，负责对软件配置项进行变更管理。而变更管理包括了需求的变更以及由缺陷修复带来的代码变更。
但是要明确一点，任何模型都不是完美的，双V模型也有它的缺陷：虽然开发活动和测试活动是并行开展的，但是对于测试内部来说，单元测试、集成测试、系统测试都是串行展开的，而这种严格的阶段之分只是一种理想状况，并不适用现在大部分企业迭代式开发、增量式开发的软件工程过程。实际上在开发过程中，UT、IT、ST可能会在某个时段内同时存在.
