网站测试报告Word格式.docx

网站测试报告Word格式.docx

《网站测试报告Word格式.docx》由会员分享，可在线阅读，更多相关《网站测试报告Word格式.docx（8页珍藏版）》请在冰豆网上搜索。

测试概要4

测试进度4

测试结果4

测试结论8

分析摘要9

建议9

典型缺陷引入原因分析10

编写目的

编写该测试总结报告主要有以下几个目的

1．通过对测试结果的分析，得到对软件质量的评价

2．分析测试的过程，产品，资源，信息，为以后制定测试计划提供参考

3．分析系统存在的缺陷，为修复和预防bug提供建议

定义

缺陷级别说明：

1.致命（最严重等级，缺陷导致系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、死机等）

2.严重（系统的主要功能部分丧失、数据不能完整保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响）

3.一般（系统的次要功能没有完全实现，但不影响用户的正常使用）

4.较小（操作不方便或遇到麻烦，但不影响功能的使用和执行）

测试对象

http:

//192.168.0.66:

8080/mlocsoMonitor/application.action

测试阶段

系统测试

测试工具

ZenTao缺陷管理系统

PLSQLDeveloper

IBMAppScan7.8

Loaderunner11

IEtester

参考资料

《XXXXX系统需求和设计说明书》

《XXXXX系统测试计划》

《XXXXX系统测试用例》

测试概要

XXXXX系统从2012年8月16日开始到2012年8月17日结束；

测试功能点6个；

测试共发现23个bug，其中严重级别的bug23个，平均每个测试功能点3.8个bug。

测试进度

此次测试严格按照项目计划和测试计划执行，按时完成了测试计划规定的测试对象的测

试。

针对测试计划规定的测试策略，在测试执行中都有体现，在测试执行过程中，依据测试

计划和测试用例，对系统进行了完整的测试

测试结果

Bug趋势图

从Bug趋势图来看，8月16、17号测试进度正常，一共发现了23个bug。

由于此位置网站监控系统只有应用程序、中间件、操作系统这3个模块，每个模块功能基本一致，因此，测试上各个模块发现的问题基本一样。

Bug严重程度

BUG分布

测试发现的bug，出现了23个严重级别的bug，出现严重级别的bug主要表现在以下几个方面

1.系统功能未完全实现；

2.监控查询界面设计缺陷；

3.监控系统刷新频繁，导致数据冗余。

BUG类型统计

通过bug类型统计图可以看出，本次位置网站监控系统设计缺陷比重较大，主要原因有：

1）理解何种输入是正确的，但是用户输入错误后，系统提示出错。

2）提示信息错误，不同模块相同结果的提示信息不一致，用户操作后，相应的提示信息不明确引起用户误解。

3）一致性，用户在不同页面执行相同的操作，提示信息不同。

4）易用性：

监控系统界面按时间查询后没有重置按钮，只有页面刷新后才可以重新查询。

测试结论

功能性

测试运用了等价类划分、错误推测法、边界值分析法进行测试、充分验证了系统的以下功能

1.应用程序系统监控；

2.中间件系统监控；

3.操作系统监控；

4.监控指标

5.监控报表导出

6.界面自动刷新功能

7.监控介面信息查询

8.监控介面信息分页查询

系统在实现功能的过程中，在细节方面存在这较多的缺陷，例如在添加字段的时候当不能判断添加的数据项是否为空、是否符合数据库中规定的数据类型、实现分页是否能够比较稳定的实现等，在以后要继续完善。

易用性

●现有系统实现了如下易用性：

1.应用程序、中间件、操作系统的查询操作相关提示信息的一致性，可理解性

2.输入限制的正确性

3.输入限制提示信息的正确性，可理解性，一致性

●现有系统存在如下易用性缺陷：

1.界面排版不美观

2.输入，输出字段的可理解性差

3.输入缺少解释性说明

兼容性

现有系统支持window下的IE6-8浏览器，支持1024*768以上分辨率

现有系统未进行其他兼容性测试

安全性

●现有系统控制了以下高危安全性问题：

1.跨站脚本攻击（跨站脚本编制）

2.sql注入

3.目录泄露

4.检测到目标站点存在SVN相关文件

●仍遗留低危安全性问题

1.跨站请求伪造

2.HTML注释敏感信息泄露

分析摘要

覆盖率

此次测试，部分页面需求描述无明确的定义，对输入限制无详细定义，无明确的测试依

据，在测试过程中，测试是根据输入字段含义，测试人员理解，以及和项目经理，开发人员

沟通获得测试依据，无法保证测试依据的正确性和完整性，因此，没有进行完整的，正确的

无效数据的测试，测试覆盖率不够，无法保证测试的有效性和正确性

下面为此次测试测试用例覆盖率分析图：

建议

1.在项目开始的时候应该制定编码标准，数据库标准，需求变更标准，开发和测

试人员都严格按照标准进行，可以在后期减少因为开发，测试不一致而导致的

问题，同时也可以降低沟通成本。

2.每次申请测试的时候，正确布置测试环境，减少因为测试环境，测试数据库数据的

问题而出现的无效bug。

3.开发人员解决bug的时候，填写bug原因以及解决方式，对于需求上没明确定义标准的BUG，需向产品部确认后回复。

4.开发人员在开发版本上发现bug，可以通知测试人员，因为开发人员发现的bug

很有可能在测试版本上出现，而测试人员和开发人员的思路不同，有可能测试人

员没有发现该bug，而且，这样可以保证发现的bug都能够被跟踪。

典型缺陷引入原因分析

测试过程中发现的缺陷主要有以下几个方面：

1.需求定义不明确

需求文档中，存在功能定义错误，输入输出字段描述错误，输入输出字段限制定

义错误，输入输出限制定义缺失这几种类型的缺陷。

使得开发人员根据需求进行设计

时，没有考虑相关功能的关联性，以及需求错误的地方，在测试过程中，需求相关的

问题表现出来。

需求做改正，设计必须跟着做改动，浪费时间和影响开发人员的积极

性，降低开发人员对需求的信任，可能会导致开发人员不按照需求进行设计而根据自

己的经验来进行设计。

2.功能性错误

系统在输入数据的检查方面有一些措施但是不完善，对于部分非法输入会导致系统异常，建议加入数据检查和异常处理能力。

3.页面设计易用性缺陷

5）页面设计不友好，界面栏应整齐排列。

6）理解何种输入是正确的，但是用户输入错误后，系统提示出错。

7）提示信息错误，不同模块相同结果的提示信息不一致，用户操作后，相应的提示信息不明确引起用户误解。

8）提示信息一致性，用户在不同页面执行相同的操作，提示信息不同。