测试流程的指定

测试流程制定

目标

制定完整且具体的测试路线和流程,为快速、高效和高质量的软件测试提供基础流程框架。最终目标是实现软件测试规范化、标准化。

测试流程说明

流程图

需求分析

需求分析由产品经理制定,要求细化每一个功能的细节,每一个按钮的位置以及边界范围,对于稍大或稍复杂需求要求建模。

( 1 )测试需求是制订测试计划的基本依据,只有确定了的测试需求才能够为测试计划提供客观依据 ;

( 2 )测试需求是设计测试用例的指导,只有确定了要测什么、需要测哪些方面,才能有针对性的设计测试用例 ;

( 3 )测试需求是计算测试覆盖的分母,没有测试需求就无法有效地进行测试覆盖 .

需求评审(需求澄清)

参与人员,包括:产品,开发和测试。

产品提出需求。

开发人员考虑功能实现的方案与可行性。

测试人员主要是对需求的理解提出疑问,以便才能根据需求写用例。

开发人员编写排期

开发人员需求根据需求功能点进行排期,然后将开发计划发送给参与项目的所有人员。

测试计划排期

测试人员根据开发计划,安排测试的具体测试时间,然后将测试计划发送给参与项目的所有人员。

注:排期小技巧,根据需求先去预估大概需要多少测试用例来覆盖,用例数目预估出来之后,根据自己编写的速度和执行测试的速度,时间这样就出来了。

编写测试用例

根据详细的需求文档,开始进行用例的编写。

编写测试用例的准则: 1 ,覆盖所有的需求; 2 ,每个需求分支必须至少包含正常和异常两种场景; 3 ,测试用例的版本号必须与需求的版本号保持一致;

例如以禅道为例如下:

整体用例完成之后,如下:

用例评审

用例评审前,先将用例发送给相关人员,以便他们事先了解用例将对哪些功能进行验证以及验证的细节。

在用例评审中,参与人员需要对用例中与实际功能不符合的用例或者格式不规范规用例提出修改建议。

提交基线

开发人员完成所有功能后,会对自己的功能进行一个自测。自测完成后提交测试进行基线。

自测用例输出不少于整个迭代测试用例的 30% ,自测用例主要由自测用例由开发人员执行

Showcase

开发人员自测完成后将实现的功能演示给测试人员。测试人员可以提出疑问由开发人员解答或者后续提单解决。

转测

转测试是开发把所有需求都开发完成,并所有需求都 showcase 完毕。(即:开发转版本给测试组前进行的系统测试,目的是来评断这个版本功能是否可测。如果预测试不通过,打回,开发组返工,如果通过,测试组开始第一轮系统测试。)迭代出口(转测之前是迭代出口,迭代出口前是迭代期)完成了,需要自己到测试环境进行验证。

转测时间根据版本制定。版本转测试以后,需要对本版本进行总结,版本制作人需要对合入版本期间的异常进行总结,对合入的事件做好记录,对版本延迟的原因要给出负责主题。

(1) 第一轮系统转测试,测试组会执行所有测试用例,发现缺陷提交问题单。第一轮测试结束后,测试组将所有的问题单跟踪提交给开发人员,由他们进行修改。然后对基线后的第二轮进行测试,第二轮会对第一轮中发现的问题进行重点回归。

(2) 在他们修复 bug 期间,测试组会对第一轮系统测试做一个测试评估,出一个测试报告。 还要根据实际情况,对测试组写的测试用例进行修改和增加,开发修改 bug 结束,提交一个新的版本给测试组。首先是回归缺陷,然后会在用例中挑选一些优先级别比较高的用例来进行测试,发现问题继续提交缺陷问题单,直到缺陷率低于用户要求,测试组将进行最后一轮的大版本测试,结束系统测试。具体测试轮次根据版本质量和项目复杂度而决定。

转测试之前,需要规划执行哪些用例,用例的规划结合禅道如下:

测试通过

经过两到三轮或四轮的测试后,直到没发现新的问题。或暂时无法解决,或不紧急的问题,通过上级确认,可以通过。

编写测试报告与验收方案,测试报告和验收方案由测试人员编写,测试报告。

测试报告是把测试的过程和结果写成文档,并对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,同时为软件验收和交付打下基础。

测试模块(每个模块里需要记录测试的开始时间、结束时间、设计多少用例、通过多少、失败多少、有多少 BUG 、遗留多少 BUG 、解决多少 BUG 、追后对这个模块总结一下)

BUG 的统计,根据时间轴来统计 BUG 的数量,例如: XXXX 年 X 月 X 日,发现 BUG 多少,关闭 BUG 多少,剩余 BUG 多少,高级的 BUG 有多少,中级的 BUG 有多少,低级和建议的 BUG 有多少,一直罗列到项目完结

项目总结,汇报一下测试的大致结果。

遗留和风险,该软件还有什么遗留问题,还有什么风险,都要一一说明

测试评估

执行阶段结束了进入测试评估阶段,测试组会出一个总的测试报告对测试组测试的这个过程和版本的质量做一个详细的评估 :

1) 需求需要评审那些?

2) 用例需要评审那些?

3) 计划应该评审那些?

4) 缺陷评审那些?

5) bug 评估?

测试总结文档报告输出

可以让具体的任务负责人对该本次测试中个人负责的模快进行评价,提出相关建议,给出总体的评估。

整体上的 bug 按照不同等级统计出来,用例数量、用例执行数量。

对项目中测试人力资源的统计。(单位:人 / 天)

项目中软硬件资源统计。

提出软件总体的评价。

测试报告

测试报告包括对软件功能的结论,说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。

说明该项目软件的开发是否达到预定目标,是否可以交付使用。总结测试工作的资源消耗数据:如工作人员的水平级别数量、机时消耗等。

记录测试结果与发现及本项目测试工作所得到的各项输出的承载体,根据输入与计划、要求的对比来总结此次项目所获得的经验。

备注

测试团队职责:需求评审、测试计划、测试用例、测试用例评审、测试执行、缺陷报告、缺陷跟踪、测试报告

测试团队交付件:测试计划、测试用例、缺陷报告、测试报告

原文地址:https://www.cnblogs.com/softtester/p/11586081.html

时间: 2024-07-29 13:54:44

测试流程的指定的相关文章

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

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

【转】一般的测试流程和各阶段测试工具简介

一般测试流程:1.需求分析阶段:只要就是对业务的学习,分析需求点.2.测试计划阶段:测试组长就要根据SOW开始编写<测试计划>,其中包括人员,软件硬件资源,测试点,集成顺序,进度安排和风险识别等内容.3.测试设计阶段:测试方案一般由对需求很熟的高资深的测试工程师设计,测试方案要求根据<SRS>上的每个需求点设计出包括需求点简介,测试思路和详细测试方法三部分的方案.<测试方案>编写完成后也需要进行评审.4.测试方案阶段:主要是对测试用例和规程的设计.测试用例是根据<

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

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

移动互联网APP测试流程及测试点(2014版)【转】

移动互联网APP测试流程及测试点(2014版) 来自:http://wenku.baidu.com/link?url=uFn09W0tDsdSqpRw3mQflsASTf-5XK7ccCn0bVBwMqWUpOgI7YkzFh0DnpYlgXnJ2lyiddsUrIDH9qMmi1hE00a24oTz4uQj9M-lSZ_-wRK 1 .APP测试基本流程 1.1流程图 1.2测试周期 测试周期可按项目的开发周期来确定测试时间,一般测试时间为两三周(即15个工作日),根据项目情况以及版本质量可适

互联网App应用程序测试流程及测试总结

近年来随着移动互联网发展迅猛,APP也进行了爆发式的增长,相应的APP的测试检测就摆在每家企业眼前,以下是由国内应用安全检测团队-爱内测(www.ineice.com)的CTO为我们介绍App应用程序测试流程及测试总结: 1. APP测试基本流程 1.1流程图 仍然为测试环境 Pass 1.2测试周期 测试周期可按项目的开发周期来确定测试时间,一般测试时间为两三周(即15个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间.正式测试前先向主管确认项目排期. 1.3测试资源 测试任务开始前

一个项目的整个测试流程

最近一直在进行接口自动化的测试工作,同时对于一个项目的整个测试流程进行了梳理,希望能对你有用~~~ 需求分析: 整体流程图: 需求提取 -> 需求分析 -> 需求评审 -> 更新后的测试需求跟踪xmind 分析流程: 1. 需求提取: 分析依据(包括:需求矩阵.产品交互图.需求说明书) 获取需求的纬度 客户价值 可以为客户带来哪些价值? 可以解决哪些问题? 根据以上问题定位功能是否合理 UI功能 - 展示功能 模块关联-历史模块 新功能模块关联 考虑是否关联?耦合部分是否需要支持? 客户

软件测试的生命周期&amp;测试流程

一.软件的生命周期 二.软件生命周期的阶段 三.软件模型 四.软件测试的基本流程 五.软件开发流程.测试流程梳理 六.C/S与B/S架构 七.对软件测试行业的理解 八.常见笔试面试题 一.软件的生命周期定义:软件生命周期是指软件的产生直到报废的生命周期. 人类整理的第一个软件生命周期:1970年,瀑布型生命周期 二.软件生命周期的阶段1. 问题的定义及规划开发方和需求方共同讨论,主要是确定软件的开发目的及可行性.制定开发计划12. 需求分析对软件需要实现的各个功能进行详细分析,弄清楚用户对软件系

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

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

软件测试中常见测试流程

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