集成测试通过之后，各个模块已经被组装成了一个完整的软件包，这时就需要进行系统测试了。传统的系统测试指的是通过集成测试的软件系统，作为计算机系统的一个重要组成部分，其将与计算机硬件、外部设备、支撑软件等其他系统元素组合在一起进行测试，目的在于通过与系统需求定义作比较，发现软件与需求规格不符合或者相矛盾的地方，从而提出更加完善的解决方案。这里特别提出需要软硬件支撑的虚拟现实(Virtual Reality，VR)项目测试的特殊性。

本节以“某教务管理平台系统”的系统测试总结报告为例,介绍软件项目的系统测试活动是如何组织安排的。

01、测试前的准备

1. 测试目的

进行系统测试主要有以下 4 个目的。

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

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

(3) 评估测试执行和测试计划是否符合产品需求。

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

2. 术语定义

出现以下缺陷，测试将会把问题定义为严重 Bug。

(1) 系统无响应，处于死机状态，需要人工修复才可复原。

(2) 选择某个菜单后出现“页面无法显示”或者返回异常错误。

(3) 进行某个操作(增加、修改、删除等)后，出现“页面无法显示”或者返回异常错误。

(4) 当对必填字段进行校验时，未输入必填字段，却出现“页面无法显示”或者返回异常错误。

(5) 系统定义为不能重复的字段，在输入重复数据后，出现“页面无法显示”或者返回异常错误。

02、测试概要

该软件系统测试共持续 22 天，测试功能点 124 个，执行 1780 个测试用例，平均每个功能点执行测试用例 14.3 个，测试共发现 244 个 Bug，其中严重级别的 Bug42 个，无效 Bug35 个，平均每个测试功能点 1.8 个 Bug。

本软件共发布了 9 个测试版本，其中，V1~V4 为计划内迭代开发版本(针对项目计划的基线标识)，V5~V9 为回归测试版本。计划内测试版本 V1~V4 测试进度依照项目计划时间晚 2 天完成并提交报告。V5~V9 为计划外回归测试版本，总体比计划晚 5 天完成测试。

本软件测试通过项目管理工具中的缺陷管理进行缺陷跟踪管理，V1~V4 测试阶段都有详细的 Bug 分析表和阶段测试报告。

1. 功能性测试用例

(1) 系统实现的主要功能，包括各实体内容的查询、添加、修改、删除。

(2) 系统实现的次要功能，包括学期自动切换，为用户分配权限，课程教师与班级绑定，大纲与课程绑定，权限控制菜单按钮等。

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

2. 易用性测试用例

(1) 操作按钮提示信息的正确性、一致性、可理解性。

(2) 限制条件提示信息的正确性、一致性、可理解性。

(3) 必填项的标识。

(4) 输入方式的可理解性。

(5) 中文界面下数据语言与界面语言的一致性。

03、测试环境

1. 软硬件环境

本次系统测试的软硬件环境如表 1 所示。

■ 表 1 系统测试软硬件环境配置

2. 网络环境

本次系统测试的网络拓扑结构如图 1 所示。

■ 图 1 系统测试网络拓扑结构

04、测试结果

1. Bug 趋势图

此次系统测试共发布 9 个测试版本，其中，V1~V4 为计划内迭代开发版本，V5~V9 为回归测试版本，Bug 版本趋势图如图 2 所示。

■ 图 2 Bug 版本趋势图

(1) 第一阶段(V1~V4)：增量确认测试。

V1：从图 7-3 中看到 V1 共有 43 个 Bug，因为 V1 版本有一个功能模块在 V2 版本才开始测试，故 V1 测试模块相对较少，该版本 Bug 相对较少。

V2：由于 V1 中的一个功能模块增加到 V2 中进行测试，这一版本除了对 V1 中的 Bug 进行验证，同时对 V1 进行了回归测试，所以 V2 中的 Bug 数相对 V1 出现了明显的增长趋势。

V3：V3 版本因为有 V2 版本的 Bug 验收测试，以及 V1、V2 的回归测试，共发现 23 个 Bug，有了明显的下降，说明前期测试的工作及程序开发人员的修正的效率和质量都比较高。

V4：V4 版本 Bug 数有一个小幅回升增加的趋势，是因为提出了新的开发功能模块，该版本需求定义又有变动。

(2) 第二阶段(V5~V9)：Bug 验证及功能回归确认测试。

V5 和 V6 进行了回归测试，V7 对之前的 Bug 进行了验证。

V5：进行第一轮回归测试，发现 Bug 数量为 21 个。

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

V7：没有进行全面的回归测试，只验证了 V1~V6 未通过验证的 Bug，所以 Bug 数明显比较少。

V8：V8 版本进行了全面的回归测试，同时重点测试了权限控制、业务流程以及前后关联映射，所以本次发现的 Bug 有 7 个是严重级别的，说明最后冲刺阶段系统测试的功能及业务控制还存在一定问题。

V9：V9 版本经过程序开发人员较为精密的修改验证，为延期 4 天后提交的版本，本次对重新发布的版本进行了全面的回归测试，特别是对严重级别的 Bug 进行了重点测试，没有发现问题，只有个别功能性的问题存在操作便捷性的修正。总体说明系统功能已经稳定。

2. Bug 严重程度

如图 7-4 所示，测试发现的 Bug 主要集中在“一般”和“次要”级别，属于一般性的缺陷，但是测试时出现了 42 个严重级别的 Bug，严重级别的 Bug 主要表现在以下 4 方面。

(1) 系统主要功能没有实现。

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

(3) 学校学期自动切换控制这一功能未能有效形成约束，部分排课数据出现查询异常的问题。

(4) 所设计的数据库角色管理及控制混乱，出现部分角色找不到页面，或页面不具备操作权限等问题。

■ 图 3 Bug 严重程度图

3. Bug 引入阶段

如图 4 所示，此次系统测试发现的 Bug 主要为后台编码阶段和前台编码阶段的 Bug，甚至接近全部 Bug 总数的 80%。

■ 图 4 Bug 引入阶段分析

4. Bug 引入原因

如图 5 所示，此次系统测试发现的 Bug 主要源于前台编码、后台编码和易用性的不合要求，其占到全部 Bug 的 78%。

■ 图 5 Bug 引入原因分析

5. Bug 状态分布

如图 6 所示 Bug 状态图可以看出，未得到有效解决的 Bug 有 3 个，这是因为后期毕业设计流程的需求部分有变动，需要重新设计，所以暂时没有处理，其他部分都已经解决。

■ 图 6 Bug 状态图

05、测试结论

1. 功能性

系统正确地实现了基于学期管理的教务功能，实现了培养方案、课程及大纲等的自动获取和初始化，实现了学期教学安排、实验排课安排、毕业设计管理等功能，同时也实现角色及权限管理的查询、添加、修改、删除等操作，系统还实现了将权限控制细化到部分菜单按钮的功能。

系统在实现毕业设计管理功能的同时，存在毕业生学生志愿选择以及教师审核过程权限控制不严密的问题，权限设计有可以进一步补充完善的地方。

2. 易用性

现有系统实现了以下易用性。

(1) 查询、添加、删除、修改操作相关提示信息的一致性、可理解性。

(2) 输入限制的正确性。

(3) 输入限制提示信息的正确性、可理解性、一致性。

现有系统存在以下易用性缺陷。

(1) 界面排版不美观，部分页面功能按钮操作不符合大众习惯。

(2) 输入、输出字段的可理解性差。

(3) 输入缺少解释性说明。

(4) 中英文对应信息不完全正确。

3. 可靠性

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

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

4. 兼容性

现有系统主要在 Windows 下测试，对 IE11 浏览器、Chrome84 浏览器和 Firefox88 浏览器兼容，但未进行其他平台浏览器的兼容性测试。

5. 安全性

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

(1) 把某一个登录后的页面保存下来后，在本地打开并不能在不登录的情况下单独对其进行操作。

(2) 直接输入某一页面的 URL 不能打开页面并进行操作，会跳转到登录页面。

现有系统未实现以下安全功能。

(1) 用户名和密码对大小写敏感。

(2) 登录错误次数未作限制。