软件测试管理规范.doc
- 文档编号:393136
- 上传时间:2022-10-09
- 格式:DOC
- 页数:8
- 大小:82KB
软件测试管理规范.doc
《软件测试管理规范.doc》由会员分享,可在线阅读,更多相关《软件测试管理规范.doc(8页珍藏版)》请在冰豆网上搜索。
软件测试工作规范
1 目的
Ø 统一公司所有项目的软件测试流程;
Ø 提供一套适合公司所有项目并可裁减的软件测试工具;
2 范围
Ø 本规范中单元测试适用于所有的JAVA项目;
Ø 本规范中集成测试、系统测试和性能测试适用于所有项目。
3 测试阶段与软件开发阶段的对应关系
1 过程描述
1.1 单元测试活动
该活动包括以下环节:
l 编写单元测试计划;
l 设计单元测试用例;
l 执行单元测试过程;
l 记录单元测试缺陷;
l 编写单元测试报告;
1.1.1 活动目的
验证软件系统模块内功能、容错、界面和报表测试和桩模块、子模块之间的接口测试。
1.1.2 角色与职责
角色
职责
项目经理
监控单元测试过程;
开发组长
开发人员
编写单元测试计划;
对单元代码进行检查,设计单元测试用例;
执行测试用例;
记录单元测试缺陷,修改缺陷并关闭缺陷;
编写单元测试分析报告;
配置管理员
管理测试需要的资源,包括软硬件环境,版本管理和Bug管理。
1.1.3 测试范围
l 单元模块的功能性测试
l 单元模块内和模块之间的接口测试
l 单元模块的容错性测试
l 单元模块的界面测试
l 单元模块内的权限
1.1.4 进入条件
已经完成被测模块的编码工作
1.1.5 输入
《详细设计说明书》
1.1.6 活动说明
对于结构化的编程语言,程序单元指程序中定义的函数或子程序。
单元测试是指对函数或子程序所进行的测试。
对于面向对象的编程语言,程序单元指特定的一个具体的类或相关的多个类。
单元模块之间的接口等。
(1) 开发人员依据详细设计编写单元测试计划和和单元测试用例,《详见junit使用说明》和《jprobe使用说明》,需详细描述该用例的输入、输出和预期结果等相关内容;
(2) 开发人员编写程序代码;
(3) 开发人员执行单元测试用例,并记录执行结果;
(4) 开发人员执行测试用例过程中发现的缺陷,必须提交到缺陷跟踪工具中;
(5) 开发组长完成单元测试后,编写单元测试分析报告,项目经理审核《单元测试分析报告》。
1.1.7 输出
已通过回归测试、打标签单元级的代码
《单元测试分析报告》
1.1.8 退出条件
l 被测代码语句覆盖率满足单元测试计划中制定的代码覆盖率要求;
l 测试用例执行覆盖率应达100%;
l 《单元测试分析报告》通过评审;
l A类缺陷、B类缺陷、C类缺陷为零,D类缺陷少于10%,E类缺陷少于15%。
1.1.9 工具与方法
l JAVA项目
Junit3.7以上版本:
利用Junit提供的组件测试代码的功能逻辑;
Jprobe5.0以上版本:
使用Coverage组件检查代码覆盖率。
l 工具使用
参见《Junit使用简明手册》,《Jprobe使用简明手册》。
1.2 集成测试活动
该活动包括以下环节:
l 编写集成测试计划;
l 设计集成测试用例;
l 执行集成测试过程;
l 记录集成测试缺陷;
l 编写集成测试分析报告;
1.2.1 活动目的
1.2.2 角色与职责
角色
职责
项目经理
协调软硬件和人力资源、风险控制等;
测试经理
协调相关测试资源,风险控制等;
跟踪集成测试执行过程;
测试组长
测试工程师
制定集成测试计划;
编写编写测试用例;
执行集成测试用例;
提交缺陷;
回归测试;
编写集成测试分析报告;
架构师
协助测试组长制定集成测试计划。
确认测试缺陷,并分发测试缺陷于开发人员进行修改;
评审集成测试计划、测试用例、集成测试分析报告;
开发人员
修改缺陷;
提交缺陷修改程序代码;
配置管理员
管理测试需要的资源,包括软硬件环境,版本管理和缺陷跟踪管理。
建立代码基线,配合进行配置检查。
1.2.3 测试范围
l 系统集成后的功能性测试;
l 系统集成后的容错性测试;
l 系统集成后的界面测试;
l 系统集成后的安全(权限)测试;
l 系统集成后的系统的内部接口测试;
l 系统集成后的可用性测试;
l 系统集成后的数据完整性测试。
1.2.4 进入条件
《概要设计说明书》通过评审
1.2.5 输入
《概要设计说明书》
1.2.6 活动说明
(1) 测试组长制定《集成测试计划》;
(2) 测试人员负责组织编写集成测试用例,编写测试脚本,编写测试用例。
(3) 测试人员执行测试用例。
(4)测试过程中发现缺陷提交到缺陷跟踪系统;
(5)架构师对缺陷进行评估并分发,若判断是缺陷则指定相关开发人员进行修改;
(6) 开发人员修改完缺陷后,由测试人员进行回归测试,测试通过则缺陷关闭,检验未通过,则转给开发人员,继续修改;
(7) 测试人员编写集成测试分析报告。
1.2.7 输出
l 已通过回归测试、打标签系统级的代码;
l 《集成测试分析报告》;
l A类缺陷、B类缺陷、C类缺陷为零,D类缺陷少于5%,E类缺陷少于10%。
1.2.8 退出条件
《集成测试分析报告》通过评审
代码基线化
1.2.9 工具与方法
因具体项目而定
1.3 系统测试
该活动包括以下环节:
l 编写系统测试计划;
l 设计系统测试用例;
l 执行系统测试过程;
l 记录系统测试缺陷;
l 编写系统测试分析报告;
1.3.1 活动目的
通过与系统的需求规格作比较,从功能和非功能两方面,发现软件与系统需求规格不相符合或与之矛盾之处。
1.3.2 角色与职责
角色
职责
项目经理
协调软硬件和人力资源、风险控制等;
测试经理
协调相关测试资源,风险控制等
跟踪系统测试执行过程;
测试组长、测试工程师
制定系统测试计划;
在架构师的协助下,搭建系统测试环境;
编写系统测试用例;
执行系统测试用例;
提交缺陷;
回归测试;
编写系统测试分析报告;
架构师
协助测试组长制定系统测试计划。
确认测试缺陷,并分发测试缺陷于开发人员进行修改;
评审系统测试计划、测试用例、测试分析报告;
开发人员
修改缺陷;
提交缺陷修改程序代码;
配置管理员
管理测试需要的资源,包括软硬件环境,版本管理和缺陷跟踪管理。
建立代码基线,配合进行配置检查。
1.3.3 系统测试范围
l 系统的功能性测试;
l 系统的初始化测试;
l 系统的(负载,性能,并发)测试;
l 系统的配置测试;
l 系统的安全性测试(防火墙,TLS,SSL安全机制,加密);
l 系统的外部接口测试;
l 系统的数据完整性测试;
l 系统的可用性测试;
l 系统的安装部署测试;
l 系统的恢复性测试;
l 系统的可移植性测试
l 系统的文档测试。
1.3.4 进入条件
l 《需求说明书》经过评审;
1.3.5 活动说明
(1) 测试组长制定《系统测试计划》;
(2) 测试组长负责组织编写系统测试用例、编写测试脚本,编写测试用例;
(3) 测试组长在架构师的协助下搭建与用户需求一致的测试环境,质量管理部配合确认测试环境,参见《系统环境确认单》;
(4) 测试人员执行测试用例;
(5) 测试过程中发现缺陷提交到缺陷跟踪系统;
(4) 架构师对缺陷进行评估,若判断是缺陷则指定相关开发人员进行修改;
(5) 开发人员修改完问题后,由问题提出人进行回归测试,测试通过则缺陷关闭,检验未通过,则转给开发人员,继续修改;
(6) 测试组长编写《系统测试分析报告》。
1.3.6 输出
已通过回归测试、打标签系统级的代码
《系统测试分析报告》
1.3.7 退出条件
l 系统测试报告通过评审;
l 代码基线化;
l A类缺陷、B类缺陷、C类缺陷为零,D类缺陷少于3%,E类缺陷少于6%。
1.3.8 工具与方法
因项目的需求而定。
1.4 性能测试
该活动包括以下环节:
l 编写性能测试计划;
l 设计性能测试用例;
l 搭建性能测试环境;
l 执行性能测试过程;
l 记录性能测试缺陷;
l 编写性能测试报告;
1.4.1 活动目的
检查系统是否满足在需求说明书中规定的性能要求。
1.4.2 角色与职责
角色
职责
项目经理
协调软硬件和人力资源、风险控制等;
测试经理
协调相关测试资源,风险控制等;
跟踪系统测试执行过程;
测试组长
测试工程师
制定性能测试计划;
执行性能测试脚本;
提交缺陷;
回归测试;
编写性能测试分析报告;
架构师
协助测试组长制定性能测试计划;
确认测试缺陷,并分发测试缺陷于开发人员进行修改;
评审《性能测试计划》、《性能测试用例》、《性能测试分析报告》;
开发人员
修改缺陷;
提交缺陷修改程序代码;
配置管理员
管理测试需要的资源,包括软硬件环境,版本管理和缺陷跟踪管理。
建立代码基线,配合进行配置检查。
1.4.3 测试范围
性能测试的主要是范围:
l 系统的大用户压力;
l 系统的并发用户压力;
l 系统的数据库压力;
l 系统的稳定性等。
1.4.4 进入条件
《需求规格说明书》通过评审;
1.4.5 输入
《需求规格说明书》
1.4.6 活动说明
(1) 测试组长根据《需求规格说明书》了解系统性能需求
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 管理 规范