软件测试工作作业流程标准规范.docx
- 文档编号:9657956
- 上传时间:2023-05-20
- 格式:DOCX
- 页数:13
- 大小:65.94KB
软件测试工作作业流程标准规范.docx
《软件测试工作作业流程标准规范.docx》由会员分享,可在线阅读,更多相关《软件测试工作作业流程标准规范.docx(13页珍藏版)》请在冰点文库上搜索。
软件测试工作作业流程标准规范
软件测试工作步骤规范V1.0
xxxxx
4月20日
修订历史统计
版本
日期
修订模块
修订者
说明
V1.0
.5.10
文档新建
技术部
1.目标
经过规范企业测试步骤,确保测试工作规范性和有效性,以验证软件产品质量满足用户需求。
测试作为质量控制一个有效手段,运行测试用例找出软件中潜在多种缺点,经过帮助开发人员修正缺点来提升软件质量,回避软件公布后因为潜在软件缺点和错误造成隐患和降低质量成本。
经过测试管理为产品和过程改善提供可靠数据分析,起到缺点预防作用。
本过程方针:
Ø实施测试策划活动
Ø依据测试策划所要求要求编写测试需求和用例,实施相关测试活动
Ø管理测试活动中发觉产品缺点
2.工作范围
测试人员在软件开发过程中任务:
1)参与评定软件需求,编写测试需求;
2)依据用户需求,编写软件测试用例;
3)在开发人员完成单元测试后,进行模块测试,以期尽早发觉bug;
4)依据软件测试用例,实施集成测试,寻求尽可能多bug;
5)对bug进行追踪和分析,确保bug立即得到修复;
6)对软件性能进行衡量,并进行测试总结,提交软件测试汇报书。
3.工作职责
工作内容
输出文档
提交天天工时申报
OA工时登记
提交每七天工作周报
工作周报
每个月5号前提交上月工作考评评价表
月工作考评评价表
若有加班/请假/调休,在OA上走对应步骤
加班/请假/调休登记
测试组长,测试计划阶段提交测试计划、测试用例
测试计划、测试用例
测试实施阶段提交测试汇报
系统测试汇报
测试评定阶段提交遗留问题分析汇报
测试遗留问题分析汇报
4.测试步骤
●需求分析
需求分析由产品人员制订,细化每一个功效细节,每一个按钮位置,对于稍大或复杂一点需求全部进行建模。
●需求评审
全部参与项目人员进行,开发人员、测试人员、项目责任人。
测试人员提出需求,开发人员考虑功效实现方案和可行性、当然开发负责也是要参与。
测试人员关键是对需求了解提出疑问,方便才能依据需求写用例。
项目责任人是最终对软件质量进行验证人,所以也需求了解需求。
●开发人员编写排期
开发人员需求依据需求功效点进行排期。
然后将该计划转交给测试人员。
●测试计划排期
测试人员依据开发计划,对测试确定具体测试时间,也就是开发功效完成后时间,进行几轮测试等。
然后,把项目标开发和测试计划发送给各部门责任人及参与项目标全部些人员。
●编写测试用例
依据具体需求分档,开始进行用例编写。
●用例评审
在用例进行评审之前,先以邮件形式将用例发送给相关人员,方便她们事先了解用例对哪些功效进行验证和验证细节。
然后,测试人员组进行用例评审,开发人员对用例和实际功效不符合有哪些,产品人员对会经过用例对功效具体实现进行把握等等。
●实施测试
测试人员第一轮测试,发觉问题经过缺点管理工具进行反馈,开发人员对问题进行修复,完成第一轮测试后,需要写测试结论,发到相关人员。
然后进行第二轮测试,第二轮会对第一轮中发觉问题进行关键回归。
●测试经过
经过两到三轮或四轮测试后,直到没发觉新问题,或临时无法处理,或不紧急问题。
经过上级确定,能够经过。
编写测试汇报和验收方案。
验收方案是交由项目责任人进行验证。
在现企业步骤中是将测试和项目责任人分开,测试人员关键关注是功效是否能够正常运行。
项目责任人关注是整个步骤质量和最终用户质量。
5.测试准备
测试计划
依据需求文档和项目计划制订测试计划。
测试计划意在说明各测试阶段任务、人员分配、时间安排、测试关键点、工作规范等。
测试计划在策略和方法方面说明怎样计划、组织和管理测试项目。
测试计划完成后应该在项目组内进行评审。
测试用例
测试用例是为实施测试而向被测试系统提供输入数据、操作或多种环境设置和期望结果一个特定集合。
处理要测什么、怎么测和怎样衡量问题。
依据用户需求分析说明书、概要设计文档和开发具体设计说明书来设计测试用例,发觉需求和设计中问题后,和需求者立即沟通确定。
测试用例设计方法
测试用例设计方法有等价类测试、边界值分析、基于判定表测试、基于因果图测试、基于状态图测试、基于场景测试。
在设计测试用例时常见设计方法有等价类测试、边界值分析两种方法。
测试用例操作步骤
1)在设计编写测试用例时,首先要从测试用例库中选择对应功效测试用例,在原有测试用例基础上依据系统需求文档对测试用例进行修改、更新,评审经过后将使用该测试用例测试被测系统。
2)在测试实施过程中和进行回归测试后,对已设计测试用例进行维护更新。
测试用例选择准则
Ø测试用例代表性:
能够代表多种合理和不合理、正当和非法、边界和越界,和极限输入数据、操作和环境设置等;
Ø测试结果可判定性:
即测试实施结果正确性是可判定或可评定;
Ø测试结果可再现性:
即对一样测试用例,系统实施结果应该是相同。
测试环境
依据需求文档提供内容,和开发部沟通确定测试项目所需软硬件环境,完成对测试项目所需软硬件资源准备工作,使软硬件资源得到满足。
测试数据准备
完成对测试项目基础数据准备操作,包含数据库连接、用户信息、用户角色权限、单位组织等信息和测试相关测试数据。
6.测试实施
测试准入条件
1)不接收无具体需求文档和开发说明项目;
2)需要测试项目最少提前2个工作日提交测试进行需求分析 ;
3)开发人员经过自测经过,最少确保程序能够正常运行;对应功效在正常步骤下是能够正常使用。
项目测试阶段
测试人员依据测试计划和测试用例进行测试活动。
测试通常分为两个阶段:
1)测试实施阶段:
该阶段测试人员测试出bug后将缺点提交至缺点管理库。
2)回归阶段:
开发修改完bug以后,测试进行验证回归。
测试退出标准
1)全部测试用例实施完成;
2)根据系统测试计划完成了系统测试,系统测试功效覆盖率达100%;
3)系统功效和性能满足产品需求规格说明书要求;
4)在系统测试中发觉错误已经得到修改而且各级缺点修复率达成标准;
5)系统测试后不存在1、2类缺点;
6)3类缺点许可存在,不超出总缺点10%。
测试变更
当需求变更,功效改变,测试人员依据变更情况,评定测试变更所需时间,提出变更风险。
如变更情况被项目组经过,测试人员将按上述步骤进行变更测试。
7.缺点管理
BUG管理步骤
BUG状态
●激活
1)新创建bug;
2)已处理但验证未经过bug;
3)已关闭bug重新出现需要再次激活 。
●已处理
开发已经修改完成bug。
●关闭
已验证经过bug或系统工程师确定转为需求bug。
BUG处理方案
●已处理
Bug已经被修改,待测试进行验证。
●设计如此
测试人员了解错误,无需改动,即无效bug。
●反复bug
已经有一样bug,需标明反复bug号。
●无法重现
依据测试写重现步骤,无法重现bug。
●延期处理
确实是bug,但现在不处理,以后处理。
●新增/变更需求
分析确实是存在问题,但需求没有描述清楚,应指派给需求确定,进行需求新增或变更。
BUG优先级
●高
阻止和此亲密相关功效深入测试,需要立即修复。
●中
必需修改,不一定立即修改,必需修改,发版前必需修正。
●低
对系统影响较小,假如时间许可应该修改。
BUG严重等级
●严重(一类)
不能实施正常工作功效或关键功效,因软件原因造成系统死机等,须立即修正致命错误。
通常有以下情况:
1)系统停机(含软件、硬件)或非法退出,且无法经过重启恢复;
2)系统死循环;
3)和数据库连接错误;
4)数据库发生死锁或程序原因造成数据库断连;
5)数据通讯错误或接口不通;
6)关键功效无法正常使用、功效不符适用户需求。
●通常(二类)
影响系统功效或操作,应用模块错误使业务中止无法进行后续操作,关键功效存在严重缺点,影响到产品使用,但不会影响到系统稳定性。
具体基础上可分为:
1)业务步骤错误或不完整;
2)业务数据起源不正确、业务数据紊乱或丢失;
3)业务数据保留不完整或无法保留到数据库;
4)部分功效使用存在问题,不影响业务继续开展,但造成使用障碍;
5)初始化未满足用户要求或初始化错误;
6)功效点能实现,但结果错误;
7)缺乏数据有效性检验或检验不合理;
8)删除操作不给提醒;
9)日志统计信息不正确或应统计而未统计;
10)数据库表、业务规则、缺省值未加完整性等约束条件;
11)在产品申明支持不一样平台下,出现部分通常交易无法使用或错误;
12)系统一些查询、打印等实时性要求不高辅助功效无法正常使用。
●轻微(三类)
使操作者不合理或不方便或操作碰到麻烦,但它不影响实施工作功效或关键功效,次要功效,对产品使用影响不大。
比如:
程序在部分显示上不美观,不符适用户习惯,或是部分文字错误。
具体基础上可分为:
1)缺乏产品使用、帮助文档、系统安装或配置方面需要信息;
2)联机帮助、脱机手册和实际系统不匹配;
3)系统版本说明不正确;
4)提醒说明未采取行业规范语言;
5)显示格式不规范;
6)界面不整齐;
7)软件界面、菜单位置、工具条位置、对应提醒不美观,但不影响使用;
8)辅助说明描述不清楚;
9)提醒窗口描述清楚;
10)输入输出不规范;
11)可输入区域和只读区域没有显著区分标志。
●提议(四类)
BUG书写规范
测试人员BUG提交
1)专题
Ø用一个简短句子描述问题,不要写成一大段
Ø以进入问题模块路径开头,方便项目经理分配任务,和开发人员定位问题
Ø描述问题时要具体、简练、抓住关键点,直接切入正题,不要罗嗦
Ø不要夸大或缩小问题严重程度
2)步骤
Ø用数字编号,一步步描述重现问题全部操作步骤
Ø提供明确再现问题步骤,避免问题被以“不能重现”关掉
Ø设置区域需要具体描述,如:
各设置项值为默认、**值更改为“”,其它设置项值为默认
Ø 尽可能用动词作为开头,描述每个步骤。
如:
打开、点击、设置、选择、插入、双击等
Ø不要在一个步骤中描述不相关多个操作。
假如是相关一系列操作,能够使用“→”来连接描述
Ø根据你写步骤去实施,看问题能否重现
Ø不要在步骤中使用含糊不清缩写词描述
3)实际结果
Ø实际只描述一个问题
Ø一样操作步骤产生多个现象,要在一个缺点汇报中加以描述
Ø不一样操作步骤产生不一样问题,分别报bug
Ø假如有截图,请列出所附图片信息
4)预期结果
Ø不要加入实际结果描述信息
Ø描述要清楚,不要使用含糊不清缩写词描述
Ø假如有截图,请列出所附图片信息
5)备注
Ø避免写成大段落,要写得简单、易读
Ø问题特征
Ø出现问题后处理方法
Ø对终端用户影响情况
Ø假如有必需,列出产生问题配置环境
Ø一样问题也在其它模块发生需写明备注信息
开发人员BUG处理
1)BUG原因
2)BUG修改方法
3)BUG能够在哪个版本上进行验证
4)测试人员验证bug时,需要写明:
验证了什么,在什么版本验证,是否经过,假如不经过需写明原因。
假如在验证目前bug时有新现象产生阻碍了验证此bug,则该bug不能关闭,写明没有验证原因,并为新现象提bug。
8.标准文档
《测试申请单》
《测试计划》
《测试用例》
《测试汇报》
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 工作 作业 流程 标准规范