软件测试规范管理V11.docx
- 文档编号:25794019
- 上传时间:2023-06-14
- 格式:DOCX
- 页数:9
- 大小:96.47KB
软件测试规范管理V11.docx
《软件测试规范管理V11.docx》由会员分享,可在线阅读,更多相关《软件测试规范管理V11.docx(9页珍藏版)》请在冰豆网上搜索。
软件测试规范管理V11
软件测试规范管理
(V1.1)
修订历史记录
日期
版本
作者
审核者
说明
20123-3-6
V1.1
**
初稿
1.概要
1.1.目的
本文档是测试和开发团队的日常工作规范,主要侧重测试工作流程的控制,明确软件工程的各阶段测试应完成的工作以及开发应提供的文档。
1.2适用范围
本过程适用于软件测试过程中所有活动,即适用于参与项目的所有开发和测试人员。
1.3术语、名词定义
1.3.1开发文档
开发人员提供给测试人员的开发文档至少包括以下几种:
需求文档,概要设计,详细设计,用户手册等。
1.3.2测试文档
测试文档包括测试计划、测试用例说明、BUG报告及分析、测试总结,以及测试工作全部完成后的测试报告等。
测试文档由测试人员编写并维护。
1.3.3缺陷等级说明
1)A类:
致命缺陷,最严重的等级,缺陷会导致网站任何一个主要功能完全丧失,用户数据受到破坏、系统崩溃、死机等。
2)B类:
严重缺陷,系统的主要功能部分丧失、数据不能完整保存,系统的次要功能完全丧失,系统所提供的服务和功能受到明显的影响
3)C类:
一般缺陷,系统的次要功能没有完全实现,但不影响用户的正常使用
4)D类:
较小缺陷,界面错误、菜单布局不合理,提示不准确等,在使用过程中跟用户带来一定的不方便和操作难度
5)E类:
建议缺陷,对网站使用的友好性有影响,如拼写错误、界面布局、文档的可读性、操作的一致性等
2.测试职责
测试是软件开发过程中的重要组成部分,肩负着如下责任:
•在项目的前景、需求文档确立基线前对文档进行测试,从用户体验和测试的角度提出自己的看法。
•编写合理的测试计划,并与项目整体计划有机地整合在一起。
•编写覆盖率高的测试用例。
•针对测试需求进行相关测试技术的研究。
•认真仔细地实施测试工作,并提交测试报告供项目组参考。
3.测试流程图
4.测试申请
开发组向测试负责人提交《测试申请表》,该文档要说明:
申请测试人员数量,进行哪些功能的测试,需要提交哪些测试文档,测试周期,测试环境要求。
4.1项目初期
项目立项初期时需提交《需求文档》、《概要设计》、《详细设计》、《开发进度表》
4.2迭代功能开发
开发组提交《送测表》,其中包括可测试内容和测试注意事项
否
迭代功能测试流程图
5.测试准备
5.1文档分析
测试人员和开发人员均应参加需求评审、设计评审。
对《需求说明书》、《系统界面原型》和《软件设计说明书》等进行阅读和审查,与产品经理、项目经理沟通,根据系统功能复杂度,系统业务复杂度估算开发时间和有效测试执行时间,为项目总计划和测试计划的制定提供参考和依据。
通过对文档分析,分解各功能模块,各功能点,为测试用例设计提供数据依据。
5.2测试计划
根据需求文档和项目计划制定测试计划。
测试计划旨在说明各测试阶段任务、人员分配、时间安排、测试要点、工作规范等。
测试计划在策略和方法方面说明如何计划、组织和管理测试项目。
测试计划完成后应该在项目组内进行评审。
5.3测试用例
测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。
解决要测什么、怎么测和如何衡量的问题。
依据用户需求分析说明书、概要设计文档和开发详细设计说明书来设计测试用例,发现需求与设计中的问题后,与需求作者及时沟通确认。
5.3.1测试用例设计方法
测试用例的设计方法有等价类测试、边界值分析、基于判定表的测试、基于因果图的测试、基于状态图的测试、基于场景的测试。
在设计测试用例时常用的设计方法有等价类测试、边界值分析两种方法。
5.3.2测试用例操作步骤
1、在设计编写测试用例时,首先要从测试用例库中选择相应功能的测试用例,在原有测试用例的基础上依据系统需求文档对测试用例的进行修改、更新,评审通过后将使用该测试用例测试被测系统。
2、在测试的执行过程中和进行回归测试后,对已设计的测试用例进行维护更新。
5.3.3测试用例选择准则
测试用例的代表性:
能够代表各种合理和不合理的、合法的和非法的、边界和越界的,以及极限的输入数据、操作和环境设置等;
测试结果的可判定性:
即测试执行结果的正确性是可判定的或可评估的;
测试结果的可再现性:
即对同样的测试用例,系统的执行结果应当是相同的。
5.4测试软/硬件环境
根据需求文档提供的内容,和开发部沟通确定测试项目所需的软硬件环境,完成对测试项目所需软硬件资源的准备工作,使软硬件资源得到满足。
5.5测试数据准备
完成对测试项目基本数据的准备操作,包括数据库连接、用户信息、用户角色权限、单位组织等信息和测试相关的测试数据。
6.测试执行
6.1测试准入条件
1、不接受无详细需求文档和开发说明的项目
2、需要测试的项目至少提前2个工作日提交测试进行需求分析
3、开发人员经过自测通过,至少保证程序可以正常运行;对应的功能在正常流程下是可以正常使用
6.2项目测试阶段
测试人员依据测试计划和测试用例进行测试活动。
测试一般分为两个阶段:
1、测试执行阶段:
该阶段测试人员测试出bug后将缺陷提交至缺陷管理库。
2、回归问题单:
开发修改完bug之后,测试进行验证回归。
6.3测试退出标准
1、测试对可回归缺陷的回归率达到100%。
2、全部的测试用例集执行完毕。
3、缺陷处理达到100%。
6.4测试变更
当需求变更,功能变化,测试人员根据变更情况,评估测试变更所需时间,提出变更风险。
如变更情况被项目组通过,测试人员将按上述流程进行变更测试。
7.缺陷管理
7.1缺陷管理流程
7.2提交缺陷
测试人员将缺陷填写到缺陷管理库中,将缺陷分配给为开发组长或相应的开发人员。
7.3分配缺陷
开发人员分别对自己收到的缺陷进行评审。
评审后如果对提交的缺陷有疑问,可以与提交人协商。
对未能达成一致的缺陷由项目经理组织项目组成员评审。
评审人员可以是项目组人员。
如果缺陷初次分配的开发人员无法修改该缺陷,初次分配的开发人员可以将缺陷再次分配给其他开发人员。
如果开发对测试提出的bug不理解或者不能重现时,可以要求测试复现bug。
7.4修改缺陷
开发人员对已确认的缺陷进行修改,填写修改记录,修改缺陷状态为“已修改”或其他状态。
修改完后开发应对修改后会影响的其他功能模块做个说明,还需对缺陷产生的原因和解决方法做个备注,以便日后追溯。
开发人员认为该缺陷可以不予修改或者不是缺陷的,可与测试人员协商后将状态改为“已否决”或由测试人员直接关闭缺陷。
并要注明原因。
7.5关闭缺陷
测试人员对已修改的缺陷进行验证。
如果已修改完成,测试人员将缺陷状态设置为关闭。
如果没有修改或引起回归问题,将修改缺陷状态为“重新打开”或新增缺陷,由开发人员继续修改。
7.6保留缺陷
对于有争议的缺陷进行,将有项目经理最终决定是否修改。
如果缺陷是由于技术原因、版本原因等不能修改,则保留该缺陷并加以注释。
8.测试结果分析
测试结果分析是对测试结果的一个综合评估,主要描述有测试中各个等级的缺陷数量,缺陷分布情况,缺陷修改情况、回归测试提交缺陷数量等情况。
测试报告由测试人员编写并提交给项目经理。
测试报告需要经项目组评审通过。
9.约定
就测试与开发人员就测试过程中的交互,约定如下:
1.每次迭代开发后的正式送测必须编写送测表。
2.如送测后的功能执行关键测试用例不能通过,则测试人员有权利中止测试。
待开发修改完并自测确定无阻塞性问题后再提交测试。
3.测试人员测试过程中,必须依据所有的BUG都体现在测试报告中的原则,保证所发现的BUG都已添加到测试报告中。
4.测试人员测试完毕后,必须通知相关的负责人及程序人员。
5.开发人员必须明确写明BUG引起的原因及解决方法,以方便以后做追溯。
6.开发人员如对测试人员所填写的BUG不理解或不能重现,可请求测试人员解释或重现,而不能直接拒绝修改。
7.在修改送测功能时,开发人员做的任何代码上的改动(非针对明确写出的BUG时),都必须同时通知测试人员,以便进行针对性的回归测试。
10.标准文档
《测试申请单》
《送测表》
《测试计划》
《测试用例》
《测试报告》
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 规范 管理 V11