测试部管理规范样本.docx
- 文档编号:3734174
- 上传时间:2022-11-25
- 格式:DOCX
- 页数:20
- 大小:26.04KB
测试部管理规范样本.docx
《测试部管理规范样本.docx》由会员分享,可在线阅读,更多相关《测试部管理规范样本.docx(20页珍藏版)》请在冰豆网上搜索。
测试部管理规范样本
测试工作流程及管理规范
一・编写目的
错误!
未定义书签。
二.规范说明
错误!
未定义书签。
错误!
未定义书签。
三、测试团队构成
(一)职责
错误!
未定义书签。
(二)角色划分
错误!
未定义书签。
四.工作流程及规范
错误!
未定义书签。
(-)计划与设计阶段
错误!
未定义书签。
1、召幵测试启动会议
错误!
未定义书签。
2、成立测试团队
错误!
未定义书签。
(二)实施测试阶段
错误!
未定义书签。
1、设计测试用例
错误!
未定义书签。
2、实施测试用例
错误!
未定义书签。
3、提交测试报告
错误!
未定义书签。
4、回归测试
错误!
未定义书签。
(三)总结阶段
错误!
未定义书签。
1、编写测试工作总结
错误!
未定义书签。
2、测试验收
错误1未定义书签。
3、缺陷跟踪
错误!
未定义书签。
(四)培训阶段
错误!
未定义书签。
错误!
未定义书签。
错误!
未定义书签。
(五)项目维护阶段
5.测试管理规范
(-)缺陷类型定义错误!
未定义书签。
(-)缺陷严重等级错误!
未定义书签。
六、测试标准文档错误!
未定义书签。
7.绩效考核标准(参照附件绩效考核标准)错误!
未定义书签。
附件1:
测试部绩效考核标准错误!
未定义书签。
一、编写目的
本文档是测试团队的日常工作规范,主要侧重测试工作流程的控制,明确软件工程的各阶段测试团队应完成的工作。
测试技术和策略等冋题不在本文档描述范围内。
2.规范说明
1、测试部是独立于项目部的一个部门,必须按照测试部工作要求开展工作;
2、测试部工作人员应按照测试需求文档以及客观事实执行测试,严格坚持原则;
3、测试部工作时间及反馈应根据项目总体时间和进度来制定,时间安排受技术总监整体掌控;
4、测试验收报告必须由软件部负责人、项目经理、美工部主管、测试部主管、项目测试负责人五方共同签字,并提交总经理助理一份,与总经理共同逬行抽查;
5、测试完成后出具《测试总结报告》,项目方可正式上线。
3.测试团队构成
(—)职责
测试是软件开发过程中的重要组成部分,肩负着如下责任:
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
退出标准
测试小组成立
项目贵任人
測试负贵人
主负贵人
測试部主管
(二)实施测试阶段
1、设计测试用例
在《需求说明书》和《详细设计文档》文档确立基础以后,测试组需要针对项目的测试需求编写测试用例,在实际的测试中,测试用例将是唯一实施标准。
在用例的编写过程中,具体的任务和责任人如下:
过程要点
详细说明
输入条件
测试需求明确,测试计划明确
工作內容
根据每一步测试计划编写全部的测试用例
退出标准
测试用例需要覆義所有的测试需求
贵任人
测试用例诛计工程师(可由测试实施工程师或测试负责人兼做)注:
编写完成的测试用例,需项目经理审核确认,保证其全面性;
2、实施测试用例
实施《测试用例》将花费测试组绝大部分时间,这些工作都是建立在前期很多计划工作的基础上。
过程要点
详细说明
输入条件
测试负责人之前一个工作日定出当日的测试计划,确定可用的测试用例。
工作內容
测试实施工程师根据测试计划中分配给自己的测试任务和提供的测试用例,实施相应的测试用例,并将记录实施用例的结果
退出标准
测试用例中的所有任务被执行,结杲被记录。
贵任人
测试实施工程师
3.提交测试报告
利用《禅道软件》进行软件质量管理(主要包括bug、测试用例、
测试任务、测试结果)等功能。
过程要点
详细说明
输入条件
测试组完成了预定周期的测试任务
工作内容
测试部測试工程师经过《禅道软件》向程序部提交测试报告,主要内容如下
1)项目測试的版本
2)测试的人员和时间
3)测试所覆羔的缺陷,包括:
测试中所有发现的bug。
B、程序人员处理的bug。
4)测试人员验证发现bug是否被修改。
5)统计项目缺陷的數量及其状态分类。
6)急待解决的问題一写明当前项目需要晟先解决的问题,能够重复提出。
退出标准
在每轮測试结束之后应尽快将符合标准的测试报告发给提交项目组。
责任人
测试部负贵人
4、回归测试
在每轮测试结束之后,由测试组重新修改最新版本,进行回归测
试。
过程要点
详细说明
输入条件
在每轮测试中,按照现有的测试用例没有新的缺陷破发现,测试报告中全部的活动缺附都被解决。
工作内容
測试组将按照测试计划中对于回归测试的策略对项目进行回归测试。
退出标准
回归测试所运行的缺陷全部经过。
贵任人
测试部主管.项目测试负贵人
(三)总结阶段
测试工作结束或即将结束时,测试组就要开始着手准备进行总结的工作。
1、编写测试工作总结
测试总结工作是在以上的工作全部结束以后,它的目的是评估本次测试工作,总结经验,使下一次的工作做得更好。
1输入条件
测试负责人完成了符合标准的《测试总结报告》,发送给全项目组
工作内容
测试负责人根据测试的结果,按照测试总结的文档模板编写测试总结,
退出标准
测试负责人完成了符合标准的《测试总结报告》,发送给全测试组。
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和XX涌洞安全检测;
退出标准
1)解决客户所提出的操作问題;
2)保存检测记录,包括《检测报告》和图片
责任人
测试负责人
5.测试管理规范
(-)缺陷类型定义
本规范定义以下四类缺陷
缺陷类型编号
缺陷类型
描述
1
性能问题
不满足系统性能方而的需求,如:
执行时间,事务处理速率等、因文件的大小而导致系统崩溃等
2
功能错误
来实现相关说明书中的功能要求
3
界而71版式间题
人机交互界面格式,确认用户输入,功能有效性,页面排版美观度等方而的缺陷
4|建议不是缺陷,而爱从优化等方而来提出更好的建汉
(二)缺陷严重等级
定级划分
界定标准
等级一
•需求书中的重要功能未实现;
•开发的程序与需求不符的,需与程序部确认之后方可;
•造成系统崩溃、死机,而且不能经过其它方法实现功能;
•常规操作造成程序非法退出、死循环、通讯中断或异常,数据破坏丢失或数据库异常、且不能经过其它方法实现功能的。
•出现的错误导致测试无法进行的,如新增功能不好使,影响修改、删除等;
等级二
•严重错误一般使系统不稳定、不安全、或破坏数据、或产生错误结果,而旦是常规操作中经常发生或非常规操作中不可避免的主要问题,如:
•重要功能基本能实现,但系统不稳定、一些边界条件下操作会导致run-timeerror.文件操作异常、通讯异常、数据丢失或破坏等错误;
•重要功能不能按正常操作实现,但可经过其它方法可实现;
•错误的波及面广,影响到其它重要功能正常实现;
•密码明文显示;
•C/S、B/S模式下,利用客户端某些操作可造成服务端不能继续正常工作的。
等级三
程序的功能运行基本正常,可是存在一些需求、设计或实现上的缺陷;次要功能运行不正常,女口:
•次要功能不能正常实现;
•操作界面错误(包括数据窗口内列名定义、含义不一致);
•打印内容、格式错误;
•查询错误,数据错误显示;
•简单的输入限制未放在前台进行控制;
•删除操作未给出提示;
•数据库表中有过多的空字段;
•因错误操作迫使程序中断;
•找不到规律的时好时坏;
•数据库的表、业务规则、缺省值未加完整性等约束条件;
•经过一段时间运行后,系统性能或响应时间会变慢;
•重要资料,如密码未加密存放(包括配萱文件中的密码)<或其它存在安全性隐恚的;
•硬件或通讯异常发生恢复后,系统不能自动正常继续工作(需要过多的人工干预才行);
•系统兼容生差,与其它支持系统一起工作时容易出错,而没有充分理由说明是由支持系统引起的;或者由于使用了非常规技术或第三方组件造成不能使用自动化测试工具进行测试的。
等级四
程序在一此显示上不美观,不符合用户习惯,或者是一此文字的错误.女口:
•界面不规范;
•辅助说明描述不清楚;
•输入输出不规范;
•长操作未给用户提示(或长操作结束后提示没有消失);
•提示窗口文字未采用行业术语;
•可输入区域和只读区域没有明显的区分标志;
•界啬存在文字错误;
•在功能实现方式上如果需求中没有明确定义,而没有按常规实现,而且不比常规方式实现优越的;(如用户名第一位用数字或特殊字符)
6.测试标准文档
1、《测试任务说明书》
2、《测试计划》
3、《测试用例》
4、《测试总结报告》
5、《缺陷跟踪报告》
6、《使用说明书》
7、《客户培训计划》
7.绩效考核标准(参照附件绩效考核标准)
附件1:
测试部绩效考核标准
测试工作绩效考核标准
糾**天鼎当前的测试部人员,由网络营销部门人员共同组成,两部门实为同一组人员。
为了提升测试部员工的工作积极性,确保能够按时保质保量的完成测试任务;为了企业能够赢得管理,增加效益。
特制定此测试绩效考核标准。
一、测试绩效的基本奖金额度
测试部的整体绩效额度由项目规模决定,项目标准及奖金额度如下:
项目级别
合同金额
奖金额度
A级
W6,000元
100元
B级
W10.000元
300元
C级
W30.000元
500元
D级
W50.000元
800元
E级
W80.000元
1000元
F级
W100,000元
1200元
G级
W3,00.000元
3000元
H级
>3,00.000元
3000-5000元
二、测试部奖金分配与处罚制度
1.奖金分配制度
1)测试部奖金分配人员主要包括测试主管、测试人员。
测试人员奖金分为A、B、C三个等级,具体参考如下表:
角色
奖金
级别
评定标准
提成
比例
备注
测试部
主管
1.负责测试il•划的編写;
2.测试工作的分配.监督和执行
3.测试报告汇总;
4.测试完成后进行项目总结,并出具验收报告;
5.与开发部的沟通和协调:
6.解决测试过程中遇到的问题;
25%
1.剩余的30%提成能够奖励测试效率商、质量好,能够使测试部整体计划提前完成的测试人员;
2、主管能够根据个人表现分配奖励;
测试组
成员
A级
1.测试出的缺陷数址多•11作细致而且有独特性:
2.能按时保质保量完成测试工作,工作态度认真积极:
3.测试报告填写完整,描述洁陋.能提出合理修改建议:
4.主动跟踪缺陷修改情况;
5.与开发部成员形成良好的沟通及配合;
6.注重测试部整体团队合作;
20%
B级
1、测试出的缺陷数量一般,且多为同类型缺陷:
2、能按时完成测试匸作,但丄作不够认真细致;
3、测试报告填写较完整.描述校清晰.但不能提出合理修改建议:
4、被动跟踪缺陷修改情况;
5、测试部整体团队合作一般;
15%
C级
1.测试出的缺陷数虽较少•同类缺陷数量女,工作不细致;
2.能完成工作,但需要加班的(不给加班费);
3.测试报告填写不完整,描述混乱,不能准确表示及描述问题:
4.从不主动跟踪缺陷修改情况;
5.很少与开发部成员进行沟通及配合;
6.不注重测试部整休团队合作:
10%
2)如果由于程序部没有进行自测,或者项目需求不明确的情况下,测试
人员在客户验收之前,自主发现关键性冋题,做好了最后的保障工作,给予奖
金300元;
2、处罚制度
角色
处罚制度
测试组
成员
K测试部人员没有按照测试主管安排.不能"按时保质保址”的完成测试任务,而且对丄作有拖延者
1)前两次给予警告;
2)累计三次,取消该项目绩效奖;
3)超过3况根据问题严重程度应给予50・100元处罚;
整体
K客户验收后发现严重漏洞,扣除测试部整体奖金100%
2.客户验收后发现一般漏洞,扣除测试部整体奖金50%
3、客户验收后发现细节漏洞,扣除测试部整体奖金20%
4、依据项目需求,在功能性测试的基础上,让不合格的项目产品给客户部署上,造成客户抱怨时.该项目的主要测试负责人和测试部主管,应给予处罚,每次罚款50J00元:
5、如无特殊原园.测试部没有按时完成测试任务,影响整个项目的上线部署和后期的客户培训,给公司造成成本増加时.应给予50・100元处罚;
注:
1、项目经理需要明确开发周期.合理的进行测试时间的安排;
2、多个项目同时进行时,会根据项目的紧急和重要程度,调整测试周期;
3、测试周期,不包括程序部对bug的修改时间;
三、缺陷质量评判标准(也为组员奖金级别评定标准):
四、绩效奖励时间
测试部绩效奖金分两阶段:
1、第一阶段:
核算时间,项目验收部署后客户未提疑义,核算测试奖金;
2、第二阶段:
款项到帐后当月,测试部提取测试奖金。
注:
测试工作随项目开展情况逬行,未必每月都有。
五、特殊情况说明
1、未面向市场(即未产生直接经济效益)的产品及项目(例如省政协网站.*糾*天鼎的后台产品等),测试奖金按原项目奖金额度的50%提取;
2、测试组成员奖金级别由测试部主管逬行综合评定;
漏洞
质量
第一类:
功能性问题,即未实现需求分析及设计时要求的功能要求.功能及链接不能正常使用
1、非常严重:
在功能说明书和客户需求确认书中所描述的主体功能没有实现,10分/个
2、较严重:
功能基木实现.在特定的情况下导致功能失败・7分/个
3、一般:
功能部分失败.对整体功能的实现基木不造成影响・4分/个
4、轻微:
功能提示不明确•系统易用性不好.2分/个
第二类:
用户体验问題,即功能设讣合理性以及用户使用便捷程度
K非常严重:
重要、关键性功能操作没有明确提示,易造成重大隐患,7分/个
2、较严重:
界面及功能设il•提示语句易误导用户,造成数据丢失等重大问题.5分/个
3、一般:
数据的重要操作(如删除.添加.保存等)没有提示,3分/个
4、轻微:
系统易用性不好.1分/个
第三类:
界面问題,即页而设讣的美观程度、浏览器兼容性等问題.错别字、错误链接等;
1、一般:
UI中出现以下问题(文字内容错误、图片不正确),2分/个
2、轻微:
UI中出现以下问题(拼写错误、页面布局不合理、页面中有乱码、风格不一致.字体不一、语言不一致等)、1分/个
注意
(也为组员奖金级别评定标准):
分数级别越高
六、举例
十一月份进行测试的是消防内网,合同金额8万余元,整体奖金额度属于F级,即部门整体奖金1000元,在整个项目测试过程中,孙老师得到A级奖金,得20%的奖金200元;金鑫其次,得15%奖金150元,许婷测试情况一般,得10%的奖金100元,穆老师作为测试主管,得25%奖金250元。
剩余30%奖金300元,测试主管能够根据个人表现分配奖励;
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 管理 规范 样本
![提示](https://static.bdocx.com/images/bang_tan.gif)