展开

关键词

深入敏捷测试计划不要忘了全局

顾翔老师开发的bugreport2script开源了,希望大家多提建议。 来源:http://www.uml.org.cn 关于计划的不同观点 因为敏捷宣言说响应高于遵循计划,所以经常有人误以为敏捷开发不需要做计划。 而实际上,优秀的敏捷团队的计划性往往比传统瀑布式项目团队更强。它会根据需要把任务分解为足够小的任务块来完成,然后通过快速反馈加以了解和调整。 计划的精度 ? 品版本: 一个或多个团队开发的一个产品,以明确的时间间隔或明确的日期发布。一个产品版本可能有一个或者许多特性。 特性: 一些业务性能或者用于业务的功能块,它应该是较大特性集的一部分。 在产品版本层,测试计划应该包含测试风险的识别和针对当前版本所做的假设;不仅强调针对产品集成问题的测试,也应该强调针对跨团队依赖可能存在问题的测试。 特性层计划精度 ?

20720

测试思想-测试流程 敏捷测试开发之我见

下文本着实用性原则,谈谈敏捷测试开发相关的一些想法,如有不同意见或想法,欢迎提出~~ 1、 团队优先 个人觉得,不管做啥,应该把“团队合作”放在第一位。 问题: 产品经理、策划人员、设计人员(UE、UI),开发人员,测试人员、运营人员……都做到敏捷了么? 2、 需求为主 所有的一切源于需求。由需求而生,随需求而灭。 原型设计好了,共享给相关人员查阅,以便及时获得反馈,及时更正,如果时间来得及,最好是评审下原型 8、 项目开发与用例设计 开发人员根据原型进行项目、产品开发测试人员根据用户故事、原型(假定原型已经被认可的情况下 当且仅当你一看用例名称,即测试验证点,就能想到步骤和结果时(比如翻页,密码大小写验证等),那么可省略,因为这时候,用例名已经起到了足够的“提醒”,…… 9、 开发自测 开发发布前,根据测试提供的用例进行简单自测 备注:开发如果有看下测试给的用例,哪怕是瞄下,说不定就看到没注意的细节了,,进而可将bug于测试前修复,要是再细看下就更好了……知道大致做到什么程度,才不会让测试抓住辫子,才算完成了开发工作,,,这里体现的就是敏捷的思想

48320
  • 广告
    关闭

    腾讯云+社区系列公开课上线啦!

    Vite学习指南,基于腾讯云Webify部署项目。

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    敏捷测试——打通开发测试的壁垒!

    敏捷模型弱化了团队中每一个岗位的职能,也就是说,在敏捷团队中,项目经理、开发人员、测试人员不一定是固定不变的,岗位之间是可以轮换的,因此,敏捷团队对团队成员的能力也提出了更高的要求。 2.灵活的调整测试计划 敏捷提倡灵活,对应到测试工作也是一样,事先确定一个最小化的测试范围。 在实际的测试工作中,随时关注迭代的变化及进展,灵活的调整测试计划,快速响应变化,保证测试计划与迭代计划匹配。 8.完善的工具链支持 在上面讨论测试如何融入敏捷团队的要点中可以看出,人的因素占绝大多数,但是这并不说明工具不重要。 为了管理迭代与测试计划,需要有一套能够适应敏捷的需求及测试计划管理工具。 实践敏捷测试 一旦确定要在团队中推动敏捷开发,就需要从多个方向着手:工具平台、流程体系、规范制度、成员能力、组织架构,每一个方向都不可或缺。那么对于测试,应该如何参与呢?

    25730

    敏捷测试- 快速俘虏产品 & 开发

    二、读代码 这是一门偷窥开发GG每日做什么的最佳手段,但是一般人肯定不想身边有个测试妹子碎碎问。所以要采用下面的几个读心术的工具,来知道我们的开发怎么实现某些功能。 通过观察开发每日提交的代码,查看这个代码的修改点是什么,是否在自己的覆盖范围内,完善自己的测试分析。 多写多动手 不会写程序的产品不是好测试,摆脱开发做根因分析 孰能生巧,这绝对不是说假的。一个不懂开发的人,写了10年的代码,也是可以写出一些代码来。 测试分析感觉听起来像是一个开发,其实不然,测试分析没有必要跟着开发一样实现代码,但是至少能看懂开发的代码,知道开发解决的是什么问题,会不会影响以前的逻辑,会不会造成其他的bug。 这个也是开发测试岗位的术业与专攻,我们关注的是从代码里面发觉更准确的测试路径,提前把bug更早的发现。

    34170

    【腾讯TMQ】敏捷测试-快速俘虏产品 & 开发

    比如,医生可以很快的定位出病人的病痛;测试人员可以很快找到bug所在。而测试分析目的是为了通过分析,可以更快的找到bug。 怎么快速提升测试分析呢?我们测试分析的对象是产品的需求,是开发写的代码。 二、读代码 这是一门偷窥开发GG每日做什么的最佳手段,但是一般人肯定不想身边有个测试妹子碎碎问。所以要采用下面的几个读心术的工具,来知道我们的开发怎么实现某些功能。 6.多写多动手 不会写程序的产品不是好测试,摆脱开发做根因分析 孰能生巧,这绝对不是说假的。一个不懂开发的人,写了10年的代码,也是可以写出一些代码来。 测试分析感觉听起来像是一个开发,其实不然,测试分析没有必要跟着开发一样实现代码,但是至少能看懂开发的代码,知道开发解决的是什么问题,会不会影响以前的逻辑,会不会造成其他的bug。 这个也是开发测试岗位的术业与专攻,我们关注的是从代码里面发觉更准确的测试路径,提前把bug更早的发现。

    81200

    敏捷测试敏捷方法论:理解敏捷测试的完整指南

    一般而言,敏捷宣言有四个核心原则,对于测试人员来说很重要: 个人和流程与工具之间的互动 通过综合文档工作软件 响应遵循计划的变更 通过合同谈判与客户合作 所有这一切的底线是,每个人 - 测试人员,开发人员和其他人 让我们来看看一些最流行的敏捷方法和测试方法,包括: 敏捷方法论 Scrum 看板 测试方法 行为驱动开发(BDD) 验收测试驱动开发(ATDD) 探索性测试 基于会话的测试 2敏捷方法论类型 1)Scrum Scrum Master可以是团队中的任何人,例如开发人员或测试人员。 采用有什么意义? Scrum为来自瀑布环境的团队提供了最简单的转换之一,因为它基于时间的冲刺和发布仍然可以提前计划。 当开发人员准备好完成下一个任务时,他/她将其从待办事项列表中拉出来。由于计划会议较少,这种方法意味着团队需要非常接近。在这种类型的环境中,如果开发人员的工作速度比测试人员快得多,那么就会出现瓶颈。 看板仍然有像瀑布这样的要求,但是由于测试团队没有开始考虑测试每个要求,直到开发人员从积压的顶部选择它,因此需求可能会发生变化。相比之下,瀑布是基于时间的,在计划中有很多开销。

    51920

    敏捷回归测试

    当今世界敏捷大行其道,软件迭代越来越快和发版隔间越来越小,很多公司团队都提倡小步快跑的软件开发模式。 从这个定义来看,很明显,这样的测试类型应该集中在通过预定义的计划、触发器或按需执行的全部或部分测试场景中。 如果根据最佳实践正确开发了回归测试并涵盖了足够的功能区域,则它们带来的价值就很高,并且这种测试模型能够发现回归错误,代码更改的副作用或其他意外的问题。 如果不考虑这些考虑因素,则可能会导致整个测试流程延迟劲儿导致发布计划的失败。 在考虑在敏捷环境中进行回归测试的策略时,需要了解这种环境会不断变化。 测试工程管理需要专注于回归套件的持续维护并确定以下内容: 哪些测试用例已经过验证,需要包含在回归套件中,哪些应该排除在外? 回归和子集回归套件的执行时间计划是什么?

    23520

    什么是敏捷测试

    敏捷测试的定义 埃森哲对敏捷测试的定义(与维基百科的定义基本一致)大概如此:敏捷测试是遵从敏捷软件开发原则的一种测试实践。敏捷开发模式把测试集成到了整个开发流程中而不再把它当成一个独立的阶段。 用户验收测试在每个sprint的结尾都会进行; 更灵活的计划敏捷测试也需要拥抱变化,测试计划不再是一成不变的文档,而会根据业务价值交付的顺序进行灵活的调整; 更高效的自动化:相比传统测试,自动化在敏捷测试中扮演了极其重要的角色 当然,除了适应开发的节奏外,敏捷测试还是有其特有的价值: 缩短价值交付周期 通过采用敏捷测试这种模式,可以契合整个敏捷开发周期,使得整个敏捷开发按照相同而快速的迭代速率和周期交付,让最终用户尽快获取到业务价值 敏捷测试一直强调质量属于每一个人的责任,除了测试之外,开发、产品经理等都有义务对自己的交付件质量负责,这样才能确保项目的整体质量; 化繁为简节省成本 敏捷测试没有要求需要详细的测试计划测试文档,也没有定义繁复的测试流程及缺陷流程 测试以需求文档为准 4. 测试以最终用户为准 5. 详细的测试计划 5. 精益化的测试计划 6. 计划是一次性活动 6.

    14250

    敏捷软件测试(上)

    of agile software development.1 译文:敏捷测试是一种遵循敏捷软件开发原则的软件测试实践。 敏捷测试与传统测试的区别 传统模式是把软件开发分为软件需求、软件开发(设计&编码)、软件测试、软件发布等阶段,一般利用里程碑的方式对各阶段进行明确定义。 ;敏捷测试拥抱变化,测试计划比较灵活,按业务价值交付顺序执行;需求方需求定义后,参与每一次产品演示,确认每一次迭代产物,全程参与项目。 二.典型的敏捷软件开发过程 在敏捷的软件开发过程中,敏捷测试人员利用他们的专业知识从客户那获取需求所包含的业务行为,与开发团队协作,将这些行为转化为指导编码的可执行规范。 2 测试人员参加需求说明会和计划会:产品经理给项目人员串讲用户故事,在这个过程中项目人员提出自己的建议和想法,并充分讨论。

    13320

    敏捷测试二三事

    敏捷测试方法已在软件开发测试生命周期中不断变化的企业所采用。优秀的敏捷实践要求开发测试活动必须同时进行,与传统瀑布模型相比,其结构非常不同。因此,敏捷测试方法也与传统测试方法完全不同。 本文将探讨在应用程序/软件开发过程中,敏捷测试开发团队不同协作的几种主流方式。 ## 开发测试过程变化 人们非常关注持续发展,持续整合和持续增长。 因此,开发过程需要开放的沟通,讨论和思想交流渠道。最初的报告行交给`Scrum`团队,然后再到各自的测试开发团队。 ## 使用敏捷工具 测试开发团队需要工具来支持持续的开发测试活动。 ## 信息通畅 在敏捷场景中,测试成为约束力,测试人员与开发人员经常配完成工作。在此过程中,每个成员都希望保持对不断变化和迭代的了解和掌握,必须通过确保响应能力来保持业务敏捷性。 只有不断实施变更,敏捷测试才能为企业带来一致的价值。对于一直在传统开发方案中工作的组织和团队而言,这可能是一个挑战。因此,在采用敏捷测试实践之前,需要适当的再培训/培训计划

    18830

    敏捷测试二三事

    敏捷测试方法已在软件开发测试生命周期中不断变化的企业所采用。优秀的敏捷实践要求开发测试活动必须同时进行,与传统瀑布模型相比,其结构非常不同。因此,敏捷测试方法也与传统测试方法完全不同。 本文将探讨在应用程序/软件开发过程中,敏捷测试开发团队不同协作的几种主流方式。 开发测试过程变化 人们非常关注持续发展,持续整合和持续增长。 因此,开发过程需要开放的沟通,讨论和思想交流渠道。最初的报告行交给Scrum团队,然后再到各自的测试开发团队。 使用敏捷工具 测试开发团队需要工具来支持持续的开发测试活动。 信息通畅 在敏捷场景中,测试成为约束力,测试人员与开发人员经常配完成工作。在此过程中,每个成员都希望保持对不断变化和迭代的了解和掌握,必须通过确保响应能力来保持业务敏捷性。 只有不断实施变更,敏捷测试才能为企业带来一致的价值。对于一直在传统开发方案中工作的组织和团队而言,这可能是一个挑战。因此,在采用敏捷测试实践之前,需要适当的再培训/培训计划

    22030

    敏捷软件测试(下)

    无论人员来自哪里,在敏捷团队中,测试开发同属一个项目,大家的目标是一致的,敏捷测试人员在质量思想方面影响团队的其他成员。 如测试人员可能会帮开发人员评审代码,开发人员也会帮测试人员进行测试,人员角色的职能可以模糊化。 敏捷测试团队还需要把客户纳入到组织中,学会一起工作并建立起彼此间的信任,一起做好软件的质量保证。 建立有效沟通方式 敏捷测试人员需要与需求人员、开发人员保持沟通,建立一种相互合作的氛围。 五.总结 敏捷软件测试不是独立存在的,它依赖敏捷的软件开发过程,强调的是敏捷项目团队的整体对质量的负责,测试团队不再是质量职责的全部。 答:提高技术的方式挺多,途径包括参加培训、自学(包括线上文章、视频等),工作时可以多请教高人,参与一些群(包括QQ、微信),对于之前没有技术背景的同学,最重要的是制定一个计划,主要还是要围绕自己的工作展开

    12520

    什么是敏捷测试

    读者提问:什么是敏捷测试? 阿常回答:这个问题我从三方面回答:1、什么是敏捷测试;2、几种应用形式;3、敏捷测试的核心。 一、什么是敏捷测试 敏捷测试又被称为 “ 小步快跑 ”、“ 快速迭代 ”。 二、几种应用形式 一)每日站会 每日站会,就是每天早晨 10~30 分钟的会议时间,项目组成员(包括产品、设计、研发、测试)依次介绍昨天任务的完成情况、遇到的问题、今天计划要完成的工作内容等。 三)测试驱动开发 如果先编写代码,然后再测试实现,则可能会遇到一些问题,即过度研发,设计偏离,可测试性问题。 测试驱动开发(在编码之前先写测试代码,测试代码就绪后编写代码,再去用测试代码去验证编写代码,及时修改完善逻辑)有助于将软件缺陷减少 40% 到 60%。 敏捷测试的目标不是发现更多的 Bug,而是帮助开发人员理解需求(提前预防缺陷,而不是等开发完成了才发现很多问题),尽快地交付高质量的软件,这就是质量内建。 明天我们再来聊一聊【质量内建】。

    6830

    敏捷业务实践之计划游戏

    而另一些则是一些人想接敏捷之手宣传自己的思想与实践,强行在敏捷中加入了自己的想法。这些原因使得如今的敏捷五花八门,甚至出现两人在谈论完全不一样的敏捷计划游戏(Planning Game) 计划游戏是极限编程生命之环外圈的一个业务实践,它主要指的是IPM以及为了支撑IPM的一系列实践,比如估点,故事优先级排列以及速率预估和检查等等。 N:可协商(Negotiable) 开发人员和业务人员还有测试人员应该能够就故事的细节进行协商。例如可能业务部门需要一些精美的界面,但开发人员可以以成本低的理由协商该功能能否以另外的方式实现。 迭代计划会议(Iteration Planning Meeting, IPM) 此时我们已经拥有了故事卡和每张卡的故事点,为了开启一个新的迭代,我们需要组织一次所有成员和利益相关者参与的计划会议。 在演示中会展示所有故事的所有验收测试和单元测试,同时还应该由利益相关者来操作演示新添加的功能,这是为了避免开发人员试图隐藏某些信息。 速率 迭代的最后一步是更新速率图和燃尽图。

    22200

    软件测试——测试计划

    1.2在线测评系统测试目的与测试任务在开发本计算机程序能力在线测评系统(PTA)的过程中即时使用了许多保证软件质量的方法和技术(包括权限管理,试题分布、高并发在线测评),但开发出的软件中还会隐藏许多错误和缺陷 主观上由于开发人员思维的局限性,客观上由于目前开发的软件系统都由相当的复杂性,决定了在开发过程中出现软件错误是不可避免的。 若能及早排除 开发中的错误,就可以排除给后期工作带来的麻烦,也就避免了付出高昂的代价,从而大大地提高了系统开发过程的效率,因此,软件测试在整个软件开发生命周期 各个环节中都是不可缺少的。 1.3受众本《测试计划》的预期读者是:程序教学平台开发经理技术部经理测试部管理人员测试组所有成员(包括SQA)开发公司授权调阅本文档的其他人员本测试计划主要有两类主要受众:测试管理人员和测试人员。 测试管理人员根据该测试计划制定进一步的计划、安排(工作任务分配、时间进度安排)和控制测试过程。测试人员通过该测试计划了解测试过程和相关信息。

    28730

    敏捷开发」企业架构和敏捷开发:对立吸引?

    因此,在许多组织中,敏捷与创新能力同等重要。创新和敏捷性是可持续业务的必要能力。 ? 敏捷开发已成为软件开发的标准。但真正的业务敏捷性需要的不仅仅是拥有一堆Scrum团队。 此外,如果您只关注敏捷软件开发提供的小规模敏捷性,您可能看不到树林:为什么您希望像企业一样灵活,这需要什么? 在更大的规模上组织敏捷 企业不仅仅是小团队的一系列本地开发项目。 传统的企业架构具有相当自上而下的特性,您可以在实施之前制定广泛的计划敏捷运动的重点在于适应变化和对“大型设计前沿”(BDUF)的抵制,恰恰相反。 两种方法都有其优点和缺点。 TOGAF也有一个迭代结构,由其架构开发方法(ADM)熟悉的“麦田怪圈”图表示。但是,在敏捷环境中应用它需要进行一些调整。特别是企业架构需要变得更加外向,从而更加面向业务,最终客户和以结果为中心。 再次关注TOGAF,TOGAF的实施治理(ADM中的阶段G)与实施项目和计划(即底层两层)的接口方式需要一些工作。特别是,敏捷方法强烈依赖于反馈循环,而TOGAF的治理本质上是前馈。

    52920

    谈谈敏捷开发

    但是在接触敏捷开发这个体系之前,自己有机会做一个项目,那个时候我开始将自己认为更有利于项目的管理工作做了一些应用,那个阶段我的主要做法是: 1、项目中开始划分更短的制品交互周期,而不是以前那样等待产品开发完毕后发布各种测试版本 Ø 开发负责人组织并确定迭代计划内容,明确每个迭代提交的产品目标、开发任务安排、测试跟踪计划 Ø 每个迭代过程中都由需求及测试进行确认每个任务的实现结果是否跑偏 Ø 后面就是每二周向客户演示一次产品 他需要知道这个开发任务的需求是如何,提前做好测试计划测试用例,在接到开发制品后测试并提交BUG,这个工作是可以开发过程中就能不断的进行的。保证每一个任务的质量,可以大大减少后期集成的错误量。 另外根据敏捷开发的思想,测试团队在开发过程中也需要加强与开发团队的交流,甚至有必要组成虚拟团队,位置调整到一起,这样可以及时快速的交流,参加开发团队的站立会议同样可以及时了解到开发的实际情况及进度,反过来把握测试计划测试内容 特别是测试从另一个角度来审视需求,这样也可以一定程度上发现或者改善需求上的不足。 3、发挥团队人员的潜力 敏捷开发比较提倡开发任务由开发自己评估并认领工作任务,这样可以激发开发的潜在动力。

    45600

    测试驱动之敏捷测试人员(六)

    所谓敏捷测试人员,就是具备专业的测试知识以及开发技术,可以良好的合合作,懂得并且熟悉所要测试的需求,和驱动开发的技术能力,知道与他人合作以实现自动化的测试,更好的理解客户对软件的需求,和具备和客户沟通的能力 作为敏捷测试人员,个人认为,应该具备如下素质和人文修养。 另外,持续反馈同时也要注意,测试对业务,开发技术等不了解的,要及时的,持续的和有关人员沟通,并且反馈测试结果,做到问题尽早的解决。 ,并努力的来实现这些计划。 作为敏捷测试人员,要具备承担一切责任的能力,并且保持与团队共进退。

    32260

    敏捷开发--scrum

    请简述一下什么是敏捷开发(Agile Development),以及什么是持续集成。 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题,让团队能够更快的开发内聚的软件。 2.  你所知道的敏捷方法有哪些? * 1、Scrum计划会议     在每个Sprint开始之前,需要召开Sprint计划会议,会议时间一般为4~8小时,参加人员有产品责任人、Scrum Master、Scrum团队和其他感兴趣的人, 在Sprint评审会议上,Scrum团队用Demo的形式展示产品的功能之后,与会人员依据在Sprint计划会议上确定的这个Sprint的目标来评审具备了这些新功能的产品。

    78860

    相关产品

    • 金融专有云开发测试平台

      金融专有云开发测试平台

      金融专有云开发测试平台是腾讯云为客户专属搭建的小型化测试开发平台,可以为您快速搭建一套完整的金融云开发测试环境,方便客户在完全模拟现网环境下,进行开发测试,整体环境运行维护统一由腾讯云提供,可以帮助客户减小维护成本,提升运营效率。

    相关资讯

    热门标签

    扫码关注云+社区

    领取腾讯云代金券