软件测试系列二《软件测试流程规范》
Posted 再见孙悟空_
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了软件测试系列二《软件测试流程规范》相关的知识,希望对你有一定的参考价值。
1.目标
持续建设能够保证事业部产品质量的测试队伍和体系。
2.背景
测试团队刚成立,测试工作还没有形成一个完善的体系,为此编写此文档,旨在规范测试流程,明确产品各个阶段的测试工作,逐渐形成一个完善的测试体系,真正实现对产品质量的保证。
3.测试工作总要求
- 建立支撑事业部的测试团队;
- 新产品对外发布、发布后产品的缺陷修改发布(补丁),均需测试通过方可执行。紧急情况需对外发布时,需注明未测试。
- 研发团队依据测试过程中定义的职责进行测试过程中的工作;
- 测试团队对测试过程执行情况进行跟进并执行过程改进;
- 测试团队依据《测试流程规范》开展工作;
- 完善支撑事业部测试开展的《测试流程规范》;
- 建立支撑事业部测试团队运行的软硬件环境;
4.测试流程概述
根据软件开发流程,各个阶段中测试工作以及对应的输出如下:
4.1需求评审
过程要点 | 详细说明 |
输入条件 | 需求定义完成 |
工作内容 | 测试团队成员对需求中不清楚、不完整、太概括或存在疑义的地方提出问题,相关人员解答并确认。 |
输出条件 | 所有人员对需求无异议 |
参与人员 | 需求调研人员、产品经理、项目经理、开发组、测试组 |
注: 需求定义基本完成,此时应在评审会议召开之前发给测试团队,预留时间给测试相关人员熟悉、理解。
4.2测试设计阶段
4.2.1测试计划编写
针对需求分析文档和产品开发计划文档,测试组需要编写测试计划文档、制定测试策略及预估测试过程中的风险,并设计出合理的规避风险的策略,为后续的测试工作提供直接的指导。
过程要点 | 详细说明 |
输入条件 | 产品需求文档,产品开发计划完成。 |
工作内容 | 1.根据产品的需求文档、设计文档,按照测试计划文档模板编写测试计划。 测试计划中应该至少包括以下关键内容:
测试计划编写完毕后,必须提交给产品组全体成员,并由产品组组中各个角色组联合评审。 2.产品中编写测试方案要求:
|
输出条件 |
|
责任人 | 项目组测试负责人 |
4.2.2设计测试用例
在需求分析文档评审确认后,测试组需要针对产品的测试需求编写测试用例,在实际的测试中,测试用例将是唯一实施标准,在出现线上问题后,测试用例会作为问题是否测试遗漏的依据。在用例的编写过程中,具体的任务和责任人如下:
过程要点 | 详细说明 |
输入条件 | 需求明确,测试计划明确 |
工作内容 | 1.根据需求说明书或需求规格说明书分析形成测试需求,再根据测试需求分解成测试项,根据测试项编写测试要点; 2.根据测试计划、测试需求/测试要点设计测试用例,设计参考方法:
|
输出条件 |
|
责任人 | 测试组成员 |
备注:
测试过程中,根据实际执行情况,进行用例的完善,包括新增、修改、删除用例。
4.3计划/用例/方案评审
测试计划、测试用例、方案的设计工作完成后,需通知产品组相关成员召开评审会议。在这之前需要将待评审的内容发给相关人员熟悉和理解。
过程要点 | 详细说明 |
输入条件 | 测试计划、测试用例、方案完成 |
工作内容 | 评审测试计划、方案内容的正确性及合理性:
评审测试用例:
评审方式:
|
输出条件 | 测试计划、测试用例、方案评审通过。 |
责任人 | 测试组,项目经理。 |
4.4测试实施阶段
提交测试:当开发完成需求的实现并自测试通过后,按照提交测试的流程规范将软件提交测试组进行测试;测试组接收测试软件包后,检查提交的文件是否正确、完整,不满足条件打回,开发重新提交。
冒烟测试:在确认提交软件可测后,执行冒烟测试。冒烟测试即对系统的主功能、基本业务流程进行测试,验证基本功能是否实现。冒烟测试通过,开始进行测试;冒烟测试不通过,打回版本包,开发修改再提交;
测试实施:根据测试用例、需求进行测试,将发现的问题提交到相应的管理工具,同时在测试用例中记录测试结果;测试完成一轮后,开发修改问题后,再次将版本提交测试,测试人员对之前的问题进行验证,同时对以前测试过的功能进行回归测试;根据实际产品中问题解决的情况进行多轮测试,直至问题解决。
交叉测试:功能测试完成,问题都修改以后,测试人员A将功能交由测试人员B进行交叉测试,这样可以避免单个人员测试存在漏测问题;
系统测试:每次版本发布前,需要对系统的主要功能(包含本次没有修改的功能)进行回归测试,保证主业务流程可以正常使用。
测试总结:测试完成以后,编写测试报告,对所测系统进行问题总结。
测试过程中的流程如下图:
4.4.1提交测试
过程要点 | 详细说明 |
输入条件 | 测试设计内容(测试用例、测试计划/测试方案)评审完毕,开发团队编码工作完成,并已完成内部测试; |
工作内容 |
|
输出条件 |
(1)软件测试申请表(包含需求文档、设计文档、程序包等信息,明确标明已完成功能、未完成功能) (2)邮件通知相关人员 (3)提测功能涉及的安装部署操作手册(根据具体功能而定) |
责任人 | 项目经理,项目组测试负责人 |
4.4.2冒烟测试
提交测试软件在冒烟测试时,若发现致命级别错误(大于等于2)、严重界面错误(大于等于6),则暂停测试返回开发;提交测试软件功能点少于计划范围内功能模块数的需要暂停,并与产品经理协商处理。
4.4.3实施测试
实施测试将花费测试组大部分时间,这些工作都是建立在前期很多计划工作的基础上。
过程要点 | 详细描述 |
输入条件 | 测试用例、被测软件的需求文件 |
工作内容 |
|
输出条件 | 测试用例中的所有任务被执行,结果被记录。 |
责任人 | 测试组成员 |
4.4.4交叉测试
过程要点 | 详细描述 |
输入条件 | 测试用例;被测功能所有问题已修改 |
工作内容 |
|
输出条件 | 交叉测试结果。 |
责任人 | 测试组成员 |
过程要点 | 详细描述 |
输入条件 | 所有功能模块已经测试通过,问题已修改 |
工作内容 |
|
输出条件 | 系统测试用例执行通过。 |
责任人 | 测试组成员 |
4.4.6测试总结
阶段性测试报告
在约定的测试周期(暂定每轮测试)完成之后,测试负责人需要总结此次测试的结果,编写阶段性测试报告。
过程要点 | 详细描述 |
输入条件 | 测试组完成了预定周期的测试任务 |
工作内容 | 测试负责人根据此轮测试的结果,编写阶段性测试报告,主要应包含以下内容:
|
输出条件 | 在每轮测试结束之后尽快将符合标准的测试报告发给产品组。 邮件发送产品组成员,并将报告上传SVN |
责任人 | 项目组测试负责人 |
系统测试报告
测试工作结束或即将结束时,测试组就要开始着手准备系统测试报告,进行总结的工作。
过程要点 | 详细描述 |
输入条件 | 测试组完成了所有的测试实施工作 |
工作内容 | 测试负责人根据测试的结果,编写系统测试报告,系统测试报告必须包含以下重要内容:
|
输出条件 | 测试负责人完成了符合标准的《系统测试报告》,发送给全项目组。 |
责任人 | 项目组测试负责人 |
4.4.7出口准则
测试用例设计已经通过评审并执行完毕;
按照系统测试计划完成了测试;
达到了测试计划中关于测试所规定的要求;
系统满足需求规格说明书的要求;
测试中发现的错误已经得到修改,各级缺陷修复率达到标准:
- 致命、严重缺陷修复率应达到100%
- 一般、轻微缺陷修复率应达到95%以上
- 建议类缺陷(确认修改的)修复率应达到60%以上
提交测试软件在进行冒烟测试时,发现致命级别错误或者严重级别错误,需暂停测试返回开发;
提交测试软件功能点少于计划范围内功能模块数的需要暂停,并与产品经理协商处理;
软件产品需暂停以进行调整时,测试应随之暂停,并备份暂停点数据;
软件产品在其开发生命周期内出现重大估算,进度偏差,需暂停或终止时,测试应随之暂停或终止,并备份暂停或终止点数据。
5.其他规范
5.1缺陷管理
在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来,填写测试记录。为了能准确的找出问题产生的原因,及时的解决问题,保证测试工作的顺利进行,一般来说所发现的问题必须是能够重视的。
所有的缺陷需要记录到jira中。
5.1.1缺陷属性
属性名称 | 描述 |
缺陷标识 | 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识。 |
缺陷严重程度 | 缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。 |
缺陷优先级 | 缺陷的优先级指缺陷必须被修复的紧急程度。 |
缺陷状态 | 缺陷状态指缺陷通过一个跟踪修复过程的进展情况。 |
缺陷发现的阶段(缺陷起源) | 缺陷来起源指缺陷引起的故障或事件第一次被检测到的阶段。 |
缺陷引入的活动(缺陷来源) | 缺陷来源指引起缺陷的起因。 |
序号 | 缺陷严重等级 | 描述 |
1. | 致命缺陷 | 致命缺陷通常是一些致命的错误,造成系统或应用程序崩溃,死机,系统悬挂,或造成数据丢失,主要功能组完全丧失。 |
2 | 严重缺陷 | 通常是产品不稳定、不安全、或产生缺陷结果,而且是常规操作中经常发生或非常规操作中不可避免的主要问题。 |
3 | 一般缺陷 | 程序的功能运行基本正常,但是存在一些需求、设计或实现上的缺陷;次要功能运行不正常。 |
4 | 轻微缺陷 | 以上是关于软件测试系列二《软件测试流程规范》的主要内容,如果未能解决你的问题,请参考以下文章 |