----测试报告

测试报告

1.目的

   

[根据测试需求，并编写测试计划，在此基础上收集和设计测试用例，且通过对被测系统基本功能、操作流程和业务流程的熟悉，执行测试用例，找出该系统在功能、界面、易用性等方面的缺陷，提交缺陷报告。通过该项目熟悉并掌握软件测试的流程，深入了解软件测试的实施过程。]

测试时间、地点及人员

版本名称	测试时间	测试人员	测试地点	起始时间	结束时间
6.2	2012-02-15	赵三航	公司	2012-02-15	2012-03-03

:环境描述

硬件环境	软件环境
名称	型号	大小	个数	名称	版本号
CPU	325	251	20	操作系统	7.2
内存				应用软件
硬盘				数据库

 

总结和评价

4.1测试过程统计

4.1.1 用例数统计

模块	规模	用例数(KLOC)	用例数/KLOC%
GUI界面	大	200	152

合计

4.1.2 用例对需求的覆盖度

需求id 用例数

SRS-某某项目-001

SRS-某某项目-002

SRS-某某项目-003

SRS-某某项目-004

SRS-某某项目-005

合计

4.1.3 用例的稳定性

模块	用例数	变更用例数
参数检查	520	35
统计代码
统计注释行	80	0
统计空行
统计总行
GUI界面
合计	600	35

4.1.4 用例的有效性

模块特性	用例数	发现的缺陷数	缺陷数/用例数
参数检查	2000	100	100/2000
统计代码
统计注释行	500	20	500/20
统计空行
统计总行
GUI界面
合计	2500	120	2500/120

4.1.5 测试执行工作量统计

模块特性	用例数量	投入人时	用时
参数检查	5000	5人	20天
统计代码	2000	2人	1天
统计注释行	3000	3人	1天
统计空行	1000	2人	1天
统计总行	500	1人	1天
GUI界面	6000	7人	30天
合计	17500	20人	54天

4.1.6 测试执行的效率

模块特性	执行用例数	发现缺陷数	人时	执行用例数	用时
参数检查	3000	50	6	1200	5天
统计代码	100	2	1	100	1天
统计注释行
统计空行
统计总行
GUI界面
合计	3100	52	7	1300	6天

4.1.7 版本缺陷统计

模块特性	缺陷个数	合计
参数检查	20	20
统计代码	12	12
统计注释行	15	15
统计空行	10	10
统计总行	20	20
GUI界面	30	30
合计	107	107

4.1.8 测试过程分析

（这里主要根据以上的统计数据和日常小组的工作情况，对测试过程中的异常情况，如测试延期，测试质量不高等问题进行说明，并适当分析原因，给出改进的建议。）

4.2 被测系统质量评估

4.2.2 缺陷个数

模块	用例数量	缺陷数	百分比
参数检查	5000	200	5000/200
统计代码	2000	100	2000/100
统计注释行	100	10	100/10
统计空行	300	10	300/10
统计总行	50	2	50/2
GUI界面	1500	10	1500/10
合计	8950	332	8950/332

4.2.3 缺陷严重等级评估

模块特性
致命	严重	一般	提示	合计
1	2	5	10	18

4.2.4 缺陷原因分布

缺陷原因	致命	严重	一般	提示	合计
需求	1	2	5	6	14
设计	2	5	5	2	23
编码	12	4	6	4	8
合计	15	11	16	12	45

4.2.5 测试用例的通过率

模块特性	OK项	NOK项	BLOCK项 NA项	合计	用例通过率％
编码	2000	600	50	2050	82%

4.2.6 软件质量评价

测试对象的整体质量：B

备注：A：质量稳定，适合大规模使用。

​ B：存在少数非严重问题，但有规避措施，可以局部使用。

​ C：基本功能可用，但严重问题较多，不能发布。

​ D：基本功能不可用

4.3 测试总结和改进建议

（这里主要根据以上的数据从测试过程，软件质量，以及各个团队在该项目中的协作进行整体的总结和评价，暴露项目中出现的问题，并积极提出改进的建议）

第五章节: 遗留问题报告

表1 遗留问题统计表

问题总数	A致命问题	B严重问题	C一般问题	D提示问题	C其他统计项
200	20	50	30	72	28

建议：

(1)开发人员在需求评审的时候能够根据代码能力和系统功能难易程度综合评估，尤其要考虑系统性能问题。

(2)测试人员在测试用例编写阶段要尽可能的设计细致，考虑全面

Bug等级分类

A级：严重程度为系统崩溃、系统死锁、严重错误或优先级为特级、

加急、高的 Bug 修复率 100%

B级：严重程度为次要错误或优先级为中的 Bug 修复率 90%以上

C级别：严重程度为不合理或别扭、文字错误、微不足道的 Bug 修复

率 80%以上

D级别：新特性或优先级为低的 Bug 可以暂时不做修复