2019-06-11 08:32:43 engrossment 阅读数 170
  • SCRUM敏捷开发视频教程

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

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

敏捷软件开发宣言

  • 我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观
    • 个体和互动高于流程和工具。
    • 工作的软件高于详尽的文档。
    • 客户合作高于合同谈判。
    • 响应变化高于遵循计划。
  • 也就是说,尽管右项有其价值,我们更重视左项的价值。

敏捷开发的特征

  • 依赖客户的参与。
  • 测试驱动。
  • 紧凑的迭代开发周期。

敏捷测试

  • 本质上,敏捷测试是协同测试的一种形式,它要求每一个人都参与到测试计划的设计、实现以及执行中去。他们的任务是通过持续的测试反馈推动项目进行,帮助开发者修复缺陷。

极限编程与测试

  • 极限编程(XP)的关注点是:
    • 实现简单的设计。
    • 开发人员与客户的沟通协作。
    • 不断地测试代码库。
    • 重构以适应规格说明的变更。
    • 寻求用户的反馈。
  • XP 更倾向于适合中小规模的软件开发,这些软件的规格说明变更非常频繁,而且它们还可以进行接近实时的沟通。
  • 单元测试是极限测试中采用的主要测试方法,它具有两条简单规则:所有代码模块在编码开始之前必须设计好单元测试用例,在产品发布之前必须通过单元测试。

廖杰良 - 2019-6-11

2018-11-15 21:00:48 shanxixy 阅读数 771
  • SCRUM敏捷开发视频教程

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

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

一、敏捷开发/测试的特征

      1. 敏捷开发提倡迭代式和增量式的开发模式,并强调测试在其中的重要性。

       敏捷开发模式的三个特点:依赖客户的参与、测试驱动以及紧凑的迭代开发周期。

      2. 敏捷测试是协同测试的一种形式,它要求每一个人都参与到测试计划的设计、实现和执行中去。客户通过定义用例以及程序属性参与到定义验收测试的设计中来。开发者和测试者共同打造可以进行功能自动化的测试配件。敏捷测试往往伴随着大量的沟通与协作工作。

      3. 敏捷开发下的测试与传统测试的不同点:

        1)意识从发现Bug转变为预防Bug出现,从越多发现Bug转变为越早发现Bug

        2)在测试前期:

          ①全程参与需求讨论,帮助需求和开发对需求有正确和共同的认识。如主导更多的用户场景、异常讨论等。

          ②测试的用例有优先级,针对性编写用例。

          ③在测试中,与开发直接交流、灵活应对变化,什么bug是重要的,什么可以后期做,分清楚Bug 的优先级。最高的优先级是“用户使用最多”以及“最容易发生bug”的场景交集。

          ④测试产出:测试用例、测试报告。

          ⑤缩短测试时间,更多使用自动化,如Selenium,fitness 的使用。

      4. 敏捷开发的两种常见模式

        1)TDD测试驱动开发

        TDD的基本思想就是在开发功能代码之前,先编写测试代码,然后只编写测试通过的代码,从而以测试来驱动整个开发过程的进行。这有助于编写简洁可用高质量的代码。

        2)BDD 行为驱动开发

        BDD是对TDD理念的扩展,TDD重点偏向开发,通过测试用例来规范约束开发者编写出质量更高、BUG更少的代码。而BDD更侧重设计,要求在设计测试用例时对系统进行定义,并用通用语言(如story形式)将系统的行为联系起来,将系统设计和测试用例结合,以此为驱动进行开发工作。

二、极限编程与测试

      极限编程模型是主流敏捷开发方法之一,这种轻量级的开发过程主要把目光集中于沟通、计划以及测试。极限编程中的测试成为“极限测试”。极限测试在极限编程中的地位非常重要,需要首先创建单元测试和验收测试,然后才能创建代码库。一旦代码库发生变更,就需要进行单元测试。在重要的发布结点,由客户来执行验收测试。

2018-07-31 15:10:21 Andrea_Chi 阅读数 59
  • SCRUM敏捷开发视频教程

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

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

跳过非重点章节,直接到第九章

敏捷

首先我们来回顾下敏捷宣言以及价值观

个体和互动 高于 流程和工具

工作的软件 高于详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

敏捷开始提倡迭代式和增量式的开发模式,并强调测试在其中的重要作用。

这是一个围绕以用户为主心,以客户需求为导向的开发过程,在此过程中随时做好 迎接变化 的准备。

如果客户不打算参与进来,那么选择一些传统开发流程或许更好。

 

敏捷模式有三个共同点:1.依赖客户的参与 2.测试驱动 3.紧凑的迭代开发周期

敏捷开发方法 比较常见的XP和scrum

快速原型的一种手段
dev test Ops
1.周期短 2.需求变换快 来不及写文档  3.没啥好测的

敏捷测试要解决哪些问题

可持续集成CICD

脚本化 自动化 可度量 

快速全生命周期质量保证 单元集成系统

前后端分离
前端按照接口文档实现,后端如此
如果问题不能每天集成 那么问题就会越来越多
敏捷其实就是在强调沟通,如果做不到CI持续集成,那么敏捷就是在骗人
几乎IDE可以保证代码可以编译执行,CI的质量保证来自于单元测试jnit testng
maven mvn test
CD持续发布 编译版本可上线 CI做好+质量扩展监督=CD
CI像非诚勿扰 相亲  CD 随便挑一个

我怎么验证CI出来的版本是可以CD的   需要测试
把从CI到CD的内容自动化掉 
1.用自动化提前做掉所有今天需要验证的版本内容
2.用自动化验证上一个版本的内容,通过手工冒烟验证更新内容
自动化并不能提高质量,也不能证明质量
随着现在测试工具的提升,测试质量日益下降
人月神话
如何在敏捷中从user story到测试设计

需求阶段           全生命周期的测试设计    将设计脚本化     CI-CD
user story        单元 集成 系统        自动化 可度量   脚本验证 冒烟测试
用例设计


单元测试
sonar
findbug
testng
jacoco
高一点的代码覆盖率 条件判定覆盖和语句覆盖
覆盖代码流程,覆盖代码多接口调用
自顶向下
driver和mock

 

 

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

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

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


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

综述

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

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

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

本部分将简要介绍敏捷开发中测试人员所需要具备的素质和职责。

敏捷开发团队介绍

我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计,一位项目经理和一位产品经理组成(参见图 2)。每天早上十点,在固定的时间和会议室里面,团队会举行站立会议。这时候,团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务,所遇到的困难和当天要完成的任务。同时,项目经理更新 Sprint Backlog(一张制作精良的 Excel 表格),并及时解决每个人所提出的问题。

在这里插入图片描述

测试人员需要具备的素质

测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不同的组织给测试人员以不同的称号:测试开发 (Test Developer)、质量分析员 (Quality Analyst)、软件质量工程师 (Software Quality Engineer) 等。

每个称号隐含有不同的职能。以上的称号分别对应以下的能力要求:

具有质量检测和编写代码的能力–> 测试开发

具有防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员

具有开发和执行测试程序的能力 -> 软件质量工程师

总结而言,有三方面的基本素质要求:代码编写(Coding)、测试 (Testing) 和分析 (Analysis)。

在很多其他的开发流程中,各个测试阶段对测试人员的能力有所不同;有时候侧重分析(比如系统配置测试),有时候侧重代码编写 ( 比如功能测试 )。但是,在敏捷开发流程中,测试人员需要结合这三方面来开展工作,只有这样才能真正反映敏捷测试的本质:简单而高效得应对变化。

测试人员的主要职责

在敏捷软件开发中,测试人员的职责有三个主要方面:

定义质量 (Define Quality)

这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在 Sprint 计划的时候直接与客户交流,从自己的经验出发,共同为产品功能制定质量要求。

交流缺陷(Communication)

敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能,测试人员应该抓住细节,寻找设计中的“missing door”;另外,开发人员使用单元测试来保证产品的基本质量,测试人员可以使用验收测试(Acceptance Test)来鉴定客户需求与实际成果之间的不一致性。

及时反馈 (Feedback):

敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。
这样一来,团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话,敏捷流程要求每天汇总质量问题。在我们的项目中,内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。
另外,我们的测试框架提供自助测试 (Self-assistant Test):通过点击测试用例列表中的某个具体用例,开发人员不需要中断测试人员的工作就可以重现缺陷。

敏捷开发中QA的职责之敏捷中的QA

QA,通常指的是质量保证(Quality Assurance)工程师,但我更喜欢定义敏捷中的QA为质量分析师(Quality Analyst),主要基于以下几个方面的原因:

质量保证更偏向于工业说法,称参与软件测试的人员为质量分析师感觉更恰当;

质量保证师更多的还是把测试当作软件质量的最后把关着、看门人,而敏捷中的QA更多的是建议提供者而非看门人,把QA称为质量分析师更能体现敏捷中团队对质量负责的原则;

质量分析师更重视业务价值,关注业务价值的分析。

QA,质量分析师,显然与测试有关。敏捷中的QA,也就是与敏捷测试有关。敏捷测试就是在敏捷开发模式下对软件进行的测试,要求尽早测试、频繁测试,以及时提供反馈。敏捷测试要求团队对软件产品的质量负责,而不是某个带有QA头衔的特殊人员。 敏捷中的QA可以是参与敏捷测试的所有团队人员,而并不一定是特定的专职的测试人员。

这听起来是不是有点特别?跟传统开发模式下的测试人员是不是有些不一样?别急,我们先来看看敏捷中的QA是如何进行日常工作的。

敏捷QA的日常活动

从迭代到发布,敏捷测试的生命周期各个阶段QA的活动主要有:测试分析,测试自动化策略分析、框架构建等,故事测试,迭代计划会议和客户演示,测试自动化的维护和执行等。如下图示:

在这里插入图片描述

QA通常不是仅仅工作在某个迭代,而是并行的同时工作在多个迭代:要对当前迭代的故事进行验收测试、探索性测试,和开发人员结对实现测试自动化;还要和业务人员结对分析下一个迭代的故事,编写验收标准和测试用例。

在这里插入图片描述

在单个迭代内部,伴随着故事生命周期,QA的活动有哪些呢?用户故事生命周期包括以下几个阶段:故事分析、故事计划、故事开发、故事验收、故事测试/探索性测试、系统测试和客户演示。QA参与故事的整个生命周期,在每个阶段都会发挥作用。

在这里插入图片描述

  • 故事分析阶段:需求澄清,业务场景和验收测试的确认

  • 故事计划阶段:拆分测试任务,在每个故事开发估算基础上考虑测试的时间和估算

  • 故事开发阶段:和开发人员结对实现自动化测试,和团队沟通发现的问题和缺陷

  • 故事验收阶段:开发人员开发完故事后,QA和业务分析人员要在开发机器上进行验收,以提供快速的反馈;同时还要对测试覆盖率(单元测试、组件集成测试、功能测试)进行确认和提出反馈

  • 故事测试/探索性测试阶段:执行自动化验收测试,执行探索性测试,强调会阻碍故事发布的因素,和团队就测试覆盖率进行沟通,为发现的缺陷添加自动化测试

  • 系统测试和客户演示阶段:执行端到端的系统测试,执行业务或集成的用户测试场景,和团队及客户就功能特性的质量和稳定性进行沟通,参与给客户演示功能和特性

正如前面提到的,在每个阶段,QA除了要独立进行测试,通常还需要跟不同的角色结对,包括业务分析人员、开发人员、以及客户。

在这里插入图片描述

  • QA与业务分析人员结对:通常在业务分析师分析用户故事的时候,QA要与业务分析人员结对编写验收标准。通过与业务分析人员结对,QA能够更好的理解领域知识,从而有利于定义合适的测试用例;QA从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。

  • QA与开发人员结对:QA和开发人员分别能给团队带来不同的技能集,认识到这一点很重要。
    作为一个团队,最好通过平衡不同的技能集来获得共同的目标。这对于传统的瀑布式团队来说是一个很重要的心态改变。
    通常在实现测试自动化的时候,QA与开发人员结对是比较理想的方式。这样结对实现的自动化测试质量相对较高,有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分,而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。
    另一方面,QA通过与开发人员结对,编码能力也会相应有所提高,而开发人员通过与QA结对,测试意识也会增强,更有利于编写质量较高的产品代码,更有利于形成全功能团队。

  • QA与客户结对:客户是业务领域专家,通过与客户结对,QA能够更好的从终端用户的角度理解系统,从而定义或者增加更多的端到端的测试用例;
    一旦QA理解了领域知识和终端用户的观点,其业务价值分析能力会有所提高,在团队需要的时候可以承担业务分析角色;在用户验收测试(UAT)阶段,QA通过与客户结对,帮助客户熟悉使用系统,在必要时可以帮助客户解决一些系统问题。

敏捷QA的这些日常活动,的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。下面为大家来详细介绍一下两者的不同,以及敏捷测试对QA的要求有哪些。

敏捷QA与传统测试人员有何不同

我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面,来看看敏捷QA与传统测试人员有哪些不同:

传统测试人员 敏捷QA
单独的测试团队 多角色开发团队的一员
在开发流程后期才开始测试 测试贯穿于整个开发流中
通常是独立工作 QA和不同角色进行结对
被当作最后也是唯一的质量保证 关注并强调风险
缺乏与业务人员的直接沟通 和业务人员直接沟通
没有机会参与发布计划制定 参与发布计划的制定

从上表的对比可以看到,敏捷QA是特殊的,主要体现在:

  • 敏捷QA是提出建议者而非看门人,需要在参与的每个阶段提出自己的建议,而不是等到开发流程最后来对系统进行验证;不仅要验证开发设计是否满足需求,还要发现需求是否能真正体现业务价值,分析是否有不恰当或缺失的需求。
    比如说,敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求,在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。

  • 发现风险,并将风险与团队及客户沟通。QA参与整个开发流程,对系统整体的认识和把握可以说是团队里边最全面的,因此也更容易看到系统存在的风险。

  • 及时向团队提供关于产品质量的反馈,便于调整。在每个迭代结束时候,QA需要分析统计该迭代的缺陷,并结合自己通过测试对系统质量的了解,及时跟团队反馈,讨论分析质量下降的原因以尽快作出改进,或总结质量上升的经验,鼓励团队再接再厉。

  • 在制定产品和版本的发布计划的时候,QA可以根据自己对产品质量的了解,从测试人员独有的视角提出一些关键的建议。

  • QA通过参与开发流程的每个阶段,能够协助团队从内部提升质量,让质量融入到产品开发中来。比如:在故事验收阶段对测试覆盖率的确认。

这些特殊性对敏捷QA也提出了更高的要求,需要做到:

  • 具有丰富的产品知识和对用户业务目标的准确了解

  • 对不同系统和数据库所用到的技术知识的了解

  • 和不同角色以及客户进行有效沟通

  • 主动验证质量目标并及时说出自己的想法

  • 编写测试计划,列出需要执行的活动并进行估算

  • 自动化测试的能力和对测试工具的基本了解

  • 在团队内部进行知识分享,协助整个团队参与到测试活动中来

  • 持续提供并获取反馈

大家熟悉的测试工作(也是传统的瀑布式),是接到项目后参与需求评审,然后根据需求文档写写用例和准备脚本,等开发提测之后正式开始测试、提bug、回归,测试通过后就结束了,项目交给运维上线,之后投入下一个项目继续重复这样的流程。

这样的流程看似没什么问题,但缺点是:

  • 测试过程是在一定时间间隔内发生的,测试人员必须等待产品完全构建才能找到错误和故障。不可否认,花费的时间超过了可以商定的时间;
  • 测试同学非常被动:当需求质量、开发质量差的时候,你只能被动接受,结果就是你会进行漫长痛苦的测试过程以及因为质量差导致上线延期;
  • Bug的成本在后期是非常高的,需要花费很多精力和时间去修复。甚至严重的情况是产品都不能按时发布,导致很大的损失。
  • 很有可能一个线上问题裸奔了几个月,最后是业务方先发现才排查到是Bug导致,由于影响时间过长给公司造成的损失巨大,还被质疑为什么这么明显简单的问题上线之后没人发现。

敏捷开发中的测试

阅读数 2019

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