医院住院管理信息系统
一、绪论
1.1项目背景
随着人口的快速增长，我国的人口数量越来越多，随之而来的还有一系列的问题，其中一项就是就医问题。在人口基数大的基本情况下，医院单纯靠人力无法短时间解决这种问题，此时急需一个医院住院管理信息系统[1]。作为信息时代的产物，该系统具有超高的处理效率，患者可以直接选择网上办理而不用去医院排队挂号，大大节省了用户的时间，方便用户使用。
1.2国内外研究现状
医院住院管理信息系统的研究开始于十九世纪六十年代，第一个医院住院管理信息系统是1971年，美国加利福尼亚州的EICamino医院研制的TDS (technicon medicalinformation system）系统，该系统主要完成医生和各辅助部门的信息通信功能。这些系统的出现令人耳目一新，但功能有限，主要提供收费服务。
随着互联网应用进入到一家一户，成为人们日常生活工作娱乐不能缺少的一部分，又使得信息系统的重要性得到了充分的展示。医院引入信息化系统管理模式之后，改善了很多流程。
目前我国数字化医院的建设重点以“医疗数字化”为主，即着重发展医院内与医疗活动相关的各类信息的数字化管理和综合利用，并保证系统的开放性，为将来扩展到区域医疗打下基础[2]。
在信息时代的今天，数据成为了不可或缺的资源。由于医院数据资源密集，业务流程复杂，数据流程大，因此每一环都离不开信息资源的流转与共享。然而医院信息化急速的发展虽然带来的便利与效率，也带来一定程度上的问题，在医院住院管理信息系统建设的过程中不可避免的存在大量的“信息孤岛”，在今后建设的过程中难以解决，影响整体调控。除此之外，院内数据量虽然急速增长，但是由于数据不能形成结构化的数据，无法利用起来。因此，制造能被利用的、合理的结构化数据成为关键，满足医院管理的需求成为重要的挑战[3]。
1.3项目前景
随着我国经济和社会的发展，群众医疗保健需求的持续增长，社会对医院的 期望上升，必然导致医院服务功能与任务逐步扩大，由此带来医院管理内容、管 理方法以及管理手段等一系列的变化。研究分析医院管理发展趋势，有助于管理 者自觉遵循事物发展方向，促进管理工作[4]。
1.4可行性分析
系统的可行性分析的目的在于用最小的成本在最短的时间内确定在现有的技术、经济和人员等各方面条件下该问题能否解决、是否值得去解决。从本质上讲，该过程压缩简化了的系统分析和设计，也就是在逻辑层面上以较抽象的方式所进行的系统分析和设计。
一般应该从技术方面的可行性、经济方面的可行性、操作上的可行性及社会方面的可行性四个方面研究该系统的可行性。
1.4.1技术可行性分析
医院住院管理信息系统采用B/S架构,使用SSM框架进行开发[5]，并采用MySQL作为数据库系统。MySQL数据库可以实现数据的存储、传递，可以提高数据的准确率和可利用率。程序，快捷稳定。
1.4.2经济可行性分析
本系统对运行环境没有特殊要求，普通配置台式机即可满足，搭配医院现有内网环境，即可稳定运行。对现有的科室人员也没有太多要求，界面简洁易用，简单操作电脑就能使用本系统。然后系统对医院住院管理工作效率的提升远远高出投入成本，并可促进相关业务的运转，与传统的手工方式相比将获得超高效益比。
1.4.3操作可行性分析
本系统根据医院工作人员的特点，系统界面简单，操作简洁，不会对工作人员造成额外的工作负担，减轻一定的工作压力，使工作人员从繁琐的人工操作中解脱出来。
面对于系统设计还应该以“标准性、安全性、兼容性、高效性、保密性、可维护性”为标准，在着眼于当前实用的基础上，为将来系统的扩展，升级留有余地。软件的功能能够满足一定时间内业务的发展需求。
1.4.4社会可行性分析
1.必要性
医院患者信息及就诊信息量过大，手工处理不仅造成时间上的浪费，也可能产生操作错误，造成信息的准确性不能保证，查询修收等数据处理的操作难度更大，甚至无法实现。
2.可能性
新的系统上线有可能造成员工的不适，从而产生抵触心理，我们应做好宣传，表明系统的易用与能带来的方便和好处，降低工作人员的反感，协助工作人员适应系统。
二、需求分析
2.1需求列表
2.1.1病人
病人拥有结算中心和护理中心两个功能模块如表2.1所示。用户在结算中心可以预缴费用、查询缴费记录和查询相关费用，在护理中心可以录入自己的体征数据并查询，还可以查询自己的住院历史和用药历史[6]。
表2.1 用户需求列表
用户类别 页面 功能点 功能描述
病人 结算中心 费用预缴 通过住院号、科室、姓名主治医师，选择缴费途径和预交费用，记录收款用户和姓名
缴费记录 通过住院号、姓名等信息查询详细信息
费用查询 通过住院号、姓名等查询费用的记录
护理中心 录入体征数据 通过住院编号、姓名、床位号、记录下体温、心率、血压、血糖、备注等
体征数据查询 通过姓名、床位号、住院号、测量时间、查询到之前的体征信息、并生成体征信息变化趋势表
住院历史 通过身份证号查询住院的记录
用药历史 通过住院号、查询用药的具体信息
2.1.2前台
前台拥有除用户功能外的入院管理、出院管理、统计中心、药品管理外四大功能模块如表2.2显示。医生和护士拥有用户和前台的所有功能模块。
表2.2 前台需求列表
用户类别 页面 功能点 功能描述
前台 入院管理 入院登记 登记姓名、性别、身份证号、工作单位、家庭住址、民族、家庭电话、科室、主治医师、病房类型、病房号、床位号、入院管理、入院状态、紧急联系人、手机号等
住院查询 根据科室、住院号、病房号、入院时间、姓名、床位号、进行查询
出院管理 出院管理 出院之前登记、住院号、姓名、性别、科室、身份证号、主治医师、入院时间、病房号、是否结算、床位号
出院查询 通过住院号、时间、姓名、查询到出院人的具体信息。
转院/病房 通过住院号、姓名、去调换科室、主治医师、病房类型等
统计中心 病人统计 通过时间、查询各个科室、医院的病人数量、生成图表信息
病房统计 通过科室、查询病房的使用情况。
药品管理 药品入库 记录编号、名称生产厂商、数量等药品信息
药品发放 记录发放药品病人的住院号、以及药品信息
退药处理 记录退药人的住院编号、患者姓名药品信息、还有退药的原因等
入库查询 通过编号和药品名称查询入库药品的详细信息
库存查询 通过药品编号和名称查询详细信息
2.1.3管理员
管理员拥有病房管理、用户管理、医生管理、系统配置等功能模块如表2.3所示。
表2.3 管理员需求列表
功能类别 页面 功能点 功能描述
管理员 病房管理 新置病房 输入房间号、科室、类型容量、来进行添加
病房价格调整 调整不同病房价格
用户管理 用户注册 给用户注册、给用户权限
用户查询 查询用户的详细信息
医生管理 医生录入 录入医生的详细信息
医生查询 查询到所有医生的详细信息
系统配置 参数设置 添加修改、科室、职称、病房类型、病房等
运行日志 通过时间查询运行日志
2.1.4超级管理员
超级管理员拥有病人、前台以及管理员集成的所有功能，包括入院管理、出院管理、病房管理、结算中心、护理中心、统计中心、药品管理、用户管理、医生管理和系统配置。
2.2功能性需求分析
2.2.1功能结构图
图2.1 病人功能结构图
病人拥有体征数据管理、历史数据查询和费用管理功能，具体如图2.1所示。
图2.2 医生功能结构图
医生的功能包括病人管理、体征数据管理、历史数据查询和药品管理，具体如图2.2所示。
图2.3 管理员功能结构图
管理员的功能包括病房管理、费用管理、药品管理、用户管理和医生管理，具体如图2.3所示。
图2.4 系统功能结构图
超级管理员的功能包括病人管理、病房管理、体征数据管理、历史数据查询、药品管理、用户管理和医生管理，具体如图2.4所示。
2.2.2系统用例图
图2.5 病人用例图
病人的需求有登录、用药历史查询、费用查询、缴费记录查询、住院历史查询和体征数据查询，而费用查询功能是在病人在入院登记之后才能够使用的。
图2.6 服务前台用例图
前台的需求有入院登记、出院登记、转院/病房和费用预缴。前台在对病人进行出院登记时需要查询病人的费用信息，确保病人已经缴费；前台在给病人转院或者转病房时需要查询病人当前住院信息，并进行相应修改；在病人预缴完费用之后前台可以打印出缴费单，递交给病人。
图2.7 医生—护士用例图
医生与护士共同的需求有登录、住院查询、出院查询、体征数据管理和查询用药历史和药品发放。在药品发放之前需要查询库存，确保库存中药品充足，并在发放药品之后打印出对应的发票。与护士相比，医生特有的需求有查询住院历史；与医生相比，护士特有的需求有缴费记录查询和费用查询。
图2.8 管理员—超级管理员用例图
管理员与超级管理员共同的需求有登录、用户管理、医生管理、病房管理、库存管理、入库查询和药品入库，药品入库之后可以生成入库单。超级管理员特有的需求有退药处理和药品发放。
2.2.3用例规约
表2.4 登录用例规约
用例名称 登录
简介 登录系统进入首页
前置条件 用户进入医院住院管理信息系统
后置条件 用户进入对应角色的欢迎界面
基本事件流 1.进入系统
2.输入账号，密码和验证码
3.点击登录
备选事件流 1.用户不存在
2.密码错误
3.验证码错误
表2.5 入院登记用例规约
用例名称 入院登记
简介 前台对需要住院的病人进行登记
前置条件 病人申请办理入院手续
后置条件 病人入院
基本事件流 1.进入入院登记页面
2.输入病人的姓名、身份证号等信息
3.点击登记
备选事件流 1.找不到主治医师、病房等
表2.6 住院查询用例规约
用例名称 住院查询
简介 前台按条件查询住院病人
前置条件 进入对应的查询界面
后置条件 查询到指定病人
基本事件流 1.进入住院查询页面
2.输入科室、住院号等条件
3.点击查询
备选事件流 1.未找到信息
表2.7 转院/病房用例规约
用例名称 转院/病房
简介 给病人转科室或病房
前置条件 病人需要转科室或病房
后置条件 病人转到相应的科室或者病房
基本事件流 1.进入转院/病房页面
2.更改病人科室或病房
3.点击保存
备选事件流 1.病房已满
表2.8 新置病房用例规约
用例名称 新置病房
简介 增加新的病房
前置条件 病房不足
后置条件 病房总数增加
基本事件流 1.进入新置病房页面
2.输入房间号、科室等数据
3.点击增加
备选事件流 1.房间号格式不正确
2.病房号已存在
表2.9 新置病房用例规约
用例名称 病房价格调整
简介 调整不同类型病房的价格
前置条件 病房价格需要更改
后置条件 病房价格更改完成
基本事件流 1.进入病房价格调整页面
2.修改对应类型病房的价格
3.点击保存
备选事件流 1.房间号格式不正确
2.病房号已存在
三、系统设计
3.1功能模块设计总述
3.1.1挂号
图3.1 挂号顺序图
病人通过相关渠道进行挂号，缴费后系统提示挂号成功。病人去往对应科室进行医疗咨询，医生根据病人健康情况合理开方。病人拿到处方后去往前台进行缴费，并递交处方给药房拿药。具体如图3.1所示。
3.1.2住院
需要住院医治的病人在前台登记住院，前台根据病人情况安排病房，交给病人相应的床位安排清单。病人向前台预交一定费用后，前台给病人安排对应床位，
随后由护士对病人进行住院医护。病人康复后可以办理出院手续，结算完住院相关费用后可以离开医院。具体如图3.2所示。
图3.2 住院顺序图
3.1.3药品出库
图3.3 药品出库顺序图
管理员登录管理系统后，可以对药品出库记录进行相关审查，并统计药房的领药记录生成出库清单。管理员根据清单内容对数据库进行相应修改。具体如图3.3所示。
3.1.4药品采购
图3.4 药品采购顺序图
管理员登录管理系统后，可以对药品出库记录进行相关审查，并统计药房的领药记录生成出库清单。管理员根据清单内容对数据库进行相应修改。具体如图3.4所示。
3.2状态图
状态图是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应。
初始状态：每个状态图都应该有一个初始状态，它代表状态图的起始位置。一个状态图只能有一个初始状态，用一个实心的圆表示。
终止状态：终止状态是一个状态图的终点，一个状态图可以拥有一个或者多个终止状态。对象可以保持在终止状态。
3.2.1病人挂号
图3.5 病人挂号状态图
如图3.5所示，病人最开始处于未挂号状态，当病人去往前台或者机器挂号并缴纳相关费用后，病人可能处于未诊断状态。医生仔细诊断病人的身体状态后，给病人写处方，当前病人可能处于未取药状态。病人给前台提交处方并缴纳医药费后，病人成功取得药品，此时病人处于已取药状态。最后病人处于出院状态。
3.2.2病人住院
图3.6 病人住院状态图
如图3.6所示，病人最开始处于未登记状态，当病人去往前台登记住院后，病人处于已登记状态。病人预交费后，前台给病人安排对应的床位，当前病人可能处于已住院状态。病人在医院住院一段时间，最终恢复健康后，此时病人可能处于未出院状态。最后病人处于出院状态。
3.2.3药品管理
图3.7 药品状态图
如图3.7所示，药品最开始处于未入库状态，管理员查看药品库存，针对库存量较少的药品，到相关厂商进行采购，此时药品可能处于已入库状态。医生给病人开处方后，当前药品处于未出库状态。病人根据处方去前台缴纳医药费后去药房拿药，此时药品处于已出库状态。
3.3数据库设计
3.3.1种类及特点
本项目采用了MySQL 数据库。MySQL是一个关系型数据库管理系统，关联数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。MySQL具有以下几个特性：
1）MySQL为多种编程语言提供了API，包括C语言、Java、PHP、Python语言等。
2）MySQL优化了SQL算法，有效的提高了查询速度。
3）MySQL内提供了用于管理，检查以及优化数据库操作的管理工具。
4）提供TCP/IP、ODBC和JDBC等多种数据库连接途径。
5）支持大型的数据库。可以处理拥有上千万条记录的大型数据库。
3.3.2逻辑结构设计
（1）系统E-R图
图3.8 医生实体图
医生实体的属性有编号、姓名、职称、性别、工作时间、工作状态和部门。
图3.9 护士实体图
护士实体的属性有护士编号、护士姓名、科室、年龄和性别。
图3.10 收费实体图
收费实体的属性有费用编号、病人编号、费用类型、金额、收费人编号和收费时间。
图3.11 药品实体图
药品实体的属性有药品编号、药品名称、价格、生产公司、保质期和生产日期。
图3.12 病人实体图
病人实体的属性有病人编号、病人姓名、民族、出生日期和性别。
图3.13 系统E-R图
（2）类图
1）病房管理
类间关系说明：
医生与护士为多对多的关系。
护士与病人为一对多关系。
护士与床位为一对多关系。
医生与病人为多对一关系。
主要方法说明：
医生通过入院登记，住院查询为病人安排对应床位，护士类具有同样的权限，并且有新置病房的方法。病人在预交费后被安排病房，或申请转院后安排病床。
图3.14 病房管理类图
2）药品管理
类间关系说明：
管理人员与药库药房为多对多的关系。
药房和药库为泛化的关系。
药房和药品为一对多的关系。
主要方法说明：
管理员可以进行药品入库查询与发放，并可以进行退药处理药库进行出入库管理。
图3.15 药品管理类图
3）财政管理
图3.16 财政管理类图
类间关系说明：
财务数据库与管理员为一对多的关系。
主要方法说明：
财务数据库提供的方法，对不同权限的管理员提供不同级别的服务，主要提供的方法有查询数据和修改数据。
4）成员管理
图3.17 成员管理类图
3.3.3物理结构设计
根据3.3.2的逻辑结构设计，设计相应的数据库表。
表3.1 药品表
字段名 数据类型 字节 允许空值
id int 10 否
drugId varchar 15 是
drugName varchar 30 是
price float 0 是
count int 11 是
表3.2 医生表
字段名 数据类型 字节 允许空值
doctorId int 6 否
gender int 11 否
doctor_department int 11 否
name varchar 10 否
doctor_title int 11 否
working_time date 0 是
state int 11 否
表3.3 取药记录表
字段名 数据类型 字节 允许空值
id int 10 否
drugId varchar 30 是
drugName varchar 30 是
drugPrice float 0 是
drugCount int 11 是
patientName varchar 30 是
patientId varchar 30 是
grantUserId varchar 20 是
grantUserName varchar 30 是
grantTime datetime 0 是
表3.4 病人表
字段名 数据类型 字节 允许空值
id int 11 否
patientId varchar 20 是
patientName varchar 20 否
gender int 11 否
nation int 11 是
birth date 0 是
department int 11 是
certificateNo varchar 18 是
workUnit varchar 200 是
maritalStatus int 11 是
doctorId int 11 是
admissionTime datetime 0 是
homeAddress varchar 255 是
homePhone varchar 11 是
contacts varchar 20 是
contactsPhone varchar 11 是
admissionStatus int 11 是
roomType int 11 是
roomNo int 11 是
bedNo int 11 是
state int 11 是
settlementState int 1 否
leaveState int 1 是
leaveTime datetime 0 是
3.4页面设计与介绍
3.4.1登录页面设计
登录页面主要是优先展示在用户面前的界面在设计方面主要就是简洁大方、突出重点，让用户在使用过程中没有压力。
图3.18 登录界面图
3.4.2系统欢迎界面设计
此为超级管理员欢迎界面，不同用户拥有的权限不同，欢迎界面都是一样的，不同在于左侧导航框。
图3.19 系统欢迎页面图
3.4.3入院信息添加界面设计
为用户添加入院信息的过程中我们要保证对于用户个人信息录用的方便性，准确性我们采用的是输入框的形式。
图3.20 入院登记界面
3.4.4住院信息查询页面设计
通过科室和住院号进行住院信息的查询。
图3.21 住院查询界面
四、系统实现
我主要负责的功能模板是登录功能、整体的页面设计、入院管理。其中整体的页面设计要提前完成方便其他成员参照页面进行自己的功能实现。
4.1整体功能实现说明
（1）根据定义好的数据库表构建对应的pojo类，用于存储数据库数据。
（2）在Mapper接口（号用于指代对应的pojo类名）中定义各类数据的增加、删除、修改和删除方法，并在Mapper.xml文件中编写相应的sql语句并映射到对应的方法上。
（3）在Service接口中再次定义一次对应的Mapper接口中的方法，并在接入此接口的ServiceImpl类编写代码的业务逻辑，注意在类名上使用@Service注解修饰。
（4）在Controller类中，将对应的Service接口作为属性，使用@AutoWired注解修饰。在该类中定义相应的请求方法，在各个方法内使用Service接口中定义好的方法来完成对数据的增删改查操作，页面数据交互可以使用js文件中的ajax来调用映射的请求地址，从而调用后端的具体方法来实现，
4.2整体的页面设计
4.2.1登录界面
登录界面的设计主要分为登录框和背景，背景设置的是两张拼接在一起的图片，背景中飘动的气球是使用JS进行的功能实现。在登录框中主要分为三个文
本框，分别是用户名、密码、验证码三部分，采用JSP文件进行页面的实现。
图4.1住院查询界面
4.2.2顶部导航栏的设计
顶部导航栏是一个由蓝变紫的过程，最左边是本系统的名字，在名字的旁边是三条杠，需要实现对于侧边栏的隐藏和显示。顶部导航栏的右边是用户的名字和一个对于全屏显示的按钮。
4.2.3侧边栏的设计
图4.2 住院查询界面
侧边栏主要是由图标和文字简介组成，每个功能模块下都有详细的功能划分。
4.2.4功能模块界面的设计
功能模块分为信息录入数据库和从数据库查询。信息录入实现主要就是表明录入信息的名字和文本框。文本框主要是输入文本框和下拉文本框两种形式。从数据库查询主要是根据信息将查询到的结果显示在表格中。
图4.3住院查询界面
4.3登录功能
4.3.1登录验证
本系统是多用户的登录，当系统的用户准备登录系统的时候需要输入输入自己的用户名和密码还有随机生成的验证码。每个用户的用户名和密码都存储在数据库中，随时生成的验证码只存储在缓存中。用户登录认证业务逻辑controller只校验验证码，如果验证码无误&&没有NameOrPasswordException就认定为登陆成功，并且写入cookie信息。用户名和密码的校验交给服务UserserviceImpl的login(username,password)方法，用户名或密码不正确时，该方法将抛出异常在业务逻辑层捕获这个异常。系统超级管理员在登录过程中，系统级超级权限登录认证用户名&&密码&&验证码都为superman 即为超管用户。
图4.3.1 管理员登录界面
4.3.2验证码的实现
验证码由四个字符组成，字符包括26个英文字母和数字。特别注意的是在生成验证码的过程中英文字母是区分大小写的，但是在用户的检验过程中，英文字母是不区分大小写的。
图4.3.2 验证码不区分大小写
4.3.3权限的分配
在登录的过程中获取获得cookie中的name，使用function() 通过if去判断是那个用户，为相对应的用户分配相应的权限。在登录过程中出现无法登陆的情况只能返回登录页重新进行判断。
4.4入院管理
4.4.1入院登记
入院登记是前台和护士这些用户使用的操作权限。进入登记界面是对于入院登记个人信息的填写，将患者的基本信息插入到user表，如果患者以前住过院，用户表里会存有患者身份证，则不再插入，同时为了保证身份证信息的合法准确性，利用正则表达式对输入的身份证信息进行判断。性别、民族、科室、主治医师、病房类型、病房号、病床号、入院状况等都是下拉必选项。家庭住址和手机号也是必填项，为了防止信息有误手机号也进行了正则表达式的判断。保存成功后出现弹框提示。将所有信息保存到数据库中，在输入过程中有重置按钮。
图4.4.1 入院登记界面
4.4.2住院查询
在整个系统的使用过程中，对于医院的管理者来说，可以看到当前住院的各种信息。可以通过科室、住院号、病房号、入院时间、姓名、床位号等进行数据库查询得到符合条件的信息。点击清空条件按钮后可以刷新当前界面。
图4.4.2 住院查询界面
五、系统测试
5.1测试用户注册
表5.1 不输入数据测试用例表
测试用例编号 Test_001
测试项目 用户注册
测试内容 不输入任何数据
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统提示数据不能为空
测试结果
表5.2 手机号输入测试用例表
测试用例编号 Test_002
测试项目 用户注册
测试内容 输入错误的手机号
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统提示填写有误
测试结果
表5.3 密码确认测试用例表
测试用例编号 Test_003
测试项目 用户注册
测试内容 再次输入的密码与第一次输入的密码不一致
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统提示两次密码不一致
测试结果
表5.4 注册成功测试用例表
测试用例编号 Test_004
测试项目 用户注册
测试内容 输入正确的的用户数据
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统提示注册成功
测试结果
5.2测试用户查询
表5.5 输入错误条件测试用例表
测试用例编号 Test_005
测试项目 用户查询
测试内容 输入错误的查询条件
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统提示未找到信息
测试结果
表5.6 点击查询测试用例表
测试用例编号 Test_006
测试项目 用户查询
测试内容 不输入查询条件，直接点击查询按钮
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统显示所有用户数据
测试结果
表5.7 条件查询测试用例表
测试用例编号 Test_007
测试项目 用户查询
测试内容 输入正确的查询条件，点击查询按钮
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统显示指定条件下的用户数据
测试结果
表5.8 清空条件测试用例表
测试用例编号 Test_008
测试项目 用户查询
测试内容 点击清空条件按钮
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统清空输入条件和查询到的数据
测试结果
表5.9 删除用户信息测试用例表
测试用例编号 Test_009
测试项目 用户查询
测试内容 删除用户信息
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统提示删除成功
测试结果
表5.10 修改用户信息测试用例表
测试用例编号 Test_010
测试项目 用户查询
测试内容 修改用户信息
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统提示更新成功
测试结果
表5.11 重置用户密码测试用例表
测试用例编号 Test_011
测试项目 用户查询
测试内容 重置用户密码
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统提示密码重置为123456
测试结果
5.3测试医生录入
表5.12 不输入单条数据测试用例表
测试用例编号 Test_012
测试项目 医生录入
测试内容 不输入其中任意一条数据
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统提示数据不能为空
测试结果
表5.13 录入医生测试用例表
测试用例编号 Test_013
测试项目 医生录入
测试内容 输入正确的医生信息，点击保存按钮
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统提示保存成功
测试结果
5.4测试医生查询
表5.14 输入不存在的医生条件测试用例表
测试用例编号 Test_014
测试项目 医生查询
测试内容 输入不存在的医生条件，点击查询按钮
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统提示未找到信息
测试结果
表5.15 查询所有医生条件测试用例表
测试用例编号 Test_015
测试项目 医生查询
测试内容 直接点击查询按钮
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统显示所有医生信息
测试结果
表5.16 按条件查询医生测试用例表
测试用例编号 Test_016
测试项目 医生查询
测试内容 输入已有的医生条件，点击查询按钮
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统显示指定条件下的医生信息
测试结果
表5.17 删除医生测试用例表
测试用例编号 Test_017
测试项目 医生查询
测试内容 选择某个医生信息，点击离职链接
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统提示该医生成功离职
测试结果
表5.18 修改医生信息测试用例表
测试用例编号 Test_018
测试项目 医生查询
测试内容 选择某个医生信息，点击修改链接
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统提示更新成功
测试结果
5.5测试参数设置
表5.19 查看详细参数测试用例表
测试用例编号 Test_019
测试项目 参数设置
测试内容 点选某个参数
重要级别 高
预置条件 在联网的情况下成功打开服务器映射地址，
并以管理员身份登录
预期输出 系统显示某一参数下的所有实例
测试结果
点击拨打：