所谓的V模型，其实是对瀑布模型的一种修改，也算一个Change吧，详见下图：
由于瀑布模型对于软件的需求分析与设计阶段考虑不足，导致可能会出现严重的设计问题，最后交付到客户手里才会被发现，所以V模型就考虑到这点，针对开发的各个过程都会有相应的测试环节，比如用户需求会对应验收测试，需求分析和系统设计会对应确认测试和系统测试等等（详见上表），这样子起码在交付前会把用户需求方面的问题覆盖到，不太会出现说这个产品不是客户想要的这种问题。
但是缺点也是显而易见的，跟瀑布模型一样，测试过程还是放在了最后环节，虽然可以满足客户的需求，但是问题都只能到最后阶段才能被发现，必然会导致上面瀑布模型发生相同情况，也就是成本和时间的增加，所以V模型充其量也只能是瀑布模型的2.0版本。（不过好歹已经有了Change，我相信在那个年代的背景呀，已经算挺不错了，已经考虑到需要对需求分析这些进行测试了）
当然，时代总是在不断地变化之中，你不懂得Change，那唯一的结局就是落后，落后就要挨打，有多少曾经风光的软件公司在今天已经找不到踪影，活下来的公司都是能不断适应时代改变而改变的公司。
V模型虽然比瀑布模型稍微先进那么一点，但是总是没法跟得上时代的进步，因为有现在看来显而易见的缺点（当然，这里得说一下，即使在现在，瀑布模型和V模型还是有其用武之地，特别是那种对质量看得非常严格，基本上方案定了不会有改动的行业，所以它们没有被淘汰，我这里讲的Change其实更多是针对敏捷开发的公司的，这类公司其实以前就应该敏捷，只是那个时候没敏捷的想法，但是它们的开发流程总是有敏捷的需求，所以这个流程总是在Change中，并且不断地去适应和反过来推动它们的流程的继续发展。）
上面讲了这么多，大家已经知道了瀑布模型和V模型对于需要敏捷的公司有一个致命伤了，也就是他们的测试环节总是放在开发完成后，从而导致了所有的Bug都是只能在最后才能被发现，客观上增加了产品是否能按时和正确地发布的风险。既然知道了问题所在，咱们的过程分析管理人员们也不是盖的，纷纷想出了高招。
首先来介绍一下W模型（见下图），W模型其实是有两个V模型组成，其实也就是双V了，看起来像W就叫做W模型了，W模型强调测试需要和开发同步进行，开发包括哪几个步骤，测试就需要测哪几个步骤，更重要一点是需要同步进行，也就是说你做完这一步我就需要测掉这一步，那开发的步骤也无非就包括了需求、设计和代码了，所以这些步骤都进行测试。
其他还有几种著名模型，比如H模型和X模型，都是对瀑布模型和V模型进行了不错的更新，当然也还是有其局限性，上面W模型存在的问题还是没法解决。
不过，时代还在继续发展，还有More Change等着咱们呢，且继续听下回分解。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/
