测试报告项目测试环境.docx
《测试报告项目测试环境.docx》由会员分享,可在线阅读,更多相关《测试报告项目测试环境.docx(15页珍藏版)》请在冰豆网上搜索。
测试报告项目测试环境
XX项目
测试报告
版本信息
日期
版本
状态
简要描述
编写
审核
批准
2018-07-18
V1.0.0
N
首次建立项目测试报告(标准版)模板
xxx
注:
状态可以为N-新建、A-增加、M-更改、D-删除
2测试参考文档
3项目信息
4测试概述
4.1基本信息
4.2测试过程
4.3测试范围
5测试过程评估
5.1测试设计
5.1.1测试用例
5.1.2测试方法
5.2测试执行
5.2.1测试用例覆盖总结
5.2.2测试用例执行总结
6缺陷统计与分析
6.1缺陷统计
6.2缺陷分析
6.2.1
缺陷分布-
-按严重等级划分.
6.2.2
缺陷分布-
-按功能模块划分.
6.2.3
缺陷分布-
-按缺陷类型划分.
6.2.4
缺陷趋势-
-新增缺陷
6.2.5
缺陷趋势-
-重新打开缺陷.....
6.2.6
缺陷趋势-
-修改缺陷
6.2.7
缺陷趋势-
-关闭缺陷
7版本需求变更分析
7.1需求变更描述
7.2需求变更统计
8版本演进轨迹
9测试总结
9.1
测试结论•……
9.2
测试建议…•…
9.3
遗留问题列表
9.4
风险分析•……
编写目的
本测试报告为【XX】项目的测试报告,目的在于总结测试阶段的测试情况以及分析测试结果,描述系统是否符合需求并对测试质量进行分析。
本报告作为测试质量参考文档提供给用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理阅读。
测试参考文档
《用户需求说明书》
《软件需求规格说明书》
《软件开发计划》
《软件测试计划》
《软件测试方案》
《软件测试策略》
《软件测试用例》
《缺陷分类指南》
《功能及UI测试标准》
项目信息
项目名称
xx
项目编号
xxx
项目周期
2018/1/19~2018/2/26
项目性质
全新产品/大版本升级/小版本升级(只能选择一个)
项目版本号
项目经理
xxx
测试经理
xxx
测试工程师
xxx
开发工程师
xxx
测试概述
基本信息
本次测试的基本信息如下:
测试时间
2018/1/19~2018/2/26
测试环境
硬件
处理器:
InterCorei5,1.6GHz内存:
8GB
操作系统:
Windows10
软件
NavicatPremium、xshell、IE,FireFox,CoogleChrome等浏览器
测试站点
xxx
测试过程
阶段
任务说明
开始时间
结束时间
工作量
(人/天)
责任人
计划
实际
计划
实际
计划
实际
计
划
实际
测试准备
编写测试计划
2018-3-25
2018-3-25
2018-3-25
2018-3-25
0.5
0.5
xxx
需求理解澄清
无
无
无
无
编写测试策略
编与测试方案
编写测试用例
评审测试用例
测试环境准备
测试数据准备
测试脚本准备
测试执行
系统测试
回归测试
测试结束
编写测试报告
编写用户手册
项目实施
培训
项目部署
测试范围
任务
测试覆盖功能点
一级功能
二级功能
三级功能
历史
新增及修改
测试过程评估
测试设计
测试用例
1、测试用例的设计方法采用等价类划分、边界值、因果图、错误推测法等。
2、依据需求文档和原型图设计测试用例,测试用例覆盖所有需求功能点,在评审通过后执行测试。
测试方法
根据系统需求规格说明书的描述,明确指出了系统应该具有的功能。
在完全不考虑程序内部结构和内部特性的情况下,测试者只需检查程序功能是否按照系统需求规格说明书的规定正常使用,是否能在输入适当的数锯下产生正确的输出信息,并且能保持外部信息(如数据库或文件)
的完整性。
因此采用了着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试的测试方法:
黑盒测试。
本次测试的重点集中在基本数据录入、业务流程和各功能模块间的接口。
测试执行
测试用例覆盖总结
1、执行的测试用例数覆盖了所有的功能点
模块名称
用例数
(条)
覆盖情况
执行情况
客户管理
94
系统测试2轮,验收测试2轮
执行94条,未通过1条
用例通过率:
98.94%
测试用例执行总结
测试执行统计表
测试用例版本号
工作量投入(人
天)
测试用例规模
总用例数
新增用例数
vl.0.0
4
1234
23
执行结果统计表
计划执行的用例数
实际执行的用例数
通过的用例数
执行率
覆盖率
通过率
发现缺陷数
执行率=实际执行的用例数*计划执行的用例数
覆盖率=实际执行的用例数-总用例数
通过率=通过的用例数*实际执行的用例数
发现缺陷数=本次版本一共提交了多少个BUG单
<案例总数与计划执行案例数不一致,请说明原因。
(指本次测试总案例数与本次测试总的计划执行案例数),与本文最后一个章节的风险相对应。
>
<计划执行案例数与实际执行案例数不一致,请说明原因。
(指本次测试总的计划执行案例数与本次执行总的实际执行案例数),与本文最后一个章节的风险相对应。
>缺陷统计与分析
缺陷统计
缺陷总计:
28个;
打开:
17个;
处理中:
2个;
重新打开:
3个;
已解决:
5个;
已关闭:
1个
缺陷分析
缺陷分布--按严重等级划分
缺陷严重等级
合计
已关闭
未解决
已关闭所占百分比
轻微-Trivial
一般-Minor
重要-Major
严重-Critical
阻塞-Blocker
缺陷分布--按功能模块划分
模块名称
合计
已关闭
未解决
已关闭所占百分比
缺陷分布--按缺陷类型划分
缺陷类型
合计
已关闭
未解决
已关闭所占百分比
需求冋题
4
1
3
25%
代码问题
3
1
2
33%
设计问题
6
2
4
33%
配置问题
4
2
2
50%
环境问题
4
3
1
75%
兼容问题
9
4
5
44%
安全问题
3
1
2
33%
性能问题
3
3
0
100%
脚本问题
3
1
2
33%
数据问题
4
3
1
75%
其他
7
4
3
57%
非缺陷
5
1
4
20%
缺陷趋势--新增缺陷
缺陷趋势--重新打开缺陷
缺陷趋势--修改缺陷
缺陷趋势--关闭缺陷
版本需求变更分析
需求变更描述
本次版本测试共收到35个需求变更:
其中14个为测试过程中已有项目的需求变更,主要
集中在准时装项目、海外购二期项目、在线支付异常同步商家需求等需求中;4个技术优化,17个为新增的需求变更。
本次版本需求变更数量依旧不少,需求变更方面的控制还需加强,版本的变更对版本质量的影响很大,本次版本发布风险较高。
需求变更统计
新增需求:
12个
变更需求:
1个
需求优化:
23个
版本演进轨迹
罗列本项目内的所有分支及各个分支合并后的回归测试
版本号
发布时间
是否合并
回归测试结果
2018-07-19
否
通过
测试总结
测试结论
<对测试的过程和结果进行简要分析,给出测试结论和建议>
<测试结论要明确,即通过或者不通过,不能附带任何条件。
对于有条件通过的需求,需要在后续风险分析”章节进行描述>,有条件通过是根据准出条件有部分条件不通过,具体准则如下:
通过—达到准出条件,女口:
测试案例执行率达到95%、阻塞和致命的缺陷全部修复且测试通过、严重缺陷修复率超过95%、一般缺陷修复率已超过85%、提示缺陷修复率超过75%;
不通过----未达到准出条件,如:
测试案例执行率低于95%、阻塞和致命缺陷未全部修复或复测未通过、严重缺陷修复率未达到95%、一般缺陷修复率未达到85%,提示缺陷修复率未达到75%;
有条件通过----指未达到准出条件但项目责任人确认相关风险,或风险可以得到处理,在此条件下同意测试有条件通过。
1、通过对本系统的两轮测试工作,将系统所存在的缺陷全部暴露并交予开发人员进
行bug修复,再经过回归测试确保了所有功能及模块已经实现,并且满足客户需
求。
2、本系统的测试充分有效,主要业务模块的测试覆盖达到100%缺陷解决率达到100%
3、目前的测试工作基本达到了预定目标,即完成除原有的系统功能外的所有功能及
模块功能的功能测试,测试任务已全面完成。
4、根据测试结果、BUG勺修复率和测试计划中的测试通过标准得出该项目功能测试通
过,可以交付使用。
测试建议
1、从测试的整个过程来看,比较常见的问题是:
编辑框中数据输入过长不能正确处
理或者页面变形,页面样式不统一(翻页、提示语等),数据添加成功,上传附件
不显示,查询冗余数据等。
开发人员在编码过程中,系统在实现基本功能的前提下需要注意页面样式的一致性和操作界面友好性等非功能的方面。
2、在这次测试过程中,提出建议:
测试人员在提交bug时,需要详细描述:
版本号、操作步骤、期望结果、实际结果,以便开发人员读懂并能重现bug,避免将bug
直接打回,延长bug的存在周期。
同时开发人员必须将打回bug之前需给予问题
解答的简单描述,以利于回归测试。
在本次测试中因没有按照标准执行,导致有
些bug在回归几次后才有效解决,所以必须在以后的测试项目中测试人员和开发人员严格按照标准执行。
3、在本次测试过程中存在一个问题多次修改的情况。
造成此问题出现的最主要原因
是开发人员在提交新版本时未进行单元测试。
所以,我们建议开发人员将程序包
提交给测试人员之前先对程序代码进行检查,这样能有效地缩短BUG的生存周期,
提高测试人员和开发人员的工作效率。
遗留问题列表
<给出遗留的影响到系统上线或者进入下一个环节的问题,比如,状态为致命”的测试缺陷,或
者需要重点关注的状态为严重”的测试缺陷。
对于其他需要需求负责人、开发负责人、版本负责人等加以关注或者加以改进的问题,也需要在此处列出>
缺陷编号
缺陷描述
严重级
别
重现
概率
影响说明
遗留原因
致命
100%
导致系统崩溃
需求变更,待确认需求后统一修改
严重
100%
导致数据丢
失
数据库迁移,待迁移后修复
风险分析
<对系统上线或者进入下一个环节有可能存在的风险进行分析,并提出规避的措施或者建议,以
便相关人员对此进行关注或者解决问题>
序号
风险问题类型
风险问题描述
风险
等级
提出人
提出时间
责任人
应对解决万案
计划解决日期
问题状态
备注
1
第三方
插件问
第三方插件
无法正常加
中
XXX
XXX
开发在查
问题中
未解
题
载
决
2
代码重
构
代码重构后,引发大量BUG
高
XXX
XXX
开发修改
未
解
决
3
需求变更过于频繁,无法及时开发完成
中
XXX
XXX
下个版本
迭代开发
需求变
更