软件工程大作业

 

 

 

软件工程

 

 

 

 

 

题    目：	软件工程
指导老师：	王卫东
姓    名：	张佳骏
学    号：	202241802532
专    业：	计算机科学与技术

 

 

 

 

2023年5月

 

1       引言

1.1 研究背景

随着移动互联网的普及，旅游服务行业正面临着巨大的市场需求。旅游服务APP为游客提供了一个便捷的线上交流平台，帮助游客了解景点、订票、预订住宿和餐饮等。为了满足市场需求，我们设计并实现了一个旅游服务APP。

 

1.2 国内外研究现状

近年来，国内外众多研究者致力于旅游服务APP的开发。一些知名的旅游服务APP如TripAdvisor、携程旅行等已经取得了很大成功，但市场依然有很大的增长空间。因此，开发一个功能齐全、用户友好的旅游服务APP具有重要的现实意义。

 

1.3 目标和意义

本项目旨在设计并实现一个旅游服务APP，为游客提供一个方便、实时的线上交流平台。通过实现在线注册、浏览、订票、预订住宿和餐饮等功能，为游客提供全方位的旅游服务支持。本项目不仅有助于提升旅游服务行业的信息化水平，同时也有望带动相关产业的发展。

 

2       可行性分析

2.1 技术可行性分析

本项目采用Java进行开发，数据库使用MySQL，这些技术都是成熟的，具有良好的技术支持。前端使用HTML5、CSS和JavaScript，辅助以Bootstrap等前端框架。因此，本项目在技术层面具有较高的可行性。

2.2 经济可行性分析

旅游服务APP具有广泛的市场需求，预计将带来可观的盈利。随着旅游业的持续发展，用户对旅游服务的需求将进一步增加，进而推动旅游服务APP市场的扩大。因此，在经济层面，本项目具有较高的可行性。

2.3 操作可行性分析

操作可行性主要考虑的是目标用户是否能够接受和使用这个产品。旅游服务APP提供的功能，如景点查询，酒店查询，信息分享等，都是旅游者常需要的服务，而且可以通过移动设备随时随地访问，因此对用户来说应该是很方便的。在设计界面时，我们需要注意用户体验，使得APP易于使用。总的来说，只要我们关注用户需求和用户体验，该项目在操作上也是可行的。

本项目的用户界面设计友好、易于使用，可以在不同设备上正常显示。为了保证良好的用户体验，我们还对各个界面进行了适配。此外，后台管理系统易于操作，可以方便地进行景点信息和攻略的添加和维护。因此，在运行层面，本项目具有较高的可行性。

2.4 法律可行性分析

旅游服务APP需要遵守相关的法律法规，例如数据保护和隐私法，消费者权益保护法等。在设计和实现过程中，我们需要确保所有的功能和数据处理都符合这些法规。此外，如果使用了第三方API，我们还需要遵守他们的使用条款。总的来说，只要我们注意遵守这些法规和条款，该项目在法律上是可行的。

 

3       需求分析

3.1 需求概述

随着我国经济的快速发展，人们的经济基础得到显著的提高，精神生活也在逐步的丰富起来，在休假时旅游是目前人们主要的休闲手段之一。目前移动网络、移动设备的飞速发展，人们不再想在台式机或笔记本上在旅游前查找相关的信息，而是希望能通过移动设备随时随地的查询自己需要的信息，比如景点信息、酒店信息、饭店信息、天气情况等等。由于各景区的负载能力往往有限，旅客如果需要获得较好的旅游体验，需要了解景区目前的接待人数是否饱和。目前，自驾游的人群也越来越多，但是去一个陌生的景点，人们往往对其路线是不熟悉的，此时旅游地图和导航的功能就非常重要。另外天气情况方便旅行者在旅游途中随时掌握当地的天气情况，对旅途做更好的安排。信息发布平台则方便旅行者在旅行途中分享自己的旅游感想，也可以对景区提建议，以便景区工作的完善。

移动端设备硬件和操作系统的飞速发展和进步，给人们带来的用户体验越来越好。Android 操作系统经过 Google 和移动终端设备厂商的不断优化，系统的性能越来越好，使得现在市面上基于 Android 平台的应用软件越来越丰富。人们在旅行途中可以使用移动终端设备，比如智能手机进行拍照，发布旅行照片，旅行感想以及导航等功能。

最近几年来，针对旅游的信息化不少，但是功能相对来说比较单一，比如微博等很多论坛是信息发布的平台，百度地图、高德地图具有导航定位等功能，大多数的 App 没有将信息发布、地图、信息查询等功能进行合理的整合，这对使用者来说操作及其不便，特别是一些对智能设备操作不熟练的人们，会出现在设备上操作几次后找不到拍照、地图等功能。

为了更好地提供旅游服务，本系统在一般旅游系统的基础上进行完善。本移动端旅游软件系统是集成信息发布平台、酒店查询、景区查询、导航以及定位等功能的综合信息管理平台。用户通过手机等移动终端使用系统，可以在系统中查询各类信息，并且可以通过系统的地图功能获取路线规划等，系统还支持游客发表各类游记，具有一定的社交功能。

3.2 运行环境

1. 浏览器

旅游服务APP的浏览器是应用程序内置的，不需要用户手动安装。浏览器内核使用的是Webkit，同时也可以支持其他主流浏览器内核。

1. 数据库

旅游服务APP需要使用数据库来存储用户的个人信息、订单信息、景点信息、攻略信息、评价信息等数据。建议使用关系型数据库来存储数据，如MySQL、PostgreSQL等。数据存储在云服务器上，需要保证云服务器具有稳定的网络和可靠的存储设备。

1. 后台技术栈

旅游服务APP的后台使用基于Java的Spring框架来开发，同时也需要使用MyBatis等持久层框架和Tomcat等Web服务器。建议使用最新的版本，以获取更好的性能和安全性。

1. 前端技术栈

旅游服务APP的前端使用基于React的框架进行开发，同时也需要使用Redux等状态管理工具和Webpack等构建工具。建议使用最新的版本，以获取更好的用户体验和开发效率。

3.3 功能需求

需求包括景点查询、景区周边酒店查询、旅游信息平台、天气查询以及地图和导航等功能模块。其中景区查询用于按照各种条件搜索景区的信息；景区周边酒店查询用于检索景区周边的酒店和相关配套设施，并获取酒店和配套设施的相关信息；旅游信息平台用于用户进行信息交流、分享；天气查询用于查询景区周边的天气情况、空气质量、湿度等信息；地图和导航等功能用于完成从出发地到景区的路线规划与导航。

3.3.1 系统用例建模

移动端旅游信息平台包括手机端、Pad 端在旅游行业中的应用，使用 Android

移动设备作为终端开发，可以非常便捷的实现 PC 端的业务移动设备化。移动通信4G，以及商用不久的 5G 为实现系统的网络功能提供了强有力的支撑，使得系统的数据传输快、稳、准，很好的解决了数据传输的问题。

从平台的使用用户来说，分为：酒店的信息管理人员、景区的信息管理人员、

游客以及后台管理人员。

（1）酒店信息管理人员，可登录系统的酒店管理页面，增加、删除和查询修

改酒店的相关信息，提供在线服务以及查看游客给酒店的反馈，酒店信息管理人员可将反馈信息上报领导以便改进完善酒店服务。

 

图 3‑1 酒店信息管理人员用例图

（2）景区信息管理人员，登录景区管理页面、增删查改景区信息、在线服务

以及查看游客给景区的反馈，将反馈信息上报领导以方便景区服务的完善。景区管理人员用例图如图 3-2 所示。

 

图 3‑2 景区管理人员用例图

（3）后台管理人员，由于系统的各项功能支持配置，系统需要管理用户以及

密码等信息，后台管理人员有权限处理用户忘记密码等事项，能够为不同的用户设置角色，并将角色对应到不同的权限中，同时需要对整个系统的后台进行管理，比如监控系统的运维情况等。

 

图 3‑3 后台管理人员用例图

 

（4）游客，登录游客页面，查询景区信息、查询酒店信息、酒店预订、信息

发布、导航地图功能、查看天气。

1）查询景区信息

景区信息的查询是游客使用的主要功能，通过该功能系统可以提供给游客有关景点移动端旅游软件系统需求分析景区的各项资料，包括景区的介绍，周边的配套等。在景区查询时，可以通过关键字或者景区的类别等进行检索，系统根据游客输入的关键信息匹配景区后，将景区的信息返回给旅客。

2）景区周边酒店查询和预定

酒店信息是旅客出行时较为关心的信息，对于需要住宿的景区，游客一般需要安排住宿，预定酒店。因此，本系统需要根据景区的情况，查询其周边的酒店信息，包括酒店的类型、价格、入住率等。在有条件的情况下，系统需要提供酒店的预定功能，在系统中可以直接对接酒店的系统，并进行预定。

3）旅游信息发布

游客在旅游过程中或者旅游后可能需要分享自己的旅游心得或者发送信息对景区等进行评价。通过信息发布，能够让其他旅客更好的了解该景区的情况，也有利于景区人员能够及时得到游客的反馈改进工作。因此，本系统提供信息发布功能，为游客提供发帖等功能。

4）天气预报

天气是影响游客出行的重要因素，因此获取景区的天气情况有助于游客提前做好各项准备工作。本系统支持景区近一周天气预报的信息提供，游客可以在选择景区后查看天气情况。

5）地图和导航功能模块

景区的路线规划为游客出行提供参考，因此本系统需要提供景区的地图信息以及导航等功能。游客的用例图如图 3-4 所示。

 

 

图 3‑4 游客查询用例图

3.3.2 数据流图

 

图 3‑5 用户注册模块数据流图	图 3‑6景点查询模块数据流图
图 3‑7酒店查询模块数据流图	图 3‑8 信息平台模块数据流图
图 3‑9天气预报模块数据流图	图 3‑10 地图与导航模块数据流图

 

3.3.3 数据字典

表 3-1 用户注册的数据字典

 

表 3-2 景点查询的数据字典

 

 

 

 

 

 

 

 

 

 

表 3-3 酒店查询的数据字典

 

表 3-4 信息分享的数据字典

 

表 3-5天气预报的数据字典

 

表 3-6 地图导航的数据字典

 

 

3.3.4 外部接口需求分析

本项目需与第三方支付平台、地图API和酒店预订平台等进行集成。外部接口需求包括：

1. 支付接口：为实现在线支付功能，需要与第三方支付平台进行对接，如支付宝、微信支付等。

2. 地图API接口：为展示景点位置信息，需要与地图API进行集成，如高德地图、百度地图等。

3. 酒店预订接口：为实现酒店预订功能，需要与酒店预订平台进行对接，如携程、去哪儿等。

 

3.4 性能需求

APP应具备较快的数据处理和响应速度，同时支持多用户在线操作。APP应支持高并发请求，对于用户的操作应有良好的响应及反馈能力。在满足功能需求的前提下，系统需要符合一定的性能需求才能正式投入使用，对景区旅游移动软件的性能要求如下：

（1）可靠性

可靠性是指软件的使用过程中能够确保自身功能的完整。具有可靠性的软件才能应用在实际的场景中。可靠性需要在软件设计时从架构上进行规划，并且通过严格的测试来分析其可靠性。

（2）快速响应

软件需要能够快速响应用户的输入，快速将计算结果反馈给用户。快速响应有利于提高用户的交互体验。

（3）健壮性

健壮性是系统在面临各类故障的情况下，仍然可以保持一定的可用状态。具有健壮性的系统才能够应对现实应用中可能面临的各类突发情况。

（4）安全性

由于系统会涉及用户的基本信息以及支付等功能，因此保障用户使用过程中数据、财产的安全性是系统的基本要求。

（5）兼容性

本系统运行在 Android 平台上，由于 Android 平台具有不同的版本，因此为保障系统的可运行性，需要兼容不同的 Android 版本，保障不同手机的客户均能使用该系统。

综合以上分析，景点移动端旅游软件系统的性能指标如下：

（1）平均并发在线用户为 300 人，高峰时期并发在线用户为 1000 人，保障系统响应时间小于 5s，并且系统正常运行。

（2）100 次操作手机软件的情况下，手机内存占用比例小于 50%。

 

4       总体设计

4.1 系统拓扑结构设计

系统的拓扑结构是对系统各个结构组成进行设计。得益于 4G 网络的不断建设以及 5G 技术的快速发展，目前移动端互联网能够覆盖大部分区域。对系统的拓扑结构进行设计需要满足未来扩展的灵活性，保障系统的各个组成部分的解耦，以便于满足未来变化的需求。

 

图 4‑1系统的拓扑结构图

 

从图 4-1 可以看到，本系统对接地图 API、景区信息、酒店信息等第三方数据，然后通过系统的数据库进行保存，由系统的 Web 服务器提供对外的服务。移动终端通过 WIFI、4G/5G 等网络访问系统服务器。从拓扑结构来看，系统具有一定的分层结构，最上层属于应用层，中层是系统的 WEB 等处理业务的模块，底层是保存数据的数据库。通过分层结构的设计，能够让各层保持独立，具有一定的扩展能力。

4.2 系统逻辑结构设计

目前软件开发的架构中为了解耦合等需要，一般将系统划分为表示层、业务层以及数据层。表示层负责移动端内容的展现以及与用户的交互，业务层负责处理系统的各项功能，数据层负责存储各类数据。本系统按照这三个层次进行逻辑划分，本系统的逻辑架构如图 4-2 所示。

 

图 4‑2系统逻辑结构

从图 4-2 可以看到，本系统的逻辑架构分为表示层、业务层以及数据层。表示层处于系统的最上层，是系统提供应用的对外接口。业务层处于系统的中间层次，提供各类业务功能，数据层处于最底层，负责各类数据的存储、查询等。

（1）数据库层

数据库层主要就是负责数据信息的存储，存储的信息包括系统中各种数据：用户信息、气候信息、酒店信息、景区信息、游记文章信息、各种配置信息等。为了方便业务层对数据进行操作，在数据层还需提供对外操作数据库的接口，封装各类操作细节，提高系统的抽象级别，增强系统的扩展性。

（2）业务层

业务层是系统中处理业务功能的层次，也是系统最为核心和复杂的层次。业务层处于表示层与数据层之间，接受表示层的各类输入及服务请求，然后完成业务逻辑处理，并将数据保存到数据层。业务层完成系统的核心逻辑处理，比如登录时需要校验用户的身份以及密码的正确性等。本系统的业务层需要完成各项系统功能，比如在对地图进行操作时，业务层需要处理地图 API 的调用，负责对地图返回信息进行处理与封装，最后还要将相关的信息返回给表示层进行展现。

（3）表示层

表示层主要是为业务层提供不同的展示方式，因为本文的设计是将功能和界

面分离开，由业务层完成各项功能计算以后，将结果返回给表示层。表示层负责在移动端设备上展现各类信息，并且与用户进行交互。

4.3 业务流程设计

使用UML的活动图描述系统的主要业务流程图。

4.3.1 用户注册登录流程

用户通过APP注册界面进行手机号、姓名、密码等信息的输入，系统进行校验并创建新账号。注册成功后跳转到登录界面，用户可利用已注册的账户信息进行登录操作。

 

4.3.2 景点查询模块设计

用户在APP主界面点击“景点浏览”按钮，进入景点浏览页面。用户可以使用搜索框或浏览热门景点排行榜进行查找，并可选定具体的景点进行查看。

 

图 4‑3 景点查询功能模块

 

图 4‑4景点查询流程

通过景点查询，可以获取景点的详细信息、门票价格、景区的当前接待量、景区评分、开放时间、门票预订情况等信息，同时可以对该景点进行收藏以及转发。景点查询需要支持景点名、景点评分等不同维度的查询，通过景点查询返回符合要求的景区。景区查询结果采用列表的方式返回，用户点击查询的结果后能够进入景区的详细列表，查询景区的详细信息，比如接待量、评分等。同时，对于有系统对接的景区，支持在 APP 上提前订票，将订票结果发送给景区系统，并返回订票的结果。

4.3.3 酒店查询和预订模块设计

用户在景点详情页点击“订票”按钮，选择所需预订日期和数量等信息，确认订单并完成支付操作。

 

图 4‑5 酒店查询和预定

 

图 4‑6 酒店查询流程图

通过酒店功能模块，可以实现对酒店信息、酒店价格、距离、酒店评分、预订

等信息的查询。酒店查询支持通过酒店名称、景区附近等方式进行查询，可以查看详细的酒店信息，并预定该酒店。APP 上可以支持线上付款功能，将预订酒店的费用发送给酒店管理系统，并接受预订酒店的结果信息，返回给使用者。

4.3.4 旅游信息平台模块的设计

用户在相应的预订界面中选择想要住宿和美食餐厅，并完成相应支付操作。

 

图 4‑7 旅游信息平台结构

 

图 4‑8 旅游信息平台流程

（1）发布/回复帖子用户登录以后，可以在旅游信息平台发布以及回复帖子。在发布与回复帖子时，第四章 景点移动端旅游软件系统设计33可以选择文字、表情以及图片等不同格式的信息。为了在移动终端保持输入信息的兼容性，需要考虑手机控件对不同信息格式的兼容。登录后的用户可以阅读其他用户发布的信息，并且在信息下方进行回复。回复后的信息系统可以通知到发帖人进行查看，发帖人可以继续回复帖子。

（2）关注/点赞热门帖子由于旅游信息平台上的帖子可能较多，并且有的帖子具有一定的热度，每个用户关注的帖子也有所不同，因此旅游信息平台提供帖子的关注与点赞等功能。通过关注与点赞可以增强信息平台用户的社交属性。用户可以选择自己感兴趣的帖子或者用户进行关注，当被关注的用户发布新的帖子或者有新的动态时，可以通知用户及时查阅新的帖子。当用户之间建立双向关注以后，有利于系统进一步提高社交属性。

（3）好友粉丝系统提供添加好友的功能以及粉丝的功能，粉丝是在关注的基础上，进一步提供用户的动态给粉丝。添加好友以后，系统允许好友之间进行私密的通信，并在页面上更新好友的动态。

（4）分享/举报为了推广景区旅游系统的使用，系统调用 QQ、微信朋友圈、微博等接口，允许用户将帖子分享到各类社交软件上，以方便其他用户进行阅读，也能够推广本系统的使用。同时，为了方便对帖子内容进行管理，对违规的信息进行查处，系统提供举报功能，当用户发现帖子内容具有不当之处时，可以进行举报，有系统管理员进行进一步的处理

（5）景点评分本系统还提供对景点的评分功能，用户可以根据自己对景区的感受，对景区进行评价。系统支持 1-5 星级评分，5 星代表满意，1 星代表不满。

4.3.5 天气预报模块的设计

管理员登录后台系统，进入景点管理模块，可以增删改查现有景点信息。同时管理员还可以管理攻略和订单信息。

 

图 4‑9 天气预报模块结构

 

图 4‑10天气预报模块流程图

4.3.6 地图与导航模块的设计

 

 

图 4‑11 地图功能模块结构

 

图 4‑12地图功能流程图

游客在系统中查询景点以后需要获取景区的地图以及导航信息，以方便用户进行行程规划等，并对地图信息进行管理。

（1）行程规划

行程规划是系统地图模块提供的基本功能。用户输入目的地以后，系统根据用户所在位置以及目的地之间进行路线规划，提供通行方案给用户。用户可以根据自身的出行情况选择不同的出行方案。为了进一步提高系统的交互特性，系统允许用户将不同的出行方案发布在信息平台，以供不同的用户参考或者接收其他用户反馈的意见。

（2）信息标注及封装

由于本系统主要从第三方地图 API 获取数据，为了降低数据请求时耗费的时间，提高效率，系统在本地也会保留一些地图数据作为离线数据，当用户在信号不好时，可以通过离线数据进行路线的规划。同时，系统也需要标注用户选择的不同路径，以分析用户的出行偏好，同时将地图沿路用户可能需要的加油站等设施进行标注，以方便用户的使用。

（3）导航收藏

系统提供导航收藏功能，以便用户能够提前收藏到不同景区的各类路线。为了方便存储，系统将相关信息存储在服务端，为每个用户建立独立的存储空间，方便记录用户的收藏信息。

（4）导航系统

导航页面允许用户选择不同模式的导航地图，既可以选择高清模式也可以选择较为粗放的模式，系统提供 1:50、1:100、1:200、1:400 等不同比例的地图模式。同时，系统还提供对地图的交互，用户可以移动地图，选择不同的地点，由系统计算两者的距离，或者进行模拟导航等。地图支持平面移动，用户通过手指滑动，可以控制地图的移动。地图移动以后，会及时获取新的地图信息，更新地图信息显示。

4.4 系统架构设计

考虑到本项目需要支持高并发请求和多用户在线操作，我们设计了一个分布式的系统架构。其中，前端采用HTML5 + CSS3 + Javascript技术，后端采用Java编程语言实现，使用Spring框架进行MVC设计，MyBatis框架进行数据库访问，通过Apache Dubbo框架实现微服务化的架构。为了保证系统的扩展性和灵活性，相关服务支持容器化开发和Kubernetes集群部署。同时，系统还会根据业务需求使用Nginx反向代理和CDN加速等提升系统的运行速度。

 

5       详细设计

5.1 数据库设计

根据需求分析的结果，在景区移动端软件中主要包括景区、酒店、信息平台等实体对象，这三个对象的 ER 图如图 5-1 所示。

 

图 5‑1 ER图

其中景区包括景区名、景区的介绍、门票等相关属性。酒店包括酒店的介绍、房间数、价格、酒店的评价等相关信息。信息平台包括各类发帖情况、发帖内容等信息。用户通过查询操作获取不同景区以及酒店的信息，并且一个用户可以查询多个景区与酒店。酒店在景区周边，因此存在一定的隶属关系。

（1）用户信息表设计

用户信息是使用系统时最基本的数据，景区、酒店、旅游信息平台均会用到，用户信息表结构如表 5-1 所示。

表 5-1 用户信息表

 

（2）酒店信息表设计

酒店信息包括酒店的基本信息、酒店的房间信息，订房信息以及客房评价信息。

酒店信息表的结构如表 5-2 所示。

表 5-2酒店信息

 

 

酒店房间信息表结构如表 5-3 所示。

 

表 5-3酒店房间信息表

 

订房记录信息表结构如表 5-4 所示。

表 5-4 订房记录表

 

客房评价信息表结构如表 5-5 所示。

表 5-5客房评价信息表

 

（3）景区信息表设计

景区信息表结构如表 5-6 所示。

表 5-6景区信息表

 

景区门票预订记录信息表结构如表 5-7 所示。

表 5-7景区门票预订记录信息表

 

 

（4）旅游信息平台表设计

旅游信息平台信息表结构如表 5-8 所示

表 5-8旅游信息平台信息表

 

5.2 模块划分

本项目主要分为前台和后台两个模块，每个模块又可分为不同的功能模块，以易于管理和维护。

根据对某景区移动端旅游软件的需求分析，本系统主要包括景点查询、景点移动端查询和预定、旅游信息平台、地图和导航个天气预报处理等五个功能模块，如图5-2 所示。

 

图 5‑2 系统功能模块

旅游软件系统中的核心对象为景区以及酒店，系统的主要逻辑结构设计如图5-3所示。

 

图 5‑3 系统逻辑结构

从图 5-3 可见，系统中包括景区以及酒店等两个主要的数据库，存储景区以及酒店的各种信息。服务器模块维护与数据库的接口，根据景区模块以及酒店模块的请求，从数据库汇总获取信息。比如景区模块可能发送查询目前景区票价的请求，服务器模块接收请求后进行查询。当酒店模块发送酒店信息查询时，服务器模读取酒店数据库，返回酒店信息。因此，酒店数据库与景区数据库是整个系统的关键，目前本系统采取自建数据库的方式维护相关数据，而对于天气、地图等数据主要采用第三方接口的形式进行获取。

5.3 类和接口设计

为了更好地组织代码和功能模块，我们设计了如下类和接口。

1. User类

用户类，记录用户的姓名、手机号以及密码等信息

public class User {

    private int id;

    private String name;

    private String mobile;

    private String password;

    // Getter 和 Setter 略

}

1. ScenicSpot类

景点类，记录景点名称、图片、介绍等信息

java复制代码public class ScenicSpot {

    private int id;

    private String name;

    private String introduction;

    private List<String> images;

 

    // Getter 和 Setter 略

}

1. 景点查询

类名称：ScenicSpotQuery

接口：

searchByName(String name)：通过景点名称搜索景区信息

searchByLocation(double longitude, double latitude)：通过经纬度搜索附近景区信息

searchByCategory(String category)：通过景点分类搜索景区信息

1. 景区周边酒店查询

类名称：HotelQuery

接口：

searchByScenicSpot(String scenicSpotName)：通过景点名称搜索附近酒店信息

searchByLocation(double longitude, double latitude)：通过经纬度搜索附近酒店信息

searchByPriceRange(double minPrice, double maxPrice)：通过价格区间搜索酒店信息

1. 旅游信息交流平台天气查询

类名称：WeatherQuery

接口：

queryWeather(String city)：查询指定城市的天气情况

queryAirQuality(String city)：查询指定城市的空气质量

queryHumidity(String city)：查询指定城市的湿度

1. 地图和导航

类名称：MapNavigation

接口：

routePlanning(String start, String end)：从出发地到目的地规划路线

navigation(String start, String end)：导航从出发地到目的地

 

6       界面设计

6.1 前台界面

 

 

图 6‑1 景点查询模块界面

 

 

 

图 6‑2 酒店查询和预订模块界面

 

图 6‑3 机票订购界面模块

 

 

图 6‑4 地图与导航模块界面

 

图 6‑5 天气预报模块界面

 

 

6.2 后台管理界面

 

图 6‑6 后台管理登录界面设计

 

图 6‑7 后台管理人员界面

 

7       测试

系统测试的目的是在完成基于 Android 平台的移动端旅游软件开发完成以后，通过采用各种测试的方法，保障系统的软件功能能够满足正常使用。本章对移动端旅游软件进行测试，由于是移动端软件，因此本章搭建了基于 Android 操作系统的手机及 PAD 环境，以便能够在不同的移动端对本系统进行测试。在搭建完测试环境以后，还要设计功能用例，按照系统测试的操作步骤，在系统中进行操作，然后验证系统能否按预期产生输出。如果操作后产生的输出不一致，有可能是系统存在功能问题，那么需要仔细检查系统的开发代码，对存在的问题进行修正。在功能测试的基础上，为了保障系统能够正常的在手机上运行，同时系统的各项服务不会因为出现大的负荷而崩溃，因此需要对系统进行性能测试。为了保证系统的正确性和可靠性，我们进行了如下测试：

 

7.1 测试范围.

测试将覆盖所有的主要功能，包括用户注册、登录、景点搜索、订票、住宿预定、餐饮预定、评价以及后台管理。

7.2 测试计划

测试计划将包括以下阶段：单元测试、集成测试、系统测试、验收测试。每个模块都将进行详尽的测试，以确保系统的稳定性和可靠性。

7.3 测试阶段.

1. 单元测试：测试每个独立的代码组件，确保它们都能按预期工作。

2. 集成测试：将单个组件组合起来，测试它们之间的接口和交互，确保它们能够正确地一起工作。

3. 系统测试：将所有的组件和模块作为一个整体进行测试，以确保整个系统的功能和性能符合要求。

4. 验收测试：最终用户或客户进行的测试，以验证系统是否满足了他们的需求。

 

7.4 测试进度

测试进度将跟随软件开发生命周期的每个阶段进行，从单元测试开始，然后进行集成测试，接着是系统测试，最后是验收测试。

 

7.5 功能测试

功能测试的目的是保障系统的各项操作流程能够产生符合预期的输出，一般

功能测试可以通过设计测试用例的方式来完成，测试用例是一系列的操作步骤，每个步骤都有一定的输出，而测试的标准就是检查输出是否与预期一致。

（1）系统登录测试

系统登录测试用例如表 6-2 所示。

 

 

 

表 7-1 登录功能测试用例

测试用例编号	前提准备	操作步骤	预期结果	测试结果
1	系统数据库中预先生成 测试账号“test”以及密码“123456”	访问系统页面，输入系统中存在的测试用户名“test”以及密码“123456”，点击登录	系 统 验 证 通 过，跳转到系 统首页
2	系统数据库中预先生成测试账号“test”以及密码“123456”	访问系统页面，输入系统中 存在的测试用户名“test”以 及密码“5678910”，点击登录	验证失败，拒 绝登录
3	系统数据库中预先生成测试账号“test”以及密码“123456”，同时删除系统中可能的账户“test1”	访问系统页面，输入系统中存在的测试用户名“test1”以及密码“5678910”，点击登录	验证失败，拒 绝登录
4	系统数据库中预先生成测试账号“test”以及密码“123456”，同时删除系统中可能的账户“test1”	访问系统页面，输入系统中存在的测试用户名“test1”以及密码“123456”，点击登录	验证失败，拒 绝登录

登录测试用例设计了按照不同的方式输入用户名和密码以后系统的输出

（2）景区查询和酒店查询测试

景区查询和酒店查询和预定模块主要用来测试景区与酒店能否被正常搜索，

该功能模块的测试用例如表 6-3 以及表 6-4 所示。

表 7-2 景点查询功能测试用例

 

 

表 7-3 酒店查询功能测试用例

 

 

景点和酒店查询中包括输入不同的查询条件，然后对系统进行操作，检查系统输出的景区与酒店是否是按照条件进行筛选。比如在景区筛选时，用户可能按照名称、类型等进行搜索，系统在后台匹配相关数据以后，会返回查询的结果。在测试中，可以检查异常输入的情况，比如输入正常的酒店名进行查询以后，可以返回该酒店的详细信息，同时也可以采取模糊匹配的方式，输入关键字进行查询，然后系统需要返回满足该关键字的所有的酒店信息。同时，还需要输入不存在的酒店条件，最后系统会提示不存在此类型的酒店。通过测试以后，可以看到本系统的搜索功能能够正常运行，并且与系统设计逻辑保持一致。

（3）地图和导航功能测试

地图与导航模块的功能主要用来反映能够正确定位与导航，该功能的测试用例如表 6-5 所示。地图与导航的查询中包括输入不同的查询条件，然后对系统进行操作，检查系统输出的定位与路线是否是按照条件进行筛选。比如在定位景区时，用户可能按照名称、类型等进行搜索，获取导航相关数据以后，会返回查询的路径的结果。在测试中，可以检查异常输入的情况，比如输入正常的景区进行查询以后，可以返回该景区的详细信息以及具体的路径规划，同时也可以采取模糊匹配的方式，输入关键字进行查询，然后系统需要返回满足该关键字的所有的路线。除了搜索功能以外，还要测试地图的批注以及收藏功能，允许用户在地图上批注若干文字信息，并且在加入收藏以后，这些文字信息需要被保存，在下一次打开导航与地图时被正确显示。通过测试以后，可以看到本系统的地图与导航功能能够正常运行，并且与系统设计逻辑保持一致。

 

表 7-4 地图与导航功能测试用例

 

 

（4）天气预报模块

天气预报模块用于获取不同景区、城市的天气情况，该模块的测试用例如表 6-

6 所示。

 

表 7-5 天气预报功能测试用例

 

天气预报包括输入不同的查询条件，然后对系统进行操作，检查系统输出的天

气是否是按照条件进行筛选。比如输入某个城市以后，系统需要读取天气预报接口，获取该地区的天气情况，如果信息获取失败，系统需要给出历史信息。由于在实践过程中，有可能遭遇网络不好的问题，因此本次测试通过关闭移动网络模拟在信号不好区域进行操作的场景。同时，还需要测试天气预报的信息能否被发布在微信等朋友圈界面中，因此在测试时需要保持微信接口的可访问性。通过测试以后，可以看到本系统的天气预报功能能够正常运行，并且与系统设计逻辑保持一致。

（5）信息模块

信息平台模块用来完成用户发布各类信息的功能，该模块涉及一系列的操作，

本文设计测试用例如表 6-7 所示。

表 7-6 信息平台功能测试用例

 

 

信息平台模块的测试主要包括测试当用户新建帖子时能否正常发布，同时用

户还有可能编辑发布的帖子或者删除发布的帖子。对于用户而言，在没有权限以及其他问题的情况下，应该能够正常发布帖子。而且用户对于自己发布的帖子具有权限来编辑和删除，同时不能删除与编辑他人发布的帖子，只能在帖子中进行回复。由于是在移动端发布帖子，因此需要对帖子的内容比如字数、图片等进行限制，最后还可以调用天气接口来分享天气信息到帖子中。    

 

7.6 性能测试

系统性能测试主要是完成系统在各种不同负载与压力下性能参数变化的测试，检验系统是否存在某些场景中出现性能下降或者内存泄露等问题。

（1）负载和压力测试

本文采用 LoadRunner 模拟不同的用户数进行操作，LoadRunner 能够生成各种

并发的线程，并且按照脚本规定的操作运行。本文主要模拟 300 至 1500 个用户完成登录以及操作响应的情况下，系统能否正常响应。通过模拟用户的并发操作，可以观察系统能否正常输出。在模拟用户操作时，逐渐增加用户的使用数量，观察系统延时是否增加或出现奔溃的情况。

表 7-7 负载和压力测试

目的	操作过程	预期结果
模拟 300 个用户，进行查询、编辑等操作	通过 loadRunner 生成 300个用户，随机进行操作	响应时间低于 0.4 秒
模拟 1000 个用户，进行查询、编辑等操作	通过 loadRunner 生成 1000个用户，随机进行操作	响应时间低于 0.7 秒
模拟 1500 个用户，进行查询、编辑等操作	通过 loadRunner 生成 1500个用户，随机进行操作	响应时间低于 1.5 秒

 

（2）内存使用情况

一般手机的资源是有限的，为了测试手机在使用系统时是否会消耗较大的内

存，并对内存使用进行测试，本文采用 Eclipse 中的 DDMS 内存监控功能对使用手机的过程中内存使用情况进行监控，并对手机应用程序进行调试。

 

8       结论

8.1 项目总结

在这个项目中，我们成功设计和实现了一个提供综合旅游服务的APP，包括用户注册、景点查询、酒店查询、旅游信息平台、天气查询和地图导航等功能。通过深入的需求分析，我们清晰地理解了每个功能的具体需求，并按照这些需求进行了详细的设计和开发工作。

我们设计了清晰的系统架构，以满足各种功能需求；我们实现了直观易用的用户界面，为用户提供了良好的使用体验；我们创建了强大的后端系统，支持大量的数据存储和检索，同时保证了系统的稳定性和性能；我们整合了第三方服务，如地图API和天气API，进一步提升了我们的服务质量。

在整个开发过程中，我们进行了严格的测试工作，确保了APP的质量和稳定性。在项目管理方面，我们有效地控制了项目进度和质量，确保了项目按计划进行，并且达到了预期的目标。

8.2 未来工作

在未来，我们计划进一步改进我们的APP，不断添加新的功能和服务，以满足用户的更多需求。我们也将持续监控APP的运行情况，及时发现并修复可能出现的问题，保证APP的稳定运行。同时，我们会密切关注旅游行业和技术发展的趋势，以便及时调整我们的服务，更好地满足市场需求。

此外，我们也将重视用户反馈，通过收集和分析用户反馈，我们可以更好地理解用户需求，优化我们的服务，提高用户满意度。在这个持续发展和变化的环境中，我们希望我们的APP能不断提升，为用户提供更优质的旅游服务。