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

    2011-11-09 21:47:06
    敏捷测试
  • 敏捷测试人员如何做好敏捷测试

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

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

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

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

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

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

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

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

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

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

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

    提交的缺陷不被重视。

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

    等待版本、等待环境。

       

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

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

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

    (一)心态

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

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

    (二)文档

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

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

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

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

    (三)主动意识

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

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

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

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

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

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

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

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

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

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

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

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

    (四)测试方法

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

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

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

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

    (五)敏捷观

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

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

     

    三、总结

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

    展开全文

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 8,050
精华内容 3,220
关键字:

敏捷测试