• 11
  • 11
分享
  • 系统测试总结报告模板——软件测试圈
  • 恬恬圈 2021-05-28 10:07:27 字数 6597 阅读 2520 收藏 11

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 displayed” 或者返回异常错误;

ü 系统定义不能重复的字段输入重复数据后,出现“The page cannot be displayed” 或者返回异常错误。

1.5 测试对象

1.6 测试阶段

系统测试

1.7 测试工具

Bugzilla缺陷管理系统

2 测试概要

XX后台管理系统测试从2017年7月2日开始到2017年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 进度回顾

版本/时间计划开始时间实际开始时间计划完成时间实际完成时间加班增加资源
B12017.7.22017.7.22017.7.52017.7.5
B22017.7.162017.7.162017.7.192017.7.19
B32017.7.232017.7.232017.7.252017.7.242个人日
B42017.7.282017.7.292017.7.312017.7.311个人1天1个人2天2个人日
B52017.8.12017.8.22017.8.62017.8.32个人日
B6
2017.8.4
2017.8.42个人1天2个人日
B7
2017.8.5
2017.8.51个人1天1个人日
B8





B92017.8.92017.8.92017.8.102017.8.102个人日
B10





合计


1个人6天
11个人日

2.2 测试执行

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

2.3 测试用例

2.3.1 功能性

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

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

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

2.3.2 易用性

操作按钮提示信息正确性,一致性,可理解性

限制条件提示信息正确性,一致性,可理解性

必填项标识

输入方式可理解性

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

3 测试环境

3.0.1 软硬件环境

硬件环境应用服务器数据库服务器客户端
硬件配置

CPU:Intel(R) Celeron(R) CPU 2.40GHz stepping 01

Memory:?1048256k

HD:ST380817AS 80G SATA

CPU:Intel(R) Celeron(R) CPU 2.40GHz stepping 01

Memory:?1048256k

HD:ST380817AS 80G SATA

CPU:Intel(R) Celeron(R) CPU 2.40GHz stepping 01

Memory:?1048256k

HD:ST380817AS 80G SATA

软件配置

OS:CentOS 4.2

JDK 1.5.0_06

Apache 2.2.0

Tomcat 5.5.15

OS:CentOS 4.2

MySQL 5.0.17 Linux

Window 2000 Professional(SP2)IE6.0.2900.2180.xpsp_sp2
网络环境10M LAN10M LAN10M LAN

3.0.2 网络拓扑

1.png

4 测试结果

4.1 Bug趋势图

此次黑盒测试总共发布10个版本,V1.0.1-V1.0.5为计划内迭代开发版本(针对项目计划的基线标识),V1.1.1-V1.2.2为进行的回归测试版本,所有版本一共发现bug1306个。

由Bug的版本分布图可以看出,V1.0.1-V1.0.5版本质量非常不稳定,bug数量最高达到189个,V1.0.1作为第一个版本bug数量为58个。在版本V1.0.3验证了前面发现的所有bug的基础上遗留bug数量在123个质量表现也不够稳定,在V1.1.1新增了批量制证、数据恢复、数据备份、数据清除等功能所以bug数目骤增为232个。随着版本的迭代在版本V1.2.2 ?bug数量逐渐将为0。

4.2 Bug优先级分布

测试发现的bug主要集中在未完善功能级别major,属于一般性的功能缺陷,但是测试的时候,出现了163个涉及到程序崩溃、程序启动不了、不能完成正常制证、不能完成正常印刷等严重级别的bug,出现严重级别的bug主要表现在以下几个方面:

ü 系统的主要功能没有实现;

ü 本地数据库数据量比较大的时候出现程序崩溃死机;

ü 系统主要功能逻辑混乱导致意外bug;

ü 后台进程在程序关闭后没有相应停止导致程序不能启动;

ü WebAPI接口调用错误导致核心功能不可实现。

4.3 问题类型分布

系统的问题类型主要分布于测试过程和维护过程发现影响系统运行的缺陷bug和对现有系统功能的改进improvement。Bug占所有问题类型的百分比为:97%,improvement占所有问题类型的百分比为:3%。图上结果说明系统在需求采集、程序设计工作过程中考虑十分全面极少存在功能设计遗漏问题。

4.4 Bug模块分布图

由上图可以看出,bug主要分布模块是CerDesk印刷端(405个)和CerDesk制证端(534个)两个工作台,占到了全部bug的2/3以上。而CerWeb服务器端(260个)的bug分布相对来说比较少占总体百分比为7%。CerDesk运维端(107个)的bug量最少主要原因是功能比较简单。

4.5 最近提交缺陷图

由上图可以看出,在统计的十个周bug提交和解决状况比较理想,当前提交的bug都能够在很快的时间得到修复,并且随着版本的稳定解决bug数量为全部解决新增bug数量逐渐降为0,整个过程属于正常的软件版本迭代过程。

4.6 Bug状态分布

由bug状态图可以看出,打开的bug有0个,重新打开的bug有0个。已解决bug有2个,主要是版本V1.2.2中提交的界面易用性bug,而其他的1304个都是已验证修复并关闭的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、缺陷描述:酒店基础信息管理模块,默认语言设置不一致。用中文查询酒店,进入酒店基础信息模块后,如下模块,语言显示为“请选择”。

列表页面添加页面
取消政策停留政策

担保政策

机场

参照点

会议室详情

打包促销

服务

Rate

而其他模块语言显示“中文语言”。

缺陷影响:相同功能模块默认语言设置不一致,一致性不好。

推迟原因:默认语言设置,目前无统一标准,升级版本中统一。

3、缺陷描述:tomcat日志有乱码,日志无项目名称,查看不方便;

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

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

4、缺陷描述:取消政策管理要么,取消时间“天/小时”缺少单位补充字段;

缺陷影响:该处因为是两个不同的单位时间,需要有另外一个单位补充字段补充所所填写内容的单位;

推迟原因:该缺陷单位补充字段本来存在,翻译不够准确,不能理解为补充单位的字段,需要等翻译完毕后再确认。

5、缺陷描述:数据字典种类修改,默认值设置后,在调用该数据字典种类的数据字典,默认值无显示;

缺陷影响:数据字典种类的默认值设置后,不能显示设置的默认值,相当于数据字典种类默认值设置功能未实现

推迟原因:该功能暂时不好实现,需要和和系统的默认语种一起处理。

6、缺陷描述:担保政策管理页面,“Edposit Due”缺少解释行输入描述信息;

缺陷影响:缺少解释性输入描述信息,用户不理解应该输入什么内容;

推迟原因:需求没有描述,需要解释性说明文字由项目经理整理后,在升级版本中添加。

7、缺陷描述:多媒体添加,文件上传功能未实现;

缺陷影响:文件上传功能未实现;

推迟原因:该功能暂时不好完成,在下个版本中完成。

8、缺陷描述:参照点添加权限和修改权限单独控制出现权限异常错误;

缺陷影响:用户执行添加,修改时,出现权限异常,无法完成任务;

推迟原因:B9版本发现该权限,B10版本未通过验证,目前该模块开发人员调休,无法修改bug。

9、缺陷描述:酒店渠道绑定关系权限控制出现权限异常错误;

缺陷影响:a>权限控制易用性不好,会引起用户误操作;

b>权限控制错误;

推迟原因:B9版本发现该权限,B10版本未通过验证。该模块后台无insert权限,只有Update权限,与其他模块不同,需要重新设置权限控制方式。

10、缺陷描述:酒店Rate绑定关系权限控制出现权限异常错误;

缺陷影响:a>权限控制易用性不好,会引起用户误操作;

b>权限控制错误;

推迟原因:B9版本发现该权限,B10版本未通过验证。该模块后台无insert权限,只有Update权限,与其他模块不同,需要重新设置权限控制方式。

11.缺陷描述:新建业务管理员权限用户,进入打包促销页面出现权限异常错误;

缺陷影响:除系统管理员外,其他用户无法进行打包促销操作;

推迟原因:B10版本发现该bug,目前该模块开发人员调休,无法修改bug。

6.3 建议

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

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

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

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

7 度量

7.1 资源消耗

测试时间2007年7月2日至2007年8月6日共35天
测试人力1人×7天+1人×35天=42人天
硬件资源

服务器:PC 2台

客户端:PC 2台

7.2 缺陷密度

8 典型缺陷引入原因分析

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

1、需求定义不明确

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

2、功能性错误

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

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

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

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

4、多语言数据问题

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

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

5、页面设计易用性缺陷

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

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

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

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

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


作者:及时行测

原文链接:https://blog.csdn.net/wxyy7523/article/details/86716023

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 1. Android 调试桥adb ( Android Debug Bridge)是一个通用命令行工具,其允许您与模拟器实例或连接的 Android 设备进行通信。它可为各种设备操作提供便利,如安装和调试应用。Tips: 在 android_sdk/platform-tools/ 中找到 adb 工具,然后根据其具体的路径配置好环境变量。然后启动cmd 输入‘adb’即可查看是否配置成功。2. adb工作原理启动一个 adb 客户端时,此客户端首先检查是否有已运行的 adb 服务器进程。如果没有,它将启动服务器进程。当服务器启动时,它...
            0 0 2495
            分享
          •   继 PlayStation 5 Pro 的传闻之后,微软也加入了这一行列,预告将推出拥有"有史以来最大技术飞跃"的下一代 Xbox。这一令人兴奋的消息是在暗示将推出传统游戏机之外的独特 Xbox 硬件的同时发布的,其中可能包括传闻已久的掌上设备。  在 Xbox 官方播客中,Xbox 总裁莎拉-邦德(Sarah Bond)承诺下一代 Xbox 硬件将有重大进步:  我们还有更多精彩等着你,将在这个假期分享一些令人兴奋的硬件产品,并且还致力于下一代路线图。我们真正关注的是在新一代硬件中实现有史以来最大的技术飞跃,让玩家、创作者和他们正在构建的愿景都能得到更好的体验。  微...
            0 0 943
            分享
          • 读者提问:用例评审会议有通用的流程吗,是什么样的 ?阿常回答:这个要分复杂项目和简单项目。一、复杂项目如果是复杂项目,需要走会议评审,目的是为了查漏补缺,保证用例覆盖了所有需求。1、将需要评审的用例文档共享给相关人员提前查看(主要是产品、研发、测试)。2、在项目沟通群和大家确认参加评审会的时间(给出具体的时间,让大家确认)。3、正式向相关人员(产品、设计、研发、测试)发起用例评审会议邀请。4、评审会议上由测试团队按主流程、细分模块逐一梳理测试点。5、产品及研发在测试梳理测试点的过程中,可随时提出疑问或给予补充。6、会议结束后,测试团队将更新后的测试用例同步给项目组人员查看。二、简单项...
            0 0 1494
            分享
          •   测试小伙伴们,你们有遇到下图的情况吗?  这张图其实还算“温柔”的,其实有些情况下,某些测试人员或者开发人员脾气大的可能撕逼或者快干架。所以如何和开发有效沟通,并高效劝说开发改掉bug是一门学问,以下是我总结八年测试经验给测试新人的一些建议:  1、和开发人员保持友好的团队关系。这是最重要的一点!  我以前遇到一个开发,刚开始给他提bug时,他是各种抵触情绪加敷衍。后来我就私底下和他多接触,了解他的脾气,久而久之他也和我熟络起来,结果不仅不再有抵触情绪,甚至还帮我主动定位bug。其实人心都是肉长的,我们做事既要讲理,也要适当打打“感情牌”。注意跟开发沟通的语气,要有换位思考的意识,做事情对...
            1 1 1550
            分享
          •   一旦你的系统流量有大的增长,比如类似“双十一”的流量,那么你在面临性能问题时就可能会手足无措。为了解决后顾之忧,你需要了解在流量增长若干倍的时候,系统的哪些组件或者服务会成为整体系统的瓶颈点,这时你就需要做一次全链路的压力测试。  那么,什么是压力测试呢?要如何来做全链路的压测呢?这两个问题就是本节课重点讲解的内容。  什么是压力测试  压力测试(简称为压测)这个名词儿,你在业界的分享中一定听过很多次,当然了,你也可能在项目的研发过程中做过压力测试,所以,对于你来说,压力测试并不陌生。  不过我想让你回想一下,自己是怎么做压力测试的?是不是像很多同学一样:先搭建一套与正式环境功能相同的测试...
            7 7 1739
            分享
      • 51testing软件测试圈微信