PSQA软件开发测试流程NO0326001文档格式.docx

上传人:b****6 文档编号:15898470 上传时间:2022-11-16 格式:DOCX 页数:11 大小:62.89KB
下载 相关 举报
PSQA软件开发测试流程NO0326001文档格式.docx_第1页
第1页 / 共11页
PSQA软件开发测试流程NO0326001文档格式.docx_第2页
第2页 / 共11页
PSQA软件开发测试流程NO0326001文档格式.docx_第3页
第3页 / 共11页
PSQA软件开发测试流程NO0326001文档格式.docx_第4页
第4页 / 共11页
PSQA软件开发测试流程NO0326001文档格式.docx_第5页
第5页 / 共11页
点击查看更多>>
下载资源
资源描述

PSQA软件开发测试流程NO0326001文档格式.docx

《PSQA软件开发测试流程NO0326001文档格式.docx》由会员分享,可在线阅读,更多相关《PSQA软件开发测试流程NO0326001文档格式.docx(11页珍藏版)》请在冰豆网上搜索。

PSQA软件开发测试流程NO0326001文档格式.docx

版本变化:

创建时间

版本

创建人

修改人

V_001

目录

一软件开发测试阶段说明5

二各个阶段责任主体5

三软件开发测试流程图6

四角色与职责8

五版本发布标准10

六错误级别说明11

七缺陷管理说明13

八注意事项14

编写目的

规范的工作流程和有效的测试进度控制以及和各部门的协同工作将有助于提高我们的开发和测试工作效率以及保障产品质量。

一软件开发测试阶段说明

✧单元测试——开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。

通常采用白盒测试方法。

✧集成测试——两个或两个以上的模块集成在一起进行测试,主要是测试模块间的接口,集成测试是最常见的测试类型。

✧系统测试——模拟真实用户场景,将硬件、操作系统、程序、系统支持软件、最终用户等综合在一起进行系统整体的测试,通常是在项目、产品上线后验收前进行系统测试,有条件的话也可以在β测试前进行

✧回归测试——项目、产品验收前,对以前系统中的严重级别的bugs,进行重现操作。

一般用自动化测试工具代替人工操作,但由于人力资源问题,一般公司不经历这个阶段

✧验收测试——验收测试是相对复杂的一种测试,需要研发人员、最终用户的共同参与,验收不仅仅针对系统的bugs,而是对整体项目或产品的发布流程的一种测试,一般包括系统本身测试、文档测试等。

通常所说的α测试、β测试都属于验收测试范围。

二各个阶段责任主体

✧需求——产品、运营

✧单元测试——研发人员

✧集成测试——研发人员、测试人员

✧系统测试——测试人员

✧回归测试——测试人员

✧验收测试——测试人员、研发人员、产品人员

✧测试计划评审——测试人员、研发人员、产品人员

✧测试方案评审——测试人员、研发人员、产品人员

✧测试用例评审——测试人员、研发人员、产品人员

三软件开发测试流程图

【流程说明】:

Ø

产品人员、研发人员给测试人员提交测试任务的工单

测试人员阅读、分析《需求说明文档》和《概要设计文档》;

测试人员根据《需求说明文档》、《概要设计文档》和《项目计划》制定《测试计划》;

测试人员完成《测试计划》后,邮件形式发送给产品人员和研发人员共同对此《测试计划》进行评审;

评审不通过时测试人员对测试计划进行修改、补充,直至评审通过;

测试人员完成《测试方案》后,邮件形式发送给产品人员和研发人员共同对此《测试方案》进行评审;

评审不通过时测试人员对测试方案进行修改、补充,直至评审通过;

测试人员根据《需求说明文档》和《概要设计文档》编写《测试用例》;

测试人员完成《测试用例》后,邮件形式发送给产品人员和研发人员共同对此《测试用例》进行评审;

评审不通过时测试人员对测试用例进行修改、补充,直至评审通过;

评审通过进行测试执行。

测试执行阶段工作流程:

✧第一个新版本发布后,测试人员查看自己负责模块在该版本中的发布特性,确定哪些功能可以测试,挑选对应的测试用例;

✧根据编制的测试规程和测试用例的优先级,逐个执行测试用例,记录测试结果,发现bugs时提交到bugs缺陷管理系统中

✧如果测试发现重大问题,导致该版本测试无法继续,发邮件或是直接通知相关人员该模块测试暂停;

✧如果测试用例执行完毕,邮件或直接通知相关人员该模块该版本测试完成,等待新版本发布。

✧如果模块中所有问题均已关闭,邮件或直接通知相关人员该模块测试结束。

✧下一个版本发布时,测试人员对上一个版本出现的问题进行回归测试,测试人员查看自己负责模块在该版本中的修改情况,挑选测试用例;

✧重复上述2~4,直到满足5中的条件。

完成产品系统测试、回归测试,直至测试通过

测试通过后,通知产品人员对项目进行验收,验收不通过,测试人员再次执行测试,重复测试执行的操作,直至验收通过。

验收通过,测试人员编写测试分析报告,报告中描述测试中出现的问题,以及测试结果。

发送测试报告给产品总监、研发总监、相关产品人员和研发人员。

验收通过后,产品方可上线。

测试人员在正式环境对其产品进行上线测试,执行测试执行阶段流程。

四角色与职责

1.产品人员

✧提交《需求说明》文档给研发、测试人员,测试人员编写相关测试文档;

✧制定项目时间时应把产品测试时间考虑整个项目中;

✧《需求说明》文档发生变更时,应及时通知研发人员和测试人员;

✧功能、模块流程比较复杂,用文字描述很繁琐时,要有相关的流程图;

✧测试人员编写完成《测试计划》时,产品人员需和研发人员、测试人员一起对《测试计划》进行评审;

✧测试人员编写完成《测试方案》时,产品人员需和研发人员、测试人员一起对《测试方案》进行评审;

✧测试人员编写完成《测试用例》时,产品人员需和研发人员、测试人员一起对《测试用例》进行评审;

✧测试通过时,测试人员通知产品人员对测试产品质量进行验收。

【注】:

提交的《需求说明》文档应为通过《需求说明》文档评审的。

2.配置管理人员

✧配置管理定期获得开发提交的最新的代码,编译并发布到服务器上,要保证版本管理正常与测试人员测试的一定是最新的程序。

验证各个模块是否满足发布条件(测试人员是否已经完成上个版本的测试或是否测试暂停);

✧对满足发布条件的模块,根据开发提交内容,构造并发布新版本,供测试之用。

3.研发人员

✧研发人员在接到任务工单的同时,需同时给测试组下任务工单;

✧根据项目的实际确定多长时间发布一次版本(根据项目具体情况决定);

✧制定项目进度计划,接到新的研发任务要制定进度计划时,需要把测试时间考虑进去,具体的测试时间可与测试人员进行沟通,以确保项目的进度。

(其中测试时间包括测试文档的编写时间、测试数据准备时间、测试环境下测试执行时间、测试环境下回归测试时间以及现网环境测试时间);

✧研发人员有新项目需要测试时,需要向测试人员提交相关的《概要设计文档》、《接口文档》等,以便测试人员更好的了解系统,编写相关的测试文档;

✧测试人员编写完成《测试计划》、《测试方案》、《测试用例》时,产品人员需和研发人员、测试人员一起进行评审;

✧对已开发完成的模块进行单元测试(即内部自测),提交代码等待测试版本发布,提交测试人员测试的程序不能有明显的流程问题与功能失败(环境问题除外);

✧根据bugs缺陷管理系统中相对应模块测试出的问题修改程序,优先解决等级比较高的bugs,修改完成后修改Mantis缺陷管理系统中此bugs的状态,在备注栏中概要描述是怎样解决的此bugs或是bugs的需求是否发生变化等(方便测试人员回归测试,测试相关有影响的部分);

✧某个模块出现重大问题时(影响测试),优先修改重大的问题后再提交新的版本;

✧正在测试的系统中如果某些模块、功能需求发生变更时,相关研发人员要及时通知测试人员,避免浪费测试资源;

✧新发布的测试版本,要有一个文档说明新增了哪些功能、修改了哪些功能,修改完成了哪些bugs;

✧测试环境部署应与现网环境相符,尽量避免环境问题引发的缺陷问题;

✧需要重启或暂停服务时,需及时通知测试人员;

✧项目提交测试时,需发送邮件通过测试人员,邮件内容包括:

测试地址、测试用户、及测试环境说明;

✧每周五上午邮件通知测试人员下周需要测试项目的测试计划提交给测试人员,以方便测试人员制定、安排下周工作计划;

✧负责所有研发文档的归档和备份。

4.测试人员

✧产品人员提交《需求说明》文档,项目负责人提交《项目计划》和《概要设计文档》后,测试人员编写完成《测试计划》、《测试方案》、《测试用例》,并提交项目组成员进行评审。

(项目组成员包括:

产品人员、研发人员、测试人员);

✧需求发生变更时,测试人员及时修改《测试计划》;

✧需求发生变更时,测试人员及时修改、补充《测试方案》、《测试用例》;

✧组织项目相关人员参与《测试计划》、《测试方案》、《测试用例》评审,整理评审过程中反馈的信息,修改并提交整理后的测试文档;

✧参与产品需求评审

✧参与项目进度计划制定,并提交测试进度计划

✧确认上线时间,并与产品人员确认上线版本的测试需求(多需求时,确认优先级)

✧针对测试需求优先级,执行系统测试、回归测试;

✧在Mantis缺陷管理工具提交发现的bugs并通知研发修改,测试人员对修改过的bugs进行回归测试;

✧提交测试进度说明(按周或按日,根据项目具体情况而定)

✧测试完成后,通知运营人员和产品人员对新需求或需求变更等进行验收;

✧验收通过后,测试人员编写测试报告,邮件形式发送测试报告。

产品可部署上线;

✧产品部署上线后,测试人员、运营人员、产品人员、研发人员对现网环境下的产品、项目进行测试。

(根据运营的具体需求调节);

✧由于项目进度不同,测试文档会根据不同的情况进行整合。

避免影响项目进度;

✧总结和整理测试过程中遇到的问题;

✧负责所有测试文档的归档备份。

5.运营人员

✧确认新需求或是需求变更时,需要与研发与测试人员沟通研发和测试时间

✧验收新版本中的新需求或是需求变更,验收通过测试人员提交测试报告后,商务人员提交上线部署单,产品方可上线。

【说明】:

测试完成:

是指对当前版本完成了测试,等待发布新版本进行回归测试。

测试结束:

是指经过N次测试后,所有bugs缺陷系统上所提出的问题均已解决,该模块测试关闭。

五版本发布标准

1.软件《需求说明》中定义的所有功能已全部实现,性能指标全部达到要求。

2.各级缺陷修复率达到标准。

3.所有测试产品、项目没有残余一级、二级、三级错误,四级、五级错误修复完成95%以上。

4.《需求文档》、《设计文档》和编码实现一致。

版本发布标准即验收标准

六错误级别说明

1.一级:

紧急的、阻塞开发或测试的工作进度,或影响系统无法运行的错误。

不能完全满足系统要求,基本功能未完全实现。

系统崩溃导致系统不能继续运行。

包括以下各种错误:

✧由于程序所引起的死机,非法退出

✧死循环

✧数据库发生死锁

✧因错误操作导致的程序中断,功能错误

✧与数据库连接错误

✧数据通讯错误

1.二级:

系统崩溃,丢失数据或内存溢出等严重错误、或者必需完成的任务

严重地影响系统要求或基本功能的实现,且没有更正办法(重新安装或重新启动该软件不属于更正办法)。

使系统不稳定、或破坏数据、或产生错误结果,或部分功能无法执行,而且是常规操作中经常发生或非常规操作中不可避免的主要问题。

✧程序接口错误

✧因错误操作迫使程序中断

✧系统可被执行,但操作功能无法执行(含指令)

✧单项操作功能可被执行,但在此功能中某些小功能(含指令参数的使用)无法被执行(对系统非致使的)在小功能项的某些项目(选项)使用无效(对系统非致命的)

✧业务流程不正确

✧功能实现不完整,如删除时没有考虑数据关联

✧功能的实现不正确,如在系统实现的界面上,一些可接受输入的控件点击后无作用;

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 初中教育 > 政史地

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1