敏捷测试理论以及实践（2）

所谓的V模型，其实是对瀑布模型的一种修改，也算一个Change吧，详见下图：

　　由于瀑布模型对于软件的需求分析与设计阶段考虑不足，导致可能会出现严重的设计问题，最后交付到客户手里才会被发现，所以V模型就考虑到这点，针对开发的各个过程都会有相应的测试环节，比如用户需求会对应验收测试，需求分析和系统设计会对应确认测试和系统测试等等（详见上表），这样子起码在交付前会把用户需求方面的问题覆盖到，不太会出现说这个产品不是客户想要的这种问题。

　　但是缺点也是显而易见的，跟瀑布模型一样，测试过程还是放在了最后环节，虽然可以满足客户的需求，但是问题都只能到最后阶段才能被发现，必然会导致上面瀑布模型发生相同情况，也就是成本和时间的增加，所以V模型充其量也只能是瀑布模型的2.0版本。（不过好歹已经有了Change，我相信在那个年代的背景呀，已经算挺不错了，已经考虑到需要对需求分析这些进行测试了）

　　当然，时代总是在不断地变化之中，你不懂得Change，那唯一的结局就是落后，落后就要挨打，有多少曾经风光的软件公司在今天已经找不到踪影，活下来的公司都是能不断适应时代改变而改变的公司。

　　V模型虽然比瀑布模型稍微先进那么一点，但是总是没法跟得上时代的进步，因为有现在看来显而易见的缺点（当然，这里得说一下，即使在现在，瀑布模型和V模型还是有其用武之地，特别是那种对质量看得非常严格，基本上方案定了不会有改动的行业，所以它们没有被淘汰，我这里讲的Change其实更多是针对敏捷开发的公司的，这类公司其实以前就应该敏捷，只是那个时候没敏捷的想法，但是它们的开发流程总是有敏捷的需求，所以这个流程总是在Change中，并且不断地去适应和反过来推动它们的流程的继续发展。）

　　上面讲了这么多，大家已经知道了瀑布模型和V模型对于需要敏捷的公司有一个致命伤了，也就是他们的测试环节总是放在开发完成后，从而导致了所有的Bug都是只能在最后才能被发现，客观上增加了产品是否能按时和正确地发布的风险。既然知道了问题所在，咱们的过程分析管理人员们也不是盖的，纷纷想出了高招。

　　首先来介绍一下W模型（见下图），W模型其实是有两个V模型组成，其实也就是双V了，看起来像W就叫做W模型了，W模型强调测试需要和开发同步进行，开发包括哪几个步骤，测试就需要测哪几个步骤，更重要一点是需要同步进行，也就是说你做完这一步我就需要测掉这一步，那开发的步骤也无非就包括了需求、设计和代码了，所以这些步骤都进行测试。

　一看W模型，我就觉得这个模型已经很现代了，因为它终于把测试环节解放出来了，可以说是一个革命性的改变，把大家一直认为开发最后一步的测试环节，提到了跟开发同步的环节，并且把测试环节扩展到了需求和设计环节，这个理念已经跟现在的测试理念一样了。

　　在W模型中，当客户需求出来后，测试就会开始介入，看看需求里写的是不是就是客户当时所说；在设计完成后，看看设计文档是不是真实地反映了客户需求精神；在开发完成后，就开始单元测试，集成测试，确认测试，集成测试和验收测试。这样子的话，基本上也就解决了前面瀑布模型和V模型碰到的问题。（能提出这个模型的研究员，我觉得很厉害，赞一下！）

　　当然说了优点还是得说一下缺点，W模型虽然把测试与开发过程同步进行了，但是总是有前后关系，也就是一个过程完全完成后，才能进行下一个阶段，比如说需求过程完全做完以后，再去由测试去研究是否符合客户要求，然后才能开始设计阶段；设计工作完全完成后，再检查设计文档是否真正体现客户的需求，然后再开始编码阶段。。。。。。，这样子的话，简单的软件还行，但是一旦一个软件很复杂，需求可能会经常变更，这个模型就不知道怎么处理这种变更，因为它认为需求处理完了就完了，以后不会再有变更；设计验证过了就Ok了，以后不会再有变化。如果某一天，已经在进行单元测试了，突然客户一个需求改了，或者加了一个新功能，这个模型看着就蒙了，如果是经常有更改的话，这个模型就疯了，呵呵。

　　其他还有几种著名模型，比如H模型和X模型，都是对瀑布模型和V模型进行了不错的更新，当然也还是有其局限性，上面W模型存在的问题还是没法解决。

　　不过，时代还在继续发展，还有More Change等着咱们呢，且继续听下回分解。

　　（未完待续）

本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/

敏捷测试理论以及实践（2）相关推荐

【转】从一个实例详解敏捷测试的最佳实践
陈晓颖, 软件工程师, IBM 2009 年 2 月 16 日敏捷软件开发是目前十分流行,并在业界逐步推广的软件开发模式.不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和 ...
敏捷测试的精髓都在这里了！
这些年,敏捷开发已经开始流行,敏捷测试在国内也有了较大进步,加上 DevOps 的兴起,进一步推动了测试左移(测试前移)和测试右移(在线测试).例如,大家开始重视软件的持续构建和测试自动化,大量使用体 ...
高效的敏捷测试第一课敏捷测试介绍，与传统测试对比
开篇词:重剑无锋.大道至简你好,我是朱少民,欢迎来到我的"敏捷测试"专栏.2000 年至今,我已在测试行业摸爬滚打 20 年,因为热衷分享应该有不少同行认识我.可能是因为读过我写 ...
敏捷测试——打通开发与测试的壁垒！
DevOps是当前软件行业最热门的话题,无论是互联行业,还是传统行业,大家都在拥抱DevOps,享受引入DevOps后带来的团队效能提升.但是也有不少的团队对DevOps的理解还存在误区,导致在实践过 ...
高效的敏捷测试第十课 BDD实践和深化
第24讲:BDD 及其自动化实践在第 20 讲,我介绍了 TDD.UTDD 和 ATDD,主要讨论了需求的可测试性,通过测试先行的敏捷开发理念,比如先建立用户故事的验收标准,来提升需求的质量.今天在 ...
敏捷测试的方法和实践 (上)
有一次,当开发人员完成当前Sprint 任务的代码之后,测试人员与开发人员.产品经理一起来浏览产品.从头到尾走一边,产品经理发现了问题,认为需要对功能进行比较大的修改.这时开发人员估计需要两天时间才能 ...
高效的敏捷测试第四课测试的团队协作
第08讲:借助 Tet Owner 角色,完成团队转型? 三年前的一天,我碰到了一个之前在思科的老同事,问了下他现在软件开发采用的是什么模式? 他回答:"已全面实施敏捷开发模式了,有些团队都 ...
微服务理论与实践[1]-什么是微服务
微服务理论与实践[1]-什么是微服务什么是微服务微服务 (Microservices) 是一种软件架构风格,将应用程序构造为围绕业务的小型自治服务的集合微服务以专注于单一责任与功能的小型功能区块 ...
最近有一本你必须关注的书《敏捷测试实战指南》
软件测试,从来不是一件容易的事情. 在软件交付领域,我们总是倾向于重开发,轻测试,把测试作为整个软件交付的辅助部分.软件交付和生产最大的不同在于,软件交付每一次都针对不同的需求,不是一个简单重复的过程 ...

敏捷测试理论以及实践（2）

敏捷测试理论以及实践（2）相关推荐

最新文章

热门文章