1 概述

1.1 项目背景

在过去，国内外相关的三维地质建模软件、资源评价软件较为匮乏。并且过去的软件效果并不能达到用户的要求。近些年，随着科学计算机技术的日益成熟，开发一款适应用户需求的产品就显得非常必要。在本次开发过程当中，我们通过运用计算机图形学、软件工程、计算机网络、计算机算法等理论来开发一款更加贴近需求的软件产品。

「根据自己项目的情况对自己系统进行大致描述，比如分为几个慕课，满足了甲方何种需求等方面，说明系统所支持的模块」

1.2 编写目的

本报告为「XXXXXXXXX」（指项目名称）系统测试报告；本报告目的在于总结测试阶段的测试及测试结果的分析，描述系统是否达到需求的目的。

本报告预期参考人员包含：测试人员、测试部门负责人、项目管理人员、SQA人员和其他质量控制人员。

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

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

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

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

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

1.3 参考资料

本报告主要参考资料包含《需求规格说明书》 、软件测试清单、测试计划、测试用例、缺陷记录。

1.4 定义（专业术语/定义）

Software Testing（软件测试）：软件测试是在一定控制条件下，围绕一个系统或应用的操作并评价其结果，控制的条件应当包括正常和异常的条件。测试企图使得事情变得糟糕，从而来检测出一些应当发生而没有发生，或者不应当发生而发生的事情。测试以检测为主。

Software Development Life Cycle（软件生命周期）：SDLC是软件的产生直到报废的生命周期，周期内有问题定义，可行性分析，总体描述，系统设计，编码，调试和测试，验收与运行，维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班，逐步推进，每个阶段都要有定义，工作，审查，形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。

Software Quality Assurance（软件质量保证）：SQA介入于整个软件开发过程——监督和改进过程，确认达成的标准和过程被正确的遵循，保证问题被发现和解决。它以预防为主。

Static Analysis（静态分析）：对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。

Dynamic Analysis（动态分析）：通过观察软件运行时的动作，来提供执行跟踪，时间分析以及测试覆蓋度方面的信息。

Acceptance Testing（验收测试）：系统开发生命周期方法论的一个阶段，这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的的测试。这时管理性和防御性控制。

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

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

√ 点击某个菜单后出现“The page cannot be displayed”或者返回异常错误。

√ 进行某个操作（增加、修改、删除等）后，出现“The page cannot be displayed”者返回异常错误。

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

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

2 测试工作经过

2.1 测试范围

在本节，需将所有涉及测试的模块进行列表，具体示例如下：

添加图片注释，不超过 140 字（可选）

2.2 测试案例设计思路

本次软件测试根据上述范围测试点进行测试用例的设计。主要采用黑盒/白盒用例设计方法等价类划分法、边界值分析法、错误推测法、场景法等方法。

2.2.1 功能测试/黑盒测试（Functional testing）

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品。功能测试也叫黑盒测试或数据驱动测试，只需考虑需要测试的各个功能，不需要考虑整个软件的内部结构及代码。一般从软件产品的界面、架构出发，按照需要编写出来的测试用例，输入数据在预期结果和实际结果之间进行评测，进而提出更加使产品达到用户使用的要求。

在本次测试当中，我们对所有涉及到的功能全都进行了功能测试，我们以产品特性、操作描述和用户方案来帮助我们全面的测试，从而，极尽可能满足用户需求。

本次测试，我们使用了较为稳定的Google Chrome 88.0.4324.104浏览器去进行Client端的测试工具。详细测试平台及开发所涉及技术如表所示2-1所示。

表2-1 测试系统及运行环境

项目	系统软件说明
操作系统	Windows10
数据库	MongoDB
开发语言	Python
软件框架技术	Vue, BEEGO, Flask, MVC
并行计算	TensorFlow
科学计算库	NumPy
可视化技术	WEB, Three.js
浏览器	Google Chrome

2.2.2 用户界面测试（UI）测试

为了核实用户与软件之间的交互，确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能，确保UI中的对象按照预期的方式运行，确保各个窗口风格（包括颜色、字体、提示信息、图标、等等）都与需求保持一致，或符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯。

2.2.3 流程测试

核实实际业务流程在系统中的完整正确实现。应确保各业务流程内部数据流转及流程之间接口数据的正确，确保角色权限对流程的操作的限制的正确性。

2.2.4 安全性测试

由于本次开发的特殊性，我们对系统的保密性做了专业的安全性测试。从而确保用户、管理员的密码管理安全、应用程序级别与系统级别的安全的安全性。

2.2.5 兼容性测试

确保系统在各种 不同版本不同类项浏览器均能正常实现其功能。

2.2.6 白盒测试

在本次测试中，由于系统的特殊性我们也使用了条件组合覆蓋和路径覆蓋。

条件组合覆蓋：在白盒测试中， 选择足够的测试用例，使所有判定中各条件判断结果的所有组合至少出现一次，满足这种覆蓋标准成为条件组合覆蓋。

路径覆蓋：是每条可能执行到的路径至少一次。

3 测试执行情况与记录

地浸开采资源储量四维动态评价系统共分为登录模块、数据库模块、地质模型、地下水模型、资源储量动态管理与评价模块、鉆浸技术计划编制模块、时间设置模块、三维动态展示模块、系统维护模块。

3.1 测试环境

硬件环境	应用服务器	数据库服务器	客户端
硬件配置	CPU: Intel(R) Celeron(R)CPU 2.40GHz steppingHD:ST380817AS 80GSATA	CPU: Intel(R) Celeron(R)CPU 2.40GHz steppingHD:ST380817AS 80GSATA	CPU: Intel(R) Celeron(R)CPU 2.40GHz steppingHD:ST380817AS 80GSATA
软件配置	Windows10/PostgreSQL	Windows10/8MongoDB	Windows10/8MongoDB
网络环境	—	—	—

3.2 网络拓扑

添加图片注释，不超过 140 字（可选）

3.3 测试时间/执行

后台管理系统测试从20XX年XX月XX日开始到20XX年XX月XX日结束，共持续XXX天，测试功能点X个，执行X个测试用例，平均每个功能点执行测试用例XXX个测试发现了X个bug，其中严重级别的bug为X个，无效bug为X个，平均每个功能点有X个bug。

本次开发一共发布了X个测试版本，其中B1为计划内迭代开发版本，B2为回归测试版本，计划内测试版本，B2测试进度依照项目计划时间准时完成测试。且B1版本提前两天结束测试。B3版本测试推迟十天结束测试，测试增加XX个人日，准时完成测试。

本次测试通过Bugzilla缺陷管理工具进行缺陷跟踪管理，B1测试阶段都有详细的bug分析表和阶段测试报告。详细进度回顾如表所示。

版本/时间	计划开始时间	计划结束时间	实际开始时间	实际结束时间	加班	增加资源
B1	2020.12.15	2020.1.10	2020.12.15	2021.1.8	3个人2天	6个人日
B2	2021.X.X	2021.X.X	2021.X.X	2021.X.X	否	否

经过评审，本次测试严格按照项目计划和测试计划执行，在BX、BX和BX都在规定时间完成。BX和BX基本按照规定时间完成，且延期原因明确（bug的不可抗力因素）。针对测试计划规定的测试策略，在测试执行中都有所体现，在执行测试的过程当中，依据测试计划和测试用例，对系统进行了完整和详细的测试。

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

本次测试符合规定，且解决了可修复bug。

3.4 冒烟测试

冒烟测试	时间	是否通过	如不通过，填写原因
2021.X.X

3.5 测试用例及统计

用例总数	执行个数	成功个数	失败个数	未执行个数	案例成功率
XXX	XXX	XXX	XXX	X	XX%

3.5.1 正确性

本次系统开发过程中，涉及许多数值计算公式的加减的正确性、操作按钮提示信息正确性、XXXX正确性。

「因各自系统不同而不同」

3.5.2 功能性

系统实现的主要功能，包括增加、删除、修改，查询功能。「因各自系统不同而不同」

系统实现的次要功能，包括管理用户分配，为用户分配权限，权限控制菜单按钮。

系统维护功能。

时间设置功能。

3.5.3 兼容性测试

本次测试采用不同浏览器显示与操作，相同浏览器不同版本，不同分辨率设备都进行了严格测试，以此来保证软件的兼容性。

3.5.4 可靠性

软件部署于XX（云）服务器，经过测试，本次系统开发在规定的条件下和规定的时间完成了规定功能的能力。详见图

添加图片注释，不超过 140 字（可选）

3.5.5 安全性

系统采用C/S设计模式且采用了最先进、稳定的MVC框架作为支撑，在密码传输以及数值计算等方面全部采用了特殊加密传输/存储算法来保证数据的保密性。以及同一用户同一终端多浏览器登录测试和同一用户多终端浏览器登录。

3.5.6 可移植性

可移植性是软件质量之一，良好的可移植性可以提高软件的生命周期。本次开发使用了较为先进的X语言作为开发主语言，有着更强的移植性，完全满足软件从一个平台更好地过渡到实际平台操作中。

3.5.7 可维护性

本次软件测试过程中，我们对软件的结构、接口、功能和内部过程的难易程度进行了一一测试，通过该系统提供的用户说明书、设计文档、结构化设计、源代码内部文档说明来对软件进行测试，因此本系统有着较好的可理解性。

通过不同的测试方式对系统进行了完整的测试，通过测试得知本系统的可测试性较好。

综上所述，该系统有着较好的可维护性。

3.5.8 完整性

本系统有着较高的代码安全性，保障性和可维护性。运作较为良好，能够满足用户基本需求，能够经受一般性测试及压力测试，有部分安全功能能够规避安全漏洞且易于理解并遵循逻辑。但修改和扩展时有引入新错误的风险。因此基本符合高软件完整性要求。

4测试结果

4.1 BUG趋势图

此次黑盒测试总共发布4个版本，B1-B2为计划内迭代开发版本（针对项目计划的基线标识），B3-B5为进行的回归测试版本，bug版本趋势图如下图所示。

4.2 第一阶段、增量确认测试

时间从2020年12月15日开始至2021年2月7日结束，从BUG趋势图也可以看出，从B1到B2的bug数有着明显的上升。综合分析原因，一、在B1阶段测试模块相对较少；二、在B2阶段测试模块通过与用户研讨修改后，bug相对增加。

B1：在B1测试阶段，共有27个BUG，因为B1版本相对不完整，因此，其Bug数量较低。

B2：由于在与用户的头脑风暴及体验中，用户改进及项目趋于完整，这一版本中，除了对B1版本中bug验证同时对B1进行了回归测试，所以B2中的bug呈现了明显的增长趋势。

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

时间从2021年2月10日开始至2021年3月31日结束，验证了B1-B3的bug。

B3：进行第一轮回归测试，发现的bug数为13个，遗留两个问题：三维展示数据标注、三维实时标注。

B4：进行第二轮回归测试，第一次回归测试没有涉及到用户管理、地下水模块的测试。本次回归测试的时候，重点进行了这个方面的测试，并发现了大量的数值问题bug。并开始进行全面测试。最终测试发现27个bug，严重级别的bug有17个。严重级别的bug主要集中在三维展示模块；功能性严重bug发现一个，系统基本可以正常运行。

B5：B5验证了B1-B4中未验证的bug，重点对地下水测试点及三维动态展示测试点进行了测试。测试过程中未发现bug。

4.4 BUG严重程度

本次测试中，大部分功能能够正常运行并符合测试标准，bug错误主要集中在一些前台编码及页面设计方面；另外，个别功能bug程度较为严重如：三维动态展示及地下水模型的bug严重程度较大。在第二轮回归测试阶段，主要功能部分没有实现、产品与需求规格书不符、功能与要求不符。以及在地下水模块中存在着严重的数值计算错误。

4.5 BUG引入阶段

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

4.6 BUG引入原因

4.7 BUG状态分布

由bug状态图可以看出，未解决的bug有2个，主要是B3中新提交的bug，是三维动态标注部分。

5 软件测试结论

5.1 功能性

系统正确实现了用户所提出的需求，实现了系统的启动与登录、数据库功能、XXXX功能、XXXX各项功能、XXXX功能、鉆浸技术计划编制模块功能、时间设置功能、XXXX展示功能及系统维护功能。

5.2 易用性

现有系统实现了易用性，其包括系统中所涉及的查询、添加、删除、修改操作相关提示信息的一致性和可理解性。

使用了下拉列框限定名词，使用了更加友好的UI设计等。

开发了三维动态展示并与二维模型相关联以此提升了可视化。

5.3 可靠性

现有系统容错性较高，数据库稳定性较高。

5.4 兼容性

现有系统支持市面上所涵盖的所有主流浏览器。

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

5.5 安全性

系统采用C/S设计模式且采用了最先进、稳定的MVC框架作为支撑，在密码传输以及数值计算等方面全部采用了特殊加密传输/存储算法来保证数据的保密性。以及同一用户同一终端多浏览器登录测试和同一用户多终端浏览器登录。

6缺陷汇总/质量评估

6.1 覆蓋率

此次测试涵盖了此次系统开发100%的功能，极少部分页面需求描述无明确定义，对输入限制无详细定义，无明确的测试依据。此次测试用例覆蓋率分析图：

6.2 遗留缺陷的影响

缺陷描述：XXXXXX （以实际项目为准）

缺陷影响：XXXXXX 例如：影响用户整体观感，用户易用性不好。

推迟原因：XXXXXX 例如：实现较为困难（以实际项目为准）。

缺陷描述：XXXXXX （以实际项目为准）

缺陷影响：影响用户对于XXXX的及时更新，导致用户体验差。（以实际项目为准）

7 改进建议

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

项目开发过程当中，应与用户保持较多的沟通，通过沟通之后，能够在很大程度上避免一次性软件开发错误，提升用户满意度。

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

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

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