从B/S架构的原理可知，云游旅游网站的各大模块的实现均需要对数据库的数据进行操作，具体包括查询数据、写入数据、更新数据和删除数据，因此，在开发各功能模块前，首先创建一个名称"conn.php"的文件，该文件主要用于连接数据，以后对程序需要操作数据时，可能使用语句"<?php reqiure_once('conn.php');?>"调用就可以了。
该文件的代码如下：
<?php
error_reporting(0);
//数据库链接文件
$host='127.0.0.1';//数据库服务器
$user='root';//数据库用户名
$password='';//数据库密码
$database='phpxsschsg7555AE10';//数据库名
$conn=@mysql_connect($host,$user,$password) or die('数据库连接失败！');
@mysql_select_db($database) or die('没有找到数据库！');
用户在填写数据的时候必须与注册页面上的验证相匹配否则会注册失败，注册页面的表单验证是通过JavaScript进行验证的，用户名的长度必须在6到18之间，邮箱必须带有@符号，密码和密码确认必须相同，你输入的密码，系统会根据你输入密码的强度给出指定的值，电话号码和身份证号码必须要求输入格式与生活相符合，当你前台验证通过的时候你点击注册，表单会将你输入的值通过name值传递给后台并保存到数据库中。
用户注册流程图如下图所示。
图5-1用户注册流程图
用户注册界面如下图所示。
图5-2用户注册界面
主要由两部分组成，登录前的登录界面以及登录后的用户功能界面。登录界面，要求用户输入用户名和密码，当用户名和密码其中一个输入为空时，给出提示“用户名，密码不能为空”。获取用户名和密码后到数据库中查找，如果用户名存在，以及对应的密码正确，则登录成功，否则登录失败。登录失败后给出提示，并把焦点停在文本框中。登录成功后将该次会话的全局变量username设置为用户名。登录成功后进入会员的功能模块，主要有会员基本信息修改，已经发布景点信息管理，发布信息，和退出功能。退出功能是清除全局变量username的值，并跳回到首页。
登录流程图如下图所示。
图5-3登录流程图
用户登录界面如下图所示。
图5-4用户登录界面
用户登录/注册成功之后可以修改自己的基本信息。修改页面的表单中每一个input的name值都要与实体类中的参数相匹配，在用户点击修改页面的时候，如果改后用户名与数据库里面重复了，页面会提示该用户名已经存在了，否则通过Id来查询用户，并将用户的信息修改为表单提交的数据。
用户可以发表自己的评论。将页面session中的用户账号userId和发表评论文字框内容传入控制层，调用addLiuyan方法，通过实现评论接口向数据库评论表插入，将结果返回lyb.php界面。
评论添加流程图如下图所示。
图5-5评论添加流程图
评论发表界面如下所示。
图5-6评论发表界面
用户提交酒店订单后后台会自动生成酒店订单列表。从session中取出该用户信息，前台发起请求，将对应的用户信息、dingdanpId参数信息从前台传递酒店订单控制类里，匹配到create()方法，create()方法调用酒店订单逻辑层的createDingdan()方法获取数据，调用本类的getCartDingdanItem()方法得到酒店订单列表。
酒店预订界面如下所示。
图5-7酒店预订界面
将页面session中的用户账号userId和景点攻略框内容传入控制层，调用addPinglun方法，通过实现景点攻略接口向数据库景点攻略表插入，将结果返回Pinglun_list.php界面，用户可以自由搜索景点攻略。
景点攻略添加流程图如下图所示。
图5-8景点攻略添加流程图
景点攻略管理界面如下图所示。
图5-9景点攻略管理界面
景点购票功能需要考虑高并发，防止出现景点重复购票、景点状态显示出错等情况，特对景点这一共享数据增加锁机制。在乐观锁、悲观锁以及线程锁中，综合考虑性能效率和错误的可接受性选择了乐观锁机制。乐观锁的实现方式是使用版本标识来确定读到的数据与提交时的数据是否一致，提交后修改版本标识，不一致时可以采取丢弃和再次尝试的策略。在数据库景点表（对应景点实体）设计中增加了version字段，每次数据提交时（更改景点状态）会判断version是否匹配，若不匹配停止本次提交，若匹配则提交成功并增加version的值。
景点购票功能整体流程：用户浏览景点信息时，同时会显示景点的状态，系统会在其显示详细信息的页面时便会判断景点的状态，若景点状态为可购票，则会显示购票的链接按钮。在用户点击购票按钮时，会先通过拦截器判断用户是否登录，若未登录，会跳转至登录页面，提示用户先登录，若为登录用户就会跳转至填写购票信息的页面，填写好购票信息之后，点击提交按钮，购票成功之后返回提示信息，告知用户购票成功。
景点购票流程图如下图所示。
图5-10景点购票流程图
景点购票界面如下图所示。
图5-11景点购票界面
购票管理界面如下图所示。
图5-12购票管理界面
酒店预订功能整体流程：用户浏览酒店信息时，酒店房间列表中可显示房间状态，若房间状态为可入住，则会显示预订的链接按钮。在用户点击酒店预订按钮时，会先通过拦截器判断用户是否登录，若未登录，会跳转至登录页面，提示用户先登录，若为登录用户就会跳转至填写预订信息的页面，填写好预订信息之后，点击提交按钮，预订成功之后返回提示信息，告知用户已经预订成功。
酒店预订流程图如下图所示。
图5-13酒店预订流程图
酒店预订界面如下图所示。
图5-14酒店预订界面
酒店预订管理界面如下图所示。
图5-15酒店预订管理界面
此页面的关键是编写景点信息，包括景点编号，名称，价格，详情等。单击提交按钮以完成信息的添加。如果未写入完整的景点信息，例如，如果未写入景点编号，系统将给出相应的错误提示，并且无法成功输入。数据以概念的形式以onsubmit =“return checkForm（）”的形式写入以进行检查，checkForm（）函数是一种用于写入数据的不同类型的校对方法，是不是为空也是经过form表单中的οnsubmit=”return checkForm()来检查。
管理员点击左侧菜单“景点信息管理”，页面跳转到景点信息管理外观，调用后台景点查询所有景点信息。并将信息密封到数据集合List，绑定到请求对象，然后页面跳转到相应的php页面，显示出景点信息，单击删除按钮完成景点信息的删除。
景点管理流程图如下图所示。
图5-16景点管理流程图
景点添加界面如下图所示。
图5-17景点添加界面
景点管理界面如下图所示。
图5-18景点管理界面
根据需求，需要对地区进行添加、删除或修改详情信息。删除或修改地区时，系统根据地区的状态判定为可删除状态下，才会给出删除和修改链接，点击删除链接按钮时，请求到达后台，还会先查询地区状态再次做出判定能否删除。点击修改链接按钮时，会跳转到修改信息的页面，重新填写好数据后，数据提交到后台会对数据库中相应的记录做出修改。
添加地区时，会给出数据填写的页面，该页面根据填写好的地区编号同样会事先发送Ajax请求查询编号是否已存在，数据填写好之后提交到后台，会调用相关服务在数据库中插入记录。
地区管理流程图如下图所示。
图5-19地区管理流程图
地区添加页面设计效果如下图所示。
图5-20地区添加界面
地区管理页面效果如下图所示。
图5-21地区管理界面
对任何系统而言，测试都是必不可少的环节，测试可以发现系统存在的很多问题，所有的软件上线之前，都应该进行充足的测试之后才能保证上线后不会Bug频发，或者是功能不满足需求等问题的发生。下面分别从单元测试，功能测试和用例测试来对系统进行测试以保证系统的稳定性和可靠性。
下表是景点管理功能的测试用例，检测了景点管理中对景点信息的增加，删除，修改，查询操作是否成功运行。观察系统的响应情况，得出该功能也达到了设计目标，系统运行正确。
前置条件；用户登录系统。
表6-1 景点管理的测试用例
| 功能描述 | 用于景点管理 | |
| 测试目的 | 检测景点管理时的各种操作的运行情况 | |
| 测试数据以及操作 | 预期结果 | 实际结果 |
| 点击添加景点，必填项合法输入，点击保存 | 提示添加成功 | 与预期结果一致 |
| 点击添加景点，必填项输入不合法，点击保存 | 提示必填项不能为空 | 与预期结果一致 |
| 点击修改景点，必填项修改为空，点击保存 | 提示必填项不能为空 | 与预期结果一致 |
| 点击修改景点，必填项输入不合法，点击保存 | 提示必填项不能为空 | 与预期结果一致 |
| 点击删除景点，选择景点删除 | 提示删除成功 | 与预期结果一致 |
| 点击搜索景点，输入存在的景点名 | 查找出景点 | 与预期结果一致 |
| 点击搜索景点，输入不存在的景点名 | 不显示景点 | 与预期结果一致 |
下表是酒店管理功能的测试用例，检测了酒店管理中对酒店信息的增加，删除，修改，查询操作是否成功运行。观察系统的响应情况，得出该功能也达到了设计目标，系统运行正确。
前置条件；用户登录系统。
表6-2 酒店管理的测试用例
| 功能描述 | 用于酒店管理 | |
| 测试目的 | 检测酒店管理时的各种操作的运行情况 | |
| 测试数据以及操作 | 预期结果 | 实际结果 |
| 点击添加酒店，必填项合法输入，点击保存 | 提示添加成功 | 与预期结果一致 |
| 点击添加酒店，必填项输入不合法，点击保存 | 提示必填项不能为空 | 与预期结果一致 |
| 点击修改酒店，必填项修改为空，点击保存 | 提示必填项不能为空 | 与预期结果一致 |
| 点击修改酒店，必填项输入不合法，点击保存 | 提示必填项不能为空 | 与预期结果一致 |
| 点击删除酒店，选择酒店删除 | 提示删除成功 | 与预期结果一致 |
| 点击搜索酒店，输入存在的酒店名 | 查找出酒店 | 与预期结果一致 |
| 点击搜索酒店，输入不存在的酒店名 | 不显示酒店 | 与预期结果一致 |
下表是购票管理功能的测试用例，检测了购票管理中购票单的操作是否成功运行。观察系统的响应情况，得出该功能也达到了设计目标，系统运行正确。
前置条件；用户登录系统。
表6-3 购票管理的测试用例
| 功能描述 | 用于购票管理 | |
| 测试目的 | 检测购票管理时各种操作的情况 | |
| 测试数据以及操作 | 预期结果 | 实际结果 |
| 未选择景点，点击提交 | 提示请选择景点 | 与预期结果一致 |
| 未输入文字，点击提交 | 提示请输入文字 | 与预期结果一致 |
| 未选择时间，点击提交 | 提示请选择时间 | 与预期结果一致 |
使用阿里云PTS（Performance Testing Service）性能测试服务对线上系统进行压力测试。线上服务器环境为：1核心CPU，1G内存，1Mbps公网带宽，Centos7.0操作系统。
压测过程中使用了2台并发机器，每台机器20个用户并发，对系统主页，登录，数据查询和数据维护等模块进行并发访问，测试结果是有40个用户并发时，数据管理相关页面的响应时间甚至达到了7s，通过查看服务器出网流量发现已经达到1381kb/s，可以看出服务器的带宽已经达到峰值，如果系统使用5Mbps的带宽，系统的响应时间和TPS将会大大增加。在整个测试的过程中，CPU的使用率占用仅8%，也提现出带宽瓶颈对系统的影响非常严重。
">