第1章 引言

1.1项目概述

1.1.1项目背景

1. 项目的提出原因 ；
2. 项目环境背景 ；
3. 项目运作的可行性 ；
4. 项目优势分析（资源、技术、人才、管理等方面）；
5. 项目的独特与创新分析；
   项目背景是站在客观的角度观察行业、政策、竞争者、客户、技术等方面的变化和情况。也可以从（重要性、价值、条件、问题等角度入手）
   如果实在不会写，可以考虑复制项目章程中的项目背景

1.1.2项目范围

1. 范围说明书： 这是项目范围规划过程中的主要输出成果，包括了前述的项目的合理性说明、项目成果描述、项目阶段目标、项目可交付产品或者服务清单等内容，是范围定义过程的主要依据之一；
2. 制约因素： 即对项目组行为进行限制的因素和条件，如项目预算、范围、时间等；
3. 前提条件： 即为了制定项目计划而必须假设能够在将来获得解决的一些条件，这些前提条件一般都是真实的、符合现实的、肯定的，也是可以解决的，但也存在未能如期解决的风险；
4. 其他计划结果： 其他领域内的结果也可以作为确定范围定义时的一个参考因素；
5. 历史资料： 其他IT项目或者相关项目及相关领域内项目的历史资料，也是在进行项目范围定义时参考的因素。
   如果实在不会写，可以考虑复制项目章程中的项目范围

1.2编写目的

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

1. 通过对测试结果的分析，得到对软件质量的评价；
2. 分析测试的过程，产品，资源，信息，为以后制定测试计划提供参考；
3. 评估测试测试执行和测试计划是否符合；
4. 分析系统存在的缺陷，为修复和预防 bug 提供建议。

1.3预期读者

主要读者：XX系统XX版本的管理人员及开发人员
其他读者：XX系统XX版本的其他相关人员

第2章 测试环境

2.1软硬件环境

硬件配置	服务器	pc客户端环境	手机客户端环境
硬件配置	16g内存、40g硬盘、双核CPU	处理器：Intel Core i5、内存：8GB、操作系统：windows10	Redmi 10X 4G
软件配置	Springcloud	Springcloud Google Chrome、360Chrome	微信自带浏览器
网络环境	20M带宽	20M带宽	20M带宽

2.2网络拓扑

第3章 测试结果及缺陷分析

3.1测试结论

在测试中发现的错误已经得到修改，各级缺陷修复率已达到标准要求如下：

1. 致命错误、严重错误（1、2级bug）共18个，修复率达到100%
2. 一般错误(3级bug)共530个，其中530个已解决，修复率达到100%
3. 微小问题（4级bug）共77个，其中77个已解决，修复率达到100%

3.2测试风险

1. 需求风险：对需求理解不准确或需求变更导致测试用例更新不及时，导致测试范围存在有意或无意的遗漏
2. 缺陷风险：某些缺陷偶发，难以重现，容易被遗漏，比如由于数据清空、代码修改或者是偶然操作问题导致原先的bug无法重现
3. 代码质量风险：代码质量可能导致缺陷较多，容易出现测试的遗漏
4. 回归测试风险：回归测试时一般不运行全部测试用例，可能存在测试不完全的地方
5. 沟通协调风险：测试过程中涉及角色较多，存在不同人员、角色之间的沟通、协作，难免存在沟通不畅的情况，导致项目延期
6. 测试设备不完备导致的风险：测试过程中测试机型是固定机型，可能会出现不兼容其他安卓或IOS机型手机的风险

3.3任务完成情况

3.3.1项目时间安排

预计完成时间	实际完成时间	任务	完成情况	意外原因
2021.3.19-2021.4.6	2021.3.19-2021.4.6	用例设计	已完成
2021.4.7-2021.5.14	2021.4.7-2021.5.21	一轮测试	已完成	延期一周
2021.5.17-2021.5.21	2021.5.21-2021.5.28	二轮测试	已完成	推迟一周

3.3.2每日新增bug走势图

1. 管理系统每日新增bug走势图

2. 单位系统每日新增bug走势图

3. 用户系统每日新增bug走势图

4. 项目每日新增bug走势图

3.3.3每日解决bug走势图

1. 管理系统每日解决bug走势图

2. 单位系统每日解决bug走势图

3. 用户系统每日解决bug走势图

4. 项目每日解决bug走势图

3.3.4任务完成情况分析

根据图3.3.2四个图的总体分析可以看出在一轮测试（4.7-5.21）期间，新增bug数前期每日递增，后期每日递减。二轮测试（5.21-5.28）期间新增bug数与一轮测试状态相同。且二轮测试每日新增bug数和总新增bug数低于一轮测试。
根据对八张图的总体分析可以看出：每日解决bug数与每日新增bug数几乎持平，也就是说本项目的大多数bug可以做到日清，较少bug会出现次日请情况，这种情况主要出现在当日新增bug数较多的时候。
通过以上分析可以得出结论：本项目的测试任务完成的较为顺利，项目目前提出的bug全部解决，无未关闭bug。

3.4用例情况

3.5.1用例个数及书写方式

1. 用例个数：用例共3304个，涵盖了所有版块。

2. 用例书写方式：以提取要点的方式分析整个项目，合理地利用边界值、等价类划分、边界值分析以及正交法进行对要点的整理从而全面的写出用例。

3. 要点具体内容：见附件-XX系统XX版本测试用例要点.emmx（需要用mindmaster打开）。

4. 用例具体内容见禅道-XX系统XX版本1.0测试单：
   http://192.168.0.143:8081/zentao/testtask-browse-12.html

3.5.2用例执行情况分析

用例共3304条，其中3014条执行一次通过，200条执行两次及以上通过，主要集中在管理系统及单位系统。由于提出的bug总条数为625条，可以看出有很多的bug无法完全被用例覆盖。
主要原因有以下几点：

1. 测试人员操作不当；
2. 后期需求更改；
3. UI界面调整等。

3.5缺陷bug情况

3.6.1缺陷bug有效性

缺陷bug总数	有效bug数	1-4级bug数
625	575	625

3.6.2bug性质及模块分布

模块	bug性质
	一级 紧急	二级 高	三级 中	四级 第低	五级 建议	总数
管理系统	20	9	238	60	无	327
单位系统	6	1	152	8	无	167
用户系统	0	0	79	2	无	81

3.6.3每人解决bug分布图

1. 管理系统每人解决bug数

2. 单位系统每人解决bug数

3. 用户系统每人解决bug数

4. 项目每人解决bug数

3.6.4bug等级分布图

1. 管理系统bug等级分布图

2. 单位系统bug等级分布图

3. 用户系统bug等级分布图

4. 项目bug等级分布图

5. 分析：

1. 由上图可看出，三个系统中，3级bug占比分别为管理系统：71.51%，单位系统：91.57%，用户系统：97.92%，占比较重；1、2级bug占比分别为管理系统：9.43%，单位系统：3.94%，用户系统：0%，占比较轻。
2. 1、2级bug分布在管理系统和单位系统，其中以管理系统为主，由于管理系统和单位系统涉及到权限问题以及创建单位、活动、项目、岗位等功能较多，一旦上述模块出现bug就会导致后续相关模块的测试出现堵塞。所以1、2级bug才会集中出现在管理系统和单位系统。
3. 1、2级bug一般指会影响产品运行，波及面广，会堵塞后续测试或影响其他模块测试的缺陷，也就是重大缺陷。
4. 3级bug一般指不影响产品的运行且不会成为故障的起因，但对产品外观和下道工序影响较大的缺陷，也就是一般缺陷。
5. 4级bug一般指程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误类型的缺陷，优先级最低。
6. 图中所示的1、2级bug主要包括：
   i. 堵塞后续测试的bug；
   ii. 非常规操作导致的程序崩溃、死机、死循环 (非常规操作：用户使用软件时不会进行的操作）；
   iii. 常规操作引起的系统崩溃、死机、死循环等。
7. 图中所示的3级bug主要包括：
   i. 次要功能无法正常实现；
   ii. 操作界面错误；
   iii. 查询错误、数据显示错误；
   iv. 输入限制未控制（如统一社会信用代码未规范长度、内容等）；
   v. 操作后toast提示错误等。
8. 图中所示的4级bug主要为UI提出的关于项目外观的优化问题。

3.6.5bug模块分布图

1. 管理系统bug模块分布图

由图1可以看出管理系统的bug主要集中在1，2，3以及3，4个模块，占整个管理系统的63.61%。

2. 单位系统bug模块分布图

由图2可以看出单位系统的bug主要集中在1、2以及3，3个模块，占整个单位系统的79.22%。

3. 用户系统bug模块分布图

由图3可以看出用户系统的bug主要集中在1和2，2个模块，占整个单位系统的53.12%。

4. 项目bug模块分布图

由图4可以看出整个项目的bug主要集中在以上说过的9个模块，占整个项目的68,16%。

5. 分析：

1. 由上图可以看出项目中的bug主要集中在上述的9个模块，其他模块出现的bug数呈均匀分布。
2. 上述 9个bug集中分布的模块拥有的共同点：
   i. 单一页面功能较多；
   ii. 单一模块页面较多；
   iii. 功能与其他模块有关联；
   iv. 有权限配置相关功能。

3.6.6bug解决方案分布图

1. 管理系统bug解决方案分布图

2. 单位系统bug解决方案分布图

3. 用户系统bug解决方案分布图

4. 项目bug解决方案分布图

5. 分析：

1. 由上图可以看出92.15%的bug已解决，5.93%的bug解决方案为不予解决和设计如此，1.44%的bug解决方案为无法重现，0.48%的bug解决方案为重复bug。大多数的bug已解决，说明了项目bug的提出总体来说比较合理，且开发人员解决bug的能力较为优秀。
2. 不予解决和设计如此原因：由于产品、UI、测试以及开发对于产品的不同理解，导致出现了不予解决和设计如此的bug解决方案。
3. 重复bug原因：同类问题在多个页面或板块出现
4. 无法重现原因：
   i. 测试机性能不好，打开网页加载慢，打开页面过程中控制台报错，js代码无法继续执行；
   ii. 未清除缓/未完全清除缓存导致的无法重现，这类bug实际已经修改；
   iii. 测试环境原因：开发环境和测试环境不同/笔记本和台式兼容不同导致bug无法复现，需要再同一环境下重新复现；
   iv. 测试bug描述不清/开发没有完全理解bug描述，理解成了另外一个意思，建议加强项目间的成员交流；
   v. bug修改后，未成功更新到测试环境；
   vi. 操作问题：执行测试用例的时候不经意间做了一些其他操作，这种不经意间完成，而又忽略了这一操作，以至于很难重现。

3.6.7bug激活次数分布图

1. 管理系统bug激活次数分布图

2. 单位系统bug激活次数分布图

3. 用户系统bug激活次数分布图

4. 项目bug激活次数分布图

5. 分析：

1. 由上图可以看出管理系统的bug再次激活次数为15.1%，单位系统的bug再次激活次数为7.87%，用户系统的bug再次激活次数为4.17%。管理系统的bug再次激活的次数比其他两个系统的次数高。
2. Bug再次激活的原因：
   i. 开发人员无法重现bug，暂时关闭后，bug复现；
   ii. 开发人员解决bug后因调整其他模块导致bug复现；
   iii. 开发人员解决bug后在其他页面发现相同bug。

第4章 测试结论及建议

4.1测试结果分析

4.1.1用例情况

用例共3304条，其中3014条执行一次通过，200条执行两次及以上通过，主要集中在管理系统及单位系统。由于提出的bug总条数为625条，可以看出有很多的bug无法完全被用例覆盖。
主要原因有以下几点：

1. 测试人员用例写的不全面，未能完整覆盖项目；
2. 测试相关人员操作不当；
3. 后期需求更改；
4. UI界面调整等。

4.1.2bug性质分析

1. 需求阶段的bug:模糊不清的需求、忽略的需求、冲突的需求；
2. 分析、设计阶段的bug:模糊的设计、忽略的设计；
3. 实现阶段：设计缺陷、代码错误、遗漏的功能、内存溢出、其他类型。

4.1.3系统功能问题

系统功能问题主要出现在：

1. 管理系统：1，2，3以及4四个模块；
2. 单位系统：1、2以及3三个模块；
3. 用户系统：1、2两个模块。

第5章 总结

5.1测试总结

• 需求分析阶段：测试过程中有需求不明确的地方，没有明确需求，后续测试尽量在测试左移，在需求分析阶段把问题抛出来，多关注需求的必要性，需求的完性整，是否有逻辑的缺失，需求需要用什么方式实现问题
• 产品研发阶段：产品研发初期，避免过于关注代码细节，适当思考产品整体设计，出现产品设计与需求不符的情况，需要项目成员间多沟通，尽量避免由于不熟悉需求而导致的bug；产品交付后出现了接口没做或是接口不稳定的情况，测试在不影响研发进度的情况下尽早介入，进行接口测试，确保接口的稳定性，保证后续测试质量和测试进度
• 测试阶段：

1. 从测试方来说，项目研发初期，需求变更后，未及时通知整个项目组成员，导致测试未及时更新测试用例，后续测试过程中可能发生漏测；测试过程中，过早进行全集测试，项目测试前期过分关注细节问题，导致一些重要的功能问题在后期反复出现；在内网测试环境测试完以后，没有尽早在外网测试环境测试，导致在外网测试环境时没有充足的时间进行全集测试
2. 从开发方来说，开发自测过程中，比较关心单个问题和局部问题，一定程度上忽略了流程问题和关联问题，从而导致了单个bug修复速度快，但是关联bug出现较多的情况，测试中期，bug激活频繁，建议开发：除了原先提出的定期进行设计Review、代码Review、进行单元测试、保证代码质量以外，还可以多关注下系统流程，改完bug后对可能受影响的功能进行测试，避免改完局部bug却造成整体功能受影响的情况

5.2测试的局限性

• 通过手工测试无法做到覆盖所有代码路径;
• 许多与时序、死锁、资源冲突、多线程等有关的错误通过手工测试很难捕捉到；
• 在系统负载、性能测试时，需要模拟大量数据、或大量并发用户等各种应用场合时，也很难通过手工测试来进行；
• 代码全部Code Path测试覆盖也几乎不可能

1. 每一个if…else…或switch语句就会把情况增加一倍
2. 许多异常处理代码在正常使用中不会碰到
3. 许多与时序，死锁，资源冲突，多线程有关的错误很难捕捉到

• 可重复使用的自动测试对产品未来版本的测试将有事半功倍的效果

XX系统XX版本 测试报告相关推荐

1. XX系统测试总结报告

   XX系统测试总结报告 1        引言 1.1  编写目的 编写该测试总结报告主要有以下几个目的 1．  通过对测试结果的分析,得到对软件质量的评价 2．   分析测试的过程,产品,资源,信息, ...

2. 券商的xx系统节点的VIP异常案例介绍及深入分析

   系统环境    硬件平台 &  操作 IBM 570 操作系统版本  AIX 5.3 物理内存  32G Oracle 产品及版本  10.2.0.5 RAC 业务类型  OLTP 背景概 ...

3. 经纪xx系统节点VIP案例介绍和深入分析异常

   系统环境    硬件平台 &  操作 IBM 570 操作系统版本号  AIX 5.3 物理内存  32G Oracle 产品及版本号  10.2.0.5 RAC 业务类型  OLTP 背 ...

4. Microsoft JDBC Driver XX （XX表示版本号）for SQL Server的安装

   使用eclipse与server sql 时,需要下载微软的jdbc 驱动连接,(重点来了)唯一需要注意的是Microsoft JDBC Driver XX (XX表示版本号)for SQL Serv ...

5. 团队作业9--beta版本测试报告及发布说明

   Beta版本测试报告 1.bug的分类 a.修复的bug 部分用户无法获取位置 e. 这个bug的确应该修复,但是没有时间在这个版本修复,延迟到下一个版本修复. 前端无法查看用户签到信息 2.场景测试 ...

6. Beta版本测试报告以及Beta版本发布说明

   Beta版本测试报告 请根据团队项目中软件的需求文档.功能说明.系统设计和Beta阶段的计划安排,写出软件的测试过程和测试结果,并回答下述问题. 在测试过程中总共发现了多少bug?每个类别的bug分别 ...

7. JAVA(-Xms,Xmx,Xmn-XX:newSize,-XX:MaxnewSize,-XX:PermSize,-XX:MaxPermSize)区别

   1.-Xms:表示java虚拟机堆区内存初始内存分配的大小,通常为操作系统可用内存的1/64大小即可,但仍需按照实际情况进行分配. 2.-Xmx:表示java虚拟机堆区内存可被分配的最大上限,通常为操 ...

8. oracle、MySQL日期转XX年XX月XX日日期格式和金钱转中文大写数字的方法

   你知道的越多,你不知道的越多 点赞再看,养成习惯 如果您有疑问或者见解,欢迎指教: 企鹅:869192208 问题 工作中遇到一些项目需要打印文书,出具文书的日期,客户希望做成XX年XX月XX日的格式 ...

9. java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100/虚拟机调优

   转自:https://www.cnblogs.com/shanheyongmu/p/5775003.html JVM的堆的内存, 是通过下面面两个参数控制的 -Xms 最小堆的大小, 也就是当你的虚拟 ...

最新文章

1. ReentrantLock与synchronized
2. Kafka Eagle 源码解读
3. boost::callable_traits的remove_member_cv_t的测试程序
4. XSS跨站脚本（web应用）——XSS相关工具及使用（四）
5. Prime Gap（POJ-3518）
6. 权限管理（1）：简介
7. html - table分页断行,关于window.print网页分页换页table不断行的处理
8. Vue3计算属性computed
9. 26-[Boostrap]-全局css样式，组件，控件
10. VRRP技术原理与注意点
11. 由深圳的大树所想到的
12. 打印机服务器没有响应 请检查设置,打印机服务无法启动的解决办法
13. 如何搜索视频和字幕？
14. 2021年N1叉车司机免费试题及N1叉车司机模拟试题
15. 微信公众号排版 | 汇总和实战
16. 试读《线上幽灵：世界头号黑客米特尼克自传》
17. Bugku MISC 再也没有纯白的灵魂
18. 解决Chrome“此网页正试图从未经验证的来源加载脚本”的问题
19. 复制链接到剪切板php,剪切复制粘贴
20. 越是领军人才，越要看基本素质

热门文章

1. web课题（仿百度+个人所得税计算）
2. LaTeX/PDF转Word最佳实践总结
3. 2.23 使用python解析.bag数据集（无需虚拟机和ROS）
4. android,java判断密码强度
5. 2017天猫双11，1682亿背后的阿里绝密50+技术（长图下载）
6. 手把手教你实现一个JavaWeb项目：创建一个自己的网页博客系统（前端+后端）（一）
7. 《使用MAVEN+SSM+Ajax+shiro+MySql开发在线商场详解（4）》
8. 支付宝与微信转战刷脸支付，多年相爱相杀情归何处？
9. Flutter采坑实录
10. 怎样学好机器视觉，又能省钱？