《最终测试总结报告》模板

《最终测试总结报告》模板（该模板中有两点任务）

一：《最终测试总结报告》模板

写作要点：

1． 1.1编写目的。描述本报告所期望读者了解的几方面内容。 2． 1.2用户群。描述本报告的主要读者和其他读者。

3． 1.3 术语、定义和缩略语。描述在本文使用的独特的术语、定义和缩略语。注意不是整

个项目共用的术语、定义和缩略语，并且缩略语列表中必须按照滋补的升序排列。

4． 1.4测试工具。列举本测试所用到的测试工具，使用下表。

5． 2.1进度回顾。描述整个测试生命周期中的里程碑发生的情况。

6． 2.2测试执行。简要描述测试执行情况。5中测试分别的测试用例总数，成功执行测试

用例个数，覆盖需求个数，需求覆盖率，发现缺陷总数，解决总数。 7． 3.1软硬件环境。描述主要的软硬件环境配置，使用下表。

8． 3.2网络拓扑。绘制网络拓扑示意图表示客户端、网络和服务器的连接关系。 9． 4.1bug趋势图。按照进度回归中所列举的各里程碑，利用趋势图的方式表现每个里程碑

的缺陷的总数。并对每一个里程碑的缺陷趋势做简要说明。这里要注意一点是趋势图必须以里程碑为基点。

10． 4.2bug严重程度。按照缺陷的严重程度，绘制包含每一种严重程度的缺陷个数的柱状

图。对于严重和致命缺陷个数异常的，要做说明和解释，并按照里程碑，绘制严重和致命缺陷的走势图。

11． 4.3bug引入阶段。统计需求设计阶段、后台编码阶段、前台编码阶段、测试阶段和发

布阶段的缺陷数量，绘制bug引入阶段的饼图，并用文字说明bug出现的主要阶段。 12． 4.4bug引入原因。统计不同类型缺陷产生原因（比如需求设计错误、编码错误）所产

生的缺陷个数，绘制饼图，并说明导致bug产生的主要原因。

13． 4.5bug状态分布。统计不同状态的bug数量，绘制柱状体。如果没有关闭的bug数量

过多，则要解释原因和处理办法。

14． 5测试结论。分别描述5类测试中系统的哪些功能/性能被测试验证通过，哪些地方还

存在缺陷。

15． 6.1覆盖率。描述系统测试整体的覆盖率和5类测试各自的覆盖率，并绘制用例覆盖率柱状图。

16． 6.2遗留缺陷的影响。列举所有遗留缺陷的影响及处理方案。注意严重和致命程度的

bug不允许作为遗留缺陷。使用下表。

17．文档历史。使用下表

18.在EXCEL中画BUG图，然后拷贝到word中。

19.按照素材中的BUG图，用Excel画一个图，然后复制粘贴到Word中。

20.在网上查找相关信息分析BUG图示中图形的含义，多角度分析原因。（越详细越完善越好）

二：小组讨论BUG图数据背后的原因，并写一个会议记录（用以前的会议记录模板）

以上两点中，第一点小组中每人交属于自己任务的一个Word文档，命名规则系统日报提交里面已有。第二点以小组名义交一份Word文档，命名为：《最终测试总结报告》+组长名.word

会议记录模板：1 时间地点人物 2 议题

3 形成决议并分工 4 具体分工情况 5 会议讨论结果

第二篇：《最终测试总结报告》录音

最终测试总结报告录音素材

女为什么要编写最终测试总结报告？

男首先l 通过对测试结果的分析，得到软件质量的评价；其次，l 分析测试的过程，产品，

资源，信息，为以后的测试提供依据；再次，l 评估测试过程和测试计划是否一致；最后，该报告l 分析Bus系统存在的Bug，为修复和预防Bug提供建议。

女谁来使用最终测试总结报告？

男 Bus系统项目经理，Bus系统测试经理以及Bus系统相关人员。

女什么是严重Bug?

男严重Bug就是由于该Bug的存在，导致系统死机或者出现“该页无法显示“。

女 Bus系统测试使用的是什么测试工具？

男 Bugzilla权限管理系统

女回顾一下吧？

男当然可以。20xx.4.1--20xx.6.1完成本系统的需求调研工作；20xx.6.1--20xx.7.1，架构

师完成系统概要设计；20xx.7.1--20xx.8.1，架构师完成系统详细设计；

20xx.8.1--20xx.9.1，程序员完成编码工作；20xx.9.1--20xx.10.1，测试员完成测试；20xx.10.1--20xx.10.1，维护人员完成维护工作。其间增加了2人日编码，和3人日维护工作。

女 bus系统可以做哪些事？

男 Bus系统分为五类角色：乘务员，乘客，调度员，业务员和管理员。ü 乘客可以查询乘车

线路信息；ü 乘务员可以录入信息，执行调度员调度（包括执行调度通知，执行车况，报告信息，接收系统信息，查询运行状态，解除维修完成状态，接收进站通知）；ü 调度员接收乘务员录入信息并对乘务员发送调度命令（调度命令包括调度客流量，调度路况，调度调度处理，调度车况和调度运行状况）；ü 业务员可以定期从系统生成报表,生成图表和导出报表；ü 管理员执行系统备份和权限管理。

女 Bus系统需要测试哪些方面？

男易用性、可靠性、兼容性和安全性。

女易用性就是ü 操作按钮和ü 限制条件提示信息的一致性，可理解性和正确性；ü 页面是否

美观。

男对。

女可靠性就是Bus系统中的输入和输入保持正确，对吗？

男是的。

女兼容性就是测试bus系统可否兼容Windows和Linux操作系统，以及可否兼容IE和Firefox

浏览器。

男对。

女那么安全性具体指什么呢？

男安全性具体指Bus系统是否不容易受到攻击。

女我搭建的测试环境是这样的：服务器：PCServer（8核16G）；各个节点的PC机（2核4G）；

开发环境安装Hibernate加Spring加Struts；使用Java开发语言；Windows7操作系统。男很好

女网络拓扑是这样的，每个客户端都与服务器相连接，客户端之间没有连接。

男这种架构师正确的

女这是bug趋势图，Bug数量随着系统每阶段（单元测试阶段，集成测试阶段，验收测试阶

段）向前推进呈逐渐减少的趋势

男 bug越来越少，系统性能就越来越好。

女在单元测试阶段发现的致命错误是l 系统登录功能没有实现；在集成测试阶段发现的致命

错误是l 数据库设计未考虑系统管理员角色,导致用系统管理员进行操作的时候出现找不到页面错误；l 权限控制异常。

男严重bug一定要及时修改。

女根据统计，bug在需求设计阶段数量为总Bug数的8%；在后台编码阶段，Bug数量为总Bug

数的34%；在前台编码阶段，Bug数量为总Bug数的51%；在测试阶段，Bug数量为总Bug数的5%；在发布阶段，Bug数量为总Bug数的2%。

男 Bug产生的原因分为需求设计错误（5%），后台编码错误（34%），前台编码错误（29%），

数据库相关结构及数据错误（5%），易用性（16%），多语言（6%），通过以上分析可以看出，Bug产生的原因主要是后台编码错误和前台编码错误。

女 bug按程度可分成哪几类？

男 Bug根据严重程度划分为致命，严重，一般，轻微和建议五类

女 Bus系统经测试，一般Bug最多，致命bug最少，严重Bug、轻微Bug和建议bug数量依次

递减。

男这是bug统计结果，其他方面测试结果怎么样？

女功能已经全部实现；l 按钮操作提示信息一致，便于理解；输入限制提示信息正确，便于

理解，而且一致。缺点是页面编排不美观；现有系统的可靠性控制不够严密，许多控制是通过页面控制来实现，一旦页面控制失效，也可以向数据库插入数据，引发错误。现有系统的容错性不高，如果报错，有时候回不到初始页面；现有系统支持IE7浏览器和Firefox浏览器，能够在Windows和Linux下运行，在其他环境下未进行兼容性测试。

男系统安全性怎么样？

女系统控制了直接输入某页面的URL而可以不用登录直接访问的问题；但是没有控制登录框

对大小写字母敏感的问题；也没有控制登录页面的登录次数。

男测试用例覆盖率达到100%了吗？

女在Bus系统中，功能的测试用例覆盖率为100%，可靠性的测试用例覆盖率为60%，兼容性

的测试用例覆盖率为20%，安全性的测试用例覆盖率为10%，易用性的测试用例覆盖率为80%，数据的测试用例覆盖率为70%，性能，外国语和负载的测试用例覆盖率为0，其他的测试用例覆盖率为20%

男还存在什么问题吗？

女 bug已经基本修改完毕。目前系统还存在一些缺陷。登录页面输入框未能区分大小写，未

能限制输入次数。这将使系统存在安全隐患。开发组决定在下一版中实现。

男我有一些建议：l 在项目初期就应该制定好一系列标准，比如《数据库设计标准》《编码

规范》《需求变更标准》，这样一来，许多事情做起来有据可依了；还有l 发布新版本时，应该注意测试环境是否和预期一致，以免得出错误结论；而且希望开发人员应该负责自己这块的Bug跟踪。

女这些建议我们开会讨论一下吧。

第三篇：《最终测试总结报告》模板