软件测试报告

 项目：坦克世界游戏

专业：   软件技术  

班级：   09-23班   

学号：  090123007  

姓名：    王亚松   

石家庄科技信息职业学院

信息科学系

20##年12月

测试报告内容：

一、项目需求

1.      测试一下一些新出的坦克的性能。

2.      测试一下新地图的参数。

3.      测试都有那些内容修改过。

二、测试计划

1．简介

1.1 ：D系轻坦：VK2801、S系轻坦：T-50、T-50-2、M系轻坦：M24、M系中坦：M4A3E2、金币坦克：59式这些坦克的坦克模型、坦克弹道、坦克跑动音效、坦克开炮音效、坦克部件升级经验、坦克部件升级金钱等。

1.2 : 地图：费舍尔湾 的 地图加载、地图场景贴图（树、房子……）、地图场景音、地图场景风、地图视野等。

1.3 :测试一些修改的内容。

2．准备测试的功能

3．不准备测试的功能

炮弹的伤害值，坦克的移动速度。

4．方法

应用黑盒技术。

黑盒技术：主要是测试功坦克的性能。

5．测试提交产物

5.1本测试报告

6．测试任务

6.1认真完成本测试

6.2得到测试报告

7．游戏测试环境

表2.1游戏测试环境

8．测试计划

表2.2测试计划表

三、设计测试用例

用例1：运行游戏，选择D系轻坦：VK2801在费舍尔湾测试其坦克模型、坦克弹道、坦克跑动音效、坦克开炮音效坦克出售金钱、坦克详细信息，以及地图的有关信息。

用例2：运行游戏，选择S系轻坦：T-50、T-50-2在费舍尔湾测试其坦克模型、坦克弹道、坦克跑动音效、坦克开炮音效坦克出售金钱、坦克详细信息，以及地图的有关信息。

用例3：运行游戏，选择M系轻坦：M24、在费舍尔湾测试其坦克模型、坦克弹道、坦克跑动音效、坦克开炮音效坦克出售金钱、坦克详细信息，以及地图的有关信息。

用例4：运行游戏，选择M系中坦：M4A3E2、在费舍尔湾测试其坦克模型、坦克弹道、坦克跑动音效、坦克开炮音效坦克出售金钱、坦克详细信息，以及地图的有关信息。

用例5：运行游戏，选择金币坦克在费舍尔湾测试其坦克模型、坦克弹道、坦克跑动音效、坦克开炮音效坦克出售金钱、坦克详细信息，以及地图的有关信息。

用例6：对比一下修改内容。

四、游戏界面测试

用例1，游戏界面是否与软件功能相融洽

测试人员评价：是

用例2，游戏界面所有的文字是否正确无误

测试人员评价：是

用例3，用户能否不必阅读手册就能使用

测试人员评价：否

用例4，是否所有图标不会让人误解

测试人员评价：是

用例5，是否符合广大用户使用同类软件的习惯

测试人员评价：是

五、测试缺陷报告

表5.1

                                 表5.2

表5.3

六、测试总结报告

在软件运行成功后，测试人员要对软件进行测试，以便使用户正常使用软件。软件测试无法做到穷举测试。设计和运行测试用例还需要耗费人力和物力。因此，软件测试追求的目标是以尽可能少的测试用例发现软件中尽可能多的错误或缺陷。黑盒测试确认软件满足需求，动态软件测试实践中，集成测试和系统测试阶段主要使用黑盒测试。

 通过对实训项目进行测试，使我以后做程序会更加完善，也使我更加一步了解了测试在开发期间的重要性，一个软件，如果不经过测试人员的测试，不能投放在市场上，以免引起不必要的麻烦。

非常感谢老师的细心教导，和同学们的帮助，使我能够顺利的完成测试。

第二篇：软件测试报告

1 引言

1.1编写目的

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

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

3．评估测试执行和测试计划是否符合

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

1.2背景

1.3用户群

主要读者：XX项目管理人员，XX项目测试经理

其他读者：XX项目相关人员

1.4定义

严重bug：出现以下缺陷，测试定义为严重bug

√ 系统无响应，处于死机状态，需要其他人工修复才可复原。

√ 点击某个菜单后出现（增加、修改、删除等）后，出现”The page cannot be displayed”或者返回异常错误

√ 当对必填字段进行校验时，未输入必输字段，出现”The page cannot be displayed”或者返回异常错误

√ 系统定义不能重复的字段输入重复数据后，出现”The page cannot be desplayed”或者返回异常错误

1.5测试对象

略

1.6测试阶段

系统测试

1.7测试工具

Bugzilla缺陷管理系统

1.8参考资料

《XX需求和设计说明书》 《XX数据字典》

《XX后台管理系统测试用例》 《XX项目计划》

2 测试概要

XX后台管理系统测试从20xx年7月2日开始到20xx年8月10日结束，共持续39天，测试功能点174个，执行2385个测试用例，平均每个功能点执行测试用例13.7个，测试共发现427个bug，其中严重级别的bug68个，无效bug44个，平均每个测试功能点2.2个bug。 XX总共发布11个测试版本，其中B1-B5为计划内迭代开发版本（针对项目计划的基线标识），B6-B8为回归测试版本。计划内测试版本，B1-B4测试进度依照项目计划时间准时完成测试并提交报告，其中B4版本推迟一天发布版本，测试通过增加一个人日，准时完成测试。B5版本推迟发布2天，测试增加2个人日，准时完成测试。

B6-B11为计划回归测试版本，测试增加5个工作人日的资源，准时完成测试。

XX测试通过Bugzilla缺陷管理工具进行缺陷跟踪管理，B1-B4测试阶段都有详细的bug分析表和阶段测试报告。

2.1进度回顾

2.2测试执行

此次测试严格按时项目计划和测试计划执行，按时完成了测试计划规定的测试对象的测试。针对测试计划规定的测试策略，在测试执行中都有体现，在测试执行过程中，依据测试计划和测试用例，对系统进行了完整的测试

2.3测试用例 2.3.1功能性

系统实现的主要功能，包括查询，添加，修改，删除。

系统实现的次要功能，包括为用户分配酒店，为用户分配权限，渠道酒店绑定，渠道RATE绑定，权限控制菜单按钮。

需求规定的输出字段，以及需求规定的输入限制。

2.3.2易用性

操作按钮提示信息正确性，一致性，可理解性 限制条件提示信息正确性，一致性，可理解性 必填项标识

中文界面下数据语言与界面语言的一致性

3 测试环境 3.1.1软硬件环境

4 测试结果 4.1 Bug趋势图

此次黑盒测试总共发布11个版本，B1-B5为计划内迭代开发版本（针对项目计划的基线标

识），B6-B11为进行的回归测试版本，bug版本趋势图如下图所示：

第一阶段，增量确认测试

时间从20xx年7月2日到20xx年8月3日。从Bug趋势图中可以看出，每个版本的bug数基本维持在60个左右。

B1：从图中看到B1共有33个BUG，因为B1版本有一个功能模块在B2版本才开始测试，B1测试模块相对较少，所以B1版本bug相对较少。

B2：由于B1中的一个功能模块增加到Build 2中进行测试，这一版本除了对B1中的BUG进行验证同时对B1进行了回归测试，所以B2中的bug数相对B1出现了明显的增长趋势， B3：B3版本因为有B2版本的bug验收测试，以及B1,B2的回归测试，共发现67个bug，和B2基本保持一致。

B4：B4版本bug数有一个下降的趋势，是因为B4版本推迟发布，新增加了测试人员参与测试，对系统不够熟悉，以及测试时间紧张，部分测试用例没有执行，测试覆盖度不够，所以发现bug数呈下降趋势。

B5：B5版本bug数又有一个增加的趋势，主要是由于开发功能模块多，该版本需求定义不明确。

第二阶段，BUG验证和功能回归确认测试。

时间从20xx年8月4日到20xx年8月14日。B6和B7进行了回归测试，B8没有进行回归测试，只验证了B1-B7的bug。

B6：进行第一轮回归测试，发现的bug数为33个，遗留一个问题，为数据字典种类默认值问题

B7：进行第二轮回归测试，第一次回归测试没有涉及到权限控制菜单按钮的测试，在本次回归测试的时候，重点进行了这个方面的测试，又发现了大量权限相关的bug。

B8：B8没有进行全面的回归测试，只验证了B1-B7未通过验证的bug，所以该版本的bug数明显比较少。

B9：B9版本进行了全面的回归测试，同时重点测试了权限控制，所以发先的bug数又呈现上升的趋势。测试发现44个bug，严重级别的bug为14个，严重级别的bug集中在权限控制上，功能性严重bug没有发现，说明权限控制依旧不稳定，但是系统功能已经稳定。 B10：B10版本验证了B9版本发现的bug，没有进行全面的回归测试。B10版本新发现的

bug

详细分析见遗留bug分析。

B11：B11中验证了B1-B10未验证的bug，重点测试了权限控制，同时进行了查询，添加，删除，修改的功能测试，测试过程中未发现bug。

4.2 Bug严重程度

测试发现的bug主要集中在normal和minor阶段，属于一般性的缺陷，但是测试的时候，出现了68个严重级别的bug，出现严重级别的bug主要表现在以下几个方面

√ 系统主要功能没有实现

√ 添加数据代码重复后，出现的找不到页面的错误

√ 多语言处理，未考虑非语种代码的情况

√ 数据库设计未考虑系统管理员角色，导致用系统管理员进行操作的时候出现找不到页面错误

√ 权限控制异常

严重级别bug近版本分布如下：

由严重bug版本分布图可以看出，严重级别的bug版本趋势和bug版本趋势基本是一致的，但是，在B7和B9版本中，严重级别的bug明显增多，主要原因是B7和B9版本测试了权限控制按钮功能，权限问题出现的严重级别的bug比较多。

权限bug主要表现：

√ 具有相应按钮操作的权限，页面无相应按钮，无法执行该功能

√ 无相应按钮操作权限，页面有相应按钮，点击按钮能出现权限异常错误

√ 有相应按钮操作权限，有相应按钮，执行该功能出现权限异常错误

4.3 Bug引入阶段

由上图可以看出，主要为前台编码和页面设计方面的bug，占到了全部bug的2/3。

4.4 Bug引入原因

由bug状态图可以看出，未解决的bug有4个，主要是B8中新提交的bug，是关于用户管理的bug，因为用户权限管理需要重新设计，所以，该部分的bug暂时没有解决。

4.4 Bug状态分布

由bug状态图可以看出，未解决的bug有4个，主要是B8中新提交的bug，是关于用户管理的bug，因为用户权限管理需要重新设计，所以该部分的bug暂时没有解决。

5 测试结论

5.1功能性

系统正确实现了通过数据字典管理基础的功能，实现了数据内容的多语言功能，实现了中英文界面。实现了基础数据管理，酒店集团管理，酒店基础信息管理，渠道管理，代理管理，用户管理的查询，添加，修改，删除的功能，系统还实现了将权限控制细化到菜单按钮的功能。

系统在实现用户管理下的权限管理功能时，存在重大的缺陷，权限控制不严密，权限设计有遗漏。

5.2易用性

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

√ 查询，添加，删除，修改操作相关信息的一致性，可理解性

√ 输入限制的正确性

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

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

√ 界面排版不美观

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

√ 输入缺少解释性说明

√ 中英文对应的正确性

√ 中英文混排

5.3 可靠性

现有系统的可靠性控制不够严密，很多控制是通过页面控制实现的，如果页面控制失效，可以向数据库插入数据，引发错误。

现在系统的容错性不高，如果系统出现错误，返回错误类型为找不到页面错误，无法回复到出错前的状态

5.4 兼容性

现有系统支持window下的IE浏览器和傲游浏览器，支持linux系统下的IE浏览器和火狐浏览器。

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

5.5 安全性

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

√ 把某一个登录后的页面保存下来，不能单独对其进行操作不进行登录

√ 直接输入某一页面的Url能否打开页面并进行操作不应该允许。

现在系统未控制以下安全性问题：

√ 用户名和密码应对大小写敏感

√ 登陆错误次数限制

6 分析摘要

6.1 覆盖率

此次测试，所有测试用例都是在中文界面下执行，未在英文界面下执行，测试不包括英文界面下的测试，也不包括正对英文翻译的测试。

此次测试，部分页面需求描述无明确的定义，对输入限制无详细定义，无 明确的测试依据，在测试过程中，测试是根据输入字段含义，测试人员理解，以及和项目经理，开发人员沟通获得测试依据，无法保证测试依据的正确性和完整性，因此，没有进行完整的，正确的无效数据的测试，测试覆盖率不够，无法保证测试的有效性和正确性

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

6.2 遗留缺陷的影响

1．缺陷描述：酒店娱乐项添加页面，”距离”字段无单位，建议增加单位

缺陷影响：距离字段无单位说明，无衡量标准，用户易用性不好

推迟原因：需求定义无单位定义，统一在升级版本中解决

2．缺陷描述：tomcat日志有乱码，日志无项目名称，查看不方便

缺陷影响：其他项目日志都有项目名称，日志无项目名称，查看不方便

推迟原因：目前的日志为了调试方便，显示了很多其它信息，在项目正式发布时会统一

处理的。

6.3 建议

√ 在项目开始的时候应该制定编码标准，数据库标准，需求变更标准，开发和测试人员都严格按照标准进行，可以在后期减少因为开发，测试不一致而导致的问题，同时也可以降低沟通成本。

√ 发布版本的时候，正确布置测试环境，减少因为测试环境，测试数据库数据的问题而出现的无效bug。

√ 开发人员解决bug的时候，填写bug原因以及解决方式，方便bug的跟踪。

√ 开发人员在开发版本上发现bug，可以通知测试人员，因为开发人员发现的bug很有可能在测试版本上出现，而测试人员和开发人员的思路不同，有可能测试人员没有发现该bug，而且，这样可以保证发现的bug都能够被跟踪。

7 度量

7.1资源消耗

7.2 缺陷密度

8 典型缺陷引入原因分析

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

1． 需求定义不明确

需求文档中，存在功能定义错误，输入输出字段描述错误，输入输出字段限制定义错误，输入输出限制定义缺失这几种类型的缺陷。使得开发人员根据需求进行设计时，没有考虑相关功能的关联性， 以及需求错误的地方，在测试过程中，需求相关的问题表现出来。需求做改正，设计必须跟着做改动，浪费时间和影响开发人员的积极性，降低开发人员对需求的信任，可能会导致开发人员不按照需求进行设计而根据自己的经验来进行设计。

2． 功能性错误

√ 功能没有实现，导致无法进行需求规定的功能的测试。主要是无法进入酒店设施管理，会议室管理页面，酒店安全管理无法保存信息，地区，户型删除功能缺失。

√ 功能实现错误，实现了需求未定义的功能，执行需求定义的功能时系统出现错误。主要是银色拥有不属于自己的权限，酒店联系人删除页面跳转错误等。

3． 页面设计和需求不一致

页面设计没有根据需求进行，输入，输出字段文字错误，用户无法理解字段含义。页面设计没有完成需求规定的输入限制验证，导致用户可以输入错误的或者无效的数据，这些数据有可能会引起功能性错误。

4． 多语言数据问题

√ 系统中很多输入字段是通过调用数据字典的方式输入，但是现在有系统中，很我数据字典的语言信息没有完成，导致使用多语言的时候，显示空白字段。

√ 系统中很多地方使用多语言，由于多语言编码不统一导致页面设计和数据设计使用语言编码不一致，由此引起的多语言数据无法显示的缺陷。

5． 页面设计易用性缺陷

√ 页面设计不友好，系统中很多页面的输入字段无明确的输入提示，用户无法理解何种输入是正确的，但是用户输入错误后，系统提示出错，增加用户负担。

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

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

6． 开发人员疏忽引起的缺陷

因为开发人员的疏忽，导致系统需要验证的地方，调用了错误的验证，系统需要进行输入控制的地方没有进行相应的控制。