测试部测试管理规范测试管理样例.docx
- 文档编号:13317303
- 上传时间:2023-06-13
- 格式:DOCX
- 页数:35
- 大小:1.53MB
测试部测试管理规范测试管理样例.docx
《测试部测试管理规范测试管理样例.docx》由会员分享,可在线阅读,更多相关《测试部测试管理规范测试管理样例.docx(35页珍藏版)》请在冰点文库上搜索。
测试部测试管理规范测试管理样例
软件质量管理体系
测试部管理规范
作者
王家明
日期
2018-5-8
审核
版本
V1.10
版本号
状态
内容摘要
撰写日期
撰写人
审查人
1.00
新建
初稿完成
2018-5-8
王家明
1.00
修订
初稿修订
2018-5-10
王家明
1.01
修订
初稿修订
2018-8-3
王家明
1.02
修订
细化细节
2018-8-20
王家明
1.03
修订
细节修改
2018-12-28
王家明
1.10
修订
增加用例评审要求、需求分析、测试环节细化与调整
2019-02-13
王家明
2018-05-08
目录
软件质量管理体系1
测试部管理规范1
1概述4
1.1目的4
1.2角色职责4
1.3软件开发过程管理5
2软件测试规程6
2.1测试活动对应阶段6
2.2测试活动开展办法7
2.3项目启动7
2.3.1新产品开发7
2.3.2二次开发8
2.4需求评审(测试)8
2.5测试需求分析9
2.6测试计划10
2.7用例设计10
2.8测试用例评审12
2.9环境部署13
2.10系统测试(测试执行)13
2.11性能测试14
2.12补充测试14
2.13测试度量14
2.14测试发布(验收)14
2.15测试维护15
2.16归档15
3缺陷管理规范16
3.1BUG生命周期流转16
3.2缺陷严重级别定义16
3.3写规范(新建)18
3.3.1精炼20
3.3.2正确20
3.3.3中立21
3.3.4准确21
3.3.5普遍性21
3.3.6可再现21
3.3.7证据22
3.4缺陷类型定义23
3.5缺陷解决方案定义24
3.6缺陷修改(修复)24
3.7缺陷回归(关闭)25
3.8缺陷收敛(系统验收)26
4版本转测试规范(此处同时对研发要求)27
4.1版本转测试要求27
4.2统一SVN权限控制(New)28
4.3已测试版本发布28
4.4转测试版本号管理29
4.5测试版本发布实施29
5项目管理工具管理30
5.1禅道30
5.2知识共享-Wiki30
5.3项目管理-文档(SVN)30
5.4项目管理-代码(SVN)30
6测试部管理31
6.1服务器及资源管理31
6.2人员信息31
6.3项目测试负责人【待定】31
6.4计划、总结、沟通、协调32
6.4.1计划、总结32
6.4.2沟通、协调32
1概述
1.1目的
✓使软件系统测试活动是规范和有计划的。
✓及时对软件产品进行系统测试,验证系统是否满足需求规格的定义,找出与需求规格不相符合或与之矛盾的地方。
✓测试中发现的缺陷保证被记录、跟踪直到关闭;对项目的缺陷数据进行量化的分析。
✓规范测试部日常工作,明确软件开发过程中测试活动开展方式和方法。
本规范适用于本司所有软件产品。
1.2角色职责
测试工程师应遵守公司的各种规章制度。
测试是软件开发过程中的重要组成部分,应遵循现有的开发制度,完成各阶段中相应的测试活动开展,并完成相关测试输出(含文档)。
角色
职责
测试经理
部门管理、测试组织、资源协调、质量监控
项目经理
提供项目测试的相关资料(需求、计划、详设等)
转测试系统演示
缺陷分配至责任人
缺陷修复跟踪
版本迭代跟踪
填写版本转测试任务单
测试主管/组长
项目测试人员调配、工作分配、任务完成情况跟踪,及时反馈进度和困难
编写项目测试计划、方案、用例、操作手册等测试文档
组织测试文档评审修订
编写版本测试总结、系统测试总结报告,
抽查组内成员的工作质量,指导改进
跨部门沟通协调
反馈、参与改进部门流程优化意见
测试工程师
根据需求/原型,完成测试计划、测试用例、测试设计
执行系统测试,填写BUG,反馈测试结果
编写系统测试报告
BUG统计、跟踪及回归测试
测试工作总结与计划
协助开发人员定位BUG
参与改进部门流程优化过程
实施工程师
根据特殊项目需求,协助执行商定分配的一些测试任务
登记发现的BUG到禅道
登记需求到禅道对应项目
更新发布正式系统,检查版本发布的正确性并反馈
开发工程师
分析并修复发现的BUG
根据项目经理安排开展相关工作。
1.3软件开发过程管理
2软件测试规程
2.1测试活动对应阶段
2.2测试活动开展办法
2.3项目启动
测试经理根据项目情况,指定项目测试负责人,参加项目启动会。
确定项目关键时间点:
需求提交时间、转测试开始时间、测试验收时间,项目负责人,测试负责人。
明确项目的测试人力资源投入(初步按1:
4比例进行估算)。
根据项目经理提出,确定项目章程。
未经立项开展的测试活动,非经测试经理确认批准,相关测试任务予以拒绝执行。
2.3.1新产品开发
由项目经理组织并介绍项目情况,测试经理和项目测试组长确定测试人选,并通知相关人员。
由项目经理/测试经理在禅道上创建项目和设置团队成员。
2.3.2二次开发
开发管理过程,详见《开发部制度2018(rev6).pdf》。
2.4需求评审(测试)
由项目经理通知QA发送评审邮件召集项目成员进行需求评审。
测试人员需要提前熟悉需求,并对需求描述不清和不合理的地方提出疑问。
需求评审参与人员应包括:
用户代表(如实施)、项目经理、系统工程师、相关开发人员、测试人员、维护人员等。
需求评审应遵循如下方法:
✓完整性:
每一项需求都必须将所要实现的功能描述清楚,以使开发人员获得设计和实现这些功能所需的所有必要信息。
✓正确性:
每一项需求都必须准确地陈述其要开发的功能。
✓一致性:
一致性是指与其它软件需求或相关标准规定不相矛盾。
✓可行性:
每一项需求都必须是在已知系统和环境的限制范围内可以实施的。
✓无二义性:
对所有需求说明都只能有一个明确统一的解释,由于自然语言极易导致二义性,所以尽量把每项需求用简洁明了的语言表达出来。
✓健壮性:
需求的说明中是否对可能出现的异常进行了分析,并且对这些异常进行了容错处理。
✓必要性:
每项需求的制定都是必要的且能够追溯的。
✓可测试性:
每项需求都能通过设计测试用例或其它的验证方法来进行测试。
✓可修改性:
每项需求只应在软件需求说明书中出现一次,这样更改时易于保持一致性。
✓可跟踪性:
应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接,这种可跟踪性要求每项需求以一种结构化的方式编写并单独标明。
组织需求评审时,测试人员可以打印下表进行现场确认,是否满足测试。
序号
主要检查项
符合
备注
1
所有模块是否明确定义了前置条件。
2
所有功能是否都明确定义了输入、输出。
3
是否明确定义了操作角色及操作权限。
4
需求的描述是否正确、无二义性。
5
需求的描述是否前后一致、彼此不冲突。
6
是否清楚描述了系统中与其它子系统或模块的相关接口。
7
性能需求等(其它类型的需求)描述是否明确,是否可验证。
8
需求描述的详细程度是否可进行编写测试用例。
详见《测试评审需求检查单.docx》
无法理解的需求,项目经理需组织人员进行修订,直至可阅读为止。
2.5测试需求分析
可根据需求规格说明书,提炼需求信息,形成测试需求分析要点(思维导图)
测试需求分析的目的是明确测试对象(测试项),活动开展应在测试方案与测试用例设计之前。
方法思路:
✓明确需求的测试范围,即确定需求中包括了多少功能点;
✓明确功能的业务处理过程,对每一个功能点的输入、处理逻辑和输出进行提取;
✓根据用户需求,明确其在特定场景下实际使用时的流程及操作步骤,以明确测试场景。
测试需求分析过程是对功能点列表中列出的每一条功能需求细化和分解的过程:
1.通过分析每条功能需求描述中的输入、输出、处理、限制与约束等,给出对应的验证内容;
2.通过分析各个功能模块之间的业务顺序,以及各个功能模块之间对传递的信息和数据存在的功能交互,给出对应的验证内容;
3.经过分解获得的测试需求必须能够充分覆盖软件需求的各种特征,且每个需求都可以进行单独测试,以保证测试需求的完整性;
4.每个测试需求能够使用数量相当的测试用例来实现,即尽量保证测试案例的粒度是均匀的。
部门精简:
识别测试项,形成思维导图,注意功能交互和用户场景。
需求分析方法:
详见《软件测试基础.pptx》
2.6测试计划
根据开发计划、开发进度计划、测试需求要求(人力、含软硬件资源)等,完成项目测试计划输出。
测试计划穿插在整个软件项目过程中,出现偏差时应及时提出风险;特殊资源需求需提前申请。
计划模板:
详见《JZ-QC-001A[项目名称]-测试计划-V1.1.docx》
2.7用例设计
用例设计出来是用来执行的!
测试用例设计,应分类型进行编写,便于各项目间用例的复用。
系统测试用例包括:
模块功能用例、通用测试用例、业务流程与用户场景测试用例、通用检查项四部分,其中通用性测试用例应作为系统测试检查项进行。
短期项目因时间关系,可使用思维导图方式提炼测试项和关键测试用例,后期再补充用例。
(需经测试经理、项目经理确认,是否客户必需)
立项项目,应有计划的组织人员完成测试用例设计。
✓模块功能测试用例,应根据项目需求描述特征项进行编写;一般地,在编写用例时,测试用例结构应与特征项保持一致,并逐条描述。
✓通用测试用例,应包括系统级的通用功能;如新增、修改、删除、查询等系统常用功能,以及某项目常用的功能;
✓业务流程与用户场景测试用例,也即常说的业务流程与场景设计用例,关联多个模块的业务流程;通过业务说明、流程路径、相关说明完整描述业务流程的完整过程以及关注点,特别注意数据从哪里来,到哪里去的关系检查;注意用户常用场景测试。
✓通用检查项,主要包括页面风格等通用功能、易用性、合理性等检查项,包括文字、字段、标点、图表、按钮、翻页分页、提示描述等。
测试用例:
详见《JZ-QC-003A[项目名称]-测试用例模板实例-V1.1.xlsx》
2.8测试用例评审
测试用例评审分两种形式:
1.是文件评审,对描述不清、错误、缺漏的标识和备注
2.是会议组织,对用例进行从上到下,从左到右的全文评审;
目的:
1.减少测试人员执行的无效工作(无效用例、无效BUG);
2.澄清需求,避免三方理解不一致;
3.测试质量标准与项目要求达成一致;
内容:
1.使用测试部的用例编写规范及模板
2.小项目可以使用XMind做导图
时间:
一般要求在半小时到1小时之间,要求参与人员提前检视;如果功能点太多,应先划分优先级或分次进行;
方式:
由用例编写人员讲解用例设计方法、思路、测试点、注意事项;
评审要点:
1.是否覆盖需求描述(矩阵跟踪),遵循软件需求规定。
2.描述是否清晰,是否存在二义性。
3.用例是否可执行,如用例是否焦聚验证点,设计是否冗余,步骤是否反复执行等;
4.用例格式自评:
结构安排、优先级安排、复用性等
5.评审过程中超过5分钟无法确定的问题,记录留会后跟踪确认。
6.评审后,编写人员根据评审意见进行修正补全并发布改后用例进行确认;未确定事项需继续跟进至解决;
一般来说,评审在用例设计完成后进行,项目开展测试之前进行,当项目时间不足时,可裁减为核心业务评审和业务流程评审。
用例评审人员:
项目经理、开发经理、需求分析人员、架构师、对应开发人员和测试人员,QA,及其他项目标明参加的相关人员如客户;其中需求人员、对应开发负责人、相关测试人员必须参加。
2.9环境部署
1.测试组申请资产环境资源,维护项目系统测试环境。
2.测试组测试验证开发部提交的环境部署文档,并进行补充。
(标准:
实施适用)
2.10系统测试(测试执行)
1.根据测试计划及转测试任务单,开展系统测试。
(首测需提供安装配置手册)
2.根据测试用例,执行系统测试,填写缺陷到禅道项目管理系统。
3.根据变更需求,补充测试用例设计,验证需求变更,反馈测试结果。
4.执行回归测试,迭代版本测试,直至缺陷收敛、功能稳定。
5.根据领导意见与安排,开展专项/专题测试,反馈测试结果。
6.项目首次转测试,应提出系统演示;重要模块重构实现,应提出系统演示。
无需系统演示,必须提出并测试负责人同意后方可。
7.转测试版本必须进行冒烟测试,主业务流程不通,应及时反馈情况给项目经理和测试经理,并停止测试;下次测试提交需提请演示通过;多次出现冒烟测试不通过,讲收集信息反馈给领导。
8.版本转测试,项目经理提交《JZ-QC-009A[项目名称]-转测试申请单-V1.1.docx》
9.转测试版本,输出版本测试报告《JZ-QC-004A[项目名称]-版本测试报告-V1.1.docx》
10.系统测试完结,输出系统测试报告《JZ-QC-005A[项目名称]-系统测试报告-V1.1.docx》《JZ-QC-007A[项目名称]-出厂测试报告-V1.1.doc》(可选)
11.测试完成,编写用户操作手册《JZ-QC-006A-[项目名称]-用户手册模板实例-V1.1.doc》
2.11性能测试
根据系统性能要求,完成测试场景分析、测试场景设计、测试脚本开发调试、测试数据收集、测试分析、系统调优验证、系统指标数据收集。
性能测试完结,输出性能测试报告。
性能测试要求:
1.清楚你测试的系统网络拓扑图,识别关键性能点(如登录方式、组网方式、备份方式等等)
2.清楚你需测试的业务场景,明确测试指标,测试数据收集。
3.记录测试工具与配置、测试脚本、参数化、测试原始数据及数据分析
4.测试报告与性能评估
5.调优(协助开发完成性能调优及测试验证)
2.12补充测试
根据项目需求,针对测试过程薄弱点、BUG集中暴发模块进行补充测试。
2.13测试度量
1.测试有效性
2.测试充分性
3.软件产品质量
4.分析与改进测试过程
测试度量元素:
测试时间、测试工作量、缺陷数量、测试用例数
相关参考测试时间偏差、测试工作量偏差、功能点覆盖率、测试用例通过率、缺陷密度
2.14测试发布(验收)
1.满足条件发布:
按照金政研发体系质量管理规范的程序发布要求。
2.不满足条件版本发布:
根据领导建议,协商发布版本。
3.金政研发体系质量管理规范:
4.测试组组织测试发布验收,并邀请项目经理、开发经理、核心开发人员、QA、跨组测试人员进行成果验收展示。
2.15测试维护
根据项目特性,设定项目上线维护人员跟踪处理实施反馈问题,并进行汇总反馈给组长、经理、项目经理。
根据线上反馈问题,分析出现问题的类型和规避方法,组织安排开展补充测试。
2.16归档
所有测试评审通过的文档+程序,应及时邮件发送测试经理、测试组长、QA进行归档。
注:
后续SVN目录创建后,直接上传SVN归档。
3缺陷管理规范
3.1BUG生命周期流转
3.2缺陷严重级别定义
严重级别
缺陷严重程度描述
1-致命
完全不能满足系统要求,基本功能未实现,系统崩溃或挂起等原因导致系统不能继续运行。
例如:
1.由于程序所引起的死机或非法退出、数据丢失
2.死循环
3.数据库发生死锁
4.因错误操作导致的程序中断
5.基本功能错误(程序实现与需求不符)
6.与数据库连接中断或错误
7.数据通讯错误等
8.程序接口错误、数据流错误
9.主业务流程实现不正确
2-严重
严重影响基本功能的实现,系统不稳定,数据破坏,产生错误结果或部分功能无法执行,且常规操作中经常发生或非常规操作中不可避免的主要问题。
例如:
10.因错误操作迫使程序中断
11.系统可被执行,但操作功能无法执行(含指令)
12.单项操作功能可被执行,但在此功能中某此功能(含指令参数的使用)无法被执行(对软件系统非致命的)
13.对某些功能项的某些项目(选项)使用无效(对系统非致命的)
14.分支业务流程实现不正确
15.功能实现不完整,如删除数据时没有考虑数据关联性
16.功能实现不正确,如:
在系统实现的界面某些可接受输入的控件点击后无效,对数据库的操作不能正确实现等
17.报表格式或打印内容错误(行列不完整、数据显示不在所对应的行列等导致数据显示结果不正确的错误)
18.关键系统性能指标不达标
3-一般
系统性能或响应时间变慢,产生错误的中间结果但不影响最终结果等影响有限的问题。
例如:
19.操作界面错误(包含数据窗口内列名定义、含义是否一致)
20.打印内容、格式错误(只影响报表的格式或外观,不影响数据显示结果的错误)
21.简单的输入限制未放在前台进行控制
22.删除操作未给出提示
23.已被捕捉的系统崩溃,但不影响继续操作
24.系统正确性未受到影响,但系统性能和响应时间受到影响
25.不能定位焦点或定位有误,影响系统功能实现
26.显示信息不正确,但输入正确
27.增、删、改功能操作,在本系统界面不能实现,但在另一界面可以补充实现的
4-轻微
使操作者、直接用户不方便或遇到麻烦,但不影响执行系统功能或系统业务功能。
界面拼写错误,系统中需要完善的问题。
例如:
28.界面不规范,风格布局不统一
29.辅助说明描述不清楚
30.输入输出描述不规范
31.长时间操作或等待,未弹出系统提示框
32.系统提示框文字未采用行业术语
33.可输入区域与系统返填区域没有明显的区分标志
34.必填项与非必填项未加以区别
35.滚动条操作无效
36.键盘支持性不好,如:
在可输入多行的字段中,不支持回车换行;对相同字段,在不同界面支持不同的快捷方式
37.光标跳转设置不好,鼠标(光标)定位错误
38.界面中的文字、系统提示框的文字等出现错别字,标点符号使用不当
39.中文系统出现英文字段名
5-建议
合理化建议性问题(此类建议不列入缺陷)
40.不在预定范围的之内,但是从使用者来看是需要完善的建议。
41.基本不影响系统的运行和功能的实现。
但是与标准、规范和定义不一致。
42.基于用户操作习惯及期望的一些操作或功能实现。
附:
没有特别设计说明,对界面规范方面明确统一:
文字左对齐,数字右对齐,数字千分号间隔,并要有明确单位或者表头标明。
【此处为研发部要求】
3.3写规范(新建)
1.新建BUG样例
2.BUG描述规范
●缺陷摘要需要以简洁的语言描述表达准确的信息,用准确表达意义的缩略语进行描述,一些关键词如“程序崩溃”、“系统无反应”和“文字错误”等,便于后续对缺陷的阅读与检索。
●缺陷描述时,应先定位具体菜单页面。
如菜单页面显示多层,则统一描述为“xx>xx>xx”,如“凭证管理>凭证查询,”,后面再具体的描述问题。
●所属产品有多个项目,在缺陷描述前增加项目缩写名称,如【新会计】。
基本版本不做标识,使用共用模块信息(新增项目独有的模块应创建对应的项目模块信息),且新建模块不超过三级(一般到系统模块级,如系统管理-用户管理)。
●同一页面的界面问题,记录在一个缺陷描述内;同一模块同一类问题,记录在一个缺陷中,并且缺陷的描述中列出各个问题,分1,2,3…,便于开发一次修改完毕。
●测试工程师对已有缺陷需要补充的,缺陷为分配/未处理可以增加(应同时知会相关修改开发人员),已经处理的需要另录缺陷(不含截图和补充日志信息)
●缺陷填写要求:
必填字段填写,所属产品、项目、模块、版本等字段必填。
●BUG类型初步判断(一般为代码错误)、BUG优先级设置(一般为严重程度一致)、相关需求关联(存在需求项)
●指派BUG:
原则上指派给对应开发人员,或者项目经理/开发经理。
●缺陷处理意见、验证情况,应填写在备注中,方便查询。
●上传附件必须为*.jpg、*.png格式图片,在图上标记出问题或者文字描述更佳。
●难以重现的缺陷,应在描述中说明,如出现一次,两次,随机出现,低概率出现等。
●容易引起语义混淆的名称,可加上双引号,涉及到按钮的,应使用【】进行标记。
●回归验证缺陷,对部分解决、或未解决的缺陷,应在备注中注明原因。
●新增缺陷时,应先检查缺陷库中是否已存在此缺陷,且未被关闭,力求避免重复提交。
●已经关闭的缺陷,不可再重新激活(误操作除外),应重新增加一条缺陷,并附带描述XXX号BUG已经出现并且处理过。
●缺陷严重级别定义应遵循判定原则,或同一测试组保持定位的一致性。
3.缺陷描述应遵循以下7个要点:
精炼、正确、中立、准确、普遍性、可再现和有证据。
3.3.1精炼
缺陷描述需简单明了,不加入与问题无关的描述,去除不必要的信息,同时必须涵盖所有必要的信息。
3.3.2正确
一定要清楚所记录的缺陷的确存在,在提交前,考虑如下几点
1.对系统需求理解正确;
2.已经安装和系统相关的软件,机器设置没有问题;
3.被测软件本身的问题;
4.不是以前遗留的错误数据导致的错误;
5.不是网络引起的错误,或者其他外在因素引起的错误。
以上这些对测试的结果有很大的影响,确认这些问题是否存在。
3.3.3中立
客观的描述每一个缺陷,不要带任何情绪化的语言。
在提交一个缺陷记录首先把它通读一遍,确认描述没有损伤任何一个人员。
3.3.4准确
缺陷记录需要准确的描述缺陷发生的位置,产生条件和结果。
最好做到让缺陷阅读者不需要上机操作就知道问题所在。
例子
缺陷描述
不准确的描述
查询中按时间来查询发生错误。
准确的描述
凭证管理>凭证查询:
在时间查询输入框中输入/选择合法的数据进行查询时,页面上显示js错误,数据不显示。
3.3.5普遍性
记录缺陷需要明确的描述出该问题在整个系统中普遍存在的地方。
通常,当开发人员修改缺陷的时候,可能只是修复了所提到的一些特定的情况,并不知道这个问题具有普遍性,尚需要更大范围的修复。
3.3.6可再现
原则上所提交的缺陷都应该能够重现,对很难重现的bug,应该记录下什么情况下以再现它,列出再现bug的所有步骤,执行次序以及所需要的数据等。
对于无法再现这个bug,或者怀疑某些条件还没有想到,应尽可能的把那些认为可能有用的信息描述清楚。
一个缺陷在重现它之前,不要假设它是可以重现的,如果确实无法重现它,需要在缺陷记录中明确说明。
在考虑对缺陷的重现时应该注意以下几点:
1.怎样才能以最简单的方式把缺陷重现。
对于难重现的缺陷,这常常是个漫长而费时的过程。
2.是否有外在的原因在测试中导致了该缺陷。
例如是否和其他的软件相冲突的情况。
3.如果在测试中要输入很多的值,尽量在大量的输入中找出导致缺陷的那些特定值,并准确地写出那些导致
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 管理 规范