2018-08-14 15:57:51 qiming666 阅读数 2097
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10406 人正在学习 去看看 CSDN讲师

对敏捷sprint进程中测试任务的简要描述:

 

需求讨论:这个阶段测试人员要把自己带入到用户角色中,列举用户角度的场景需求,协助开发和产品制定技术实现方案;

确认验收标准:为了避免sprint进行中产生的扯皮推诿,应当在需求讨论会上就确定验收标准。

形成开发任务tag:形成测试tag,估算测试时间,形成概要测试计划。

开发过程中:1.针对开发任务顺序,提前预备环境,数据等。这个过程往往在需求讨论时就已经开展。

2.验收测试,反馈修改。这一阶段的重点词是“反馈”和 “现场验证”。及时而准确的反馈,是敏捷的灵魂,是开发和测试工作告诉运转的保证;“现场验证”是交付的终点,如果不做现场验证,即使在测试环境中通过也不能算作交付完成。

3.站立会议。传达测试任务进度,了解开发进度,以便预先配置环境;针对测试任务提出问题/给出建议/寻求帮助;预估风险

demo前一天:

不再接受测试任务提交;

对已通过功能现场回归测试一遍;

完成次日测试环境数据的准备;

总结会:

针对上一个sprint不足,改进测试方法流程;

发现团队不足,增强协作力。

 

2016-11-16 17:54:06 wildnesswolf 阅读数 1206
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10406 人正在学习 去看看 CSDN讲师


http://bbs.51testing.com/thread-1100977-1-1.html

综述

在敏捷开发模式,往往传统以功能测试为主的测试难以适应新的角色,而敏捷团队也面临着产品质量和快速市场的压力,需要通过快速的迭代抢占市场,但另外一方面质量的问题,又可能导致市场丢弃,这时,测试应尝试调整测试的重心和方法,目标是做到敏捷测试,测试与开发并行,测试的重心更应移到后台的业务逻辑测试,并建立起新的测试模型,特别后端接口的自动化测试,有了自动化测试,我们所说的持续交付才有可能真正实现,在开展敏捷测试时,可以在各敏捷小组之上增加量个角色以保证产品质量和迭代的效率,一个测试开发角色,负责团队基础测试技术如性能测试,安全测试,负责测试工具、测试平台开发,测试实验室的建立;而另一个过程管理角色,则负责提升整个敏捷流程效率,梳理各环节的问题,对产品、开发、测试、运维的工作成果进行审计,促进设计、开发、测试、运维等角色密切协作,倡导3C【Card、Conversation、Confirmation】。
总的来说,敏捷测试的终极目的是为了持续交付,快速向市场交付可靠的产品;在敏捷开发模式下,迭代使得代码量逐步累加,越靠后的迭代我们所面临的整合测试压力、测试任务就越大;敏捷测试需要测试人员能够随时启动自动化回归测试对发布的迭代代码进行快速验证,以确保开发人员在进行新功能开发同时,未对已有的功能进行破坏
2011-06-29 10:46:00 kity_kt 阅读数 254
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10406 人正在学习 去看看 CSDN讲师

敏捷宣言:个体和交互比过程和工具更有价值;能工作的软件比全面的文档更有价值;顾客的协作比合同谈判更有价值;及时响应变更比遵循计划更有价值。- www.agilemanifesto.org

什么是敏捷测试?

  测试遵循敏捷宣言进行,把开发作为顾客看待。项目的测试采用敏捷方法论。

  敏捷测试的原则与上下文驱动测试(Context-Driven Testing:www.context-driven-testing.com)的原则有交集,例如,上下文驱动测试的七大原则中的第三条:工作在一起的项目组成员是项目的上下文的最重要的组成部分。就与敏捷宣言中的“个体和交互比过程和工具更有价值”一样强调人的作用。

敏捷测试中测试人员扮演的角色

  1、  测试是项目的“车头灯”,它告诉大家现在到哪了,正在往哪个方向走。

  2、  测试为项目组提供信息,使得项目组基于可靠的信息作出正确的决定。

  3、  “BUG”是让用户感觉烦恼的东西,测试人员不作出发布的决定。

  4、  测试员不保证质量,整个项目组对质量负责。

  5、  测试不是抓虫子的游戏,它的目的不是纠缠在错误中,而是帮助找到目标。

单元测试和可接受性测试

  测试驱动开发,开发人员在写代码之前要先写单元测试,用于激发代码的编写、改进设计(降低耦合度,增加内聚)、支持重构。很多开源的测试工具支持单元测试(xUnit)。

  用户故事是需要编码实现的功能特性的简短的描述。可接受性测试验证用户故事的完整性。理想的情况下,用户故事是在代码编写前就写完。

  测试人员是否应该拥抱敏捷开发?

  有些人说XP会导致差的质量并且是偷懒的借口。我认为XP是令人激动的,并将在行业中改进测试的实践。

  参见《Testers Should Embrace Agile Programming 》

  (http://www.io.com/~wazmo/papers/embrace_agile_programming.html

敏捷测试实践

  通过对话产生测试,谁来测试?客户往往太忙了,不可能参与测试。定义测试是很关键的活动,应该把开发人员和顾客代表包括进来,不要只是测试员自己做。

  把用户故事转换成测试。测试提供的是目标和指南、及时的反馈、进度度量。测试应该用指定的格式出现,以便让用户或顾客能清楚明白,还要足够的明确,以便能被执行。

  开发人员负责提供支持自动化测试的特性。大部分情况下,为产品添加测试接口,而尽量不用外部测试工具。

  计划在每个迭代中探索产品,寻找bug、遗漏的特性和改进的机会。

2010-10-25 15:37:00 ganhongxia 阅读数 309
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10406 人正在学习 去看看 CSDN讲师

敏捷测试的定义

  首先敏捷测试是敏捷的一种,原有测试定义中通过执行被测系统发现问题,通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。在传统的测试定义上,还需要添加

  敏捷测试是遵循敏捷宣言的一种测试实践:

  强调从客户的角度,即使用系统的用户的角度,来测试系统

  重点关注持续迭代的测试新开发的功能,而不再强调传统测试过程中严格的测试阶段。

  建议尽早开始测试,一旦系统某个层面可测,比如提供了模块功能,就要开始模块层面的单元测试,同时随着测试深入,持续进行回归测试保证之前测试过内容的正确性。

  敏捷开发

  人与人之间的交互是复杂的,并且其效果从来都是难以预期的,但却是工作中最重要的方面。-- Tom DeMacro和Timothy Lister

  敏捷软件开发宣言:

  ● 个体和交互 胜过 过程和工具

  ● 可以工作的软件 胜过 面面俱到的文档

  ● 客户合作 胜过 合同谈判

  ● 响应变化 胜过 遵循计划

  虽然右项也有价值,但是我们认为左项具有更大的价值。

  敏捷宣言遵循的原则:

  ● 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

  ● 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

  ● 经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。

  ● 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。

  ● 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。

  ● 在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。

  ● 工作的软件是首要的进度度量标准。

  ● 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

  ● 不断地关注优秀的技能和好的设计会增强敏捷能力。

  ● 简单是最根本的。

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

  ● 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。



  当软件开发需求的变化而变化时,软件设计会出现坏味道,当软件中出现下面任何一种气味时,表明软件正在腐化。

  ● 僵化性: 很难对系统进行改动,因为每个改动都会迫使许多对系统其他部分的其它改动。

  ● 脆弱性: 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。

  ● 牢固性: 很难解开系统的纠结,使之成为一些可在其他系统中重用的组件。

  ● 粘滞性: 做正确的事情比做错误的事情要困难。

  ● 不必要的复杂性: 设计中包含有不具任何直接好处的基础结构。

  ● 不必要的重复性: 设计中包含有重复的结构,而该重复的结构本可以使用单一的抽象进行统一。

  ● 晦涩性: 很难阅读、理解。没有很好地表现出意图。

  敏捷团队依靠变化来获取活力。团队几乎不进行预先设计,因此,不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单,并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性,持续地改进设计,以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。

  为了改变上面软件设计中的腐化味,敏捷开发采取了以下面向对象的设计原则来加以避免,这些原则如下:

  ● 单一职责原则(SRP)

  就一个类而言,应该仅有一个引起它变化的原因。

  ● 开放-封闭原则(OCP)

  软件实体应该是可以扩展的,但是不可修改。

  ● Liskov替换原则(LSP)

  子类型必须能够替换掉它们的基类型。

  ● 依赖倒置原则(DIP)

  抽象不应该依赖于细节。细节应该依赖于抽象。

  ● 接口隔离原则(ISP)

  不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。

  ● 重用发布等价原则(REP)

  重用的粒度就是发布的粒度。

  ● 共同封闭原则(CCP)

  包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响,则将对该包中的所有类产生影响,而对于其他的包不造成任何影响。

  ● 共同重用原则(CRP)

  一个包中的所有类应该是共同重用的。如果重用了包中的一个类,那么就要重用包中的所有类。

  ● 无环依赖原则(ADP)

  在包的依赖关系图中不允许存在环。

  ● 稳定依赖原则(SDP)

  朝着稳定的方向进行依赖。

  ● 稳定抽象原则(SAP)

  包的抽象程度应该和其稳定程度一致。

  上述中的包的概念是:包可以用作包容一组类的容器,通过把类组织成包,我们可以在更高层次的抽象上来理解设计,我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分,然后把那些划分后的类分配到包中。

  敏捷设计是一个过程,不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。

 

转自:http://news.51tester.cn/www/1/2009-12/4404.html

2017-03-20 16:22:26 Trinity_Techologies 阅读数 2015
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10406 人正在学习 去看看 CSDN讲师
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。

敏捷开发过程中,很多时候测试人员就时常被当成项目无法加快的阻力,一下这边爆一个bug,那边有个缺陷,所以项目经理痛恨测试,程序员们也巴不得测试快快放行,让程序好好上线,但我们都知道没有测好的东西是不能硬上的,测试这种把守项目上线最后一关卡的,若没有两把刷子,可能会时常变成项目延迟的炮灰。

为了让测试的效率跟上项目开发的进度,需要抓住两个关键点:
1. 品质是规划出来,非测试出来的
测试在专案的早期就必须参加,熟悉需求,并从测试角度提出各种问题,确保产品经理、开发、测试的等角色的关注点都有备考量到,而测试也会从早期就开始撰写测试用例,在撰写过程中如果有发现任何问题也趁早反馈给产品经理、项目经理,趁早把问题给理清,这样做测试才能把自己的角色提升到为质量负责的角色。

2. 落实自动化
所有重复性的工作都应该被自动化,包含测试,如果你项目大多数的时间都花在基础功能测试,那效率肯定不会高的,所以测试环境、测试资料的准备应该都要有工具能辅助,各种测试用例如果是反覆发生且变动性少,绝对值得你花时间去撰写自动化脚本,而对于后端API接口的测试更是关键,一般的测试可能大多针对功能进行测试,但我们知道很多会露出被用户测到的bug,大多都不是点一点就能测的出来,很多都是因为API在某种情境下出错了,或在某种负载下出错了,这些靠人工非常难验证,透过自动化工具就相对简单多了。

对于敏捷开发项目的测试而言,单元和集成测试是测试策略的关键环节。单元测试是验证最小和独立单元代码行为的过程,比如C++类,C函数,Ada包。这通常在系统测试之前进行。单元和集成测试是构建稳定减少错误应用程序的重要方法,因为它允许测试人员更容易模拟应用程序基本逻辑功能,并验证其是否满足设计需求。

传统的单元测试,通常针对开发人员写的每个软件单元生成测试用例,执行这些用例验证代码功能的正确性。这种模式存在一定风险,因为开发人员在设计测试用例时,很容易受自己实现该代码的思维的影响,从而导致某些情况不能被考虑到或测试到。


自动化测试工具,如:VectorCAST可支持C/C++语言(VectorCAST C/C++)和Ada(VectorCAST/Ada)的单元测试和集成测试。两者都可以自动化地完成单元测试和集成测试的关键步骤。包括测试驱动的生成,测试用例和测试结果的管理,以及自动化的回归测试。

自动化的测试不仅大大提高了测试效率,而且自动化的客观性还能大幅提高测试的准确性。测试的自动化让敏捷开发更加“敏捷”!



没有更多推荐了,返回首页