资源描述
测试工作步骤及管理规范
目 录
一、编写目标 3
二、规范说明 3
三、测试团体组成 3
(一)职责 3
(二)角色划分 3
四、工作步骤及规范 4
(一)计划和设计阶段 4
1、召开测试开启会议 4
2、成立测试团体 4
(二)实施测试阶段 4
1、设计测试用例 4
2、实施测试用例 5
3、提交测试汇报 5
4、回归测试 5
(三)总结阶段 5
1、编写测试工作总结 5
2、测试验收 6
3、缺点跟踪 6
(四)培训阶段 6
(五)项目维护阶段 7
五 、测试管理规范 7
(一)缺点类型定义 7
(二)缺点严重等级 7
六、测试标准文档 8
七、绩效考评标准(参考附件绩效考评标准) 8
附件1:测试部绩效考评标准 9
一、编写目标
本文档是测试团体日常工作规范,关键侧重测试工作步骤控制,明确软件工程各阶段测试团体应完成工作。测试技术和策略等问题不在本文档描述范围内。
二、规范说明
1、测试部是独立于项目部一个部门,必需根据测试部工作要求开展工作;
2、测试部工作人员应根据测试需求文档和客观事实实施测试,严格坚持标准;
3、测试部工作时间及反馈应依据项目总体时间和进度来制订,时间安排受技术总监整体掌控;
4、测试验收汇报必需由软件部责任人、项目经理、美工部主管、测试部主管、项目测试责任人五方共同签字,并提交总经理助理一份,和总经理共同进行抽查;
5、测试完成后出具《测试总结汇报》,项目方可正式上线。
三、测试团体组成
(一)职责
测试是软件开发过程中关键组成部分,担负着以下责任:
A、在项目标前景、需求文档确立之前对文档进行测试,从用户体验和测试角度提出自己见解。
B、编写合理测试计划,并和项目整体计划有机地整合在一起。
C、编写覆盖率高测试用例。
D、针对测试需求进行相关测试技术研究。
E、认真仔细地实施测试工作,并提交《测试总结汇报》以供项目组参考。
F、进行缺点跟踪和分析。
(二)角色划分
在人力资源有限情况下,一个团体组员可能会同时负担多个角色。
角色名称
相关关键责任
测试部主管
1)多个项目标管理和跟进
2)安排测试任务,组建测试小组;
3)编写测试计划
4)书写测试总结汇报
5)进行抽查和验收工作
测试责任人
1)编写测试计划、测试用例
2)进行项目标分工安排和工作管理
3)和其它部门沟通,进行bug跟踪
4)项目标整体跟进,包含需求变更
5)书写测试总结汇报
测试实施工程师
实施测试用例,实施测试
四、工作步骤及规范
(一)计划和设计阶段
1、召开测试开启会议
过程关键点
具体说明
输入条件
测试部主管首先了解需求,依据需求制订《测试计划书》
工作内容
开发团体和测试团体查对测试内容,对测试任务和目标达成一致,商讨测试计划初稿可行性,统一项目组目标,分配测试任务,明确此次测试工作关键。
关键工作有:
1)程序部主管或项目经理通知测试部主管,确定项目测试开始和结束时间、项目标规模,最少提前一周。
2)提交给测试部两个文档:(1)经过用户签字确定《需求说明书》
(2)《具体需求设计文档》。
3)由测试部主管撰写《测试计划书》初稿。
4)程序部项目经理讲解功效步骤。
退出标准
明确测试内容和关键,测试方提交《测试计划书》正稿。(参考附件编写测试用例规范)
责任人
程序部责任人、项目经理、测试部主管
2、成立测试团体
在项目组成立同时,项目测试小组也将同时成立。团体成立工作和责任以下:
过程关键点
具体说明
输入条件
项目组成立(参与《项目计划书》评审)
工作内容
为测试小组任命一名此次项目测试责任人,同时确定测试小组组成人选。
(注:依据项目规模决定参与测试情况)
退出标准
测试小组成立
项目责任人
测试责任人
主责任人
测试部主管
(二)实施测试阶段
1、设计测试用例
在《需求说明书》和《具体设计文档》文档确立基础以后,测试组需要针对项目标测试需求编写测试用例,在实际测试中,测试用例将是唯一实施标准。在用例编写过程中,具体任务和责任人以下:
过程关键点
具体说明
输入条件
测试需求明确,测试计划明确
工作内容
依据每一步测试计划编写全部测试用例
退出标准
测试用例需要覆盖全部测试需求
责任人
测试用例设计工程师(可由测试实施工程师或测试责任人兼做)
注:编写完成测试用例,需项目经理审核确定,确保其全方面性;
2、实施测试用例
实施《测试用例》将花费测试组绝大部分时间,这些工作全部是建立在前期很多计划工作基础上。
过程关键点
具体说明
输入条件
测试责任人之前一个工作日定出当日测试计划,确定可用测试用例。
工作内容
测试实施工程师依据测试计划中分配给自己测试任务和提供测试用例,实施对应测试用例,并将统计实施用例结果
退出标准
测试用例中全部任务被实施,结果被统计。
责任人
测试实施工程师
3、提交测试汇报
利用《禅道软件》进行软件质量管理(关键包含bug、测试用例、测试任务、测试结果)等功效。
过程关键点
具体说明
输入条件
测试组完成了预定周期测试任务
工作内容
测试部测试工程师经过《禅道软件》向程序部提交测试汇报,关键内容以下
1)项目测试版本
2)测试人员和时间
3)测试所覆盖缺点,包含:A、测试中全部发觉bug。
B、程序人员处理bug。
4)测试人员验证发觉bug是否被修改。
5)统计项目缺点数量及其状态分类。
6)急待处理问题——写明目前项目需要最先处理问题,能够反复提出。
退出标准
在每轮测试结束以后应立即将符合标准测试汇报发给提交项目组。
责任人
测试部责任人
4、回归测试
在每轮测试结束以后,由测试组重新修改最新版本,进行回归测试。
过程关键点
具体说明
输入条件
在每轮测试中,根据现有测试用例没有新缺点被发觉,测试汇报中全部活动缺点全部被处理。
工作内容
测试组将根据测试计划中对于回归测试策略对项目进行回归测试。
退出标准
回归测试所运行缺点全部经过。
责任人
测试部主管、项目测试责任人
(三)总结阶段
测试工作结束或立即结束时,测试组就要开始着手准备进行总结工作。
1、编写测试工作总结
测试总结工作是在以上工作全部结束以后,它目标是评定此次测试工作,总结经验,使下一次工作做得愈加好。
过程关键点
具体说明
输入条件
测试责任人完成了符合标准《测试总结汇报》,发送给全项目组
工作内容
测试责任人依据测试结果,根据测试总结文档模板编写测试总结,
退出标准
测试责任人完成了符合标准《测试总结汇报》,发送给全测试组。
责任人
测试责任人
2、测试验收
测试验收工作是在以上工作全部结束后,对测试过程,效果进行验收,宣告测试结束。
过程关键点
具体说明
输入条件
测试组完成了全部测试实施工作,测试责任人完成符合标准测试总结文档
工作内容
由测试提议会上约定验收组组员,对本测试进行验收,验收内容包含:
a.测试效果验收——测试是否达成预期目标
b.测试文档验收——测试过程文档是否齐全,可信,符合标准
c.测试评定——从总体对测试质量进行评定
d.测试提议——对此次测试工作指出不足,需要在以后工作中改善地方
e.宣告测试结束——测试验收组组员签字宣告此次测试结束
退出标准
签发《测试总结汇报》
责任人
程序、美工、测试部门主管
3、缺点跟踪
测试验收结束后,要依据【禅道软件】进行缺点整体跟踪,跟踪产品在试运行阶段暴露出来新缺点,和已提交缺点是否再次发生。
过程关键点
具体说明
输入条件
测试组完成了全部测试实施工作,测试验收经过,产品试运行、运行。
工作内容
a.已发觉缺点是否再次发生
b.是否有新发觉在测试中未发觉缺点
c.是否有新发觉在测试中已发觉但未修改缺点
定义:A类:新发觉缺点
B类:已发觉缺点
C类:已发觉未修改缺点
退出标准
缺点跟踪汇报
责任人
测试部主管、项目经理
(四)培训阶段
在项目正式上线之前,将整个项目功效模块操作步骤给用户演示一遍,方便用户在工作中使用;
过程关键点
具体说明
输入条件
依据项目标大小,书写《培训计划》
工作内容
a.培训准备——依据培训规模大小,提前抵达培训现场,熟悉环境;
b.具体实施——①项目<10万:项目责任人进行培训;
②项目>10万:测试主管或商务进行培训;
c. 培训要求——在比较大项目用户培训时,需程序部派一名工程师进行跟进,处理突发性问题;
退出标准
用户签写《项目验收确定单》
责任人
测试责任人、用户责任人
(五)项目维护阶段
项目维护关键包含用户维护和后期跟进测试和安全检测。在十二个月无偿服务范围内前三个月,每个月进行一次安全检测;;
过程关键点
具体说明
输入条件
1)用户咨询操作问题;
2)定时进行网站漏洞安全检测;
工作内容
a.问题处理——对用户提出操作问题,立即给处理;
b.具体统计——对用户所咨询问题,统计到《用户维护统计表》中;
c.安全检测——①内网:安全检测软件;
②外网:用360和baidu漏洞安全检测;
退出标准
1)处理用户所提出操作问题;
2)保留检测统计,包含《检测汇报》和图片
责任人
测试责任人
五 、测试管理规范
(一)缺点类型定义
本规范定义以下四类缺点
缺点类型编号
缺点类型
描述
1
性能问题
不满足系统性能方面需求,如:实施时间,事务处理速率等、因文件大小而造成系统瓦解等
2
功效错误
未实现相关说明书中功效要求
3
界面及版式问题
人机交互界面格式,确定用户输入,功效有效性,页面排版美观度等方面缺点
4
提议
不是缺点,而是从优化等方面来提出愈加好提议
(二)缺点严重等级
定级划分
界定标准
等级一
l 需求书中关键功效未实现;
l 开发程序和需求不符,需和程序部确定以后方可;
l 造成系统瓦解、死机,而且不能经过其它方法实现功效;
l 常规操作造成程序非法退出、死循环、通讯中止或异常,数据破坏丢失或数据库异常、且不能经过其它方法实现功效。
l 出现错误造成测试无法进行,如新增功效不好使,影响修改、删除等;
等级二
l 严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果,而且是常规操作中常常发生或很规操作中不可避免关键问题,如:
l 关键功效基础能实现,但系统不稳定、部分边界条件下操作会造成run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误;
l 关键功效不能按正常操作实现,但可经过其它方法可实现;
l 错误波及面广,影响到其它关键功效正常实现;
l 密码明文显示;
l C/S、B/S模式下,利用用户端一些操作可造成服务端不能继续正常工作。
等级三
程序功效运行基础正常,不过存在部分需求、设计或实现上缺点;次要功效运行不正常,如:
l 次要功效不能正常实现;
l 操作界面错误(包含数据窗口内列名定义、含义不一致);
l 打印内容、格式错误;
l 查询错误,数据错误显示;
l 简单输入限制未放在前台进行控制;
l 删除操作未给出提醒;
l 数据库表中有过多空字段;
l 因错误操作迫使程序中止;
l 找不到规律时好时坏;
l 数据库表、业务规则、缺省值未加完整性等约束条件;
l 经过一段时间运行后,系统性能或响应时间会变慢;
l 关键资料,如密码未加密存放(包含配置文件中密码),或其它存在安全性隐患;
l 硬件或通讯异常发生恢复后,系统不能自动正常继续工作(需要过多人工干预才行);
l 系统兼容性差,和其它支持系统一起工作时轻易犯错,而没有充足理由说明是由支持系统引发;或因为使用了很规技术或第三方组件造成不能使用自动化测试工具进行测试。
等级四
程序在部分显示上不美观,不符适用户习惯,或是部分文字错误,如:
l 界面不规范;
l 辅助说明描述不清楚;
l 输入输出不规范;
l 长操作未给用户提醒(或长操作结束后提醒没有消失);
l 提醒窗口文字未采取行业术语;
l 可输入区域和只读区域没有显著区分标志;
l 界面存在文字错误;
l 在功效实现方法上假如需求中没有明确定义,而没有按常规实现,而且不比常规方法实现优越;( 如用户名第一位用数字或特殊字符)
六、测试标准文档
1、《测试任务说明书》
2、《测试计划》
3、《测试用例》
4、《测试总结汇报》
5、《缺点跟踪汇报》
6、《使用说明书》
7、《用户培训计划》
七、绩效考评标准(参考附件绩效考评标准)
附件1:测试部绩效考评标准
测试工作绩效考评标准
****天鼎现在测试部人员,由网络营销部门人员共同组成,两部门实为同一组人员。为了提升测试部职员工作主动性,确保能够按时保质保量完成测试任务;为了企业能够赢得管理,增加效益。特制订此测试绩效考评标准。
一、测试绩效基础奖金额度
测试部整体绩效额度由项目规模决定,项目标准及奖金额度以下:
项目等级
协议金额
奖金额度
A级
≤6,000元
100元
B级
≤10,000元
300元
C级
≤30,000元
500元
D级
≤50,000元
800元
E级
≤80,000元
1000元
F级
≤100,000元
1200元
G级
≤3,00,000元
3000元
H级
>3,00,000元
3000-5000元
二、测试部奖金分配和处罚制度
1、奖金分配制度
1)测试部奖金分配人员关键包含测试主管、测试人员。测试人员奖金分为A、B、C三个等级,具体参考以下表:
角 色
奖金
等级
评定标准
分成
百分比
备注
测试部
主管
1、负责测试计划编写;
2、测试工作分配、监督和实施
3、测试汇报汇总;
4、测试完成后进行项目总结,并出具验收汇报;
5、和开发部沟通和协调;
6、处理测试过程中碰到问题;
25%
1、剩下30%分成能够奖励测试效率高、质量好,能够使测试部整体计划提前完成测试人员;
2、主管能够依据个人表现分配奖励;
测试组
组员
A级
1、测试出缺点数量多,工作细致而且有独特征;
2、能按时保质保量完成测试工作,工作态度认真主动;
3、测试汇报填写完整,描述清楚,能提出合理修改提议;
4、主动跟踪缺点修改情况;
5、和开发部组员形成良好沟通及配合;
6、重视测试部整体团体合作;
20%
B级
1、测试出缺点数量通常,且多为同类型缺点;
2、能按时完成测试工作,但工作不够认真细致;
3、测试汇报填写较完整,描述较清楚,但不能提出合理修改提议;
4、被动跟踪缺点修改情况;
5、测试部整体团体合作通常;
15%
C级
1、测试出缺点数量较少,同类缺点数量多,工作不细致;
2、能完成工作,但需要加班(不给加班费);
3、测试汇报填写不完整,描述混乱,不能正确表示及描述问题;
4、从不主动跟踪缺点修改情况;
5、极少和开发部组员进行沟通及配合;
6、不重视测试部整体团体合作;
10%
2)假如因为程序部没有进行自测,或项目需求不明确情况下,测试人员在用户验收之前,自主发觉关键性问题,做好了最终保障工作,给奖金300元;
2、处罚制度
角 色
处罚制度
测试组
组员
1、测试部人员没有根据测试主管安排,不能“按时保质保量”完成测试任务,而且对工作有拖延者
1)前两次给警告;
2)累计三次,取消该项目绩效奖;
3)超出3次,依据问题严重程度应给50-100元处罚;
整体
1、用户验收后发觉严重漏洞,扣除测试部整体奖金100%
2、用户验收后发觉通常漏洞,扣除测试部整体奖金50%
3、用户验收后发觉细节漏洞,扣除测试部整体奖金20%
4、依据项目需求,在功效性测试基础上,让不合格项目产品给用户布署上,造成用户埋怨时,该项目标关键测试责任人和测试部主管,应给处罚,每次罚款50-100元;
5、如无特殊原因,测试部没有按时完成测试任务,影响整个项目标上线布署和后期用户培训,给企业造成成本增加时,应给50-100元处罚;
注:1、项目经理需要明确开发周期,合理进行测试时间安排;
2、多个项目同时进行时,会依据项目标紧急和关键程度,调整测试周期;
3、测试周期,不包含程序部对bug修改时间;
三、缺点质量评判标准(也为组员奖金等级评定标准):
漏洞质量
第一类:功效性问题,即未实现需求分析及设计时要求功效要求,功效及链接不能正常使用
1、很严重:在功效说明书和用户需求确定书中所描述主体功效没有实现,10分/个
2、较严重:功效基础实现,在特定情况下造成功效失败,7分/个
3、通常:功效部分失败,对整体功效实现基础不造成影响,4分/个
4、轻微:功效提醒不明确,系统易用性不好,2分/个
第二类:用户体验问题,即功效设计合理性和用户使用便捷程度
1、很严重:关键、关键性功效操作没有明确提醒,易造成重大隐患,7分/个
2、较严重:界面及功效设计提醒语句易误导用户,造成数据丢失等重大问题,5分/个
3、通常:数据关键操作(如删除、添加、保留等)没有提醒,3分/个
4、轻微:系统易用性不好,1分/个
第三类:界面问题,即页面设计美观程度、浏览器兼容性等问题、错别字、错误链接等;
1、通常:UI中出现以下问题(文字内容错误、图片不正确),2分/个
2、轻微:UI中出现以下问题(拼写错误、页面布局不合理、页面中有乱码、风格不一致、字体不一、语言不一致等),1分/个
注意
(也为组员奖金等级评定标准):分数等级越高
四、绩效奖励时间
测试部绩效奖金分两阶段:
1、第一阶段:核实时间,项目验收布署后用户未提疑义,核实测试奖金;
2、第二阶段:款项到帐后当月,测试部提取测试奖金。
注:测试工作随项目开展情况进行,未必每个月全部有。
五、特殊情况说明
1、未面向市场(即未产生直接经济效益)产品及项目(比如省政协网站、****天鼎后台产品等),测试奖金按原项目奖金额度50%提取;
2、测试组组员奖金等级由测试部主管进行综合评定;
六、举例
十一月份进行测试是消防内网,协议金额8万余元, 整体奖金额度属于F级,即部门整体奖金1000元,在整个项目测试过程中,孙老师得到A级奖金,得20%奖金200元;金鑫其次,得15%奖金150元,许婷测试情况通常,得10%奖金100元,穆老师作为测试主管,得25%奖金250元。剩下30%奖金300元,测试主管能够依据个人表现分配奖励;
展开阅读全文