产品迭代测试流程(一)

小编现在主要是做OA系统的迭代测试,偏于业务逻辑的功能测试,今天在这里简单记录一下可能会涉及到的测试流程知识点:

一、设计评审

按照测试流程,第一步就是参与涉及评审,一般设计评审会有三方角色参与,分别是:产品、开发、测试。产品经理会提前通知参加评审的时间和地点,以及提供srs涉及文档。常规设计评审都是以会议的模式展开,设计评审的过程:

1、产品经理讲解设计文档;

2、开发人员估测代码可行性和实现功能的工作量;

3、测试人员预估测试工作量。

通过三方讨论,最终决定设计是否过关,是否采用。而在此过程中,测试人员需要的注意事项有以下几项:

1、  设计评审前,仔细查看设计文档,理解新功能和之前版本哪些功能有交叉的测试点,以及之后进行测试时可能需要注意的地方。先预估一下测试的工作量,记录自己不懂的地方,以便于在设计评审中,重点关注一下相关模块,有疑惑及时提出。

2、  设计评审中,注意一定要养成记录评审的习惯。评审过程中肯定会有一些设计开发和产品有争议的,比如代码实现量大,或会改动到其他某些模块,也可能是暂时无法实现的,这些都要记录下来,一则加深自己对于评审的记忆(因为距离评审通过到开发交付演示,时间可能会有点长),同时也对之后编写测试用例应该注意的地方,提前做一个文档记录的预防。

3、  设计评审完成后,整理自己评审前和评审中的文档,如果评审通过,则可以根据最新的设计文档,梳理出一份简单的用例导图。

原文地址:https://www.cnblogs.com/NancyRM/p/10237127.html

时间: 2024-08-27 04:51:45

产品迭代测试流程(一)的相关文章

【转】测试流程

规范的测试流程                                                                                       放弃上份悠闲的工作,感谢那个带我入行公司,我想了解真正的测试在公作中如何进行的.所以,来到了现在这家公司.我很欣喜的是这测试有自己的团队,专业(对当时的我来说)的流程,以及与开发等同的地位. 现在的测试流程: 需求分析: 需求分析由产品人员制定,他们要做的不是一份简单的文档,而是细化每一个功能的细节,每一个按钮

测试流程?项目管理流程?

背景 工作五年了,一直是做测试.认识了很多人大牛,也接触到很多新人,从他们身上看到了很多,自己的过去,自己的未来(当然很多是自己达不到的高度). 做这测试这一行的,很多人都追求技术:自动化+性能,往往忽略测试流程,或者说是项目管理流程. 想法 流程是要结合团队来看的,换句话来说就是case by case,没有标准,适合团队/业务的流程就是好流程: Part1 待过做中国移动项目的传统行业,测试流程一套一套的,需求评审 -- 开发详细设计评审 -- 用例评审 -- 提测评审 -- 测试执行 --

产品研发上线流程 & 角色职责

友情链接: 产品开发角色流程表 研发项目上线流程图 小程序 和 APP 的 开发-测试-运营 流程图, 运营参与到线上流程中,包含产出物及回滚流程 紧急BUG版本开发及上线流程 开发APP流程(简版) 产品开发协作流程梳理 toC产品版本迭代流程 互联网产品迭代反馈团队协作流程? 产品迭代发布流程图 大版本迭代流程图-上线当天 原文地址:https://www.cnblogs.com/growingsbk/p/11263474.html

测试流程的指定

测试流程制定 目标 制定完整且具体的测试路线和流程,为快速.高效和高质量的软件测试提供基础流程框架.最终目标是实现软件测试规范化.标准化. 测试流程说明 流程图 需求分析 需求分析由产品经理制定,要求细化每一个功能的细节,每一个按钮的位置以及边界范围,对于稍大或稍复杂需求要求建模. ( 1 )测试需求是制订测试计划的基本依据,只有确定了的测试需求才能够为测试计划提供客观依据 ; ( 2 )测试需求是设计测试用例的指导,只有确定了要测什么.需要测哪些方面,才能有针对性的设计测试用例 ; ( 3 )

关于测试流程、维度和管理

测试流程 1. 了解需求(也可能是一些优化或Bug),分析需求,提出疑问: 2. 拆解功能点,准备测试文档: 3. 开发提测后,待开发人员讲解实现功能: 4. 两个人以上讨论测试大的方向: 5. 测试: 6. Lead Review: 7. 上线跟踪验证,观察线上数据,并及时给需求方做反馈: 8. 该需求停止,进行下线跟踪. 测试维度 1.从用户实际使用场景和习惯入手,可以覆盖到主要基本场景: 2.通过测试对象内部实现流程的路径及依赖关系分析入手,可填补维度一部分遗漏场景,特别是异常处理和交互处

迭代测试

一个软件的功能的越来越多,如何建立一个规范的测试流程来保证对开发的功能进行充分的测试,是摆在我们面前的难题.在修改bug中常常会出现一种"按下葫芦浮起瓢"情形--修改了A模块的bug,却造成了原来测试没有问题的B模块出现了新的问题.这就促使我们思考:如何保证测试的百分百的覆盖率.为此我设想一种迭代测试和迭代发布的流程.这个流程具体是这样的:所有功能测试分为常规功能测试和新功能测试.所谓常规功能测试是指之前测试已经比较充分的功能,但是在新版本的发布依然需要对它进行测试.所谓新功能测试是指

随口讲讲入门时的测试流程

刚入门测试行业,想来讲一下测试的大概的流程,当作是记录吧 我们的项目是每个月发一个版本,也就是说每月的最后一天发版,一个月就是一个轮回.从1号开始讲,1号的早上呢,老大会叫我们看SVN上的需求,我们要大概的了解一下这个月需要做什么需求,对于不懂的需求要及时提出来.那么去哪提出来,向谁提呢?那就是1号下午开会了,这是一个月的第一个会议,叫做需求评审,参与的人员有产品经理,测试人员,开发人员.主要针对这个月要发版的需求进行解说,我们测试人员遇到的问题也就在产品经理解说的过程中解决了疑惑,一些还是解决

测试流程:一个版本是如何测试上线的--功能测试

在传统的软件行业中,每一个版本的迭代周期少则半年,多则几年.一个版本中如此多的功能最终发布,测试是如何进行质量的保障的呢,我将以我经历的一个项目版本为案例,讲述这个过程中的测试流程. 我们常说测试要尽早的介入到项目中去,从需求开始测试.在这个项目中,需求的测试,我们这边是针对每一个需求单的评审,具体负责该单据的测试人员都要求做需求评审的问题记录跟踪表,要求需求评审中要提出对于该需求单的疑问,不合理的地方要求指出来,在评审会议后要发布需求评审问题记录表给参与该单据的评审人员,并附上结果是否评审通过

移动app传统测试流程优化

概述 在传统的软件测试流程中,每一期需求从开发到上线都要经历从需求分析与评审.测试用例评审.开发.测试.发布的流程.其中测试包含了后台测试.前端web测试.客户端测试.后台测试又包括后台代码逻辑测试.接口测试.接口压力测试等,web端测试包含了前端页面的UI界面测试.PC与移动端浏览器兼容性测试和功能测试等,而客户端测试包含的测试项目较多,而每项测试又相对技术含量较高,从而引入了专项测试的概念.和针对客户端每期需求所做的功能测试不同,专项测试的结果虽然与产品的具体功能相关,又包含独立于产品需求功