集成测试通过之后，各个模块已经被组装成了一个完整的软件包，这时就需要进行系统测试了。传统的系统测试指的是通过集成测试的软件系统，作为计算机系统的一个重要组成部分，其将与计算机硬件、外部设备、支撑软件等其他系统元素组合在一起进行测试，目的在于通过与系统需求定义作比较，发现软件与需求规格不符合或者相矛盾的地方，从而提出更加完善的解决方案。这里特别提出需要软硬件支撑的虚拟现实(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严重程度
如图3所示，测试发现的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) 登录错误次数未作限制。