一、绪论
当今社会信息技术的高速发展带领人们步入了一个全新的时代,依托于网络通讯技术信息技术得以蓬勃发展并与之相结合在大数据的支撑下展现了不一样的魅力,如今信息技术带给了我们极大的便利日常生活中都已离不开信息技术的支持,信息技术的高效性以及准确性让人们获取信息资源的渠道变的方便起来,打破了地域之间的限制极大的缩短了人与人之间的交流阻碍。如今航天航空、勘探深海、开发新能源都离不开数字信息技术的支持,信息技术的发展已成为了新时代最热门的行业,信息技术的强大逐渐展露人们对于信息技术使用的深度开发也在不断进行。各个行业都开始利用信息技术来为自己提供便利的服务,即提高了行业资源的利用率也谋求了更大的经济利润。在当下社会经济飞速发展的背景下若想不被淘汰就必须参与到信息技术的建设以便为自己博得一席之地,无论信息技术如何创新发展其本质最终为整个社会服务,而社会的发展基础在于每一位个体人员的不断奋斗付出。利用好信息技术可以大大降低企业的管理成本、人工成本、资金成本也提高了人们对于企业管理的工作效率。通过信息技术的管理运用实现对复杂企业运营活动的数据进行数字化显示,使人们可以更直观的感受到信息技术所带来的经济效益。
随着人口的不断增长体育馆需求使用量也跟着暴增,这些新增的需求量给体育馆的管理带来了新的挑战,目前国内的体育馆在数量和规模上还无法满足各方面的需求,场地资源有限这也就造就了有些人员无法参与活动的现象,而且在实际操作过程中人们还是依赖于旧式的电话预定的方式,预定效率低,无法满足现如今的管理需求,而且在人员高峰期还常常会出现重复预定的情况,不仅带来了不好的后果也让人们产生不悦的心情,相互之间互不相让处理不当有时还会发生斗殴事件,因此针对这些问题对于场地的预约安排需要做到及时准确。
为了解决平时工作中所遇到的这些问题,本次研究设计了基于SpringBoot+Vue框架开发的体育场馆预约管理系统,为广大用户提供线上预约与审核以及体育器材租借等功能。利用网络信息技术来提升体育场馆的管理效率,提升信息技术的利用程度。
二、可行性分析
2.1 经济可行性
本次开发的系统利用免费的技术进行开发,SpringBoot框架比较成熟,开发周期短,成本低,系统开发完成之后可以减少人工对体育场馆和体育器材进行管理带来的成本,所以综合起来说,本系统在经济上是可行的。
2.2 技术可行性
本次介绍的系统采用的是SpringBoot+Vue框架进行开发,Windows10操作系统,前端采用Vue框架,采用MyBatis与后台数据库进行连接,MyBatis是对Jdbc的封装,完成数据的添加、修改、删除、查询等功能。Redis实现用户登录信息存储的功能。SpringMVC框架整合Web项目框架,功能强大而且稳定,而MySQL灵活易维护在开发方面具有方便快捷、使用灵活的特点,以及目前的广泛实际应用,因此使用SpringBoot+Vue来完成该系统整体开发,从而说明本系统在技术方面可行。
硬件方面,科技飞速发展的今天,硬件更新的速度越来越快,容量越来越大,可靠性越来越高,价格越来越低,其硬件平台完全能满足此系统的需要。
2.3 操作可行性
本次开发设计的体育场馆预约管理系统其面向人群是某市体育场馆参与者和管理员,在信息技术普及的今天,他们对于使用信息化产品已经具备了一定的基础,其次某市体育场馆管理员在学习过程中本身就具有一定的知识基础,对于信息化产品的运行使用不存在任何操作上的难题,很多时候甚至都不需要指导就可以上手操作,因此本次的开发设计在操作上可行的。
2.4 系统的技术介绍
2.4.1 Spring Boot
Spring Boot 是所有基于 Spring 开发的项目的起点。Spring Boot 的设计是为了让你尽可能快的跑起来 Spring 应用程序并且尽可能减少你的配置文件。简单来说就是Spring Boot其实不是什么新的框架,它默认配置了很多框架的使用方式,就像Maven整合了所有的jar包,
Spring Boot整合了所有的框架。
2.4.2 Vue
Vue是一套用于构建用户界面的渐进式框架。与其它大型框架不同的是,Vue 被设计为可以自底向上逐层应用。Vue 的核心库只关注视图层,不仅易于上手,还便于与第三方库或既有项目整合。另一方面,当与现代化的工具链以及各种结合使用时,Vue 也完全能够为复杂的单页应用提供驱动。
2.4.5 Redis
简单来说 redis 就是一个数据库,不过与传统数据库不同的是 redis 的数据是存在内存中的,所以读写速度非常快,因此 redis 被广泛应用于缓存方向。另外,redis 也经常用来做分布式锁。redis 提供了多种数据类型来支持不同的业务场景。除此之外,redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。
2.4.6 ElementUI
Element,一套为开发者、设计师和产品经理准备的基于 Vue 2.0 的桌面端组件库。Element是前端开源维护的Vue UI组件库,更新频率还是很高的,基本一周到半个月都会发布一个新版本。组件齐全,基本涵盖后台所需的所有组件,文档讲解详细,例子也很丰富。没有实际使用过,网上的Element教程和文章比较多。Element应该是一个质量比较高的Vue UI组件库。
三、需求分析
3.1 系统功能模块概述和分析
《体育场馆预约管理系统》主要功能如下:
1、用户管理:管理整个系统的所有用户信息,而且只能由管理员角色的用户进行管理。
2、公告管理:管理员可以管理公告信息,所有用户都能查看公告信息。
3、预约管理:管理员可以管理所有预约体育场馆的信息,普通用户可以查看自己预约体育场馆的信息。
4、租借管理:管理员可以管理所有租借体育器材的信息,普通用户可以查看自己租借体育器材的信。
3.1.1 登录
功能描述 | 系统用户(普通用户和管理员)能对系统进行登录操作 |
输入项 | 用户昵称、用户密码、验证码 |
处理描述 | 系统用户(普通用户和管理员)在登录页面正确输入用户昵称、用户密码和验证码后,点击登录按钮,能进入登录后的页面 |
输出项 | 无 |
业务规则 | 系统用户(普通用户和管理员)都能进行登录功能操作 |
界面要求 | 友好、美观、易用 |
3.1.2 预约体育场馆
功能描述 | 系统用户(普通用户和管理员)能对体育场馆进行预约操作 |
输入项 | 无 |
处理描述 | 系统用户(普通用户和管理员)在登录系统后,在体育场馆列表页面,选择一条空闲中的体育场馆数据后点击预约按钮,填写预约信息后,点击确定完成预约体育场馆操作。 |
输出项 | 无 |
业务规则 | 系统用户(普通用户和管理员)只能预约处于空闲中的体育场馆信息 |
界面要求 | 友好、美观、易用 |
3.1.3 租借体育器材
功能描述 | 系统用户(普通用户和管理员)都能进行租借体育器材的操作 |
输入项 | 无 |
处理描述 | 系统用户(普通用户和管理员)在登录系统后,在体育器材列表页面,选择一条有余量且上架的体育器材数据后点击租借按钮,填写租借信息后,点击确定完成租借体育器材操作。 |
输出项 | 无 |
业务规则 | 系统用户(普通用户和管理员)只能租借有余量且上架的体育器材的操作。 |
界面要求 | 友好、美观、易用 |
3.1.4 添加体育场馆
功能描述 | 管理员能进行添加体育场馆的操作 |
输入项 | 体育场馆名称、体育场馆位置、体育场馆图片、预约费用、体育场馆状态、体育场馆简介。 |
处理描述 | 管理员要先登录系统,在体育场馆列表页面中,点击添加按钮,按要求输入体育场馆信息后,点击确定按钮,完成添加体育场馆信息的操作。 |
输出项 | 无 |
业务规则 | 只有管理员能进行添加体育场馆的操作 |
界面要求 | 友好、美观、易用 |
3.1.5 编辑体育场馆
功能描述 | 管理员能进行编辑体育场馆的操作 |
输入项 | 体育场馆名称、体育场馆位置、体育场馆图片、预约费用、体育场馆状态、体育场馆简介。 |
处理描述 | 管理员要先登录系统,在体育场馆列表页面中,选择要编辑的体育场馆,然后点击编辑按钮,按要求输入修改内容后,点击确定按钮,完成编辑体育场馆信息的操作。 |
输出项 | 无 |
业务规则 | 只有管理员能进行编辑体育场馆的操作。 |
界面要求 | 友好、美观、易用 |
3.1.6 删除体育场馆
功能描述 | 管理员能进行删除体育场馆的操作 |
输入项 | 无 |
处理描述 | 管理员要先登录系统,在体育场馆页面中,选择要删除的体育场馆,然后点击删除按钮,完成删除体育场信息的操作 |
输出项 | 无 |
业务规则 | 只有管理员能进行删除体育场馆的操作 |
界面要求 | 友好、美观、易用 |
3.1.7 添加体育器材
功能描述 | 管理员能进行添加体育器材的操作 |
输入项 | 体育器材名称、体育器材品牌、体育器材图片、租借费用、体育器材数量、体育器材状态、体育器材简介。 |
处理描述 | 管理员要先登录系统,在体育器材页面中,点击添加按钮,按要求输入体育器材信息后,点击确定按钮,完成添加体育器材信息的操作。 |
输出项 | 无 |
业务规则 | 只有管理员能进行添加体育器材的操作。 |
界面要求 | 友好、美观、易用 |
3.1.8 添加公告信息
功能描述 | 管理员能进行添加公告信息的操作。 |
输入项 | 公告内容 |
处理描述 | 管理员要先登录系统,在公告列表页面中,点击添加按钮,按要求输入公告信息后,点击确定按钮,完成添加公告信息的操作 |
输出项 | 无 |
业务规则 | 只有管理员能进行添加公告信息的操作。 |
界面要求 | 友好、美观、易用 |
3.1.9 注册
功能描述 | 系统用户(普通用户和管理员)都能进行注册的操作 |
输入项 | 用户昵称、用户密码、确认密码、手机号码 |
处理描述 | 系统用户(普通用户和管理员)在注册页面输入用户昵称、用户密码、确认密码和手机号码后,点击注册按钮后,能完成注册用户的操作。 |
输出项 | 无 |
业务规则 | 系统用户(普通用户和管理员)都能进行注册的操作,用户昵称不能出现重复。 |
界面要求 | 友好、美观、易用 |
3.1.10 删除用户信息
功能描述 | 管理员能进行删除用户信息的操作 |
输入项 | 无 |
处理描述 | 管理员要先登录系统,在用户列表页面中,选择一条要删除的用户数据后,点击删除按钮,即可完成删除用户的操作。 |
输出项 | 无 |
业务规则 | 只有管理员能进行删除用户信息的操作,删除用户信息后,被删除用户的有关信息都要同步清除。 |
界面要求 | 友好、美观、易用 |
3.2 系统功能模块设计
根据系统功能分析,将整个系统的功能模块规划为如下的功能模块图。
3.3 用例分析
3.4 数据库分析
3.4.1 概念模型设计
E-R模型:
3.4.2 数据库表设计
数据库表设计主要是把概念结构设计时设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。它包括数据项、记录及记录间的联系、安全性和一致性约束等等。导出的逻辑结构是否与概念模式一致,从功能和性能上是否满足用户的要求,要进行模式评价。
本系统数据库表如下:
user用户表
字段名称 | 数据类型 | 主键 | 是否空 | 说明 |
id | char(8) | Y | N | 用户id |
username | varchar(8) | N | N | 用户昵称 |
password | varchar(16) | N | N | 用户密码 |
phone | varchar(11) | N | N | 手机号码 |
sex | int(2) | N | N | 用户性别 |
head_pic | varchar(256) | N | N | 用户头像 |
role_id | int(2) | N | N | 用户所属角色id |
announce 公告表:
字段名称 | 数据类型 | 主键 | 是否空 | 说明 |
id | char(8) | Y | N | 公告id |
content | varchar(512) | N | N | 公告内容 |
user_id | char(8) | N | N | 公告所属用户id |
create_time | datetime | N | N | 创建时间 |
hall体育场馆表:
字段名称 | 数据类型 | 主键 | 是否空 | 说明 |
id | char(8) | Y | N | 体育场馆id |
name | varchar(16) | N | N | 体育场馆名称 |
location | varchar(64) | N | N | 体育场馆位置 |
fee | decimal(10,2) | N | N | 预约费用 元/小时 |
state | int(2) | N | N | 体育场馆状态 1:空闲中;2:已预约 |
info | varchar(256) | N | N | 体育场馆简介 |
photo | varchar(256) | N | N | 体育场馆图片 |
equipment体育器材表:
字段名称 | 数据类型 | 主键 | 是否空 | 说明 |
id | char(8) | Y | N | 体育器材id |
name | varchar(16) | N | N | 体育器材名称 |
num | int(2) | N | N | 体育器材数量 |
brand | varchar(16) | N | N | 器材品牌 |
fee | decimal(10,2) | N | N | 租借费用 元/小时 |
photo | varchar(256) | N | N | 体育器材图片 |
info | varchar(256) | N | N | 体育器材简介 |
state | int(2) | N | N | 体育器材状态 1:已上架;2:已下架 |
appointment预约体育场馆表:
字段名称 | 数据类型 | 主键 | 是否空 | 说明 |
id | char(8) | Y | N | 预约id |
hall_id | char(8) | N | N | 预约所属体育场馆id |
hall_name | varchar(16) | N | N | 预约所属体育场馆名称 |
hall_photo | varchar(256) | N | N | 预约所属体育场馆图片 |
user_id | char(8) | N | Y | 预约所属用户id |
start_time | datetime | N | N | 预约体育场馆开始时间 |
end_time | datetime | N | N | 预约体育场馆结束时间 |
state | int(2) | N | N | 预约状态 1:待审核;2:审核通过;3:审核不通过;4:使用中;5:已完成;6:已取消 |
create_time | datetime | N | N | 创建时间 |
fee | decimal(10,2) | N | N | 预约体育场馆费用 |
fee_rule | varchar(16) | N | N | 收费标准 |
remark | varchar(128) | N | N | 审核备注 |
rental 租借体育器材表:
字段名称 | 数据类型 | 主键 | 是否空 | 说明 |
id | char(8) | Y | N | 租借id |
start_time | datetime | N | N | 租借器材开始时间 |
end_time | datetime | N | N | 租借器材结束时间 |
fee | decimal(10,2) | N | N | 租借器材费用 |
fee_rule | varchar(16) | N | N | 收费标准 |
num | int(2) | N | N | 租借器材数量 |
create_time | datetime | N | N | 创建时间 |
user_id | char(8) | 租借器材所属用户id | ||
state | int(2) | 租借状态 1:待审核;2:审核通过;3:审核不通过;4:租借中;5:已完成;6:已取消 | ||
equipment_id | char(8) | 租借所属体育器材id | ||
equipment_name | varchar(16) | 租借所属体育器材名称 | ||
equipment_photo | varchar(256) | 租借所属体育器材图片 | ||
remark | varchar(128) | 审核备注 |
3.5 系统工作流程分析
系统工作流程包含普通用户工作流程和管理员工作流程,如下图所示:
四、体育场馆预约管理系统设计与实现
《体育场馆预约管理系统》主要针对普通用户和管理员两类角色。整个系统对待所有用户均采用相同的入口和相同界面。不同用户的操作选项会因为其所扮演的角色的权限而有所区别,整个系统界面风格采用体育场馆预约管理系统的常见风格,简约大气而且方便使用,下面就具体来叙述整个系统的设计和实现。
4.1 用户登录模块
用户通过主页面的登录链接进入登录页面。用户填写正确的用户昵称、用户密码和验证码后,点击登录。登录成功后进入到用户系统中。用户登录模块如下图所示。
4.2 用户注册模块
用户通过主页面的注册链接进入注册页面。用户填写正确的用户基本信息后,点击注册。注册成功后可以用注册的账号进行登录。用户注册模块如下图所示。
4.3 首页模块
用户在登录进来后首先看到的就是首页模块,首页有数据基本的统计信息展示。首页模块如下图所示。
4.4 用户模块
用户在用户列表页面,普通用户可以查看并修改自己个人的基本信息,同时管理员也能进行对所有用户进行增删改查的操作。用户模块如下图所示。
4.5 体育场馆模块
普通用户在体育场馆列表页面,可以查询体育场馆信息,同时可以选择体育场馆进行预约操作,而管理员可以对体育场馆进行增删改查的操作。体育场馆模块如下图所示。
4.6 体育器材模块
普通用户在体育器材列表页面,可以查询体育器材信息,同时可以选择体育器材进行预约操作,而管理员可以对体育器材进行增删改查的操作。体育器材模块如下图所示。
4.7 租借体育器材模块
普通用户可以在租借体育器材列表页面查看自己的租借信息,管理员可以在租借体育器材列表页面管理所有器材信息。租借体育器材模块如下图所示。
4.8 预约体育场馆模块
普通用户可以在预约体育场馆列表页面查看自己的预约信息,管理员可以在预约体育场馆列表页面管理所有场馆信息。预约体育场馆模块如下图所示。
4.9 公告模块
普通用户可以在公告列表页面中查看公告信息,而管理员可以在公告列表页面中增删改查公告信息。公告模块如下图所示。
4.10 接口设计表
接口名称 | 接口注释信息 |
public ResponseDTO<PageDTO<AnnounceDTO>> getAnnounceListByPage(PageDTO<AnnounceDTO> pageDTO) | 分页获取公告数据 |
public ResponseDTO<Boolean> saveAnnounce(AnnounceDTO announceDTO) | 保存公告数据(添加、修改) |
public ResponseDTO<Boolean> removeAnnounce(AnnounceDTO announceDTO) | 删除公告数据 |
public ResponseDTO<Boolean> saveAppointment(AppointmentDTO appointmentDTO) | 保存预约数据(添加、修改) |
public ResponseDTO<PageDTO<AppointmentDTO>> getAppointmentListByPage(PageDTO<AppointmentDTO> pageDTO, HttpServletRequest request) | 分页获取预约数据 |
public ResponseDTO<Boolean> removeAppointment(AppointmentDTO appointmentDTO) | 删除预约数据 |
public ResponseDTO<Integer> getAppointmentTotal(UserDTO userDTO ) | 获取预约总数 |
public ResponseDTO<List<Integer>> getAppointmentTotalByDays(UserDTO userDTO ) | 获取近五天预约数 |
ResponseDTO<List<AppointmentDTO>> getAppointmentExistList() | 获取已经预约的数据 |
public ResponseDTO<String> generateCaptcha() | 通用验证码生成器 |
public ResponseDTO<PageDTO<EquipmentDTO>> getEquipmentListByPage(PageDTO<EquipmentDTO> pageDTO) | 分页获取体育器材数据 |
public ResponseDTO<Boolean> saveEquipment(EquipmentDTO equipmentDTO) | 保存体育器材数据(添加、修改) |
public ResponseDTO<Boolean> removeEquipment(EquipmentDTO equipmentDTO) | 删除体育器材数据 |
public ResponseDTO<PageDTO<HallDTO>> getHallListByPage(PageDTO<HallDTO> pageDTO) | 分页获取体育场馆数据 |
public ResponseDTO<Boolean> saveHall(HallDTO hallDTO) | 保存体育场馆数据(添加、修改) |
public ResponseDTO<Boolean> removeHall(HallDTO hallDTO) | 删除体育场馆数据 |
public ResponseEntity<?> viewPhoto(String filename) | 系统统一的图片查看方法 |
public ResponseDTO<String> uploadPhoto(MultipartFile photo) | 自定义上传图片处理 |
public ResponseDTO<Boolean> saveRental(RentalDTO rentalDTO) | 保存租借数据(添加、修改) |
public ResponseDTO<PageDTO<RentalDTO>> getRentalListByPage(PageDTO<RentalDTO> pageDTO, HttpServletRequest request) | 分页获取租借数据 |
public ResponseDTO<Boolean> removeRental(RentalDTO rentalDTO) | 删除租借数据 |
public ResponseDTO<Integer> getRentalTotal(UserDTO userDTO) | 获取租借总数 |
public ResponseDTO<List<Integer>> getRentalTotalByDays(UserDTO userDTO) | 获取近五天租借数 |
public ResponseDTO<PageDTO<UserDTO>> getUserListByPage(PageDTO<UserDTO> pageDTO, HttpServletRequest request) | 分页获取用户数据 |
public ResponseDTO<Boolean> saveUser(UserDTO userDTO, HttpServletRequest request) | 保存用户数据(添加、修改) |
public ResponseDTO<Boolean> removeUser(UserDTO userDTO) | 删除用户数据 |
public ResponseDTO<UserDTO> login(UserDTO userDTO) | 用户登录操作处理 |
public ResponseDTO<Boolean> register(UserDTO userDTO) | 用户注册操作处理 |
public ResponseDTO<UserDTO> getLoginUser(UserDTO userDTO) | 获取当前登录用户 |
public ResponseDTO<Integer> getUserTotal() | 获取用户总数 |
public ResponseDTO<Boolean> logout(UserDTO userDTO) | 用户退出登录 |
五、系统测试
5.1 测试的目的与目标
在此系统进行初步实现之后,开始进行对系统进行测试,找出系统中存在的Bug,通过测试,用提交的Bug报告来为以后软件的改进提供标准和参考,能够在以后的系统改进中找到依据。
测试后的软件各模块基本功能可以顺利进行,尽可能的提高软件的健壮性。
5.2 测试方法
单元测试又称模块测试,是针对软件设计的最小单位 ─ 程序模块(这里所说的程序模块在Java中一个模块就是一个方法),进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
集成测试 (组装测试、联合测试),通常在单元测试的基础上,需要将所有模块按照设计要求组装成为系统。
确认测试(Validation Testing),确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。
系统测试(System Testing),是将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或与之矛盾的地方。
验收测试(Acceptance Testing),在通过了系统的有效性测试及软件配置审查之后,就应开始系统的验收测试。验收测试是以用户为主的测试。软件开发人员和QA(质量保证)人员也应参加。由用户参加设计测试用例,使用生产中的实际数据进行测试。在测试过程中,除了考虑软件的功能和性能外,还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。
5.3 测试用例
用户登录测试用例
功能特性 | 用户登入验证 | ||||
测试目的 | 验证是否输入合法的信息 | ||||
测试数据 | 用户昵称:sll 密码:123456 验证码:zsdn | ||||
测试内容 | 操作描述 | 数据 | 期望结果 | 实际结果 | 测试状态 |
1 | 输入用户昵称和验证码,按“登录”按钮。 | 用户昵称:sll, 密码为空, 验证码:1851 | 显示警告信息“用户昵称或密码为空!” | 显示警告信息“用户昵称或密码为空!” | 与期望结果相同 |
2 | 输入密码和验证码,按“登录”按钮。 | 用户昵称为空,密码:123456 验证码:1851 | 显示警告信息“用户昵称或密码为空!” | 显示警告信息“用户昵称或密码为空!” | 与期望结果相同 |
3 | 输入用户昵称和密码以及验证码,按“登录”按钮。 | 用户昵称:lwj, 密码:1111111 验证码:1851 | 显示警告信息“用户昵称或密码误!” | 显示警告信息“用户昵称或密码错误” | 与期望结果相同 |
4 | 输入用户昵称和密码以及验证码,按“登录”按钮。 | 用户昵称:sll, 密码:123456 验证码:1111 | 显示警告信息“验证码错误!” | 显示警告信息“验证码错误” | 与期望结果相同 |
5 | 输入用户昵称和密码和验证码,按“登录”按钮。 | 用户昵称:sll,密码:123456 验证码:1851 | 正确登录到系统首页界面 | 正确登录到系统首页界面 | 与期望结果相同 |
5.4 测试结论
把开始的代码写得越好,它出现的错误也就越少,你也就越能相信所做过的测试是彻底的。系统化测试以一种有序方式设法探测潜在的麻烦位置。同样,毛病最可能出现在边界,这可以通过手工的或者程序的方式检查。自动进行测试是最理想的,用得越多越好,因为机器不会犯错误、不会疲劳、不会用臆想某此实际无法工作的东西能行来欺骗自己。回归测试检查一个程序是否能产生与它们过去相同的输出。在做了小改变之后就测试是一种好技术, 能帮助我们将出现问题的范围局部化,因为新问题一般就出现在新代码里面。
测试和排错常常被说成是一个阶段,实际上它们根本不是同一件事。简单地说,排错是在你已经知道程序有问题时要做的事情。而测试则是在你在认为程序能工作的情况下,排错是在你已经知道程序有问题时要做的事情。而测试则是在你在认为程序能工作的情况下,为设法打败它而进行的一整套确定的系统化的试验。
六、结论
在系统的开发过程中,我们运用到了B/S三层结构技术和平时学习中掌握的一些技术,通过这些技术的实现,整个系统的性能得到了大大的提高。这些技术都在开发文档中做了比较详细的介绍。本系统还存在许多的缺陷和不足之处,比如很多细节上做的还不行,有些功能模块还应再加强。希望在以后的时间里,我们可以把这些缺陷都弥补过来,进一步完善系统。
通过本次开发我们锻炼了我们的自学、研究能力,也从中学到不少在企业在课堂上学不到的东西.通过实践我们也深刻的体会到软件开发的艰辛及问题解决后的喜悦心情,培养我们的独立思考问题的能力,同时也增强了我们的理论联系实际的能力,这为以后的工作奠定了良好的基础。
本系统可以在很大程度上帮助某企业或某高校对体育场馆进行管理,减少时间的浪费。但由于时间按和技术条件的限制,还存在一些不足之处,有些功能还需要改进,还应该做进一步的系统调查需求分析工作,更深入的完善系统。总之,一个紧跟时代步伐的真正使用的软件必需有一个不断完善改进的过程。