快速迭代的app产品需要测试用例评审吗?

目前快速迭代过程中,需求变更很快,写的测试用例也需要不断变更,一直在想真的需要测试用例评审吗?该如何做比较有效率,请高手给意见

0

2个回答

快速迭代,如果需求变得快,说明团队磨合不够,如果测试和开发一起介入需求,形成有效沟通,测试用例不细也没关系

1

快速迭代 用例不用评审的 我们就是几乎10天一个迭代 我们的迭代都是需求评审明确 严格照着需求测试 只要满足用户的需求就行了

0
Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
其他相关推荐
互联网产品快速迭代下是否需要写详细测试用例
由于自己在互联网电商公司工作,产品需求很多,平台功能迭代很快,有时一个功能需求评审+开发+测试 +上线总共只有1天时间的计划,而且有些紧急需求不允许delay,这时我们如何分配实际执行测试时间和测试用例编写时间? 我认为我们不能一味的 墨守以前的测试流程,测试用例固然重要,但是如果写测试用例消耗了绝大部分测试时间,那将是得不偿失的,写过用例的都是知道,用例在实际...
测试用例评审过程以及相关人员参与详解
1:评审的过程       A:开始前做好如下准备                     1、确定需要评审的原因                     2、确定进行评审的时机                     3、确定参与评审人员                     4、明确评审的内容                     5、确定评审结束标准                   ...
迭代评审的十个成功要点
     迭代评审会议是在每次迭代结束时给项目组内外部的相关人员展示本次迭代完成的功能,以获得相关人员对软件的反馈意见。这是客户、最终用户、管理者等对项目组完成的功能进行反馈的一个渠道。如何召开一个成功的迭代评审会议呢?我根据对多次迭 代评审会议的观察,总结了如下   1 鸡类角色与猪类角色都要参与迭代评审会议;        以下两类人员都应该参与: 项目组的所有成员,包括PO,SM...
适合于小团队且周期短的产品迭代的APP测试流程
一、测试周期 测试周期一般为1-2周,根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管或产品经理确认项目排期。 二、测试资源 app测试任务开始前,检查各项测试资源。 产品功能需求文档、概要设计文档(包含非本期开发的产品功能部分) 产品原型图(包含非本期开发的产品功能部分) 产品效果图(包含非本期开发的产品功能部分)
产品经理为什么要认真对待测试工作
写在前面:我为什么要转载这篇文章?因为刚入职的时候,接了一个改动较大的需求,结果开发两周,测试周期长达两个月,也是醉了。事后总结,一个重要的原因就是没有认真对待测试用例评审这件事情,导致测试测到哪里算哪里,每次要上线的时候都会发现bug,搞得大家都加班,还特别累。 下面是我目前安排测试的一个流程: 1、首先,讨论需求,出技术方案的时候,如果有必要可以叫上测试工程师一起参与; 2、
产品快速迭代需要注意点
    产品的快速迭代,先确实阶段性时间,再考虑功能点。    在做产品时,要考虑下一个产品版本的时间什么时候出,然后列出所有的需求的功能点,对所有需求做一个优先级排序,确认在当前时间下面,能完成哪些需求。有点不紧急的需求可以放到下一个版本中。    生活不易,请微笑对待你所接触的所有人。...
为什么测试用例需要评审
无论是初级测试工程师,还是高级的,专家级的,设计出来的测试用例都需要经过评审。   原因一:设计完成的测试用例要分配给每个人来设计具体数据,并实现自动测试。设计用例和实现用例、执行用例并非一人完成。设计用例的人并不知道用例在具体执行的时候是否有问题,或者哪些步骤不能实现自动测试。再者“测试是无穷尽的”,谁又能保证自己设计的用例能覆盖完全?   原因二:测试人员总是抱怨测试出来Bug后与开发扯皮
用例评审--用例评审
输入:测试用例、需求规格说明
关于迭代测试的一些思考
作者:朱金灿来源:http://blog.csdn.net/clever101            一个软件的功能的越来越多,如何建立一个规范的测试流程来保证对开发的功能进行充分的测试,是摆在我们面前的难题。在修改bug中常常会出现一种“按下葫芦浮起瓢”情形——修改了A模块的bug,却造成了原来测试没有问题的B模块出现了新的问题。这就促使我们思考:如何保证测试的百分百的覆盖率。为此我设想一种迭代
测试用例评审流程
1.目的   测试用例评审流程规范主要为开展测试用例评审工作提供指引,规范测试用例评审管理工作。 2.测试用例评审流程内容   2.1.前提:测试人员编写完一个完整的功能模块的测试用例或已完成所有测试用例的编写;       2.2.流程输入:A.测试用例;         B.需求规格说明;       2.3.流程输出:A.问题记录清单;   B.测试用例评审报告
产品快速迭代的五大要点
http://www.yixieshi.com/pd/13375.html 今天在微博上又一次看到有人转发小马哥的:“小步快跑,快速迭代”理论,刚好鄙人近期收集了一些快速迭代的资料,接下来结合自身的经验来浅谈产品的快速迭代方式。这篇文字可能会偏项目管理一些,不过我认为项目管理也是产品经理基本素质之一。   关于立项   这一点相信大家都不陌生,每个产品在经过 BRD、MRD
如何做测试用例评审
测试案例是贯穿了整个测试流程和项目研发流程的,因此用例显得至关重要。如何提高用例的质量,用例评审是必不可缺的一环。 很多测试同学都知道应该做测试案例评审,并且也乐意做需求评审,但是很少有测试同学总结过如何做案例评审。那么案例评审应该从哪些方面着手呢? 在开始之前,再回顾一下测试案例的几个要素。 测试案例的四要素分别是:测试环境、测试目的、测试步骤、测试结果。这四要素缺一不可。另外还有案...
敏捷开发-迭代会议
敏捷开发迭代会议,主要是挑出产品设计和功能问题,保证迭代版本的产品原型完整性、正确性、合理性。如果产品大致功能没有多大问题,留下些小问题,那么可以进行项目拆分、工时估算。(一个细节要提醒的,产品必须在迭代会议之前,把原型提前2-3天交给相关人员,开发人员可以在会议上提出交互细节的问题、竞品分析) 迭代会议一般 14-18点   或 15-17.30;前半场PM主导,讲解原型,Team提出疑问
静态测试及评审、测试用例
7.1静态测试的定义、特点 静态测试通常是指不执行程序代码而寻找代码中可能存在的错误或评估程序代码的过程,其被测对象是各种与软件相关的有必要进行测试的产物,例如各类文档、源代码等。 特点:   1)不必动态地运行程序。   2)可以人工进行,充分发挥人的思维优势。   3)不需要特别的条件,容易展开。   4)对测试人员要求比较高,至少测试人员要具有编程经验。 7.2评审 培训评审
App版本迭代时间安排(思路重要)
App 2周版本迭代时间安排 对于移动互联网产品来说,迭代的速度就是生命。 我创业时做移动App时是一周一版,而现在是2周1版。 相比起小公司,大公司迭代时间虽长,却更为不易,因为大公司流程更多,参与人数更多,需求更多,实现这样的快速迭代存在许多挑战,也有一定风险,管理者控制起来更困难。         那我们应该如何来实现2周1版的快速迭代呢?  
怎样做好测试用例的评审
大家都知道,软件测试过程中,最重要的就是测试用例的设计。首先说说测试用例的重要性。 一、编写用例的重要性 1.深入了解需求的过程,一个项目立项开始,测试就开始介入,我们从产品的PRD文档、用户交互图,视觉图等相关文档去熟悉产品的各个模块,各个业务流程。或者在产品规划和设计阶段,测试开始熟悉产品。而编写用例的过程中,会充分的思考产品需求的细枝末节,需求的不合理、有矛盾、不明确的地方,还能
产品的版本迭代机制是这样的
一款互联网产品的版本迭代不是在最开始就规划好的,也不应该规划好,甚至不用做很长远的规划,因为你的长远规划真的只是停留在规划。 一款新产品推出市场,死了或者火了的处理方法比较简单,可如果是不愠不火呢?迭代,该怎么让产品火起来? 一、产品的迭代的唯一依据————目标用户产生的数据 新产品上线,无论获取用户的方式是什么,是烧钱还是烧钱还是烧钱,一定要获取第一批种子用户。烧钱也不是乱烧的,得烧对地方
android如何进行版本迭代及代码审核
android如何进行版本迭代及代码审核
产品迭代,同样是用户体验的迭代
作者:Aaron Yan全文共 3542 字 1 图,阅读需要 8 分钟———— / BEGIN / ————我们在使用淘宝、头条、微信这些APP的时候,是不是感觉产品做的越来越好了呢?那么你觉得这种越来越好的变化,是因为APP功能的完善,还是因为操作变得更流畅了?我猜你的答案肯定是:这些APP变得好用是全方位的变好了,不仅仅只是其中一个方面变得比原来更好。我们都知道,APP越来越好用,是因为:我
PART5 测试人员经历的一个迭代
一、测试人员在发布或主题计划阶段的工作  1. 制定计划:短期计划更好。(优先级变化 、环境的不稳定,长期计划很难实现。)  2. story卡处:需要做、开发中、待验证、已完成。  3. 评估story:工作量(小中大)。集体评估,再调整。  4. story测试评估: 解决什么问题?客户怎么用这个功能?最坏的结果是什么?有关联系统吗?安全吗?性能有要求吗? 从未接触过的业务,会不会
测试评审方法---验证与确认
验证与确认     验证与确认都是确定软件产品是否满足其预期要求和条件的过程。验证可适用于分析、设计、编码、测试和评审等众多的过程,而确认通常用于验收过程。     1.验证     软件项目的验证一般应包括合同验证、过程验证、需求验证、设计验证、编码验证、集成验证和文档验证。     (1)合同验证。应根据下列准则验证合同: 供方具有满足需求的能力。 需求是一致的并覆盖了...
使用模板快速编写测试用例
内容转自美团点评技术团队。http://tech.meituan.com/testcase-templete.html 在高速发展的互联网公司,由于产品的开发迭代太快,产品测试经常遇到以下几个问题: 如何在快速的产品开发迭代中迅速地完成对产品功能的测试?面对用户众多、环境多样,如何尽可能地测试全面?公司扩张迅速、新人多、经验不足,如何使新人迅速上手进而独当一面? 下面介绍一种
迭代=冲刺?
本文作者:特邀敏捷教练梁堃前段时间在和一个小伙伴聊天的时候,他问了阿甲这样一个问题:Scrum guide中把固定时间盒周期称为sprint(冲刺),但是为什么大家在平时都愿意把它称为迭代(iteration)呢?从阿甲接触敏捷至今,对于sprint和iteration这两个词也是经常混着用,但关于这两个词之间的关系和区别,还真的没有思考过。正好阿甲也想趁这个机会和小伙伴们一起把这个概念理清楚,所...
迭代数据的4种方法测试
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using Unique; namespace ConsoleApplication4 { class Data { public in
2.迭代开发的过程是怎么样的
敏捷开发系列文章目录     在讨论PO如何给团队讲好故事这个问题之前,先给大家了解一些基本的敏捷概念,然后讲讲我们敏捷团队构成与整个敏捷开发的过程。       当初敏捷老师讲课的时候就跟我们所过,敏捷没有什么具体的形式,每个敏捷团队可能做法都不一样,表现出来的性格也不一样,比如有挑战型团队、有保守型团队等。但敏捷有一个核心是不能变的,这个核心就是3355。 1、3个角色:S
如何有效的进行测试用例评审
测试用例评审对与验证测试用例的正确性、有效性、测试覆盖等有积极的意义;而且可以有效的保障测试实施,以及测试用例改善等工作都至关重要。那么如何有效的进行测试用例评审?这里其实包含了两个问题: 1、如何进行测试用例评审? 2、如何有效的对测试用例进行评审?第一个问题:如何对测试用例进行评审?经过一些测试工程师讨论,总结如下: 测试用例本身的描述是否清晰,语言准确;是否存在二义性; 测试用例内容是否完
测试用例评审标准
<br />测试用例评审标准<br />首先要清楚内部评审的定义,是测试组内部的评审,还是项目组内部的评审。评审的定义不同,内容也不会相同。<br /><br />如果是测试组内部的评审,应该着重于:<br />1.测试用例本身的描述是否清晰,是否存在二义性;<br />2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行,验证点却不同,而且测试设计的冗余性,都造成了效率的低下;<br />3.是否针对需求跟踪矩阵,覆盖了所有的软件需求;<br />4.是否完全遵守了软件需求的规定。这并不一定的
App后台开发运维和架构实践学习总结(5)——App产品从需求到研发到开发到上线到产品迭代全过程
前言 如果没有做过开发,研发过产品的人,很难体会做产品的艰难,刚进公司的人,一般充当的是程序开发,我这里说的是开发,它与研发是有区别的. 一个需求下来,如果不能很好地理解产品需求,如果不能很好的驾驭需求实现的逻辑,肆意的根据理解去做技术方面的架构和编码,等到后来发现了不对了再去修改就特别麻烦。 所以我们在实现产品需求时,每一个功能需求,不管是大还是小,都要想商量清楚了,我们在采取编码.
做移动互联网App,你的测试用例足够吗?
做移动互联网App,你的测试用例足够吗?做移动互联网App,你的测试用例足够吗?
测试用例评审检查单
测试用例评审检查单,关于测试用例的评审以及需要注意的点和使用方面的需要
测试案例设计及评审标准 V1.0
好久没更内容了,因为最近在带一个新项目,还是自己完全未接触过的领域,加上招聘面试的结果非常不理想,自己也抽了50%左右的精力在做需求分析和测试设计。这篇文章主要是因为最近发现团队里新人的测试设计能力参差不齐,甚至可以说是太差了,因此重新梳理了一下测试设计规范。 设计工具 最常用到的工具是思维导图,即XMind,Excel,以及案例管理平台。 Xmind:Xmind能够快速的建立结构树,...
如何进行一场高质量的UI设计评审(上)
阿里巴巴_B2B_UED – 舒舟:产品设计流程中,有必要对设计进行评审是大家的共识。在我每周的工作内容中,参加各类大大小小的设计评审是必不可少的一环。既有脑力激荡的评审让设计方案脱胎换骨的,也有针锋相对的评审让设计方案摇摆不定的。怎样进行一场高质量的设计评审?设计师应该如何应对设计评审,更好的表达设计意图,并收集意见改进方案?怎样避免设计评审变成竞稿或PK?如何确保设计评审这样的流程能带来更大价
我是怎样在美团点评做App需求迭代的
一、一人一个团队 我加入大众点评的时候,点评刚刚分拆出App的业务线,刚好我是这个业务线的第一个iOS开发。所以当时的情况是一个人一个团队,而且只在点评App上开发,版本迭代的节奏基本上就是我自己的开发节奏,因为只有一个人,PM们对我充满了无尽的respect和dependency。那时候很累,我基本上很少晚上9点之前下班,周末很少双休,而所有的这一切都是自愿的,尽管没有调休没有加班工资,所以,
产品经理之如何评审开发同学的[详细设计]
详细设计是干嘛的 详细设计是开发同学理解需求、交互稿后,对要实现的功能点进行技术选型、机制确定的过程。 详细设计完成后一般进行详细设计评审,通过后,进入代码编写环节。 详细设计有什么 功能点确认 确认详细设计中是否包含了本次迭代的全部需求。 确认按此机制实现是否有违背需求、交互设计的风险。比如高级搜索功能是否能够覆盖条件A\B\C还是只能覆盖条件A。 接口设计 关注项应至少包
小步快跑 快速迭代(整理)
(1)快速迭代首先是一种产品研发理念。 在快速迭代理念支持下的产品研发是“上线-反馈-修改-上线”这样反复更新内容的过程,形式非常适合互联网产品或者移动端,通过收集数据或用户反馈迅速知道改进的结果,用快速迭代的方式可以立即在用户之间找到平衡点。 与快速迭代关系最密切的是敏捷管理。具体是故事墙+每日晨会+规划游戏+时间盒+产品演示+迭代总结+自运转团体。在敏捷管理过程中,产品经理的角色扮演十分重...
测试用例评审意义
http://blog.csdn.net/yunyuehu/article/details/4970206?locationNum=3&fps=1
产品迭代都做了写什么
产品为什么可以无限迭代下去呢?产品从诞生开始,首先要搭建出一个强健的主场景,时间期限通常是一年。一年内,主场景还没有搭好,数据还是不满意,产品基本上就没戏了,再拖下去也是等死。为了搭主场景,不断改进功能,优化界面,都是必然的。这个问题,其实是说,当主场景搭好了以后,产品为什么还会无限迭代下去。第一种可能性是加强主场景,不用解释。第二种可能性是拓展新场景,但失败率很高。一款产品的边界在哪里,往往在一开
测试用例评审___检查单(Checklist)
序号    主要检查项  1       《需求规格说明书》是否评审并建立了基线?  2       是否按照测试计划时间完成用例编写?  3       需求新增和变更是否进行了对应的调整?  4       用例是否按照公司定义的模板进行编写?  5       测试用例是否覆盖了《需求规格说明书》?  6       用例编号是否和需求进行对应?   7       非功能测试
测试用例编写及用例评审方法
     编写测试用例是测试人员的基本功,可是在学校的时候我们好像也没有相应的课程来教我们相应的设计方法。后来我们从网上或是一些软件测试相关的书上会看到不少介绍编写测试用例的方法,如:等价类划分,边界值分析法,错误推测法,判定表法,正交实验法等,可是我们工作后这些方法好像不太好用。 曾经我面试过一个同学,在面试过程中让他写了一个登录功能的测试用例。他使用等价类划分法来编写测试用例,写的超级多,我...
关于测试用例的Review
前言:做测试也两年多了,对于测试的方方面面也有了一些自己的想法,想起许久以前在CSDN开过空间,于是就来这里谢谢自己测试的方方面面。  我所在的公司还是比较重视Process的,各种各样的Review进行的都比较正式。也专门有一个部门来支持各种各样的流程改进以及相关的工具开发。目前我们的Case Review基本上是在项目Release前,测试用例已经差不多完工的时候开始。这样
文章热词 设计制作学习 机器学习教程 Objective-C培训 交互设计视频教程 颜色模型
相关热词 mysql关联查询两次本表 native底部 react extjs glyph 图标 快速学习java需要多久 大数据需要机器学习吗