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

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

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

    提起敏捷项目,大家都非常耳熟。在国内,2012年到2015年敏捷开发可谓热火朝天。即使是现在,很多软件公司的培训主题也仍然少不了它。即便如此,调查结果却显示超过一半的人并不记得敏捷宣言。如果正在或将要做敏捷项目,建议先了解下敏捷宣言,有助于产生敏捷意识,对敏捷项目有更深层的理解。

    一、敏捷测试人员的焦虑与困惑

    参加过多次敏捷项目培训,发现培训老师对测试人员的角色定位和敏捷测试意识鲜有提起,大家也更多关注于流程、功能分解、迭代周期和时间进度安排等。常常看见敏捷项目组里的测试人员对一些问题感到焦虑、困惑,比如:

    需求文档太少,无法理解需求或对需求理解不深刻,难以设计测试。

    需求变化过于频繁,测试用例维护工作量大。

    时常发现自己所做的工作超出自己的职责。

    测试人员不足,迭代周期短、测试时间紧,回归测试不全导致遗漏缺陷。

    测试人员存在感不强,难以融入开发团队。

    测试人员代码能力不足,无法编写单元测试代码或自动化测试脚本。

    开发自测不足,太依赖测试人员的系统测试。

    提交的缺陷不被重视。

    与开发人员沟通存在问题。

    等待版本、等待环境。

       

    如果对敏捷项目、敏捷开发流程多做些了解,会发现其中的一部分困惑其实主要来源于对敏捷测试的认识、思考和实践不足。下面就谈谈一个优秀敏捷项目测试人员应具备的敏捷意识,以及如何通过这些意识去解决面临的“问题”。

    二、一个优秀的敏捷项目测试人员应具备的意识

    相对传统项目而言,敏捷项目对测试人员有更高的要求,对测试人员是一种挑战,也是一个全方位锻炼、成长的机会。一个优秀的敏捷项目测试人员应具备如下意识:

    (一)心态

      以积极的心态拥抱变化:敏捷,即快速变化。敏捷项目原本充满变化

    和不确定性,因而需求变化比较快,产品开发周期短,给软件测试带来很大的挑战。但每一次的需求调整都是为了使产品开发朝着更正确的方向开展,测试人员应给予理解,减少无用的抱怨,积极主动去接受变化、理解变化,采取探索性测试尽早发现可能存在的问题,给予及时反馈。

    (二)文档

      接受精简的文档:如果要求需求频繁变化的敏捷项目像传统项目一样有

    详尽的文档,那么,每次变化将需要花费大量的时间来更新需求。特别是变化后不进行同步更新,将比精简的文档还糟糕。在敏捷项目中,直接沟通交流的效率远大于文档,而且直接沟通更能在理解上达成一致。测试人员可以通过主动沟通了解需求,自己整理出一份详细的需求,并不一定要像需求规格一样标准,易于理解即可。通过整理,可以更深入理解需求、发现问题、暴露问题。当然,也不能走极端,认为敏捷可以不要文档,核心业务逻辑应有文档或会议纪要体现。

      测试简单化:测试应关注于产生价值,不断尝试最简单的方法满足测试

    需要。比如,迭代初期,测试用例可以简单到只是包括所有测试点的清单,不仅可以节省评审时间,也可以避免需求的频繁变动加大测试用例维护的工作量。当然,每个迭代仍然需要明确且易于修改的测试计划、测试目标、测试范围、测试类型,选择合适的测试策略。在版本稳定后,再进行标准的用例库建设。

    (三)主动意识

      尽可能多的参与需求讨论:测试人员可以利用自己在用户体验、业务逻

    辑方面的经验,和项目组成员充分交流和讨论,提出有建设性的建议。也可以通过需求讨论,更加深入理解需求。

      作为勇敢的发言者:敏捷团队是民主的,团队成员能够平等参与讨论。

    思想的碰撞,更易突发灵感产生创造性的思维,有想法和建设性的建议应该勇敢提出来。测试人员和开发人员所站角度不同,测试人员的视角更接近客户,不要害怕所提的问题过于简单。要敢于提出问题、发表自己的意见、提出建议,尽早揭示风险、暴露问题,以免在后期造成更大的影响。

      主动沟通和协作意识:进入敏捷的协作环境,测试人员不应该局限在

    自己的职责领域,应关注于项目组共同的目标,尽可能产生更大的价值。优秀的测试人员应该知道如何与他人更好的沟通、合作,且随时准备协作。良好的团队沟通和协作意识也是项目成功的关键因素之一。

      乐于分享与反馈信息:一个测试人员所负责的功能一般不仅限于一个模

    块,因而比一个开发人员能掌握更多的需求信息。测试人员可以向项目组成员积极分享需求、反馈各功能模块的测试进展,让所有人更了解整体需求和项目动态。及时提供全面的质量反馈,每个周期对缺陷分类汇总,分析相似缺陷的发生频率和易发缺陷的功能模块,用清晰的图形化展示,提醒开发人员避免再次产生同样的缺陷。

      主动参与代码复审:测试人员不写代码,但可以主动参与代码复审,有

    助于提升代码阅读能力,也可能以测试人员的视角发现隐蔽的缺陷。

      不断改进工作和学习新技能:创新无论在哪里都非常重要。敏捷开发鼓

    励团队采纳新技术,使产品和团队自身都有很强的适应力和生命力。测试人员应该不断的学习和自我提升才能更好的适应和应对变化,努力培养自己的工作技术,关注、读好的文章以获得新想法和技能,试验新的工具和技术,改进测试工作。

    (四)测试方法

      测试驱动开发:敏捷项目测试人员参与了整个软件生命周期,测试人员

    应该在不同阶段确认和验证、预防缺陷,而不是等到软件开发完成后才去发现缺陷。单元测试驱动开发(UTDD)和验收测试驱动开发(ATDD),前者大多由开发负责,后者由测试操作。测试人员可以关注和推动单元测试,并利用专业测试、需求理解能力,以测试需求驱动、指导开发。当编码由测试指导,开发的产品可能更符合客户的期望,也有助于确保版本发布后重要功能正确、迭代功能无缺失。

      测试自动化:众所周知,由于敏捷项目快速迭代的特点,用自动化做回

    归测试是敏捷项目成功的要素之一。敏捷测试中回归测试是必须的,没时间实现测试自动化是一个不断积累债务的过程。测试自动化开始时会比较艰难,应尽早克服困难,选定或准备合适的工具。一旦某些核心功能稳定,每个迭代开始小规模的自动化工作,逐步把稳定的功能用自动化测试实现,减少回归时间和成本,将原本可发挥更大价值的人力从重复的手工测试中解放出来,将更多的时间用于重要的探索性测试。经验统计显示,80%的缺陷是在探索测试过程中发现的。

    (五)敏捷观

      树立正确的敏捷测试观念:敏捷项目是以结果为导向的,因此敏捷测试

    同样是结果导向。要有全局观,不只是关注于发现缺陷,也不以发现缺陷多少为目标,应关注于是否实现当前的功能。测试人员和开发人员都有相同的质量目标,应尽量协助开发人员不断提高软件的质量。不要“等待”,尽可能的早工作,做能够做的工作。

     

    三、总结

        通过上面对敏捷意识的描述,可以看到前面提到的文档问题、职责问题、融合问题、技能问题等等其实大多都不是问题,可以通过提高敏捷意识来解决,而这种敏捷意识对一个敏捷项目的成功起着极大的推动作用。敏捷测试人员在提高自身意识的同时,也应努力推动项目组的整体意识,制定出测试标准、流程,让体系约束大家,共同提高软件开发和测试的质量。

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

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

    千次阅读 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
    【敏捷开发】详解敏捷测试   敏捷软件开发是目前十分流行,并在业界逐步推广的软件开发模式。  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往...
  • 软件测试敏捷图书分享

    万次阅读 2020-04-15 14:16:25
    小编在测试这一行已经入坑3年(真的是入坑)看了一些书籍,最近整理了一下进行了一下分类推荐给各位小伙伴 有一些书,小编找到了电子版一起分享给大家 链接: https://pan.baidu.com/s/1ep1H72VSmvoorviebU_1pw 提取...
  • 敏捷测试的方法和实践 (上)

    万次阅读 热门讨论 2010-12-27 09:35:00
    什么是敏捷测试呢?敏捷测试当然不能简单地理解测得更快,绝对不是比以前用更少时间进行测试,也不是将测试的范围缩小了或将质量降低来减少测试任务。也有人说,只有敏捷开发,没有敏捷测试。下面我们就要讨论一下:...
  • 究竟什么是敏捷测试

    万次阅读 2013-04-17 10:26:03
    时至今日,还讨论这样一个老话题,是否感觉老调重弹?...在2011年,我自己也写了一篇文章《敏捷测试的思考和新发展》,刊登在《程序员》杂志上,谈到“在BDD、ATDD和TDD最根本的、共同的思想基础上,构成一个全新
  • 敏捷测试的方法和实践 (下)

    万次阅读 2010-12-27 09:34:00
    什么是敏捷测试呢?敏捷测试当然不能简单地理解测得更快,绝对不是比以前用更少时间进行测试,也不是将测试的范围缩小了或将质量降低来减少测试任务。也有人说,只有敏捷开发,没有敏捷测试。下面我们就要讨论一下:...
  • 敏捷开发流程

    千次阅读 2017-01-04 16:37:50
     在敏捷软件开发领域,更注重的以人为核心,迭代,循序渐进的开发方法。相比传统的开发方法,这种方法能更快速的开发,上线,反馈,调整、迭代。以敏捷的姿态去发展产品。 敏捷与传统开发的区别  
  • 敏捷开发流程总结

    万次阅读 多人点赞 2010-07-20 15:36:00
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以...
  • 简述敏捷开发中的测试流程

    千次阅读 2019-01-21 18:11:10
    敏捷sprint进程中测试任务的简要描述:   需求讨论:这个阶段测试人员要把自己带入到用户角色中,列举用户角度的场景需求,协助开发和产品制定技术实现方案; 确认验收标准:为了避免sprint进行中产生的扯皮...
  • 敏捷开发 —— TDD(测试驱动开发)

    千次阅读 2018-06-06 22:45:43
    测试驱动开发 TDD(Test-Driven Development)是敏捷开发的一项核心实践,同时也是一种设计技术和方法。1. 基本思想在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD虽是敏捷...
  • 敏捷DoD完成定义的多种形态

    万次阅读 2014-10-05 09:07:39
    作者:张克强 作者微博:张克强-敏捷307关于Definition of Done 完成的定义在以往的说法中,常见用 退出标准 , 完成条件,成功标准,等等在敏捷软件开发中,存在多级的不同的完成定义。典型的是迭代的DoD,这也是...
  • 敏捷测试与传统测试的区别

    千次阅读 2011-08-16 12:36:35
    敏捷测试中也有测试活动乃至专职的测试人员,但其活动内容和目标是有显著差异的。一般在传统开发团队中,产品经理(或销售)为范围或称之为需求负责,项目经理和开发组为进度负责,测试组为质量负责,部门经理为...
1 2 3 4 5 ... 20
收藏数 81,426
精华内容 32,570
关键字:

敏捷测试