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