测试体系建设与软件测试流程图文档格式.docx
- 文档编号:19204048
- 上传时间:2023-01-04
- 格式:DOCX
- 页数:15
- 大小:417.81KB
测试体系建设与软件测试流程图文档格式.docx
《测试体系建设与软件测试流程图文档格式.docx》由会员分享,可在线阅读,更多相关《测试体系建设与软件测试流程图文档格式.docx(15页珍藏版)》请在冰豆网上搜索。
3.2活动说明
3.2.1需求评审
3.2.1.1目的
从源头把握软件质量,并确保开发结果与实际需求相一致
3.2.1.2角色与职责
需求人员:
《需求规格说明书》的编写,以及软件开发过程中《需求规格说明书》的修
正;
评审人员:
评审《需求规格说明书》,从全面性、完整性、正确性、一致性、可靠性方
面检、查《需求规格说明书》,将需求缺陷提交给需求人员,并跟踪需求缺
陷直至需求缺陷验证关闭。
3.2.1.3启动标准
《软件需求规格说明书SRS》编写完成
3.2.1.4工作流程图
3.2.1.5输入/输出
输入:
《需求规格说明书》
输出:
需求缺陷
3.2.2测试计划
3.2.2.1目的
明确测试容、测试任务安排、测试进度、测试策略、测试资源、风险控制;
保持测试过程的顺畅,有效控制和跟踪测试进度,应对测试过程中的各种变更。
3.2.2.2角色与职责
测试负责人:
根据《软件开发计划》、《需求规格说明书》编制《测试计划》,明确测试
容、测试任务安排、测试进度、测试策略、测试资源、风险控制,以便
测试工作正常开展,测试计划实际编写容参见《项目测试计划模版》。
3.2.2.3启动标准
需求评审完成,《项目整体计划》编制完成。
3.2.2.4工作流程图
3.2.2.5输入/输出
《软件需求规格说明书》、《软件开发计划》
《测试计划》、《测试方案》
3.2.3测试设计
3.2.3.1目的
通过多种测试方法编写测试用例,以使最少的测试用例,实现最大的测试覆盖,保证软件功能的正确性,从而提升软件质量。
3.2.3.2角色和职责
测试人员:
采用多种测试方法编写有效的测试用例,并对遗漏/错误的测试用例进行修
正。
对测试人员编写的测试用例进行评审,提出遗漏/错误的用例缺陷,并跟踪
直至用例缺陷的验证关闭。
3.2.3.3启动标准
需求文档评审完成且测试计划制定完成
3.2.3.4工作流程图
3.2.3.5输入输出
《软件需求规格说明书》、《测试计划》、《测试方案》
《测试用例》、测试用例评审缺陷
3.2.4功能测试执行
3.2.4.1目的
依据测试计划,按照测试用例对软件进行测试,验证软件功能与需求的实际匹配程度。
3.2.4.2角色与职责
依据测试计划,按照测试用例对软件功能进行测试。
对于发现的缺陷必须记
录,并且跟踪缺陷的状态,直至缺陷的验证关闭。
在测试执行过程中发现的
遗漏测试用例必须补充至测试用例,保证测试用例与实际测试的一致性。
开发人员:
对于测试人员提交的缺陷进行确认、修复。
开发经理:
对测试人员与实际开发人员意见不一的问题进行裁决。
3.2.4.3启动标准
测试用例编写完成且用例评审完成
3.2.4.4工作流程图
3.2.4.5输入输出
功能测试用例
功能测试报告,缺陷报告单
3.2.5集成/性能测试设计
3.2.5.1目的
为集成测试提供测试依据,记录并保证集成测试覆盖度;
依据《测试计划》及性能指标制定性能测试计划、性能测试用例设计、性能测试脚本开发,保证性能测试有序进行。
3.2.5.2角色和职责
以整个软件为对象,确保新功能、老功能、新老功能接口正确进行用例设计;
依据性能指标及测试计划对性能测试进行计划、以及性能测试用例/脚本的开
发。
3.2.5.3启动标准
功能测试完成且软件功能无中断
3.2.5.4工作流程图
3.2.5.5输入输出
《功能测试用例》、功能测试缺陷、《测试计划》、性能指标
《集成测试用例》、《性能测试计划》、《性能测试用例》、性能测试脚本
3.2.6集成测试/性能测试
3.2.6.1目的
以整个软件为对象,以测试计划为指导,按照集成测试测试用例对新功能、老功能、新老功能接口进行测试和性能测试,保证测试的全面性和完整性。
3.2.6.2角色和职责
以整个软件为对象,以测试计划为指导,按照集成测试测试用例对新功能、
老功能、新老功能接口进行测试,并依据性能测试计划对软件性能进行测试。
3.2.6.3启动标准
集成/性能测试设计完成
3.2.6.4工作流程图
3.2.6.5输入输出
《集成测试用例》、《测试计划》之集成测试事项、《性能测试计划》、《性能测试用
例》
集成测试缺陷
3.2.7文档测试
3.2.7.1目的
保证对客户的指导与实际系统的使用状况相一致。
3.2.7.2角色和职责
对《用户操作手册》及在线帮助进行测试,记录文档描述缺陷,并跟踪直至
缺陷的验证关闭。
对测试人员提出的文档描述缺陷进行修正。
3.2.7.3启动标准
《用户操作手册》或在线帮助编写完成
3.2.7.4工作流程图
3.2.7.5输入输出
《用户操作手册》、在线帮助
文档缺陷
3.2.8测试报告
3.2.8.1目的
真实、客观反映测试过程中各测试阶段、测试项的情况,并将结果进行数字化/图像化进行分析,真实反映软件质量实际情况。
3.2.8.2角色与职责
真实、客观地对测试过程中各测试阶段、测试项的情况,并以数字/图像
的形式对实际情况进行分析,真实反映软件实际测试状况。
3.2.8.3启动标准
集成测试完成
3.2.8.4工作流程图
3.2.8.5输入输出
各测试阶段、测试项实际测试情况
《项目测试报告》
4.缺陷管理
4.1概述
4.1.1编写目的
为规QC的合理使用,方便各项目组管理测试过程,测试管理人员正确使用QC而编写。
4.1.2适用围
适用于功能测试有关工作,功能测试中的缺陷要求全部采用QC进行管理。
4.1.3角色和职责
角色名称
职责描述
测试经理
申请QC项目建立,分配有关人员权限
测试人员
登记测试缺陷,跟踪和修改缺陷状态,并进行复测
开发人员
从QC中获取缺陷信息,修复缺陷,并修改QC缺陷状态及分析记录缺陷相关容
4.1.4名词解释
QC:
QC(QualityCenter),也被称为MQC(MercuryQualityCenter)。
不仅可以在一个项目组进行质量控制和管理,也可以在跨地域的不同项目组部进行质量控制和管理,从而可以保证应用系统的质量。
通过在整个应用系统中提供并集成了测试的需求管理、案例管理、缺陷管理等,QC可以地加速测试过程执行。
4.2缺陷状态关系示意图
4.3缺陷流转的过程及处理
参与缺陷流转的角色有三个:
测试经理、测试人员和开发人员。
缺陷的处理步骤如下:
4.3.1新建缺陷
测试人员负责在QC中新建缺陷,并对缺陷的基本情况进行描述。
缺陷的基本信息主要包括:
缺陷描述、紧急程度、严重程度、处理子系统等。
测试人员在登记缺陷时,必须确定所输入的缺陷容要描述清楚,产生缺陷的步骤描述要完整,使缺陷能够被重现出来。
在描述缺陷产生的步骤上,务必简易清楚。
测试人员可以利用错误抓图等方式进行补充描述。
4.3.2修复缺陷
当有多个缺陷同时打开时,开发人员应首先修复紧急程度更高的缺陷。
开发人员首先分析缺陷,并将缺陷状态更改为“处理”中。
当该缺陷不是有效的缺陷时,则将“缺陷状态”更改为“拒绝”,并在“缺陷详细信息”模块中的“分析和修改容”中使用“添加注释”按钮详细填写拒绝的原因。
当确认该缺陷有效时,开发人员应按照要求修复缺陷。
缺陷修复后,开发人员需在“缺陷详细信息”模块中的“分析和修改容”中使用“添加注释”按钮详细填写修复的容,并填写缺陷起源、缺陷归属子系统,更改“缺陷状态”为“待验证”。
当确认该缺陷不是本系统引起,需要其它项目组协同进行分析解决,开发人员应保持缺陷状态为“处理”,并将该缺陷的“处理子系统”改为相应的项目组或系统,以便缺陷能及时流转。
4.3.3验证缺陷
测试人员负责验证缺陷是否已解决,如已解决则由缺陷原提出人关闭缺陷,否则将“缺陷状态”更改为“重现”,以便开发人员重新对此缺陷进行处理。
4.4缺陷页面部分字段详解
◆缺陷状态:
指缺陷通过一个跟踪修复过程的进展情况。
包括:
新建、打开、已修改、重新打开、关闭、拒绝、延迟
◆缺陷严重程度:
是指因缺陷引起的故障对系统的影响程度。
由提出人初步指定,开发人员负责确认。
致命、严重、一般、轻微
◆缺陷紧急程度:
指缺陷必须被修复的紧急程度。
由提出人指定。
各测试小组可以项目组具体协商约定紧急程度的具体含义。
包括:
高、中、低提出、处理、拒绝、待验证、重现、关闭
◆缺陷起源:
指引起缺陷的起因。
需求、架构、设计、编码、测试、环境、数据、拒绝
缺陷起源类型
含义
需求
由于需求定义或需求分析引起的缺陷
架构
由于企业架构设计的问题引起的缺陷
设计
由于本系统设计原因引起的缺陷
编码
由于编码的问题引起的缺陷
测试
由于测试人员在测试设计、测试操作或理解有误等原因引起的缺陷
环境
由于测试环境的问题引起的缺陷
数据
由于测试数据的问题引起的缺陷
拒绝
重复。
表示该缺陷已经被其它提交人找出来了(‘纯粹’重复),或者开发认为原因是相同的(但从测试来看,认为出现的地方有所不同、表现有所不同等)
不可复现。
不能重现(如因缺陷出现的环境重现不了),或以前出现的某个缺陷自动消失了(可能是在处理其他缺陷的时候把这个缺陷一并修复掉了)
是按照需求和设计实现的,不属于缺陷
延后解决。
由于时间、进度、重要程度或者技术/需求等方面的原因,认为目前不能解决或由于时间关系,须延期解决或者本版暂不解决留待到后续版本解决的缺陷
这个缺陷是一个错误,但非常轻微,对系统几乎无影响,可以忽略不计
5.配置管理
软件测试过程是一个复杂性的劳动,测试过程中会产生大量测试文档,主要通过相关管理工具的方式实行对文档的管理。
在文档的管理方面,按照公共类、项目类、软件缺陷类、开发人员类、测试工具类等:
1)公共类主要放置测试模板及测试规程说明,测试经验共享文档,开发技术规等。
2)项目类主要包括项目各阶段文档,如需求分析、测试计划、测试用例设计、分析报告等。
3)开发人员类是针对每个开发人员易犯错误的总结。
4)测试工具类主要放置常用的测试工具svn。
6.人员培养
一个优秀的测试团队的形成并非一朝一夕能形成。
软件测试和软件开发一样,是一项高智力的活动。
在对测试人员的选择上我们通常从技术能力、沟通能力、记忆力、自信心、耐心、怀疑精神、洞察力、有条理和注意细节八方面进行考虑。
对于新进入的测试人员,无论是否有测试经验或编程经验,都应进行测试的技术和管理规培训,同时根据他们以往知识和个人特点给他们定位合适的测试方向。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 体系 建设 软件 流程图