敏捷测试_敏捷测试流程 - CSDN
敏捷测试 订阅
[1]  敏捷开发的最大特点是高度迭代,有周期性,并且能够及时、持续地响应客户的频繁反馈。敏捷测试即是不断修正质量指标,正确建立测试策略,确认客户的有效需求能得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。 展开全文
[1]  敏捷开发的最大特点是高度迭代,有周期性,并且能够及时、持续地响应客户的频繁反馈。敏捷测试即是不断修正质量指标,正确建立测试策略,确认客户的有效需求能得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。
信息
定    义
不断修正质量指标,建立测试策略
特    点
从使用系统用户角度,来测试系统
中文名
敏捷测试
外文名
Agile testing
敏捷测试敏捷测试定义
首先敏捷测试(Agile testing)是测试的一种,原有测试定义中通过执行被测系统发现问题,通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。敏捷测试是遵循敏捷宣言的一种测试实践:1、强调从客户的角度,即从使用系统的用户角度,来测试系统。2、重点关注持续迭代地测试新开发的功能,而不再强调传统测试过程中严格的测试阶段。3、建议尽早开始测试,一旦系统某个层面可测,比如提供了模块功能,就要开始模块层面的单元测试,同时随着测试深入,持续进行回归测试保证之前测试过内容的正确性。
收起全文
精华内容
参与话题
  • 软件测试干货——敏捷测试流程

    万次阅读 2017-08-29 16:42:47
    千锋教育软件测试:敏捷测试流程 千锋教育的王晓军老师在对敏捷测试做出介绍的时候与现行的瀑布式测试流程做出过对比: 对于一个三个月的项目说,产品把需求分析完了给开发,然后产品就没事儿了;开发开发完成之后...

    千锋教育软件测试:敏捷测试流程

    千锋教育的王晓军老师在对敏捷测试做出介绍的时候与现行的瀑布式测试流程做出过对比:

    对于一个三个月的项目说,产品把需求分析完了给开发,然后产品就没事儿了;开发开发完成之后给测试,然后开发人员也不忙了。测试完成之后上线。那么在产品分析的阶段,开发和测试都是没事干的(这里只对单一项目)。开发阶段,产品和测试也基本没事儿。同样在测试阶段,产品与开发也是没什么事儿的。

    这不是一个该有的测试态度!

      敏捷测试的一个核心是迭代,在每个时间点上,所有项目人员都是有事可做的。

    1、下面是敏捷测试流程图:

     

    第一阶段

      通过上面的流程图,对于一个月的需求分析,在敏捷中,可能三五天就确定下来。这个需求定得会很模糊,但整体框架确定。产品对其中某一模块功能确认,开发人员开始对确认的功能编码,开发人员编码的过程中,测试进行功能分解,因为根据模糊的需求很难写出具体的用例,所以,只能尽量对功能进行分析得细些,标注需要验证的内容。

    第二阶段

      开发完成后交给测试人员进行测试,开发人员继续开发新的功能。那么测试人员发现的问题怎么办呢?会从开发团队中抽出一个人员来用于解决测试发现的问题。但开发进度并没有因为测试而停止。 

    流程分析:

      在这个流程中弱化了文档,强调了各个人员的沟通,通过这种迭代的方式,三个月的项目,可以能两个月和两个半月就会完成。

    但这种流程并非完美,加入一个功能在需求分析阶段就是错误的,因为它是一个迭代渐进的过程。也只能一路错下去。

    2、对测试问题的处理

          需要说明的是,敏捷测试在国外很流程,在内容,雷声大雨点小,推行的人很多,真正有公司引入的不多。我们所在公司千差万别,测试流程也可能有很大的不同。希望大家不要被思想局限,所以,请努力冲破一个又一个的局限吧——这正是我们这一行业的魅力啊!

         王晓军老师,正是这样一位看中测试者态度的软件测试工程师。

    王晓军老师,是百度联想企培负责人,具有10年以上年从业经验,硕士学位。曾任某上市集团测试部门主管,中航集团开发部技术主管,具备多年开发及测试工作经验。在性能测试、自动化测试及软件质量管理等方面的人才培养上具有较高的建树。

    现在,王晓军老师已经为广大软件测试爱好者和入门从业者录制了全栈软件测试工程师教学视频,供大家学习。

     

    展开全文
  • 敏捷测试

    2019-05-27 14:27:52
    敏捷测试的定义 埃森哲对敏捷测试的定义(与维基百科的定义基本一致)大概如此:敏捷测试是遵从敏捷软件开发原则的一种测试实践。敏捷开发模式把测试集成到了整个开发流程中而不再把它当成一个独立的阶段。因此测试...

    敏捷测试的定义

    埃森哲对敏捷测试的定义(与维基百科的定义基本一致)大概如此:敏捷测试是遵从敏捷软件开发原则的一种测试实践。敏捷开发模式把测试集成到了整个开发流程中而不再把它当成一个独立的阶段。因此测试变成了整个软件开发过程中非常重要的环节。敏捷测试包含了具备专业技能测试人员在内的跨职能团队,这使得这种组合式的团队能更好的交付价值,满足项目的业务、质量和进度目标。

    从定义中可以看出敏捷测试主要的核心内涵有三个:

    1. 是遵从敏捷开发的原则(强调遵守)

    2. 测试被包含在整体开发流程中(强调融合)

    3. 跨职能团队(强调协作)

    除此之外,敏捷测试用到的基本测试方法和技术与传统测试是一样的。

    敏捷测试的特点

    既然敏捷测试属于一种新的测试实践,那么到底它有什么的特点呢?我用“四个更”来归纳:

    更强的协作:敏捷开发人员和测试人员工作得更加紧密,喜欢更直接的沟通方式而不是通过邮件文档这种一来一回反反复复的沟通模式;

    更短的周期:需求验证或测试的时间不再是按月来计算,而是按天甚至按小时计算。用户验收测试在每个sprint的结尾都会进行;

    更灵活的计划:敏捷测试也需要拥抱变化,测试计划不再是一成不变的文档,而会根据业务价值交付的顺序进行灵活的调整;

    更高效的自动化:相比传统测试,自动化在敏捷测试中扮演了极其重要的角色。它是实现快速交付确保质量的一种非常有效的手段

    为什么要敏捷测试

    一个很直接的原因是如果整个项目都在采用敏捷开发模式,比如两周一个迭代,你还在跟项目谈传统的各个测试阶段,就好像两个不同转速的齿轮,根本无法结合。试问,两周时间能完成得了所有的测试阶段吗?所以必须要有新的测试实践来取代原有的模式,才能更好的适应敏捷小步快跑的特点。当然,除了适应开发的节奏外,敏捷测试还是有其特有的价值:

    缩短价值交付周期

    通过采用敏捷测试这种模式,可以契合整个敏捷开发周期,使得整个敏捷开发按照相同而快速的迭代速率和周期交付,让最终用户尽快获取到业务价值;

    更早发现测试风险

    敏捷测试使得测试人员尽早开始进行测试,尽早的发现系统缺陷或存在的问题,避免所有的问题都堆积在最后的测试阶段形成“Big-bang”的结果,降低整体系统风险;

    强调质量属于大家

    质量是构建出来的,而不是测出来的。敏捷测试一直强调质量属于每一个人的责任,除了测试之外,开发、产品经理等都有义务对自己的交付件质量负责,这样才能确保项目的整体质量;

    化繁为简节省成本

    敏捷测试没有要求需要详细的测试计划和测试文档,也没有定义繁复的测试流程及缺陷流程,这种轻量级的管理模式为测试人员减少不必要的负担,节省了工作量及成本。

    敏捷测试VS. 传统测试

    那么敏捷测试和我们熟悉的传统测试比,他们到底有什么样的区别呢?我整理了如下对比表:

    564

    敏捷测试将会变得越来越重要,届时,测试人员如何在敏捷体系下自处可能是很多人都在忧虑的一个问题。在2周一次甚至更短时间的迭代中,测试人员应该如何准备测试,保证质量是一个摆在我们眼前的“大山”,该如何跨过它,可以加群680748947了解更多关于敏捷测试的知识。

    传统测试如何迁移到敏捷测试

    1. 组织文化的转变

    德勤在介绍敏捷开发相关文章中提到,组织文化是一个被用在覆盖组织方方面面的术语——从基本的认识、态度和价值观到组织特定的语言、知识和技术等。在敏捷文化中,相比于流程,敏捷更关注人,所以敏捷测试组织是应该是以人为导向、自组织、协作式的一种文化氛围。但是据笔者观察,不少敏捷项目仍然缺乏这样的文化基因。比如在站会的时候,还是会看到所谓的TeamLead站在“C位”主持和领导着会议,团队都站在后面等待汇报工作。

    2. 组织架构的调整

    从项目特点来看,敏捷是属于“强项目型”管理的方式,所以如果以前是属于职能型的组织架构,比如开发人员隶属开发部门,测试人员隶属测试部门,那么在敏捷项目中需要进行调整。开发和测试同属一个项目一个团队,大家的目标是一致的,就是要保证项目的成功。所以测试人员可能会帮开发人员评审代码,开发人员也会帮测试人员进行测试,人员角色的职能变得模糊化。

    3. 人员培训与指导

    任何新的方法如果没有进行相关培训和了解,会让具体执行人觉得不安而没有底气。同样,敏捷项目中测试人员在进行测试前也需要接受敏捷知识的培训。如果可能的话,最好是由具有丰富经验的敏捷教练帮忙进行导入,在教练的帮助下进行成长,避免走错方向。

    4. 轻流程

    传统项目的开发管理方法体系比如CMMI相对来说比较重流程,要求的交付件也非常多。而敏捷强调轻流程,尽量减少不必要的文档,使得整个开发模式变得轻快。所以在设计流程和交付件时,需要充分考虑这个特点,尽量简化。当然,少文档不是代表不用写任何文档,一些必要的文档还是需要有的。

    敏捷测试成功的关键要素

    Lisa Crispin在《敏捷软件测试:测试人员与敏捷团队的实践指南》中总结了敏捷测试成功的七大关键要素,我觉得可以精简为下面五大关键要素:

    1. 领导层的大力支持

    任何一个改变要想实施成功,都离不开领导层的大力支持。从领导层的角度需要提供一个宽松的环境,让整个敏捷测试团队能够形成自组织的模式。当遇到问题时不是进行追责,而是给予足够的信任和支持,帮助团队度过难关,陪伴团队的成长。

    2. 测试人员具备敏捷思维

    测试人员需要了解敏捷,掌握敏捷的基本知识和原则,从而才能在整个敏捷体系中更快的融入到敏捷环境中,从而更好的开展整个测试工作。

    3. 要有勇于尝试的信心

    相比传统测试来说,敏捷测试比较新。很多测试人员对于新的事物不敢去尝试,做事畏畏缩缩、裹足不前。因此需要测试人员有敢于尝试的决心,不怕做不好,就怕不去做。只有做了,才知道哪里行哪里不行。然后再根据不足进行优化,从而最终取得成功。

    4. 与各方紧密协作

    在敏捷项目中,测试人员与其他方的直接沟通会非常频繁。测试人员不仅需要和开发人员紧密协作,还需要和产品经理甚至是最终用户保持频繁的沟通,使得整个测试更有效率。

    5. 自动化、自动化

    自动化是敏捷测试非常重要的元素。在敏捷开发这种极短的交付周期内,如果仅仅靠手工测试,则非常难以满足快速发布要求的。所以自动化测试是必不可少的一种手段。另外这里谈到的自动化不仅仅只是指单纯的自动化测试,还包括自动化测试如何集成在整个交付管道中,缩减整个交付时间,实现持续集成甚至是DevOps,最终给项目带来价值。

    作者:我也讨厌自己
    链接:https://www.jianshu.com/p/7890b92cb2ef
    來源:简书
    简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

    展开全文
  • 你确定懂什么是敏捷测试

    千次阅读 2019-09-05 09:23:50
    转自 ...utm_content=note&utm_medium=seo_notes&utm_source=recommendation 早在2009年,Lisa Crispin和Janet Gergory就写了一本书《Agile Testing: A p...

    早在2009年,Lisa Crispin和Janet Gergory就写了一本书《Agile Testing: A practical Guide for testers and Agile Teams》,国内在2010年出了它的中文版本,在第1章就论述了敏捷测试的定义,侧重从测试的敏捷形式和“敏捷测试”的实践等来彰显敏捷测试,对敏捷测试和传统测试的区别进行了分析(虽然作者把传统测试局限于瀑布模型,这显然是不对的),让我们看到一些敏捷测试的特点,如图1所示。但作者也承认“敏捷测试对不同的人意味着不同的含义”。
    img
    图1 传统测试与敏捷测试

    这样看来,“敏捷测试(Agile Testing)”就不是一个新概念了,但为什么不少人还是不理解什么敏捷测试呢?

    首先,可以明确的是,敏捷测试既不是一种方法(如黑盒方法、白盒方法等),也不是一种方式(如探索式测试)。

    因为在敏捷测试中可以采用已有的各种方法,包括白盒方法、黑盒方法;在敏捷中也可以采用探索式测试(exploratory test),也可以采用基于脚本的测试(scripted test)。

    那敏捷测试是什么?敏捷测试应该是一套解决方案、一类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程。

    就像Scrum一样,Scrum可以理解为敏捷方法的具体实现的框架、一组实践或具体的解决方案。

    简单地说,敏捷测试就是顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。

    让我们看看Wikipedia 是如何描述敏捷测试的:

    Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace.

    它强调敏捷测试是遵守敏捷开发方法原则之下的软件测试实践,由跨功能敏捷团队的所有人员参与(包括测试人员以其专业特长的特殊贡献)以保证持续的、快速的业务价值交付。所以要理解敏捷测试,我们还是要回过头来仔细看一下“敏捷宣言”背后所蕴含的12条原则。

    我相信,大家都已熟悉敏捷宣言,如果不熟悉,可以先认真阅读以下完整的敏捷宣言,不仅仅是那四句话。

    1、方法论上的敏捷测试

    先从敏捷开发这一方法论层次来讨论什么是敏捷测试,即敏捷测试有什么具体特征,或有哪些主要实践,然后再就目前非常热的敏捷具体框架Scrum来讨论Scrum中的敏捷测试(或称为Scrum Testing)。先研究一下敏捷宣言背后所蕴含的12条原则:

    1)我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。

    2)欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。

    3)经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。

    4)业务人员和开发人员必须相互合作,项目中的每一天都不例外。

    5)激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。

    6)不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。

    7)可工作的软件是进度的首要度量标准。

    8)敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

    9)坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。

    10)以简洁为本,它是极力减少不必要工作量的艺术。

    11)最好的架构、需求和设计出自自组织团队。

    12)团队定期地反思如何能提高成效,并依此调整自身的举止表现。

    这12条原则中没有一条直接谈到测试,那是否说明没有敏捷测试呢?有开发就有测试,只是原来参加敏捷宣言的17人,基本是清一色程序员,没有在原则中单独阐述一下测试的原则。但其中一些原则和测试的关联性很强,例如:

    1)软件测试如何支撑或协助“持续不断地及早交付有价值的软件”?如何在非常有限的时间内进行充分的测试?这就是我们经常在敏捷测试中强调的“自动化测试”,如果没有自动化测试,就没有敏捷,就不能持续不断地及早交付有价值的软件,而且还要“使客户满意”。

    2)“欣然面对需求变化,即使在开发后期也一样”和传统的开发原则是不同的,传统的开发希望有严格的需求变更控制,越到后期控制越严。而敏捷开发拥抱变化,那么测试如何适应这种变化?如何快速地完成回归测试?这可能要依赖于开发做好单元测试,或全员参与测试,以及全面支持系统级的、端到端的回归测试的自动化测试执行。

    3)传统的开发也要求“业务人员和开发人员必须相互合作”,但存在一定的阶段性,例如前期需求评审、期间产品走查(product walk-through)、后期验收测试等要求有紧密的沟通与协作。但敏捷开发更强调“项目中的每一天都不例外”,在这样的原则下,如何去做敏捷测试?这样可以减少测试文档,刚开始也没必要把测试计划写得很详细,而是写一页纸测试计划就可以,将来再持续的完善和调整。

    4)“可工作的软件是进度的首要度量标准”,不再是测试计划完成情况、完成的测试用例数目、测试脚本量等,而是如何及时验证每天完成的功能特性。开发的工作量也不能按代码行来衡量,而是看多少个具体的用户故事(功能特性)被实现了(done)。某个开发说已完成了某个用户故事,要么是通过他自己的验证,要么是通过测试人员的验证,谁做的测试不重要,关键是要有准备好的测试,随时验证已完成的工作。

    5)“坚持不懈地追求技术卓越和良好设计”,一方面要求测试的技术要不断提高,在处理每个测试任务时,都应该找到最有效的办法;另方面,在前期要更多地参与设计评审,及时发现设计的问题。只有良好的设计,才能更好地支持系统的功能扩充和不断的重构。

    基于这些原则,我们就可以概括一下敏捷测试的一些特点:

    1)敏捷测试一定是敏捷开发方法的一部分,应符合敏捷测试宣言的思想,也遵守上面所列的敏捷开发的原则,强调测试人员的个人技能,始终保持与客户/用户、其它成员(特别是业务人员、产品设计人员等)的紧密协作,建立良好的测试框架(特别是持续集成测试和自动化回归测试的基础设施)以适应需求的变化,更关注被测系统的本身而不是测试文档(如测试计划、测试用例等)。

    2)敏捷测试具有鲜明的敏捷开发的特征,如测试驱动开发(TDD)、验收测试驱动开发(ATDD),可以见我的另一篇文章《敏捷测试的思考和新发展》所讨论的。测试驱动开发的思想是敏捷测试的核心,或者说,单元测试是敏捷测试的基础,如果没有足够的单元测试就无法应付将来需求的快速变化、也无法实现持续的交付。这也说明,在敏捷测试中,开发人员承担更多的测试,这也就是我们说的,在敏捷测试中,是整个团队的共同努力。在敏捷测试中,可以没有专职的测试人员,每个人都可以主动去取设计任务、代码任务做,也可以去拿测试任务来做。在敏捷测试中,也可以像开发人员的结对编程那样,实践结对测试——一个测试人员对应一个开发人员、或一个测试人员对应另一个测试人员

    3)敏捷测试无处不在、无时不在。在传统测试里也提倡尽早测试,包括需求和设计的评审;在传统测试里也提倡全过程测试。但在传统测试里阶段性特征相对突出一些,例如,需求评审,意味着先让产品人员去写需求,但需求文档写好之后,测试人员再参加评审。而在敏捷测试里,团队每一天都在一起工作,一起讨论需求、一起评审需求。在敏捷测试中,这种持续性更为显著一些。

    4)敏捷测试是基于自动化测试的,自动化测试在敏捷测试中占有绝对的主导地位。在传统测试中也提倡自动化测试,但由于传统开发的周期比较长(几个月到几年),即使没有自动化测试也是可以应付的,一般来说,回归测试能够获得几周时间,甚至1-2个月的时间。而敏捷测试的持续性迫切要求测试的高度自动化,在1-3天内就有完成整个的验收测试(包括回归测试)。没有自动化,就没有敏捷。

    s2、Scrum的敏捷测试

    下面就以流行的敏捷框架Scrum来讨论敏捷测试,会更具体一些,会更具可操作性。我们通过下面图2再复习一下Scrum的模型,但这里就不详细介绍了。

    img

    图2 Scrum过程示意图

    从图中可以看出,除了最后“验收测试”阶段,其它过程似乎没有显著的测试特征,但隐含的测试需求和特征还是存在的。

    1)Product Backlog (需求定义阶段),在定义用户需求时测试要做什么?测试需要考虑客户的价值大小(优先级)、工作量基本估算之外,需要认真研究与产品相关的用户的行为模式(如BDD),产品的质量需求,哪些质量特性是我们需要考虑的?有哪些竞争产品?这些竞争产品有什么特点(优点、缺点等)?

    2)Sprint Backlog(阶段性任务划分和安排),这时候需要明确具体要实现的功能特性和任务,作为测试,这时候要特别关注“Definition of Done”,即每项任务结束的要求——即任务完成的验收标准,特别是功能特性的设计和代码实现的验收标准。ATDD的关键一步也体现在这里,在设计、写代码之前,就要将验收标准确定下来。一方面符合测试驱动开发思想,第一次就要把事情做对,预防缺陷;另方面持续测试和验收测试的依据也清楚了,可以快速做出测试通过与否的判断。

    3)在每个迭代(Sprint)实施阶段,主要完成Sprint Backlog所定义的任务,这时除了TDD或单元测试之外,应该进行持续集成测试或通常说的BVT(Build Verification Test)。而且开发人员在设计、写代码时都会认真考虑每一组件或每一代码块都具有可测试性,因为测试任务可能由他们自己来完成。如果有专职的测试人员角色,一方面可以完善单元测试、集成测试框架,协助开发人员进行单元测试;另方面可以按照针对新实现的功能特性进行更多的探索式测试,同时开发验收测试的脚本。如果没有专职的测试人员角色,这些事情也是要完成,只是由整个团队共同完成。虽没有工种的分工,但也存在任务的分工。

    4)验收测试可以由自动化测试工具完成,但一般情况下,不可能做到百分之百的自动化测试。例如易用性测试就很难由工具完成。即使对性能测试,是由工具完成,但还需要人来设计测试场景,包括关键业务选择、负载模式等。敏捷的验收测试,和传统的验收测试不同,侧重对“Definition of Done”的验证,但基本的思想和传统开发是一致的,任何没有经过验证的产品特性是不能直接发布出去的。

    3、结论

    敏捷测试就是符合敏捷宣言思想,遵守敏捷开发原则,在敏捷开发环境下能够很好地和其整体开发流程融合的一系列的测试实践,这些实践具有鲜明的敏捷开发的特征,如TDD、ATDD、结对编程、持续测试等。和传统测试的区分,可以概括如下:

    1)传统测试更强调测试的独立性,将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试可以有专职的测试人员,也可以是全民测试,即在敏捷测试中,可以没有“测试人员”角色,强调整个团队对测试负责。

    2)传统测试更具有阶段性,从需求评审、设计评审、单元测试到集成测试、系统测试等,从测试计划、测试设计再到测试执行、测试报告等,但敏捷测试更强调持续测试、持续的质量反馈,阶段性比较模糊。

    3)传统测试强调测试的计划性,认为没有良好的测试计划和不按计划执行,测试就难以控制和管理,而敏捷测试更强调测试的速度和适应性,侧重计划的不断调整以适应需求的变化。

    4)传统测试强调测试是由“验证”和“确认”两种活动构成的,而敏捷测试没有这种区分,始终以用户需求为中心,每时每刻不离用户需求,将验证和确认统一起来。

    5)传统测试强调任何发现的缺陷要记录下来,以便进行缺陷根本原因分析,达到缺陷预防的目的,并强调缺陷跟踪和处理的流程,区分测试人员和开发人员的各自不同的责任。而敏捷测试强调面对面的沟通、协作,强调团队的责任,不太关注对缺陷的记录与跟踪。

    6)传统测试更关注缺陷,围绕缺陷开展一系列的活动,如缺陷跟踪、缺陷度量、缺陷分析、缺陷报告质量检查等,而敏捷测试更关注产品本身,关注可以交付的客户价值。在快速交付的敏捷开发模式下,缺陷修复的成本很低。

    7)传统测试鼓励自动化测试,但自动化测试的成功与否对测试没有致命的影响,但敏捷测试的基础就是自动化测试,敏捷测试是具有良好的自动化测试框架支撑的快速测试。

    展开全文
  • 敏捷测试与传统测试的分别?

    万次阅读 2018-06-09 17:23:19
    敏捷测试与传统测试的区别传统项目开发模型 由于瀑布模型对于软件的需求分析与设计阶段考虑不足,导致可能会出现严重的设计问题,最后交付到客户手里才会被发现,所以V模型就考虑到这点,针对开发的各个过程都会有...

    敏捷测试与传统测试的区别


    传统项目开发模型


            由于瀑布模型对于软件的需求分析与设计阶段考虑不足,导致可能会出现严重的设计问题,最后交付到客户手里才会被发现,所以V模型就考虑到这点,针对开发的各个过程都会有相应的测试环节,比如用户需求会对应验收测试,需求分析和系统设计会对应确认测试和系统测试等等

            但是缺点也是显而易见的,跟瀑布模型一样,测试过程还是放在了最后环节,虽然可以满足客户的需求,但是问题都只能到最后阶段才能被发现,必然会导致上面瀑布模型发生相同情况,也就是成本和时间的增加,所以V模型充其量也只能是瀑布模型的2.0版本。


    敏捷开发模型


            敏捷软件开发又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。虽然在国外已经得到了广泛应用,在中国国内,敏捷开发用的还不算很多。但是随着Agile敏捷开发的流行,越来越多的公司采用敏捷开发用于软件产品和应用的开发。

            敏捷开发是一种以人为核心、迭代、循序渐进的开发方法,相对于传统软件开发方法的“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。

    特点如下:

    快速迭代:产品通过短周期的迭代交付,通过不断迭代完善产品

    快速尝试:避免过长时间的需求分析及调研,快速尝试。

    快速改进:在迭代周期过后根据客户反馈快速改进。

    充分交流:团队成员无缝的交流,如每天短时间的站立会议。

    简化流程:拒绝使用一切形式化的东西,使用简单易用的工具开始工作。扔掉建模工具,word,ppt,使用白板+wiki。

    展开全文
  • 敏捷测试人员如何做好敏捷测试

    千次阅读 2017-12-19 23:05:23
    简介:了解到身处敏捷项目中测试同事遇到的一些困扰,阅读了一些敏捷相关的文章,结合自己平时的经验积累做了些总结,希望本文能帮助敏捷项目中有类似困扰的测试人员更好的理解敏捷测试,提高敏捷测试的意识,做好...
  • 敏捷测试的价值

    千次阅读 2018-05-10 11:38:36
    敏捷项目管理如火如荼已流行了10多年,例如 Agile、Scrum 和 SAFe。无论是哪个理论最终都离不开技术落地,都要先后进行需求分析、软件设计、编码实现、单元测试、集成测试、验收测试。当然也会换换名字,例如需求...
  • 敏捷测试的特点

    2020-08-26 12:16:54
    敏捷测试的特点 敏捷测试就是符合敏捷宣言思想,遵守敏捷开发原则,在敏捷开发环境下能够很好地和其整体开发流程融合的一系列的测试实践,这些实践具有鲜明的敏捷开发的特征,如TDD、ATDD、结对编程、持续测试等。和...
  • 敏捷测试-测试流程调整

    千次阅读 2018-10-31 17:45:21
    在刚听到敏捷测试的时候做过一定的了解。但是实际项目中并没有碰到过,就一直没有系统的理解和调整过。前段时间接手一个使用敏捷开发的项目,从产品设计到第一版上线的时间只有2个月的时间。这让原有的测试流程饱受...
  • 十招玩转敏捷测试

    千次阅读 2019-07-05 10:16:32
    课程简介 近几年,Scrum、SAFe 等相关的敏捷转型活动在各大 IT 企业和组织中如火如荼得进行着。随着敏捷转型的深入,与敏捷开发相匹配的 QA 活动引起了业界的思考和探讨。...如何开展敏捷测试目前仍困扰着...
  • 敏捷测试流程和活动

    千次阅读 2017-07-17 15:29:09
    【敏捷开发】详解敏捷测试   敏捷软件开发是目前十分流行,并在业界逐步推广的软件开发模式。  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往...
  • 敏捷测试流程

    2018-04-02 10:15:30
    下面是我理解中的敏捷测试流程图:第一阶段:通过上面的流程图,对于一个月的需求分析,在敏捷中,可能三五天就确定下来。这个需求定得会很模糊,但整体框架确定。产品对其中某一模块功能确认,开发人员开始对确认的...
  • ”对于我们测试来说,要做好测试,达成测试目标,也需要谋划谋划。首先需要了解我们的测试需求是什么?我们需要测试什么样的系统?这个系统对缺陷的容忍度是怎样的?测试过程需要使用什么样的技术?一个信息管理系统...
  • 一:传统测试和敏捷测试的区别: 传统测试: 独立的测试部门 测试工作主要由测试人员承担 详尽的测试用例文档 集中的回归测试 发现更多的BUG 敏捷测试 伴随着着敏捷开发过程的所有质量相关活动 敏捷测试不能独立...
  • 2010年为《程序员》杂志写了一篇《敏捷测试的方法和实践》,我们可以回过头来,看看过去的一年,敏捷测试发生了哪些变化。首先,我做了一个实验,分别打开2010年和2011年的“STAREAST Conference at-a-Glance”,...
  • 敏捷团队里面每一个人都是yiing
1 2 3 4 5 ... 20
收藏数 81,959
精华内容 32,783
关键字:

敏捷测试