敏捷测试理论以及实践(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/

目录
相关文章
|
1天前
|
敏捷开发 运维 监控
深入探索软件测试中的持续集成与持续部署(CI/CD)实践
【5月更文挑战第17天】 在现代软件开发过程中,"持续集成"(Continuous Integration, CI)和"持续部署"(Continuous Deployment, CD)已经成为提高开发效率、确保代码质量和加速产品上市速度的关键策略。本文将深入探讨CI/CD在软件测试中的应用,包括它们的定义、目的、实施策略以及面临的挑战。通过对自动化测试、版本控制、构建流程和反馈循环的详细分析,我们将揭示如何利用CI/CD实践来优化测试流程,减少错误,并确保高质量的软件交付。
|
4天前
|
设计模式 敏捷开发 监控
深入理解自动化测试框架的设计原则与实践
【5月更文挑战第15天】在软件工程的领域里,自动化测试已成为提高软件开发效率、保障产品质量的重要手段。本文将深入探讨自动化测试框架的设计原则及其在实际项目中的应用实践。通过分析设计模式、模块化、可扩展性等关键因素,揭示构建高效、可靠自动化测试框架的策略和方法。同时,结合实际案例,展示如何在多变的测试需求中保持测试框架的稳定性和灵活性。
|
4天前
|
敏捷开发 监控 Devops
深入探索软件测试中的持续集成与持续部署(CI/CD)实践
【5月更文挑战第13天】 在现代软件开发的快节奏和复杂性中,持续集成(Continuous Integration,CI)与持续部署(Continuous Deployment,CD)成为确保软件质量和加速交付的关键策略。本文将深入探讨CI/CD在软件测试中的应用,解析其核心概念、流程以及面临的挑战,并分享实际案例分析以揭示如何在不断变化的开发环境中维持高效和可靠的软件发布周期。
|
4天前
|
机器学习/深度学习 敏捷开发 监控
深入探索软件测试中的持续集成与持续部署(CI/CD)实践
【5月更文挑战第10天】 在现代软件开发周期中,"持续集成"(CI)与"持续部署"(CD)是提升效率、确保质量的重要环节。本文将详细探讨CI/CD在软件测试中的应用,包括其基本概念、实施策略、工具应用及面临的挑战。不同于一般性概述,本文将重点分析如何优化测试流程以适应CI/CD环境,并提出针对性的改进措施。通过实际案例分析,揭示成功实施CI/CD的最佳实践,并讨论如何在不断变化的技术环境中保持测试策略的前瞻性和灵活性。
|
4天前
|
算法 测试技术 开发者
测试驱动开发(TDD)实战:从理论到实践
【5月更文挑战第8天】TDD实战指南:先测试后开发,确保代码质量与可维护性。核心思想是编写测试用例→实现代码→验证→重构。优点包括提高代码质量、促进设计思考和增强可测试性。实战步骤包括编写独立、明确的测试用例,遵循最小可用原则编写代码,运行测试并分析失败原因,以及在验证通过后进行代码重构与优化。通过TDD,开发者能提升编程技能和项目成功率。
|
4天前
|
Java 测试技术 Maven
5个编写技巧,有效提高单元测试实践
本文作者详细讲解了关于单元测试的相关知识,做好单元测试能有效地保障代码质量,本文将手把手教你学会应用单元测试并附有案例、测试插件。
|
4天前
|
Java 测试技术 开发者
卓越工程之单元测试在行权鉴权中的实践
这篇文章着重在“实践”上,是对Java编程技巧之单元测试用例编写流程这篇文章的实际应用,并没有高深的理论和技术。
53 10
|
4天前
|
Web App开发 JSON 前端开发
我理解的测试开发与实践总结——新人篇
本文以作者的视角,讲述了测试与开发、产品之间的关系,如何做好一个测试以及做好一个测试应当具有的素质与技能。
|
4天前
|
敏捷开发 测试技术 持续交付
深入理解自动化测试:框架与实践
【5月更文挑战第5天】 在现代软件开发周期中,自动化测试已成为确保产品质量和加速交付过程的关键环节。本文将深入探讨自动化测试的核心概念、框架选择以及实际实施过程中的最佳实践。通过分析各种自动化测试工具和技术的优缺点,我们旨在为读者提供一种系统化的方法来构建和维护有效的自动化测试环境。
|
4天前
|
机器学习/深度学习 人工智能 算法
深入理解与实践:基于AI的软件测试自动化
【5月更文挑战第1天】随着人工智能的不断发展,其在软件测试中的应用也日益广泛。本文将探讨如何利用AI进行软件测试自动化,包括其理论基础、实现方式以及在实际中的应用。我们将通过实例分析,展示AI在提高软件测试效率和质量方面的巨大潜力。

热门文章

最新文章