网上招聘是一个功能很复杂的系统，各个部门之间要有一定的协调能力。
要建立一个高效的管理系统的关键问题就是系统内部的各个模块的相互作用，简单的编写一个网站 只用html ，css ，javascript ，xml ，xsl技术就可以实现了。但是做一个系统就需要数据库等高端的技术支持，这样就复杂的多了，也需要处理很多数据，变得困难。
第一章节：
1. 功能描述
作为基于ssm 框架的旅游网站，分为前台展示系统和后台管理系统两个部分，这两个部分共用mysql 数据库。前台展示系统用来实现和用户的交互，前台部分用用户包括招聘用户和求职用户，两者都有基本功能有用户登陆和对个人的信息进行管理，招聘用户功能有发布招聘信息，对求职者发送相关通知，对单位信息进行修改等，求职用户功能有用户查询岗位信息，对简历内容进行撰写，填写用人单位的求职表信息等。后台管理系统包括用户管理（增删改查），单位信息管理（增删改查），新闻管理（增删改查）等。数据库用来记录用户信息，单位信息信息，个人简历信息，通知信息，新闻信息等。
2. 各功能模块
1) 前台界面
l 用户个人信息管理：实现基本的用户注册，登陆，修改信息操作。
l 用人单位信息更新：招聘用户对相关信息进行更新和维护。
l 发布招聘需求信息：招聘用户发布招聘需求，公布岗位信息。
l 处理简历信息：招聘用户可以对求职用户的简历信息进行处理，包括查看，回复，删除等操作。
l 处理求职表信息：招聘用户可以对求职用户的求指标信息进行处理，包括查看，回复，删除等操作。
l 用人单位信息查询：招聘用户对相关信息进行查询，包括对站内新闻的查询、对收到简历信息的查询、对求职用户详细资料的查询、对求职表信息的查询等。
l 个人简历信息管理：求职用户可以对简历进行编辑、预览、打印等相关操作。
l 求职者信息更新：求职用户对相关信息进行更新。
l 用人单位信息查询：求职用户对相关信息进行查询，包括对站内新闻的查询、对用人单位详细资料的查询等。
l 浏览单位及职位信息：求职用户对相关信息进行浏览，在此基础上可以填写该用人单位的求职信息表以及向单位投递简历。
l 查看消息：已登录用户可以接收到本网站推送的一些短消息和管理员回复的短消息，也可以删除消息。
2) 后台管理界面
l 用户管理：管理人员可以查看。
l 用人单位管理：管理人员可以添加，修改，查询，删除用人单位。
l 用人单位审批：管理人员可以对提出申请的用人单位进行审核批准等操作。
l 消息管理：管理人员向某个用户发送消息，也可以向多个用户推送相关信息，还可以查询已发送信息。
3) 后台数据库
本程序拟用mysql数据库，数据库表设计如下：
l 用户信息：用户id，用户的账号，密码，头像，用户登录名，性别，联系方式，身份证号，求职意向等。
l 求职表信息：求职表id，求职表选项，求职表内容等。
l 简历信息：简历信息id，简历内容等。
岗位信息：岗位信息id，岗位名称，岗位简介，等。
l 短消息：消息id，发送人id，接收人id，消息内容，状态（已读或未读）等。
3. 系统拟采用的技术路线
本课题是基于ssm框架（springMVC,spring,mybatis)的招聘系统，是标准的MVC模式，将系统分为表现层、controller层、service层、DAO层四层，使用spring MVC负责请求的转发和视图管理，spring实现业务对象管理，mybatis作为数据对象的持久化引擎，拟用win10系统，myeclipse8.6开发软件，tomcat8.0的环境进行开发，数据库采用mysql数据库，java为开发语言，页面中会用到jsp，css等技术，其性质为简化的Servlet，具有预编译、业务代码相分离、组件重用、跨平台等特性，并能够对网页中元素位置的排版进行像素级精确控制，支持几乎所有的字体字号样式，拥有对网页对象和模型样式编辑的能力。这些技术均为目前比较成熟稳定的，所以用这些技术开发本系统有利于本系统的稳定性。
本文的其他章节安排如下：
第二章：系统所用到相关的技术介绍。主要介绍系统在设计的过程中所有涉及到的有关技术。
第三章：酒店预订系统的需求分析。本章主要介绍系统在设计之前所进行的所有有关客户和用户的需求调查和分析，以使得后期系统的开发和维护更加具有合理性。其主要包括系统功能性需求分析、技术可行性分析和非功能性需求分析。
第四章：酒店预订系统的概要设计。本章主要讲解系统的总体环境搭建，和功能结构设计，该预订系统的类图设计、数据库设计和页面设计。
第五章：酒店预订系统的详细设计与实现。本章主要介绍系统的开发环境、配置和总体实现原理，以及各个模块的详细设计与实现的细节。
第六章：酒店预订系统的测试。本章主要介绍测试的目的、对该预订系统使用到的测试方法，然后对本系统的有关功能进行测试，对于测试的结果以表格的形式给出，接着对本章测试进行总的结论说明。
第二章节：
第二章 系统相关技术介绍
该酒店预订系统是基于SSM框架设计与实现的，该系统后台语言使用的是Java语言，主要涉及到的技术有B/S结构的数据库访问方式。前端的设计中涉及到的技术有JQuery和EasyUi等简洁、易用的插件集合。给出相关技术的介绍如下。
2.1 浏览器技术介绍
（1）B/S结构的数据库访问方式。
在酒店管理系统的架构中有B/S和C/S两种架构方式，本系统使用前者。B/S 模式采用 3 层结构，用户可以通过浏览器向 Web 发出请求信息，Web 根据用户需求，将指令发送至网络数据库管理系统，数据库管理系统再反馈用户想要查询的信息[10]。这样客户机上只需少量客户端软件即可，即真正的做到简化客户机的工作，把客户机从沉重的负担中解脱，把技术人员从繁重的技术维护和升级工作中解放。B/S的体系结构如图2-1所示。
图2-1 B/S结构示意图
（2）Web服务器Tomcat介绍。
Tomcat是Apache软件基金会下的一个分支部门的开发产品，它可以作为一个Servlet容器。根据Sun公司提供的技术规范，也可为Web服务器提供一些需要的功能。由于Tomcat自身含有HTTP服务器，所以它也可以被用作一个独立开来的Web服务器，我们在本程序中即就是这样使用它的。
2.2 前后端技术介绍
（1）MySQL数据库介绍。
MySQL 是一个当前较流行的数据库系统，它本是 MySQL AB公司研发的，现在已经成了Oracle公司旗下的产品。MySQL数据库管理系统将数据存于各个表中。不像先前的数据库直接将数据放一起，应用的速度会降低，也没有MySQL数据库这么灵活。
（2）SSM框架介绍。
SSM框架即就是指Spring，SpringMVC，Mybaits框架的集合，其中Spring和SpringMVC通常来说属于同一个框架，但是他们的工作内容却有着很大的不同。Spring是一个容器，用来特别标记一些常用的对象，使得对象的使用变的方便简洁。SpringMVC框架以DispatcherServlet为主要的控制器，它负责拦截前端发送的所有请求，并将请求发送给业务控制器，并且它还拥有处理器映射、视图解析、文件上传等功能。Mybaits负责和数据库进行交涉，将SQL语句从程序中单独提取出来，使得程序代码更为清晰，编程更为方便。该框架原理如图2-2所示。
图2-2 SSM框架原理图
（3）JQuery组件介绍。
JQuery是一个JavaScript库，它简化了JavaScript的编程，而且简单易学、使用方便。此外它还兼容各类浏览器，从设计之初就坚持开源插件化的理念。目前，在很多开源的 JS 框架中JQuery算是普及度较高的。很多公司像Google、Microsoft、IBM等都在使用它。但是新版的JQuery却不再支持IE8及其以下的浏览器。
（4）EasyUi组件介绍。
EasyUi是一种基于jQuery、Angular、Vue和React的用户界面的插件集合，它很简单，但是功能却十分强大。EasyUi一直在向着现代化、互动性的JavaScript程序的道路上努力着。用过EasyUi就知道它省去很多代码，我们只要加一些简单的HTML的属性就可排布自己想要的界面，它也支持用HTML5制作的网页。因此使用EasyUi将会很大的节省网页开发的时间和规模。
2.3 本章小结
本章对基于SSM框架的酒店预订系统的设计所用到的有关技术进行了简单的介绍，对该系统的实现原理有一个简单的结构介绍，便于对技术进一步掌
第三章 酒店预订系统需求分析
本章将对基于SSM框架实现的酒店预订系统的设计进行需求分析，并确定出该系统的基本功能需求和性能需求以及非功能性需求，为后续系统的设计与实现进程提供可靠的现实依据。主要建立系统的事件表、用例图、用例描述和对系统进行可行性分析等。
3.1 用户需求
对于酒店预订系统的设计首先要紧紧围绕着满足酒店客户的需求和方便管理人员的管理来进行分析。该系统需求分析的重点是摸清酒店员工和老板日常所做工作，以减少人员工作量和提高效率为宗旨，构造一个能够及时交互信息、安全、便捷的客房管理信息平台[11]。对于酒店的客户来说，首先需要注册账号、登录该系统，然后查找不同的房型和房间，选中自己想要的房间后进行网上预订，预订结束后要查看验证自己的预订订单的信息。其次就是客户应该具有管理该系统中自身的信息资料以及修改密码等功能。对于酒店的管理人员来说，首先要能够查看本系统中的客户信息，其次可以查看酒店当前的房间住宿情况，然后要具有管理订单的功能，接着需要对酒店的房型房间具有相关的管理功能，再接着就是查看该酒店的运营收入统计状况。
3.2 可行性分析
当我们准备设计一个系统时，可行性分析是一个必不可少的环节，通过可行性分析我们对系统将会有一个宏观的了解。同时能够把握该系统的可用性和适宜使用的程度。进而在设计中为我们提供一个清晰的整体思路。
3.2.1 技术可行性
开发本系统需要掌握的基础知识有Java语言的使用，以及前端基本的编程语言，例如HTML、CSS、JavaScript和jQuery基本的语法要掌握。本系统的开发框架是SSM框架，该框架的学习是本项目开发的重点同时也是难点，但是通过不断地学习和上网查阅相关的资料对该技术进一步的了解之后会有这样的认识，就是框架之下的开发使程序变得更加的规范化并且方便了我们对系统功能的实现。可能在系统开发之初会觉得SSM框架比较麻烦，但是当程序规模逐渐增大之后会对该框架的应用有更加良好的体会，从而在技术上对客户的需求具有了更多实现的可行性，因此使用该框架开发是一个行之有效的方案。
3.2.2 经济可行性
对于酒店预订系统的设计来说经济可行性是一个重要的考虑因素，我们必须从系统的软件配置和硬件配置两个方面出发进行考虑，并对项目建成以后能够取得什么样的经济效益进行提前预测。就酒店管理的设计来说价格过高的硬件设备往往会取得得不偿失的效果，所以一台性能中等的能够满足基本开发环境的电脑即可。软件资源方面我们采用开源的框架和开发软件。系统在投入运行后，所产生的经济效益也远比投入研发时更高，而且能够提高酒店运营效率，因此在经济层面上分析，具备一定可行性[12]。从当前国内状况来看中等性规模的酒店占据主体的位置，因此对于本系统的设计来讲，在经济可行性这一方面是足以具备开发前提的。
3.2.3 运行可行性
就该酒店预订系统而言其运行的条件并不苛刻，由于我们基于B/S的方式开发所以首要条件就是网络信号和接收设备，可以使用浏览器等。这些条件具备后即可以方便的运行系统。所以基于简单的运行条件，该系统可以在当今社会中进行广泛的使用。
3.2.4 社会可行性
在今天这个信息化的时代背景之下，互联网业务已经不再被社会群体束之高阁，每个人都可以轻松的使用网络预订系统，该系统的开发初衷就是紧紧围绕着良好的交互性来进行的，程序的设计质量的评估就必须依靠于市场，依靠于用户体验。所以该系统可以在当今社会中开展起来，所以该系统的使用可以对社会生活的方便快捷带来正向的影响。
3.3 系统用例分析
功能性需求分析的目的是为了详细呈现酒店预订系统的产品需求和系统的功能描述，以进一步定制系统的细节问题，便于后续的开发工作。
首先进行参与者分析。参与者分析首先要确定业务参与者，为了直观反映该系统的参与者，在这里本系统采用参与者词汇表进行描述，具体的参与者词汇表如表3-1所示。
表3-1 参与者词汇表
| 序号 | 词汇 | 同义词 | 描述 |
| 1 | 客户 | 顾客 | 想要使用该预订系统预订房间的客户 |
| 2 | 普通管理员 | 无 | 可以对该酒店预订系统进行简单管理的操作人员 |
| 3 | 总务管理员 | 无 | 对该系统的管理拥有所有的操作权限的使用者 |
当有了参与者词汇表后，我们对系统的相关事件就会有一个宏观的了解，下面我们就主要的参与者进行用例图的分析。系统用例图是指由参与者用例，边界构成的说明性视图，主要用于表达这些实体和系统之间的关系进而描述系统的功能，在该预订系统中主要的参与者有顾客，普通管理员和总务管理员，他们分别从不同方面使用系统。由于篇幅原因我们这里用系统的总用例图对系统的整体功能进行分析。酒店预订系统用例模型如图3-1所示。
图3-1 系统用例模型图
3.3.1 预订房间用例说明
在顾客预订房间的事件中，主要的业务参与者即可以为所有可正常使用该系统的用户，当管理员将该用户设置为冻结状态时那么该用户就无法登录系统。预订房间用例描述表如表3-2所示。
表3-2 预订房间用例描述表
| 用例名 | 预订房间 | 用例类型 |
| 用例ID | 01 | 业务需求 |
| 主要业务参与者 | 系统普通用户 | |
| 其他参与者 | 无 | |
| 描述 | 该用例主要内容是用户预订房间的功能分析 | |
| 前置条件 | 用户登录通过验证，成功进入系统 | |
| 后置条件 | 如果用户成功预订房间，那么将会修改系统的房间数据表中的房间状态为已预订，并且修改房型数据表中的该房型的预订数和可用数 | |
| 触发条件 | 用户点击提交预订订单时 | |
| 主事件流 | 用户 | 系统 |
| 1.[普通顾客用户]:点击预订 | 2.[系统]:显示预订订单输入框界面 | |
| 3.[普通顾客用户]:填写预订信息 | 4.[系统]:界面实时提示未填信息 | |
| 5.[普通顾客用户]:点击提交订单 | 6.[系统]:显示预订完成 | |
| 替代事件流 | A1 提交预订订单失败 | |
| [起始位置]点击提交按钮 | ||
| [触发条件]系统检测到有未填写的信息 | ||
| [具体内容]将未填信息项的名称返回提示给用户填写该信息 | ||
| [返回位置]订单信息填写界面 | ||
| 结束 | 订单生成，房间信息表、房型信息表修改完成 | |
3.3.2 查询订单用例说明
用户预订结束之后会有相应的订单生成，此时就需要查看订单信息。查询订单用例描述如表3-3所示。
表3-3 查询订单用例描述表
| 用例名 | 查询订单 | 用例类型 |
| 用例ID | 02 | 业务需求 |
| 主要业务参与者 | 系统普通用户 | |
| 其他参与者 | 无 | |
| 描述 | 用户查询自己的订单信息 | |
| 前置条件 | 用户通过登录，进入系统的个人中心 | |
| 后置条件 | 系统调用订单信息表显示酒店的该客户的订单 | |
| 触发条件 | 用户点击查询订单 | |
续表3-3 查询订单用例描述表
| 用例名 | 查询订单 | 用例类型 |
| 用例ID | 02 | 业务需求 |
| 主事件流 | 用户 | 系统 |
| 1.[普通用户]:点击查询订单 | 2.[系统]:判断该用户登录信息，调取订单表并显示该用户的订单 | |
| 3.[普通用户]:查询得到订单 | ||
| 替代事件流 | A1 查询失败 | |
| [起始位置]用户点击查询 | ||
| [触发条件]系统检测到长时间未操作 | ||
| [具体内容]该使用者一段时间未操作的情况下，被服务器删除登录信息，无法调用订单信息 | ||
| [返回位置]系统登录界面 | ||
| 结束 | 用户界面显示该用户的订单 | |
3.3.3 修改房型用例说明
在管理员管理房型的时候有时出于对业务的需要会对房型信息进行编辑。正常设置的房间数将通过编辑检查，但是当设置以后的可用房间数小于零时则会收到系统对该错误设置的提示。管理员编辑房型用例描述表如表3-4所示。
表3-4 编辑房型用例描述表
| 用例名 | 修改房型 | 用例类型 |
| 用例ID | 03 | 业务需求 |
| 主要业务参与者 | 系统管理员 | |
| 其他参与者 | 本系统具有该权限的其他管理员 | |
| 描述 | 管理员需要对房型信息进行修改 | |
| 前置条件 | 需要具有房型管理菜单的管理员 | |
| 后置条件 | 修改房型成功后系统将房型数据表中的信息进行更新 | |
| 触发条件 | 管理员点击提交修改 | |
| 主事件流 | 用户 | 系统 |
| 1.[管理员用户]:选中房型后点击修改 | 2.[系统]:调用房型信息表将该房型信息放入修改界面并显示修改界面 | |
| 3.[管理员用户]:修改信息并提交 | 4.[系统]:审查房型信息的有效性并显示修改成功的提示框 | |
| 5.[管理员用户]:点击确定，看到新修改的房型信息 | ||
续表3-4 编辑房型用例描述表
| 用例名 | 修改房型 | 用例类型 |
| 用例ID | 03 | 业务需求 |
| 替代事件流 | A1 提示修改失败 | |
| [起始位置]提交修改信息 | ||
| [触发条件]系统检测到新修改的房间数小于已入住数 | ||
| [具体内容]房型的可用房间数是房间总数减去已入住数，当可用房间数小于零时提示管理员检查数据 | ||
| [返回位置]房型修改界面 | ||
| 结束 | 房型信息修改成功，更新房型信息表 | |
3.3.4 添加房间用例说明
在同一个房型的情况下会有多个房间，那么此时每一个房间都需要有不同的编号，管理员在添加房间时，当房间编号已存在的情况下系统就要提示该编号已存在并终止更改房间的数据。添加房间的用例描述表如表3-5所示。
表3-5 添加房间用例描述表
| 用例名 | 添加房间 | 用例类型 |
| 用例ID | 04 | 业务需求 |
| 主要业务参与者 | 系统管理员 | |
| 其他参与者 | 本系统具有该权限的其他管理员 | |
| 描述 | 管理员需要添加房间信息 | |
| 前置条件 | 需要具有房间管理菜单的管理员 | |
| 后置条件 | 添加房间成功后系统将在房间数据表中插入新的房间信息 | |
| 触发条件 | 管理员点击添加房间 | |
| 主事件流 | 用户 | 系统 |
| 1.[管理员用户]:进入房间管理后点击添加 | 2.[系统]:将该系统添加房间信息界面显示到管理员界面 | |
| 3.[管理员用户]:填写信息并提交 | 4.[系统]:审查房间信息的有效性并显示添加成功 | |
| 5.[管理员用户]:点击确定，看到新添加房间信息 | ||
| 替代事件流 | A1 提示添加失败 | |
| [起始位置]提交添加信息 | ||
| [触发条件]系统检测到新添加的房间编号已存在 | ||
| [具体内容]系统调用房间信息表检查房间编号，当该房间编号与之前存储的房间编号重复时，提示管理员房间编号已存在，请检查输入 | ||
| [返回位置]添加房间界面 | ||
| 结束 | 房间添加成功，新的房间信息插入房间信息表 | |
3.3.5 修改订单用例说明
管理员也可对订单信息进行管理，可以在客户需要的情况下进行订单的修改。管理员修改订单信息的用例描述如表3-6所示。
表3-6 修改订单信息用例描述表
| 用例名 | 修改订单 | 用例类型 |
| 用例ID | 05 | 业务需求 |
| 主要业务参与者 | 系统管理员 | |
| 其他参与者 | 本系统具体该权限的其他管理员 | |
| 描述 | 管理员需要修改客户的订单 | |
| 前置条件 | 需要具有订单管理菜单的管理员 | |
| 后置条件 | 修改订单成功后系统将更新订单数据表中该条订单的信息，并且检查房型改变的情况更新房型的信息 | |
| 触发条件 | 管理员点击修改订单 | |
| 主事件流 | 用户 | 系统 |
| 1.[管理员用户]:点击修改订单 | 2.[系统]:检查是否选中订单，根据订单id从订单数据表中掉出该条订单的信息赋值到订单修改界面 | |
| 3.[管理员用户]:填写要修改的订单信息并提交 | 4.[系统]:审查订单信息的有效性，修改房型时，调用房型表更新房型表，显示修改成功 | |
| 5.[管理员用户]:点击确定，看到修改后的订单信息 | ||
| 替代事件流 | A1 提示修改失败 | |
| [起始位置]提交修改信息 | ||
| [触发条件]系统检测到订单信息中的入住和离店时间格式错误 | ||
| [具体内容]系统获取用户提交的订单信息后，将会调用数据库中的订单进行更新如时间格式错误将无法读取有效的信息继而更新失败，提示管理员需选择入住和离店时间 | ||
| [返回位置]修改订单信息界面 | ||
| 结束 | 订单修改成功，订单数据信息更新，房型更改时则房型数据更新 | |
3.3.6 添加入住用例说明
对于酒店管理来说需要该系统为自己的营销状况做出相应的统计，所以不管预订入住还是直接上店里办的入住都应当作出相应的统计。所以酒店管理员应当用到添加入住的功能，此外入住的时候可能会有支付更优惠的价格的情况，所以需要在入住信息里加上实际支付价格的信息。记录这些信息需要在前台处添加入住，添加入住将要用到入住信息表，房型表，房间表等。添加入住用例描述如表3-7所示。
表3-7 添加入住用例描述表
| 用例名 | 添加入住 | 用例类型 |
| 用例ID | 06 | 业务需求 |
| 主要业务参与者 | 系统管理员 | |
| 其他参与者 | 本系统具有该权限的其他管理员 | |
| 描述 | 管理员需要添加顾客的入住信息 | |
| 前置条件 | 需要具有入住管理菜单的管理员 | |
| 后置条件 | 添加入住信息成功后系统将在入住信息数据表中插入新的入住信息，更新订单信息表和房型信息表以及房间信息表 | |
| 触发条件 | 管理员点击添加入住信息 | |
| 主事件流 | 用户 | 系统 |
| 1.[管理员用户]:点击添加入住 | 2.[系统]:显示添加入住信息的界面 | |
| 3.[管理员用户]:点击选择订单的按钮 | 4.[系统]:调用订单信息表显示所有订单 | |
| 5.[管理员用户]:选中订单点击确定 | 6.[系统]:调用订单信息表显示选中的订单，返回添加入住界面将该订单的信息赋值到入住界面 | |
| 7.[管理员用户]:输入入住界面中的剩余未填项信息，然后点击确认添加 | 8.[系统]:审查信息有效性后，在入住信息表中插入新数据，更新订单信息表和房型信息表以及房间信息表 | |
| 替代事件流 | A1 提示选择订单 | |
| [起始位置]显示订单界面点击确定 | ||
| [触发条件]系统未检测到选择的订单 | ||
| [具体内容]系统调用订单信息表供选择，当管理员点击确定后要检查选中的订单并提取信息，如检查到未选中订单，提示管理员请选择订单 | ||
| [返回位置]显示所有订单界面 | ||
| 结束 | 入住添加成功，新的入住信息插入入住信息表，更新订单信息表和房型信息表以及房间信息表 | |
3.4 系统非功能性需求
系统非功能性需求可以分为产品需求、机构需求、外部需求等几个方面，对于该预订系统而言，因为是基于B/S的方式，所以响应时长取决于客户端浏览器的网络性能。在系统的响应时长上，对于管理员来讲需要判断其权限进行菜单的分配，所以访问管理页面大概需要0.5秒左右，对于普通用户来说其界面主要加载的是房型列表，该响应时长取决于酒店房型的数量，鉴于国内多数酒店的房型数量达不到大量数据的情况，故用户访问主页响应时长大概需要0.3秒。
从系统的可靠性方面来说，系统使用的数据库为mysql数据库，该数据库数据开源、稳定。在中国专业IT社区2019年发布的《2019-2020年中国开发者调查报告》中，mysql数据库的使用率以83%的压倒性优势稳居第一，其受到国内越来越多的公司和开发者的肯定，对于国内酒店而言利用该数据库存储数据是适宜的。
此外，在移植性方面看来，基于B/S方式的开发，使广大用户都具备使用条件。但是需要说明的是因为系统使用了easyui的插件集，所以使用IE8以下的浏览器时，在页面的兼容性方面可能会存在问题。
对于系统的维护性，因为是基于浏览器的访问所以不需要开发者奔赴使用现场提供系统升级，还有就是该预订系统使用面向对象的设计方式也可以很好的适应客户有变更的需求，对于系统的维护也提供了很大的方便。
3.5 本章小结
本章主要介绍了系统的需求分析，分别从功能性需求分析和可行性分析和非功能性需求分析的角度展开说明。本章分析包括了系统的各个模块的功能，故完成了系统大致功能的雏形，进而更加清晰了系统的设计方向。
第四章 酒店预订系统概要设计
4.1 系统设计原则
本系统的开发是为了便于酒店经营者更好的实现信息化办公，我们在系统的设计中实现了基本的管理功能可以对房型进行管理，可以对房间进行管理，可以进行入住管理，同时也可以管理客户的信息，对于酒店的客户来讲，可以通过该系统预订房间并且可以查看自己的订单，同时也可以修改密码，或修改自己的资料信息。
4.2 系统总体架构设计
本系统是基于SSM框架实现的酒店预订系统，其核心技术就是SSM开发框架。SSM开发框架是集合Spring，SpringMVC，Mybatis功能的一个框架，对于该框架在之前已经做过简单的介绍，这里我们结合本系统的框架设计进行说明。总的来说该框架是继承了MVC的开发方式来实现的，我们都知道这样的开发框架可使程序设计具有低耦合性。正是由于其分层的思想，采用这种开发模式开发的系统拥有低耦合性的特点，在实际的开发过程中，我们如果想后期能够更方便地对系统进行部分修改操作，就必须降低系统的耦合性，在设计接口的时候应该尽量简单避免重复，避免牵一发而动全身[13]。该框架的体系结构如图4-1所示。
图4-1 系统体系结构图
4.3 系统功能结构设计
在功能设计中应当紧紧遵循需求的分析，设计一些能够让用户感到使用方便的功能。在功能设计中需遵循简单原则，复杂的操作将迫使使用人员耗费大量的时间在系统操作上，合理的功能布局，颜色设计能给用户带来良好的用户体验[14]。本着操作起来方便有效的理念我们对本系统的功能模块进行划分。
该预订系统主要分为前端用户页面和后台管理员的控制页面，分别实现不同的功能，对于管理员可可以实现的功能有房型管理，房间管理，客户管理和入住管理等。对于普通用户可以实现的功能有预订房间，查询订单，修改个人信息，修改密码。具体的功能结构层次设计如图4-2所示。
图4-2 系统功能分解结构层次图
4.4 系统类图设计
该系统的静态模型用类图进行描述，类图是面向对象建模的主要组成部分，它表示的不是暂时性的信息而是类的内部结构以及类与类之间的关系。用于系统分类的一般概念建模或者详细建模。在预订房间这一用例中涉及到的对象有用户实体类，预订订单类和房型类等，在查询订单用例中涉及到的实体类有用户实体类，订单实体类等。在管理员编辑房型用例中设计的实体类有管理员用户类，房型类等，在管理员添加房间的用例中涉及到的实体类是管理员用户类，房间类，房型类等，在管理员编辑订单信息的用例中包含的实体类有订单类，其中若房型的信息被改动，那么还要涉及房型类，其他的类还有管理员用户类，普通用户类等。本系统的类图模型如图4-3所示。
4.5 数据库设计
4.5.1 数据库概念结构设计
系统开发人员完成系统所有数据表的结构设计后，再按关系数据库的设计原则将各表之间的关系用 UML 提供的元素进行连接，从而形成系统的总体数据库模型[15]。在该预订系统的概念结构设计中我们用ER图来表示各实体以及这些实体之间的相互关系。数据库的概念模型中最为常用的就是关系模型，通过一定的关系模式使得数据的管理变得严格，使用简单，能够为我们后续的开发在数据方面避免操作异常。本系统的概念结构设计ER图如图4-4所示。
图4-4 系统数据库概念设计ER图
4.5.2 数据库逻辑结构设计
逻辑结构设计即根据数据库的性质来设计和实施数据库的存储结构。该系统使用的数据库中建立的数据表有客户数据表，房型数据表，房间数据表，订单数据表，管理员用户数据表，管理角色数据表，管理权限数据表，菜单信息数据表，入住登记数据表，所有数据表的字符集均采用UTF-8的编码格式。其中客户数据表主要用于存储该系统客户的客户信息，表的结构包括客户id，用户名，密码，真实姓名，身份证号，手机号，地址和账号使用状态，其中使用状态在设计时规定“0”表示正常，“1”表示黑名单客户。其详细结构设计如表4-1所示。
表4-1 客户信息结构表
| 字段名 | 字段说明 | 类型及长度 | 可为空 | 键属性 | 初值 | 自增 |
| id | 客户id | int(11) | No | 主键 | (null) | Yes |
| username | 用户名 | varchar(32) | No | 无 | (null) | No |
| password | 密码 | varchar(32) | No | 无 | (null) | No |
| real_name | 真实姓名 | varchar(32) | Yes | 无 | (null) | No |
| id_card | 身份证号 | varchar(32) | Yes | 无 | (null) | No |
| phone | 手机号 | varchar(16) | Yes | 无 | (null) | No |
| address | 地址 | varchar(150) | Yes | 无 | (null) | No |
| status | 使用状态 | int(1) | Yes | 无 | 0 | No |
其中房型数据表主要用于存储该酒店的房型信息，表的结构包括房型id，房型名，图片地址，房型价格，房间数，预订数，入住数，使用状态，备注，其中使用状态在设计时规定“0”表示满房，“1”表示可用。其详细结构设计如表4-2所示。
表4-2 房型信息结构表
| 字段名 | 字段说明 | 类型及长度 | 可为空 | 键属性 | 初值 | 自增 |
| id | 房型id | int(11) | No | 主键 | (null) | Yes |
| name | 房型名 | varchar(64) | No | 无 | (null) | No |
| photo | 图片地址 | varchar(150) | Yes | 无 | (null) | No |
| price | 房型价格 | float(7,2) 无符号 | No | 无 | (null) | No |
| room_num | 房间数 | int(5) | No | 无 | (null) | No |
| book_num | 预订数 | int(5) | No | 无 | (null) | No |
| lived_num | 入住数 | int(5) | No | 无 | (null) | No |
| status | 使用状态 | int(1) | No | 无 | 1 | No |
| remark | 备注 | varchar(150) | Yes | 无 | (null) | No |
其中房间数据表主要用于存储该酒店的房间信息，表的结构包括房间id，图片地址，房间编号，房型id，使用状态和备注，其中状态在设计时规定“0”表示已入住，“1”表示可用，“2”表示退房清理。其详细结构设计如表4-3所示。
表4-3 房间信息结构表
| 字段名 | 字段说明 | 类型及长度 | 可为空 | 键属性 | 初值 | 自增 |
| id | 房间id | int(11) | No | 主键 | (null) | Yes |
| photo | 房间图片 | varchar(150) | Yes | 无 | (null) | No |
| s_num | 房间编号 | varchar(32) | No | 无 | 000 | No |
| room_typeId | 房型id | int(11) | No | 外键 | (null) | No |
| status | 使用状态 | int(1) | No | 无 | 1 | No |
| remark | 备注 | varchar(150) | Yes | 无 | (null) | No |
其中订单数据表主要用于存储该酒店的客户预订房间的信息，表的结构包括订单id，客户id，房型id，登录的用户名，身份证号，手机号，当前状态，入住时间，离店时间和备注，其中状态在设计时“0”表示预订，“1”表示已入住。其详细结构设计如表4-4所示。
表4-4 订单信息结构表
| 字段名 | 字段说明 | 类型及长度 | 可为空 | 键属性 | 初值 | 自增 |
| id | 订单id | int(11) | No | 主键 | (null) | Yes |
| client_id | 客户id | int(11) | No | 外键 | (null) | No |
| room_typeId | 房型id | int(11) | No | 外键 | (null) | No |
| username | 登录用户名 | varchar(32) | No | 无 | (null) | No |
| id_card | 身份证号 | varchar(32) | Yes | 无 | (null) | No |
续表4-4 订单信息结构表
| 字段名 | 字段说明 | 类型及长度 | 可为空 | 键属性 | 初值 | 自增 |
| phone | 手机号 | varchar(16) | Yes | 无 | (null) | No |
| status | 当前状态 | int(1) | No | 无 | 0 | No |
| arrive_day | 入住时间 | varchar(32) | No | 无 | (null) | No |
| move_day | 离店时间 | varchar(32) | No | 无 | (null) | No |
| remark | 备注 | varchar(150) | Yes | 无 | (null) | No |
其中管理员用户数据表主要用于存储该酒店的管理员账号信息，表的结构包括管理员id，用户名，密码，管理角色id，联系地址，头像图片地址。其详细结构设计如表4-5所示。
表4-5 管理员用户信息结构表
| 字段名 | 字段说明 | 类型及长度 | 可为空 | 键属性 | 初值 | 自增 |
| id | 管理员id | int(11) | No | 主键 | (null) | Yes |
| username | 用户名 | varchar(32) | No | 无 | (null) | No |
| password | 密码 | varchar(32) | No | 无 | (null) | No |
| role_id | 管理角色id | int(11) | No | 外键 | (null) | No |
| address | 联系地址 | varchar(150) | Yes | 无 | (null) | No |
| photo | 头像地址 | varchar(150) | Yes | 无 | (null) | No |
其中管理角色数据表主要用于存储该系统管理员的角色信息，系统的总管理员可以添加一些其他的管理员并为这些被添加的管理员赋予管理角色。该表的结构包括角色id，角色名称和备注。其详细结构设计如表4-6所示。
表4-6 管理角色信息结构表
| 字段名 | 字段说明 | 类型及长度 | 可为空 | 键属性 | 初值 | 自增 |
| id | 角色id | int(11) | No | 主键 | (null) | Yes |
| name | 角色名称 | varchar(32) | No | 无 | (null) | No |
| remark | 备注 | varchar(150) | Yes | 无 | (null) | No |
其中管理权限数据表主要用于存储该系统的管理角色所拥有的管理菜单权限，该表的结构包括id，角色id和菜单id。其详细结构设计如表4-7所示。
表4-7 管理权限信息结构表
| 字段名 | 字段说明 | 类型及长度 | 可为空 | 键属性 | 初值 | 自增 |
| id | 权限id | int(11) | No | 主键 | (null) | Yes |
| role_id | 角色id | int(11) | No | 外键 | (null) | No |
| menu_id | 菜单id | int(11) | No | 外键 | (null) | No |
其中菜单数据表主要用于存储该系统的后台使用的菜单信息，在本系统中总务管理员添加管理员时可以为其指定管理角色。不同的管理角色拥有不同的权限即就是拥有不同的管理菜单。表的结构包括菜单id，菜单名，菜单的图标。其详细结构设计如表4-8所示。
表4-8 菜单信息结构表
| 字段名 | 字段说明 | 类型及长度 | 可为空 | 键属性 | 初值 | 自增 |
| id | 菜单id | int(11) | No | 主键 | (null) | Yes |
| name | 菜单名 | varchar(32) | No | 无 | (null) | No |
| icon | 菜单的图标 | varchar(32) | No | 无 | (null) | No |
其中入住登记数据表主要用于存储在该酒店前台办理的入住信息，表的结构包括入住id，房间id，房型id，订单id，实付价格，用户名（没有订单或没有账号的顾客在入住的时候使用真实姓名），身份证号，手机号，结算状态，入住日期和离店日期，操作时间以及备注，其中结算状态在设计时“0”表示未结算，“1”表示已结算。其详细结构设计如表4-9所示。
表4-9 入住信息结构表
| 字段名 | 字段说明 | 类型及长度 | 可为空 | 键属性 | 初值 | 自增 |
| id | 入住id | int(11) | No | 主键 | (null) | Yes |
| room_id | 房间id | int(11) | No | 外键 | (null) | No |
| room_typeId | 房型id | int(11) | No | 外键 | (null) | No |
| order_id | 订单id | int(11) | Yes | 无 | (null) | No |
| real_price | 实付价格 | float(7,2) 无符号 | No | 无 | (null) | No |
| username | 用户名 | varchar(32) | No | 无 | (null) | No |
| id_card | 身份证号 | varchar(32) | Yes | 无 | (null) | No |
| phone | 手机号 | varchar(16) | Yes | 无 | (null) | No |
| status | 结算状态 | int(1) | No | 无 | 0 | No |
| arrive_day | 入住日期 | varchar(32) | No | 无 | (null) | No |
| move_day | 离店日期 | varchar(32) | No | 无 | (null) | No |
| operate_time | 操作时间 | datetime | No | 无 | (null) | No |
| remark | 备注 | varchar(150) | Yes | 无 | (null) | No |
4.6 用户界面设计
本系统的用户界面设计使用HTML，CSS基本语言，另外附带上一些EasyUi的插件用来增强界面的交互性。界面设计应该秉持简洁美观，用户可理解的原则进行设计。即程序的编制应该结构清楚，简单易理解，方便研发与维护的工作人员查阅。在酒店管理信息系统程序书写的整个流程中，通过缩进来确保程序的条理性，并且添加详细的注解内容来确保程序的可读性[16]。本系统的用户界面本着清晰简洁、方便用户使用的理念分别对不同的的功能区域进行划分，在导航栏的地方设置退出登录的按钮，导航栏的下方放置一些该酒店的宣传图片或者广告图片等，图片的下方为搜索区的输入框，输入框下方为该酒店的所有房型的列表，最下方是一些常规的页脚信息，比如公网安备号，管理员登录等。用户的主页划分的四个区域，从上往下分别为导航区，搜索区，房型列表区，脚本区。具体设计如图4-5所示。
图4-5 用户主页设计图
4.7 本章小结
本章内容主要为系统的整体结构设计。包括系统的架构层次设计，系统模块化功能结构层次设计以及对数据进行初步的归纳和分析，对数据库进行了初步的设计，通过本章的设计我们将对系统的具体实现有了更加明确思路，这将有助于我们对系统进行详细的设计与实现。
第五章 酒店预订系统详细设计与实现
5.1 系统开发与运行环境
该酒店预订系统是基于SSM框架实现的，后台语言使用java语言，开发软件使用eclipse，编译运行的环境中JDK是1.6的版本，服务器tomcat使用的是7.0版本。系统的前台配置中需要将EasyUi的官方资源包引入WebContent目录下，在每一个jsp文件中都要找到该目录引入。之后页面的实现中在需要渲染的元素中class属性加上“easyui-xxx”，每种功能都对应一个不同的名字。后台的src文件中引入SSM框架的配置文件包，配置文件可根据不同的功能需求做相应的修改。
接着建立Controller包作为本系统中的控制器，用来处理所有的包括前台和后台管理的动作指令，在需要数据时就发送请求连接数据库获取数据，mybatis下面布局mapper映射文件，将数据库的SQL执行语句写入相应的xml文件，接着将运行结果的结果集以对象的形式返回给控制器Controller，Controller获得数据后将数据分配给视图层即jsp页面，jsp页面将所得数据以良好的交互性界面展示给系统用户。其中在SpringMVC的xml配置文件中定义好拦截器就可以在Controller的控制中编写相应的类拦截非法的访问，以此的增强程序的健壮性。
5.2 预订房间详细设计与实现
用户点击预订后系统监听到点击事件调用出预订页面，用户填写信息后提交给后台，用“订单控制器”类接收前端的ajax请求，首先对每一项需要填写的数据检查是否为空值，若经过判断语句判断后该信息项是空值，则将对相应项为空值的提示信息以字符串的方式存入Map的键值对中，而后通过JavaScript中的ajax接收后以弹出提示框的方式返回给用户页面提示用户，当传到后台的信息经过判断已经确认完整时则调用房型数据表，找到对应的房型，将该房型的预订数做加1处理，接着将该房型可用数做减1处理，然后判断房型的可用数是否为零，若该房型的可用数已经为零则将房型数据表中该房型的状态的值设置为“0”，在房型信息表的设计中“0”表示为已满房不可用的状态。此外前端页面获得房型数据时判断若当前状态为满房则使用HTML和CSS语句将该房型处的预订按钮设置为不可点击的按钮状态，防止其他客户点击后出现数据错误的情况。预订房间模块的具体实现流程图如图5-1所示
图5-1 预定房间功能实现流程图
预订房间功能实现的预定界面截图如图5-2所示。
图5-2 预订房间界面截图
预订房间功能实现的运行效果截图如图5-3所示。
图5-3 预订房间的效果界面截图
5.3 修改个人信息详细设计与实现
用户在“用户中心”中点击修改个人信息，用户的个人信息将会由系统输入到对应文本框中，用户修改完成后点击提交。信息提交到后台后由“客户控制器”类接收前端的ajax请求，首先对每一项需要客户填写的数据检查是否为空值若是则将提示信息以字符串的方式存入Map的键值对中返回给页面提示用户，否则调用客户数据表检查用户名是否重复，若用户名重复，同样进行刚才的提示，若不重复则将修改后的数据替换原来的数据。修改个人信息模块的具体实现流程图如图5-4所示。
“张华”是我们新注册的用户，在她的个人信息中无真实姓名、身份证号和联系地址。修改个人信息之前用户界面截图如图5-5所示。
图5-5 修改个人信息之前界面截图
修改个人信息时的用户界面截图如图5-6所示。
图5-6 修改个人信息提交界面截图
修改个人信息提交之后的用户界面截图如图5-7所示。
5.4 修改房型详细设计与实现
酒店管理员进行修改房型的操作时系统调出修改界面，管理员修改完成之后点击提交，“房型控制器”类对数据进行检查无误后调用房型数据表更新房型信息。当管理员修改了房型中的房间数量时，用新的房间数减去旧的房间数得出一个修改偏移量，那么修改后的房型的可用数就等于旧的可用数加上这个偏移量，此时若可用数等于0，则设置房型的可用数为0，房型状设为已满。进而判断已入住数，如果大于房间总数那么就提示检查修改的数据，否则修改完成。房型修改功能模块具体实现的流程图如图5-8所示。
图5-8 房型修改功能模块实现流程图
修改房型之前单人间的房型信息界面截图如图5-9所示。
图5-9 修改房型之前管理界面截图
修改房型确认提交之后的界面效果如图5-10所示。
图5-10 修改房型效果界面截图
5.5 添加房间详细设计与实现
管理员点击添加房间时，输入完成并点击提交后，“房间控制器”类里检查房间信息是否输入完整，若信息不完整则提示检查信息，若输入完整则调用房间信息表，进而判断房间编号是否重复，若重复则给出提示并返回。当信息无误时则将新的数据插入存储房间信息的数据表中。添加房间功能模块的具体实现流程图如图5-11所示。
图5-11 添加房间模块实现流程图
添加房间操作时系统运行界面截图如图5-12所示。
图5-12 添加房间运行界面截图
添加房间完成之后的管理界面效果图如图5-13所示。
图5-13 添加房间完成效果界面截图
5.6 修改订单详细设计与实现
当管理员对订单修改时，首先应该选中需要修改的订单，若管理员未选中订单点击修改那么前端页面就会给出需要选择订单的提示。当管理员正常选中订单并点击修改后在“订单控制器”类里调出订单数据信息表中可以被修改的订单数据显示到管理员的修改订单界面上，赋值到对应的文本框中。管理员修改完成后点击确认修改，系统接收到修改指令后先检查信息是否完整，若该订单信息填写不完整则通过Map键值对的方式由ajax接收，通过页面弹窗的方式提示管理员检查相应未填项的信息输入。如果输入信息完整，则最后再判断房型是否发生了变化首先恢复原有房型的预订数和可用数接着再修改新的房型的预订数可用数。当新的房型的可用数等于零时就将该房型设置为满房的状态。修改订单功能模块的具体实现流程图如图5-14所示。
图5-14 修改订单功能模块实现流程图
当我们新注册了用户“张华”之后紧接着预订了商务标准间，现管理员要将其订单中的房型修改为豪华套房。修改订单之前的管理界面如图5-15所示。
图5-15 修改订单前的界面截图
修改完成之后的订单界面效果如图5-16所示。
图5-16 修改订单效果界面截图
5.7 添加入住详细设计与实现
当酒店前台有顾客入住时管理员需要点击添加入住，此时“入住控制器”类调出添加入住信息的界面，管理员输入信息完成后点击提交，系统首先检查信息是否完整，若信息不完整则给出提示，否则检查该入住信息是否来自于订单及订单id的字段是否为空。若是从订单来的入住那么调出订单数据表修改订单的状态为已入住，否则就把现场来登记入住的房型的可用数减一。接着再将已入住的房型的入住数加一，此时再判断减一后的房型可用数量是否为零，若是零则将房型使用状态设置为已满，从而在前端页面将该房型的预订按钮设置为不可点击，防止数据出错。最后在调用房间数据表将该房间的使用状态设置为使用中。添加入住模块功能实现的流程图如图5-17所示。
图5-17 添加入住功能模块实现流程图
添加入住之前的系统管理入住的界面如图5-18所示。
图5-18 添加入住前系统入住信息界面截图
添加入住之后系统的管理入住信息界面的效果如图5-19所示。
图5-19 添加入住完成界面效果截图
5.8 本章小结
本章对系统的各模块功能进行具体的讲解，并且给出功能模块的后台代码实现的流程图，以及运行界面的效果图，从而使得该系统的功能和效用清楚的展现出来，通过对系统的详细设计的介绍，我们对系统的设计有了进一步的认识。
第六章 酒店预订系统测试
6.1 系统测试的目的
系统测试是指将系统的硬件软件以及系统运行所涉及的设备组合起来对照系统的需求进行的测试。系统测试工作能够保证软件系统从功能单元到整体运行的准确，同时也能够对系统的性能进行测试，保证系统运行的稳定[17]。同时测试是为了检查系统设计是否和用户需求有相互矛盾的地方，以及系统功能的实现是否有漏洞等，从而使系统的设计更为完善和可靠，提高系统的使用质量。
6.2 系统测试的方法
系统的测试从宏观上来看包括动态测试、静态测试等。本章我们对该预订系统进行动态测试，下面我们将使用到黑盒测试法和白盒测试法对该系统一些功能进行测试。
系统的功能测试即就是黑盒测试的一种，它属于动态测试的一种形式。本章将对酒店预订系统的注册功能，预订房间功能，添加房间功能使用等价类划分法进行测试，然后将所得到的测试结果将通过表格的形式给出。
系统的结构测试就是指白盒测试的一种测试方法，白盒测试也属于动态测试的一部分。本章将对该预订系统的修改房型功能，修改订单功能使用基本路径测试法进行测试。在画出控制流图的基础上通过分析路径的环形复杂度设计路径基本集，接着依据基本集设计测试用例，所得测试结果以表格的形式给出。
6.3 系统测试用例
6.3.1 注册测试用例
在注册功能模块中通过分析用户名，密码，确认密码，手机号等数据规格列出该功能的等价类表如表6-1所示。
表6-1 注册功能测试等价类表
| 输入条件 | 有效等价类 | 编号 | 无效等价类 | 编号 |
| 用户名 | 任意字符 | 1 | 空值 | 5 |
| 密码 | 任意6位字符 | 2 | 非6位字符 | 6 |
| 空值 | 7 |
续表6-1 注册功能测试等价类表
| 输入条件 | 有效等价类 | 编号 | 无效等价类 | 编号 |
| 确认密码 | 相同于密码 | 3 | 不同于密码 | 8 |
| 手机 | 11位数字 | 4 | 非数字 | 9 |
| 大于11位数 | 10 | |||
| 小于11位数 | 11 | |||
| 空值 | 12 |
根据等价类表设计覆盖所有等价类的测试用例如表6-2所示。
表6-2 注册功能测试用例表
| 用例编号 | 输入数据 | 预期输出 | 实际输出 | 覆盖 | |||
| 用户名 | 密码 | 确认密码 | 手机 | ||||
| 1 | Jack | 123456 | 123456 | 12345678901 | 注册成功 | 注册成功 | 1234 |
| 2 | （空） | 123456 | 123456 | 12345678901 | 注册失败 | 注册失败 | 5 |
| 3 | Mary | 123 | 123 | 12345678901 | 注册失败 | 注册失败 | 6 |
| 4 | Mary | （空） | （空） | 12345678901 | 注册失败 | 注册失败 | 7 |
| 5 | Mary | 123456 | 123000 | 12345678901 | 注册失败 | 注册失败 | 8 |
| 6 | Mary | 123456 | 123456 | 1234567abcd | 注册失败 | 注册失败 | 9 |
| 7 | Mary | 123456 | 123456 | 123456789 | 注册失败 | 注册失败 | 10 |
| 8 | Mary | 123456 | 123456 | 1234567890123 | 注册失败 | 注册失败 | 11 |
| 9 | Mary | 123456 | 123456 | （空） | 注册失败 | 注册失败 | 12 |
6.3.2 预订房间测试用例
在预订房间功能模块中我们对入住日期，离店日期，姓名，电话，身份证号，备注等数据规格进行分析得出该功能的测试等价类表如表6-3所示。
表6-3 预订房间功能测试等价类表
| 输入条件 | 有效等价类 | 编号 | 无效等价类 | 编号 |
| 入住时间 | 日期框选择自动生成格式 | 1 | 空值 | 7 |
| 非法格式输入 | 8 | |||
| 离店时间 | 日期框选择自动生成格式 | 2 | 空值 | 9 |
| 非法格式输入 | 10 | |||
| 姓名 | 任意字符 | 3 | 空值 | 11 |
| 电话 | 11位数字 | 4 | 非数字 | 12 |
| 非11位数字 | 13 | |||
| 空值 | 14 | |||
| 身份证号 | 19位字符 | 5 | 非19位字符 | 15 |
| 空值 | 16 | |||
| 备注 | 任意字符或空值 | 6 | — | — |
根据该功能的等价类表设计的覆盖所有的等价类的测试用例如表6-4所示。
表6-4 预订房间功能测试用例表
| 用例编号 | 输入数据 | 预期输出 | 实际输出 | 覆盖 | |||||
| 入住日 | 离店日 | 姓名 | 电话 | 身份证 | 备注 | ||||
| 1 | 2020-5-1 | 2020-5-2 | 张三 | 12345678901 | 1234567890 123456789 | （空） | 预定成功 | 预定成功 | 123456 |
| 2 | （空） | 2020-5-2 | 张三 | 12345678901 | 1234567890 123456789 | （空） | 提示失败 | 提示失败 | 7 |
| 3 | 20200501 | 2020-5-2 | 张三 | 12345678901 | 1234567890 123456789 | （空） | 提示失败 | 提示失败 | 8 |
| 4 | 2020-5-1 | （空） | 张三 | 12345678901 | 1234567890 123456789 | （空） | 提示失败 | 提示失败 | 9 |
| 5 | 2020-5-1 | 20200502 | 张三 | 12345678901 | 1234567890 123456789 | （空） | 提示失败 | 提示失败 | 10 |
| 6 | 2020-5-1 | 2020-5-2 | (空) | 12345678901 | 1234567890 123456789 | （空） | 提示失败 | 提示失败 | 11 |
| 7 | 2020-5-1 | 2020-5-2 | 张三 | 1234567abcd | 1234567890 123456789 | （空） | 提示失败 | 提示失败 | 12 |
| 8 | 2020-5-1 | 2020-5-2 | 张三 | 1234567 | 1234567890 123456789 | （空） | 提示失败 | 提示失败 | 13 |
| 9 | 2020-5-1 | 2020-5-2 | 张三 | （空） | 1234567890 123456789 | （空） | 提示失败 | 提示失败 | 14 |
续表6-4 预订房间功能测试用例表
| 用例编号 | 输入数据 | 预期输出 | 实际输出 | 覆盖 | |||||||||
| 入住日 | 离店日 | 姓名 | 电话 | 身份证 | 备注 | ||||||||
| 10 | 2020-5-1 | 2020-5-2 | 张三 | 12345678901 | 123456789 | （空） | 提示失败 | 提示失败 | 15 | ||||
| 11 | 2020-5-1 | 2020-5-2 | 张三 | 12345678900 | （空） | （空） | 提示失败 | 提示失败 | 16 | ||||
6.3.3 添加房间测试用例
在管理员添加房间的功能中，我们通过对房间编号，房间类型，房间状态，房间备注等数据规格的分析后所设计的等价类表如表6-5所示。
表6-5 添加房间功能测试等价类表
| 输入条件 | 有效等价类 | 编号 | 无效等价类 | 编号 |
| 房间编号 | 任意字符 | 1 | 与原有的编号重复 | 5 |
| 空值 | 6 | |||
| 房型 | 下拉选择框中的房型 | 2 | 任意填写的房型 | 7 |
| 空值 | 8 | |||
| 状态 | 下拉选择框中的房间状态 | 3 | 任意填写的状态 | 9 |
| 空值 | 10 | |||
| 备注 | 任意字符或空值 | 4 | — | — |
在此需要说明的是“001”是管理员之前已经添加过的房间编号，根据添加房间功能的等价类划分所设计的覆盖所有等价类的测试用例如表6-6所示。
表6-6 添加房间功能测试用例表
| 用例编号 | 输入数据 | 预期输出 | 实际输出 | 覆盖 | |||
| 房间编号 | 房型 | 状态 | 备注 | ||||
| 1 | 002 | 单人间 | 可入住 | 新增房间 | 添加成功 | 添加成功 | 1234 |
| 2 | 001 | 单人间 | 可入住 | 新增房间 | 添加失败 | 添加失败 | 5 |
| 3 | （空） | 单人间 | 可入住 | 新增房间 | 添加失败 | 添加失败 | 6 |
| 4 | 003 | 带阳台单人间 | 可入住 | 新增房间 | 添加失败 | 添加失败 | 7 |
| 5 | 003 | （空） | 可入住 | 新增房间 | 添加失败 | 添加失败 | 8 |
续表6-6 添加房间功能测试用例表
| 用例编号 | 输入数据 | 预期输出 | 实际输出 | 覆盖 | |||
| 房间编号 | 房型 | 状态 | 备注 | ||||
| 6 | 003 | 单人间 | 可入住房间 | 新增房间 | 添加失败 | 添加失败 | 9 |
| 7 | 003 | 单人间 | （空） | 新增房间 | 添加失败 | 添加失败 | 10 |
6.3.4 修改房型测试用例
从本小节开始我们对修改房型功能和修改订单功能使用白盒测试法中的基本路径测试法进行测试，我们将遵从给出控制流图、基本路径集、测试用例的顺序进行测试。
对修改房型功能进行测试，判断放房间数是否为空设为节点1，判断可用数是否为0设为节点2，房型状态更新为满房设为节点3，判断可用数是否小于0设为节点4，提示修改成功设为节点5，提示检查数据设为节点6，结束设为节点7。对应的修改房型功能的控制流图如图6-1所示。
图6-1 修改房型功能控制流图
通过分析控制流图可计算得环形复杂度9（边数）-7（节点数）+ 2 = 4，即独立路径分别如下所示。
路径一：1 -> 7
路径二：1 -> 2 -> 3 -> 7
路径三：1 -> 2 -> 4 -> 5 -> 7
路径四：1 -> 2 -> 4 -> 6 -> 7
在此对测试之前的数据进行说明，该房型当前有5个房间，已入住2个房间，可用3个房间。最后设计测试用例表如表6-7所示。
表6-7 修改房型功能测试用例表
| 输入数据（房间数） | 预期输出 | 实际输出 | |
| 测试用例1 | （空） | 房间数为空 | 房间数为空 |
| 测试用例2 | 2 | 可用数为0，房型已满，设置成功 | 可用数为0，房型已满，设置成功 |
| 测试用例3 | 8 | 可用数为6，设置成功 | 可用数为6，设置成功 |
| 测试用例4 | 1 | 可用数不符，请检查您的数据 | 可用数不符，请检查您的数据 |
6.3.5 修改订单测试用例
对修改订单的功能进行测试。判断房型是否被修改设为节点1，旧房型预订数减一设为节点2，判断旧房型状态是否满房设为节点3，旧房型状态修改成可预订设为节点4，新房型预订数加一设为节点5，判断新的房型是否满设为节点6，新房型状态更新为满房设为节点7，结束设为节点8。修改订单功能的控制流图如图6-2所示。
图6-2 修改订单功能控制流图
分析该功能的控制流图可得环形复杂度为10（边数）-8（节点数）+2=4，该功能模块的独立路径分别如下所示。
路径一：1 -> 8
路径二：1 -> 2 -> 3 -> 5 -> 6 -> 8
路径三：1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 8
路径四：1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8
在此通过下方表格对测试之前的房型数，预订数等相关信息进行说明。测试前相关的房型信息如表6-8所示。
表6-8 测试前房型信息表
| 房型名称 | 房间总数 | 当前预订数 | 状态 |
| 单人间 | 5 | 5 | 满房 |
| 普通大床房 | 6 | 3 | 可预订 |
| 标准间 | 3 | 2 | 可预订 |
| 豪华大床房 | 6 | 1 | 可预订 |
根据上述路径集所设计的修改订单功能模块的测试用例表如表6-9所示。
表6-9 修改订单功能测试用例表
| 输入数据 | 预期输出 | 实际输出 | |
| 测试用例1 | 单人间的订单更换为单人间 | 修改完成，房型数据不变 | 修改完成，房型数据不变 |
| 测试用例2 | 普通大床房的订单更换为豪华大床房 | 修改完成，普通大床房预订数为2，豪华大床房预订数为2，房型状态均为“可预订” | 修改完成，普通大床房预订数为2，豪华大床房预订数为2，房型状态均为“可预订” |
| 测试用例3 | 单人间的订单更换为豪华大床房 | 修改完成，单人间预订数为4，状态为“可预订”，豪华大床房预订数为2，状态为“可预订” | 修改完成，单人间预订数为4，状态为“可预订”，豪华大床房预订数为2，状态为“可预订” |
| 测试用例4 | 单人间的订单更换为标准间 | 修改完成，单人间预订数为4，状态为“可预订”，标准间预订数为3，状态为“满房” | 修改完成，单人间预订数为4，状态为“可预订”，标准间预订数为3，状态为“满房” |
6.4 测试结论
通过本次测试我们对系统的功能得到了进一步的确认，在注册功能的测试中划分了12个等价类，我们在注册用例表中对每一个等价类都进行了覆盖，从而系统注册功能的可用性得到了进一步的确认。
在预订房间功能模块的测试中我们一共划分了16个等价类，在测试用例中包含了所有的等价类，对客户预订房间时可能出现的一些问题进行了排查。比如日期未通过点击日历获取，而是用户自行输入的格式。但是从系统的本质上来讲，该日期是用ajax获取后发送给后台的数据，从而在后台调用数据库插入语句对系统特定的格式进行插入，也就是说如果用户自行输入的格式同日历中获取的格式一样，那么该日期也可以通过后台的检查，成功生成预订订单，但是毕竟用户自行输入的情况下出错的几率比较大，本系统还是提示用户以日历的方式选择日期。
在添加房间的测试中测试用例包含了所划分的10个等价类，管理员添加房间的功能得到了进一步确认，系统能够对一些错误的或者未填写的信息进行识别并给出友好的交互性提示。
在修改房型的测试中我们提取出代码片段的抽象节点画出控制流图，因此我们得到了修改房型功能的环形复杂度为4并划分了基本路径集，所用测试用例包含了该功能的基本路径，以此确认了该功能可有效运行。
在修改订单的测试中我们使用了和之前修改房型的测试一样的方法，并且也得到值为4的环形复杂度，测试用例覆盖了该功能的基本路径，使得该功能正确有效的实现得到了更进一步的保障。
6.5 本章小结
本章节首先介绍系统测试的目的并说明了测试的必要性，然后分别从不同的方面对系统的功能进行了相应的测试，并且给出了测试结果。通过该章节的测试，我们排除了一些容易忽略的错误，因此使系统更加具备可靠性。但是系统任然存在不尽完善的地方，比如算法的应用方面不够深入，代码不够精湛，因此我们将会对系统进行持续的优化和改造
总结
本次系统设计是在互联网办公化的社会背景下进行的，我们设计的目的在于使得预订酒店更加方便，酒店的管理能够更加的容易，酒店的数据和资料的管理更加的规范和严谨。基于B/S的模式设计系统能让系统的使用更加快捷简便，在成本方面有所节省。本系统的使用者可分为预订酒店的顾客和酒店系统的管理者两类用户。对于预订用户来说实现了预订房间的功能、查询订单的功能以及管理自己信息的功能，对于酒店管理者来说实现了房型管理，房间管理，客户信息管理，订单管理和入住管理等功能。
在本次设计中使用的是eclipse的开发环境，该编辑器软件集成了各种开发所需要的开发环境，并且目前还在持续更新中，极大方便了我们对程序的编写和调试。该预订系统的开发是基于SSM框架进行的，其后台的脚本语言是java语言，虽然以前学习过该语言，但是通过本次开发后对java语言有了更多的体会。SSM框架是一个大大减轻开发工作的框架，它用自身定义的原则使得程序开发更加规范，在它对一些类进行封装后让我们对它的封装类使用起来更加省力和方便。
如有更多细节问题，请联系我交流，谢谢！
