关于测试流程的指导心得

一、软件测试应尽早介入软件研发工作中。一半以上的bug来着需求分析阶段。之前出现,需求分析写测试用例阶段,部分功能产品回复为看开发处理,应该记录并考虑相关各个场景出现的问题,并最后确认 。

二、研发计划中要给测试留出时间和准备资源。不能等最后提测了,马上就需要上线,测试没有充足的时间进行工作,最后会导致软件质量不行,项目延期、质量不行,最后也只能测试背锅了。

三、要编写正式的测试计划和测试用例,并做好评审。

四、管理好测试环境

五、为每一个build做验证测试。每一个软件研发过程,都会有很多版本,需挑选一个最精简的测试用例集合,来对每一个build做检验

六、测试开始前对软件产品做接受性测试,测试只接受符合要求的版本。开发提测前需经过开发自测,测试也需经过冒烟测试,确定达到提测标准。测试过程中发布的build的版本,都需经过可接受性测试的测试用例,可接受性的测试用例优先级为 P0 都需通过 ,再进行下一步测试。目的是将开发工作和测试工作做一个分割,以提高效率。如果没有通过可接受性测试的测试用例,则需再次打包。

七、明确bug管理流程。

八、及时提交测试报告。及时沟通,了解测试的工作情况及让上级了解当前的进度遇到的问题等。

九、正确应对bug心态。发现一个bug,要正确衡量对该bug当前版本的影响,影响项目上线不影响功能等问题可暂不处理。

十、测试进度的定义。

1)一轮测试完成:测试用例执行100%,执行后的问题进行回归解决达80%

2)二轮测试完成:一轮测试完成后变更补充测试用例,补充后的测试用例执行率达100%,执行后的问题回归解决达80%

3)三轮测试完成,三轮测试完成后基本完成测试退出标准测试

退出标准:

1)功能需求覆盖100%

2)缺陷处理达到100%

3)缺陷的趋势为收敛,且遗留问题符合公司定义的质量标准

原文地址:https://www.cnblogs.com/LinxiHuang/p/12255719.html

时间: 2024-08-01 05:56:37

关于测试流程的指导心得的相关文章

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

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

测试流程

测试工作流程: 普通测试人员,按目前项目主要分为以下4个过程. 1.  需求分析阶段 2.  测试方案阶段 3.  用例编写阶段 4.  执行用例阶段,包括报告BUG和BUG的跟踪,验证及关闭. 各阶段需要注意的 一.需求分析阶段 工作内容 对SE给出的项目业务相关文档,包括但不限于:需求规格,接口说明书,数据库表结构和注释,组网图,进行阅读和批注疑问点.交给项目负责人员先组内答疑,再将无法解决的问题交给SE确认理解和解决方式 . 注意要点: 1.  对于需求中不明白的内容不论大小只要感觉到影响

[转]微软测试流程简略

[转]微软测试流程简略 Date: 2015-05-18 转自:微软测试流程简略 最近学习了淘宝网的测试流程,感触很深,个人觉得流程特别适合淘宝网这个产品.由于之前曾Onsite微软,对微软的一些测试流程也有一定的了解,曾写过关于微软测试的一些总结,特将其share给各位师兄师姐,由于之前是用英文写的,请大家凑合着看吧: Involving testing field, all of us heard or touched lots of testing terms at Microsoft p

测试流程的规范性与重要性

关于测试的规范性与重要性,结合以往经验,做了几点简单的思考,现记录如下 1.BUG修改之后,在转测试回归之前,开发内部要自行验证. 这个是传统了,不过建议不要只依赖现有的readmine系统(公司的一个BUG管理系统),因为其内置的流程,只支持一个人审核问题,这样往往不够准确,有可能回归不通过.所以建议自行用EXCEL进行跟踪,关键是进行两轮甚至多人审核,这样可以降低回归不通过的概率. 这里有2点值得总结,首先是2轮审核的流程,其次是不依赖现有的BUG管理系统.这个是有道理的,如果没有BUG管理

测试流程的指定

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

1.2软件生命周期&测试流程

软件的生命周期 可行性分析-需求分析-软件设计-软件编码-软件测试-软件维护 1.可行性分析 主要确定软件开发的目的和可行性(PM) 2.需求分析 对软件的功能进行详细的分析(PM),输出需求规格说明书(原型图) 3.软件设计(DEV) 把需求分析得到的结果转换为软件结构和数据结构,形成系统架构 概要设计:搭建架构.模块功能.接口连接和数据传输 详细设计:模块深入分析,对各模块组合进行分析,伪代码   包含数据库设计说明 4.软件编码(DEV) 可运行的程序代码 5.软件测试 5.1.单元测试(

软件测试中常见测试流程

测试的流程: 需求阶段流程图: 单元/集成测试阶段流程图 系统测试阶段流程图 压力测试流程图 性能测试流程图 仅仅了解就够复杂的了,实际操作过程中的问题肯定更多.像压力测试.性能测试,一般的情况下我哪里用得上啊.虽然也知道些什么分布式应用.海量存储之类的,但是我连1T的数据都没见过.光说说那是是空话=.= 第二个问题:软件测试的常规方法. 软件测试中常见测试流程,布布扣,bubuko.com

【转】测试流程

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

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

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