软件系统测试报告模板Word文档格式.docx
《软件系统测试报告模板Word文档格式.docx》由会员分享，可在线阅读，更多相关《软件系统测试报告模板Word文档格式.docx（11页珍藏版）》请在冰豆网上搜索。
500G×
2，RAID0
应用服务器：
客户端
Inter（R）Core™2QuadCPUQ6600@2.4GHz
WindowsServer2003R2EnterpriseEditionSP2
2G
200G
1.3.2软件环境
客户端浏览器：
InternetExplorer6.0/7.0
GIS软件：
ArcGISServer9.3
WEB服务：
IIS6.0
2缺陷及处理约定
2.1缺陷及其处理
2.1.1缺陷严重级别分类
严重程度
修改紧急程度
评定准则
实例
高
必须立即修改
系统崩溃、不稳定、重要功能未实现
1、造成系统崩溃、死机并且不能通过其它方法实现功能；
2、系统不稳定，常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能。
3、用户需求中的重要功能未实现，包括：
业务流程、主要功能、安全认证等。
中
必须修改
系统运行基本正常，次要功能未实现
1、操作界面错误（包括数据窗口内列名定义、含义不一致）。
2、数据状态变化时，页面未及时刷新。
3、添加数据后，页面中的内容显示不正确或不完整。
4、修改信息后，数据保存失败。
5、删除信息时，系统未给出提示信息。
6、查询信息出错或未按照查询条件显示相应信息。
7、由于未对非法字符、非法操作做限制，导致系统报错等，如：
文本框输入长度未做限制；
查询时，开始时间、结束时间未做约束等。
8、兼容性差导致系统运行不正常，如：
使用不同浏览器导致系统部分功能异常；
使用不同版本的操作系统导致系统部分功能异常。
低
可延期修改
界面友好性、易用性、交互性等不够良好
1、界面风格不统一。
2、界面上存在文字错误。
3、辅助说明、提示信息等描述不清楚。
4、需要长时间处理的任务，没有及时反馈给用户任务的处理状态。
5、建议类问题。
3差异与错误汇总
3.1测试覆盖情况表
模块
是否覆盖
备注
模块1
完全覆盖
模块2
模块3
模块4
模块5
模块6
模块7
本次测试主要使用黑盒测试方法，在保证业务流程的正确性及稳定性的同时对功能的健壮性和安全性等方面进行了测试，新增模块均已覆盖，覆盖率达到100%；
3.2缺陷分布情况表
缺陷
严重级别
致命
严重
一般
轻微
建议
合计
3.3缺陷状态分布情况表
截止2016年06月05日，本系统共发现103个缺陷，目前缺陷状态如下表：
状态
Fixed
Closed
Open
Rejected
Reopen
3.4缺陷引入阶段统计表
缺陷识别阶段
缺陷注入阶段
需求开发与管理
软件设计
软件实现
软件集成及集成计划
系统测试
试运行及验收验收
需求评审
1
软件评审
代码评审+UT
集成测试
4
22
30
3.5缺陷类型统计
3.5.1缺陷类型/阶段分析
阶段
类型
1-设计缺陷
2-代码缺陷
3-UI缺陷
4-其他缺陷
3.5.2缺陷类型/模块分析
3.6系统缺陷趋势
本系统共进行了四轮测试，每轮测试情况如下表：
第一轮测试
第二轮测试
第三轮测试
第四轮测试
第五轮测试
当前发现
35
26
18
当前处理
17
39
5
8
累计发现
57
83
101
103
累计处理
56
61
91
遗留
12
缺陷趋势图如下：
从缺陷曲线来看，缺陷的发现曲线趋势相对比较正常，只是在第三轮测试中提交的缺陷有所反弹，从时间上来看，正好是第二次做用户调研前后，设计发生了一定的变更，新增了一些功能和业务逻辑，随之导致提交缺陷数量的上升。
从缺陷的处理曲线来看，起伏太大，在第三轮测试中，基本上对提交的缺陷没有进行处理，一直遗留到第四轮测试中才又集中对缺陷进行处理。
从缺陷的遗留曲线来看，在第二轮测试前后遗留的缺陷基本全部得到了处理，系统趋于稳定，而从第三轮测试开始遗留的缺陷又有较大的波动，而在第四、第五两轮测试中对缺陷的处理不够及时和有效，最终导致在第五轮测试结束后仍遗留了较多的缺陷。
从整体缺陷趋势图来看，在第二和第三轮测试之间的第二次用户调研对系统稳定性造成了一定的影响，功能上添加了一个模块类型，并针对原有的模块功能进行了较大的修改，新增的开发工作导致了对遗留的缺陷没有及时的进行修改和处理，并使得系统最终遗留下一些没有得到解决的缺陷。
4调试（纠错）后的测试结果与评价
4.1缺陷分析
根据对本次测试发现缺陷进行分析，本系统的缺陷产生的主要原因是设计，其中的原因又分为两点
从“3.4模块缺陷说明”可以看出，7个模块中，有4个模块因设计所产生的缺陷所占的比例超过或接近50%，其中模块1，63%、模块462%、电气设备设施周期检测表43%、模块661%。
具体又分为两个产生原因：
第一：
设计人员对设计文档的编写不够详细和全面；
设计人员在现场调研结束后编写的设计文档无法直接用来开发，设计文档是在开发活动的过程中由开发人员、设计人员和测试人员不断的提出改进和完善意见后，逐步完善的。
例如在各个报表的审核功能中，从用户调研到详细设计过程中，都没有考虑过审核不通过的情况，在测试人员编写测试用例时提出后，才在用户确认业务流程后重新修改了设计文档。
第二：
开发人员对设计的理解不够透彻所致；
设计文档从编写完成到开发活动开始，时间较短，开发人员不足，导致开发人员在着手开发前没有足够的时间对设计文档进行认真的通读和分析，往往时在开发过程中，才暴露出设计文档中的不足和缺失。
除此之外，在开发过程中仍然出现一些代码缺陷，如：
逻辑错误，SQL语句错误等，代码缺陷在所有提交的缺陷中约占30%。
4.2测试结论
该项目经过四个月，共五轮的测试，除模块6外，其余各模块系统比较稳定，基本可以满足用户对功能和业务的要求。
模块6由于用户的要求导致在较短的时间内，在数据采集和报表基本功能的基础上实现仓储软件的一部分功能，并且在设计，尤其是数据库设计上的缺陷（缺少基础表，导致表与表之间，字段与字段之间没有关联，需要用代码来控制一切可能出现的关联），导致该模块中仍存在较大的风险，仍有一部分缺陷没有处理，仍可能存在一些未被发现的缺陷。
鉴于公司目前开发人员紧缺的实际情况，模块6中存在的设计缺陷以及系统中仍然遗留的部分缺陷没有得到修改，建议在情况有所好转后，对物资设备表重新进行设计和开发，或者说服甲方放弃模块6中与仓储相关的功能。
5测试活动总结
本项目测试从20xx年xx月xx日开始，到20xx年xx月xx日截止，共经历五轮测试，由我公司测试人员完成。
具体见下表。
序号
姓名
技术水平
工作内容
工作量
测试管理
测试设计，测试管理，测试执行
测试员
测试执行
3
程序员
测试配合，缺陷修改
6
业务分析员
测试配合，设计修改
7
总计：
人/天
WelcomeTo
Download!
!
欢迎您的下载，资料仅供参考！
升级会员 