第三章 系统的需求分析和可行性研究
3.1 功能需求
经过对本系统的研究分析，本系统主要是为了方便让医院更快捷的管理。所面向的对象主要有病人、医生和医院的管理人员。病人运用该系统后，可以根据该系统查看自己所需要的信息，包括治疗自己病症的医生的信息、病床信息、收费信息等。医生运用该系统后，可以根据该系统查看自己病人的信息。而医院管理人员通过该系统可以查看病床利用率和收费明细的情况。[3]
根据面向对象的需求的不同，可以分析出本系统需要的主要功能有：登录、医生信息管理、病人信息管理、收费信息管理、病床信息管理、统计分析管理和系统管理。
3.1.1 系统层次结构图
该系统主要是医生和病人通过该系统，对整个医院的病床、医生、病人和消费信息进行查看，根据自己的需要进行选择。系统层次结构图如图3-1所示：
图3-1 系统层次结构图
医院管理系统包括如下功能：
- 医生管理
业务描述：管理医生信息、包括对医生信息的增加、删除、修改
- 病人管理
业务描述：管理病人信息、包括对病人信息的增加、删除、修改
- 病床管理
业务描述：管理病床信息、包括对病床信息的增加、删除、修改
- 收费管理
业务描述：管理收费信息、包括对收费信息的增加、删除、修改
- 统计分析
业务描述：病床利用率查询主要是通过对科别、医师和日期的搜索，收费明细查询主要是通过对病人姓名和日期的搜索，来进行对其相对应信息的查询。
- 修改密码
业务描述：用户可以修改自己的系统登录密码
3.1.2 医生信息管理
医生信息管理主要是通过对医生姓名的搜索，来对医生信息进行查询，其中查询的内容包括医生的编号、性别、职称、职务、科别、出生日期和工作日期，还可以对医生信息进行添加、修改、删除。
图3-2 医生信息管理结构图
3.1.3 病床信息管理
病床信息管理主要是对病床的所属科别、病床号、床位费和使用状态进行查 看，还可以对病床进行添加、修改和删除。
图3-3 病床信息管理结构图
3.1.4 病人信息管理
病人信息管理主要是通过对病人姓名的搜索，来对病人信息进行查询，其中 查询的内容包括病人的科别、病床号、性别、年龄、病症、主治医生、入院和出院日期，还可以对病人信息进行添加、修改和删除。
图3-4 病人信息管理结构图
3.1.5 收费信息管理
收费信息管理主要是通过对病人姓名的搜素，来进行对其收费信息的查询，其中查询的内容包括病人的科别、病床号、收费项目、单价、数量、金额和日期，还可以对收费信息进行添加、修改和删除。
图3-7 收费信息管理结构图
3.2 非功能性需求
3.2.1 系统性能需求
响应时间尽量短，结果准确。一般业务操作时间在3到5秒，添加以及修改报表时间不超过30到45秒。对于多用户并发访问的问题，系统通过先进缓存技术而解决了相应的问题。
3.2.2 系统安全性需求
由于医院管理住院系统是基于MVC模式以B/S框架而开发的Web应用，根据用户的确切使用要求以及系统的使用目的分析，医院管理住院系统在安全性方面有着很高的要求。因此医院管理住院系统对系统安全性要求尤为严格。
为了保证管理员可以登录本系统进行具体的操作，设立了登录信息界面，在账号与密码相匹配的情况下才可以进入系统进行实质的操作。
3.2.3 系统设计需求
为了达到标准、规范等目标，从而提高软件的复用率，在进行系统设计时，需做到如下。
1. 底层数据统一。对于底层数据采用标准的数据进行设置，对底部对于不符合规范的数据及时进行数据清洗和规范化操作，使得不同的数据资源统一在统一的数据格式之下，达到方便查询存储的效果。
2.界面风格的统一。采用统一的主题模式，不同页面会有不同的应用需求，其界面主题保持基本一致，促进组织采用树形结构，方便数据的浏览和查询。
3.数据服务化。系统中各功能模块既独立，又相互关联，在模块化的同时保证各个功能合理配置。同时预留开放接口，能够适应系统的扩展需求。
3.2.4 系统其它需求
考虑到网络环境及系统运行使用的需要，一般而言，系统表现出来的其他需求主要有：一是对各类浏览器友好、兼容性强。二是系统的适应性强。
另外，为了更好的用户体验，还应该满足以下条件：
1.可靠性需求：用户在使用该系统时，系统无法访问的概率应在5%以下。
2.易用性需求：本系统展示给用户的界面应该是友好的且易用的，用户在没有接受培训的情况下也可以使用本系统。
3.运行环境约束：由于本系统是B/S架构的Web应用程序，因此要求安装有浏览器的用户才能使用。[1]
3.3 系统的可行性分析
用户的要求和系统调研是进行系统可行性分析的基础，对将要开发的系统从经济、技术、运行等方面进行全面分析，并得出系统的开发工作能否可行，最后完成可行性分析。
1、经济可行性
经济预算是系统开发的前提工作中非常重要的部分，以本系统为例，在投入运营之前，本项目始终处于投资阶段，但投资并不大，整个项目的开发都独自完成。与此同时，当今计算机普及率较高，人们的技术水平也较高，如果本系统能够投入实际的使用，则所需的相关准备和培训人员的费用相对较少，但在它投入使用后，将节省大量的人力物力，使原来从事这方面工作的人员可以投入到更为实际的工作中去，提高管理部门的工作效率。所以综上所述，本系统的开发在经济方面是比较可行的。
2、技术可行性
技术可行性分析其主旨就是确保能够充分利用现有的技术条件，契合开发者的实际需求完成软硬件的开发及配置工作，明确技术人员专业能力等客观因素。网络技术的优势主要体现在：可靠的准确度；较快的传输速度。总之在科学技术飞速发展的今天，有利的推进了系统的发展。就技术层而言，本系统具有较高的可行性。
3、操作可行性
当今人们对计算机的操作已愈加成熟，对电脑的操作有一定基础，且本系统的操作性不算太复杂，通过简单的键盘输入以及鼠标点击即可完成相应的任务，简单培训以后立马上手，而且本系统可视性非常好，即本系统在操作上不会有太大难度。
4、时间可行性
从时间上看，在四年时间内学习了大量关于这方面的知识，尽管只是有些遗忘，而且需要在两个月内开发成此系统，但是通过查询相关知识，联系起以前学习的知识，通过这段时间的努力一定可以实现。
5、法律可行性
① 所有技术资料都为合法。
② 在开发过程中，完全不存在任何关于知识产权的问题。
③ 不侵犯版权，没有抄袭任何系统。
④ 在开发过程中，完全不涉及任何的法律问题，不会担负任何的法律责任。
根据以上分析，本系统在各个方面都是可以执行实现的。[15]
3.4 本章小结
本章主要介绍了系统的需求分析，其中主要包括两个方面：功能性需求分析和非功能性需求分析，并且还对可行性分析做了深入的研究。
第四章 系统总体设计
4.1 系统设计原则
在进行系统软件的设计中，要遵循一些原则和规范，这样才能规范设计流程，便于进行开发。本系统遵循着以下设计原则：
(1)良好的适用性。开发系统的目的是为用户服务的。也就是说我们所设计的软件需要满足用户的需求。因此本文的设计遵循的是用户需求优先的原则。
(2)结构稳定性。开发设计进行之前，需要设计系统的整体结构。一旦确定了体系的结构，这些设计便能流程化的进行。因此，维持一个稳定的结构才能保证后续一系列的工作的进行。
(3)可扩展性。衡量一个系统的好坏需要评估这个系统的可扩展性。如果软件只能实现现有的功能，对其他功能的添加有封闭性，当用户提出新的需求，只能重新设计，这显然是不合理的。因为良好的可扩展性无论对用户还是开发人员而言都是有益的。
(4)复用性。在一个系统中，有很多的模块内容是比较成熟，因此很多类似的工作就可以通过复用来实现，这样不仅提高了效率，而且可靠性也大大提高。
- 易维护性。系统的维护往往是最耗费精力和金钱的。因此设计出易维护的系统能够使维护人员能够快速查找出问题，能让系统具备自维护的特点是很有必要的。[11]
4.2 系统框架
系统采用MVC设计模式。从数据层、视图层、控制层、逻辑层这几个方面进行的。以下将对各个层面的设计进行描述。
一、信息系统视图层的设计
系统采用B/S开发，这样就可以节约一部分的成本，因为使用这个模式可以减少C/S这个模式的时候进行的安装和升级。通过信息系统的表示层中大量的选项选择可以帮助降低用户数据的输入量，而且还可以减少相应的培训者在培训过程中和操作过程中与软件之间的磨合时间，是其可以更快的熟悉系统的工作，并将系统的作用得到最大程度的发挥。
二、控制层与逻辑层的设计
在信息系统的开发中，逻辑层需尊重不同用户的不同的需求，而且还要考虑不同层次间的关系。向下依赖是逻辑层的主要设计方式，这样的设计方式不但减少了上下层间信息访问的影响程度，也充分利用了软件开发时向下依赖的设计方法，也利用了其本身的耦合程度。而且，系统在进行进一步的开发和研究时不会在原来的基础上做改变，所以，这是一种具有代表性的可抽取式软件结构。
三、设计信息系统数据层
MVC模型对于数据的处理是属于比较灵活，因为此模型不会依赖控制部件与视图部件的辅助，这样的数据处理方式就更加有利于更新和优化信息系统，使信息系统的工作效率提升到一个新的层次。对于数据库来说，访问层在数据库的工作过程中起到一个很好的稳定数据的作用，因为访问层可以根据用户的各种不同的需求进行不同程度的改进和适应，从而保证数据库的稳定。MVC的模型设计可以与三层的模式之间做到无缝兼容，而且MVC模型的应用还保证了层次和模块之间不会产生较强的依赖性。而且MVC模型中的模型部可以对用户信息以及软件系统的各个数据进行封装，加强了数据的高处理效率和增强了系统的可操作性[8]。
4.3 数据库的分析与设计
数据库简单的说其实就是长期存储的相关数据的集合，但它又不仅是局限于
对信息的存储，通过建立数据库，我们可以对数据更好的管理、存储以及查询，而且更为重要的是，我们还可以实现共享数据。数据库中的数据结构表明了具体事务之间的关系。而描述实体类型和实体之间关系的则称之为数据库模型，数据库系统主要包含四种数据模型它们分别是：层次模型、关系模型、网状模型和面向对象模型。所有的数据库系统都有它特有的数据模型。在本系统中，经过对系统数据库的功能特点以及对需求的分析，最终选择关系模型作为本系统的数据模型。[12]
4.3.1 数据库的概念结构设计
概念设计是进行系统设计的一个十分重要的阶段，概念设计主要完成的任务是在深入、详细了解系统的功能以后建立整个系统的概念模型和概念结构，然后将概念模型转换成图形的形式，一般来说，描绘概念模型的方法各式各样，比较常用的图形有ER图、类图等等，这里针对医院管理住院系统进行ER图（实体-联系图）来对整个系统进行展示。
4.3.2 E-R图
E-R 图能够很直观地表示出概念模型。E-R 图之间联系的种类主要有三种情况，分别为一对一(1:1)、一对多(1:N)和多对多(N:M)。
ER图（实体-联系图）由以下几个固定图形所构成：
实体形-矩形表示，矩形内为实体名称。
属性-椭圆形或圆角矩形来表示，主属性的下面要相应的添加下划线。
联系-菱形表示，菱形内部为联系的内容。
通过对医院管理住院系统的认真分析后，确定了以下六个实体，并标注了其各自的属性（一个实体可能有多个属性）：
医生： (编号、姓名、性别、职称、职务、科别、出生日期、工作日期)
图4-1 医生E-R图
病床： （科别、病床号、床位费、使用状态）
图4-2 病床E-R图
病人： （科别、病床号、姓名、性别、年龄、病症、主治医生、入院日期、出院日期）
图4-3 病人E-R图
收费信息： （科别、病床号、病人姓名、收费项目、单价、数量、金额、日期）
图4-4 收费E-R图
4.3.3 数据库的实现
数据库在物理设备上的存储结构与存取方法被称为数据库的物理结构，它依赖与给定的计算机系统。为一个给定的逻辑数据模型选取一个最合适应用要求的物理结构。根据上面的实体关系分析以及ER图，设计医院管理住院系统的数据库表。
- 医生信息表
表4-1 医生信息表
| 主键 | 字段名称 | 数据类型 | 长度（字节） |
| * | 编号 | varchar | 50 |
| 姓名 | varchar | 50 | |
| 性别 | varchar | 50 | |
| 职称 | varchar | 50 | |
| 职务 | varchar | 50 | |
| 科别 | varchar | 50 | |
| 出生日期 | varchar | 50 | |
| 工作日期 | varchar | 50 |
2. 病人信息表
表4-2 病人信息表
| 主键 | 字段名称 | 数据类型 | 长度（字节） |
| * | 科别 | varchar | 50 |
| 病床号 | varchar | 50 | |
| 姓名 | varchar | 50 |
表4-2 （续）
| 性别 | varchar | 50 | |
| 年龄 | varchar | 50 | |
| 病症 | varchar | 50 | |
| 主治医师 | varchar | 50 | |
| 入院日期 | varchar | 50 | |
| 出院日期 | varchar | 50 |
3. 病床信息表
表4-3 病床信息表
| 主键 | 字段名称 | 数据类型 | 长度（字节） |
| * | 科别 | varchar | 50 |
| 病床号 | varchar | 50 | |
| 床位费 | varchar | 50 | |
| 使用状态 | varchar | 50 |
4. 收费信息表
表4-4 收费信息表
| 主键 | 字段名称 | 数据类型 | 长度（字节） |
| * | 科别 | varchar | 50 |
| 病床号 | varchar | 50 | |
| 姓名 | varchar | 50 | |
| 收费项目 | varchar | 50 | |
| 单价 | varchar | 50 | |
| 数量 | varchar | 50 | |
| 金额 | varchar | 50 | |
| 日期 | varchar | 50 |
5. 管理员信息表
表4-5 管理员信息表
| 主键 | 字段名称 | 数据类型 | 长度（字节） |
| * | 管理员姓名 | varchar | 50 |
| 密码 | varchar | 50 |
4.3.4 数据库的连接原理
医院管理住院系统数据库连接也是开发该系统的关键环节，主要采用JDBC方式，这些知识在太原理工大学开设的JSP课程中有所学习，具体的操作步骤如图4-6所示：
图4-6 数据库连接具体操作
医院管理住院系统连接数据库的程序采用DAO（数据访问对象）模式来对数据库进行处理操作，其思想如图4-7所示:
图4-7 DAO模式类图
4.4 系统软件结构设计
4.4.1 数据流程图
数据流程图由四部分构成，它们分别是外部实体、数据处理、数据存储和数据流。
根据上一章对原有医院管理住院系统流程图的描述，我们从系统的多个方面进行了分析，希望使系统的管理更加合理，在使用中更具有可行性，并且利用模块化的分析办法，由顶层开始向下对医院管理住院系统逐步分层，逐步细化。我们将系统分为顶层、零层两层，下面就层与层之间的关系（系统关联）和每层的功能详细介绍。[9]
4.4.2 系统顶层图
顶层数据流图，即描述医院管理住院系统的作用范围，故其顶层图如图4-8所示：
图4-8 系统顶层图
4.4.3 系统零层图
将整个系统分为医生信息管理模块、病人信息管理模块、病床管理模块等几个大的模块作为系统的零层。各个模块可以单独运行完成它们的功能，各个模块之间又可以相互调用数据，进而完成数据的综合存储，最终共同协作，从而完成系统的预期功能。医院管理住院系统如图4-9所示 ：
图4-9 系统零层图
4.5 数据字典
数据字典是对数据流程图中包含的所有元素的定义的集合，存储了系统所有的数据信息。系统逻辑模型是由数据流程图和数据字典共同构成的，数据流图是动态描述，但数据字典是静态描述。数据字典能够更细致的说明和补充数据流程图的逻辑内容，并且能够供人查阅。数据元素、数据流、数据存储以及处理过程等部分组成了数据字典。[13]
- 数据流
数据流名称：用户登录信息
别名：无
简述：用户登录时填写的信息
来源：用户
去向：用户登录
数据流量：50份/天
组成：用户名+密码
数据流名称：医生信息
别名：无
简述：查看、修改和删除医生信息时显示或填写的信息
来源：医生或医生信息的修改、查询和删除
去向：医生信息的修改、查询和删除
数据流量：30份/天
组成：用户名+密码
数据流名称：病人信息
别名：无
简述：查看、修改和删除病人信息时显示或填写的信息
来源：病人信息的修改、查询和删除
去向：病人信息的修改、查询和删除
数据流量：30份/天
组成：用户名+密码
数据流名称：收费信息
别名：无
简述：查看、修改和删除收费信息时显示或填写的信息
来源：收费信息的修改、查询和删除
去向：收费信息的修改、查询和删除
数据流量：30份/天
组成：用户名+密码
（2）数据流分量
名称：用户名
别名：无
描述：用户信息中惟一标识某一用户的关键域
位置：用户信息表
用户登录信息
名称：密码
别名：无
描述：对用户登录进行验证的关键域
位置：用户信息表
用户登录信息
名称：病人
别名：无
描述：病人信息中惟一标识某一病人的关键域
位置：病人信息表
病人一般信息
名称：医生
别名：无
描述：医生信息中惟一标识某一医生的关键域
位置：医生信息表
医生一般信息
名称：病床
别名：无
描述：病床信息中惟一标识某一病床的关键域
位置：病床信息表
病床信息
名称：收费
别名：无
描述：收费信息中惟一标识某一收费情况的关键域
位置：收费信息表
收费一般情况
（3）数据存储
数据存储的名称: 数据库信息
简述: 存放的病人信息、医生信息、病床信息、收费信息等
数据存储的组成: 各类信息
关键字: 编号
相关联的处理: P1（对信息表进行录入）
P2（对信息表进行查询）
P3（对信息表进行修改删除)
（4）处理
处理逻辑编号: P03-01
处理逻辑名称: 信息录入
简述: 对基本信息进行录入.
输入的数据流:管理员
处理过程: 进行分类录入
输出的数据流: 各类数据表
处理逻辑编号: P03-02
处理逻辑名称: 查询各类信息
简述: 根据条件查询所需的信息.
输入的数据流:信息来源于数据库
处理过程: 输入查询条件查询,得到符合条件的信息
输出的数据流: 查询得到的信息
处理逻辑编号: P03-03
处理逻辑名称: 修改、删除信息
简述: 对信息做需要的修改后存入数据库中.
输入的数据流:数据库信息
处理过程: 对需要修改的信息做修改
输出的数据流: 修改或删除后得到的信息
4.6 本章小结
本章主要介绍了系统的总体设计，首先提出了系统设计的原则，然后分别从数据库的总体和设计、系统软件的结构设计以及数据字典三个方面对系统的设计展开了描述。
第五章 系统详细设计与实现
5.1 程序流程图
本文采用的是自顶向下的分层模块设计方法，由于医院住院管理系统分为：医生信息管理、病人信息管理、病床信息管理、收费信息管理、统计分析和系统管理等功能，我们在设计过程中按其功能把它分成不同的模块。
医院管理住院系统的主模块如图所示：
图5-1 程序流程图
5.2 系统登录
用户可以在登录页面上登陆。界面如下所示：
图5-2 系统登录图
5.3 系统主界面
用户登录系统后可以看到系统主界面。
图5-3 系统总界面图
5.4 医生信息管理
进入医院信息管理中后，可以查看医生的编号、姓名、性别、职称、职务、科别、出生日期和工作日期，可以通过对医生姓名的搜索进行医生信息的查询，还可以对医生的信息进行添加、修改和删除。
图5-4 医生信息管理图
5.5 病床管理
进入病床信息管理后，可以查看病床的科别、病床号、床位费和使用状态，还可以对病床的信息进行添加、修改和删除。
图5-7 病床信息管理图
5.6 病人信息管理
进入病人信息管理后，可以查看病人的科别、病床号、病人姓名、病人年龄、病症、主治医生、入院日期和出院日期，还可以通过对病人姓名的搜索来查看病人的信息，也可以对病人的信息进行添加修改和删除。
5.7 收费管理
进入收费信息管理后，可以查看病人的科别、病床号、病人姓名、收费项目、单价、数量、金额和日期，还可以通过对病人姓名的搜索，来对信息进行查询，也可以对收费信息进行添加、修改和删除。
第六章 系统测试
系统测试，即是一种为了保证程序的正确性而进行的过程，其主要意义是为了发现错误并改正错误。在这样的定义下软件测试有以下的目的：首先，软件测试是实际上是程序的执行一个过程，这样一个过程的目的在于发现系统中目前尚未发现的错误，而不是证明这段程序的正确而进行的过程。其次，在这样的一个目的下，一个好的系统测试用例是帮助程序员发现系统中隐藏的错误和不易发现的错误。总之，我们进行软件测试要以发现错位为目的进行，而不能以证明这段程序写的对而进行，只要我们发现了一个错误，我们这个测试用例就是一个好的测试用例。由上面测试的定义与目的总结出测试有一下几点原则：1.在系统的开发过程中应当尽早地和不断地进行相应部分的软件测试。 2.在测试中一个测试用例应由测试输入数据和与之对应的测试预期输出结果这两部分构成。 3.在设计一个测试用例时，这个测试用例应当包括合理的输入条件以及不合理的输入条件。 4.测试应该严格执行相应的测试计划，排除测试的随意性。 5.测试结束时，应当认真保存测试计划、测试用例和测试报告，方便程序员本人和其他程序员进行后期维护。[8]
6.1 系统测试目标
医院住院管理系统最终应完成的测试目标：本文应着重于系统的功能测试，测试的对象则是病人和医生，在实现了预定的系统功能及满足用户需求的前提条件下，尽可能地发现并完善系统中的漏洞与隐患，确保软件的实用性、安全性、可靠性、可扩展性以及经济性，为今后的医院住院提供更便捷的方式。[10]
6.2 测试设计
6.2.1 测试用例设计
测试用例的设计使用错误推测法、边界值法和等价类划分法等方法。
6.2.2 测试环境与需求
测试软件环境：PC 机操作系统：Windows 7；数据库管理系统： Microsoft SQL Server 2005；Microsoft Visual Studio
测试需求：对系统进行测试采用黑盒测试法，力求找出程序员在逻辑上，功能实现上的的问题，并且验证该程序输出结果是否正常，是否能对错误输入做出正常的响应。
6.3 测试用例及测试模块
6.3.1 测试用例
注：测试用例的设计只针对病人信息管理功能子模块
表6-1 测试用例表1
| 测试用例ID | TC0001 | ||
| 测设用例名称 | 增加相同科别病床号病人的信息 | ||
| 产品名称 | 医院管理住院系统 | 产品版本 | version 1.0 |
| 功能模块 | 增加病人信息模块 | 测试平台 | 所有 |
| 用例入库时间 | 2017.5.1 | 用例更新时间 | 2017.5.1 |
| 测试功能点 | 输入相同的科别病床号 | ||
| 测试目的 | 禁止添加相同科别病床号的病人信息 | ||
| 测试级别 | 详细功能测试 | ||
| 测试类型 | 单元测试 | ||
| 预置条件 | 数据库中已经有放射科科别为1病人的完整信息 | ||
| 测试步骤 |
2.按“添加”按钮 | ||
| 预期结果 | 系统拒绝添加 | ||
| 测试结果 | 系统无法添加放射科病床号为1的病人信息 | ||
表6-2测试用例表2
| 测试用例ID | TC0002 | ||
| 测设用例名称 | 成功修改病人信息 | ||
| 产品名称 | 医院管理住院系统 | 产品版本 | version 1.0 |
| 功能模块 | 修改病人信息模块 | 测试平台 | 所有 |
| 用例入库时间 | 2017.5.1 | 用例更新时间 | 2017.5.1 |
| 测试功能点 | 先查询要修改的病人信息，然后进行修改 | ||
| 测试目的 | 成功修改病人信息 | ||
| 测试级别 | 详细功能测试 | ||
| 测试类型 | 单元测试 | ||
| 预置条件 | 数据库中有相应的要修改的病人信息 | ||
| 测试步骤 | 1.输入科别+姓名或者病床，查询到要修改的病人信息 2.点击“修改”按钮，对要修改的病人信息进行修改 | ||
| 预期结果 | 病人信息修改成功 | ||
| 测试结果 | 系统可以成功对病人信息进行修改并保存 | ||
表6-3 测试用例表3
| 测试用例ID | TC0003 | ||
| 测设用例名称 | 成功删除病人信息 | ||
| 产品名称 | 医院管理住院系统 | 产品版本 | version 1.0 |
| 功能模块 | 删除病人信息模块 | 测试平台 | 所有 |
| 用例入库时间 | 2017.5.1 | 用例更新时间 | 2017.5.1 |
| 测试功能点 | 先查询要修改的病人信息，然后进行删除 | ||
| 测试目的 | 成功删除病人信息 | ||
| 测试级别 | 详细功能测试 | ||
| 测试类型 | 单元测试 | ||
| 预置条件 | 数据库中有相应的要删除的病人信息 | ||
| 测试步骤 | 1.输入科别+姓名或者病床，查询到要删除的病人信息 2.点击“删除”按钮，删除相应的病人信息 | ||
| 预期结果 | 相应病人信息被删除 | ||
| 测试结果 | 系统可以成功删除所要删除的病人的信息 | ||
注：测试用例的设计只针对医生信息管理功能子模块
表6-4 测试用例表4
| 测试用例ID | TC0004 | ||
| 测设用例名称 | 增加相同科别编号医生的信息 | ||
| 产品名称 | 医院管理住院系统 | 产品版本 | version 1.0 |
| 功能模块 | 增加医生信息模块 | 测试平台 | 所有 |
| 用例入库时间 | 2017.5.1 | 用例更新时间 | 2017.5.1 |
| 测试功能点 | 输入相同的科别编号 | ||
| 测试目的 | 禁止添加相同科别编号的医生信息 | ||
| 测试级别 | 详细功能测试 | ||
| 测试类型 | 单元测试 | ||
| 预置条件 | 数据库中已经有放射科编号为1医生的完整信息 | ||
| 测试步骤 | 1.输入相应的信息，科别为放射科编号为1医生的完整的信息 2.按“添加”按钮 | ||
| 预期结果 | 系统拒绝添加 | ||
| 测试结果 | 系统无法添加放射科编号为1的医生的信息 | ||
表6-5 测试用例表5
| 测试用例ID | TC0005 | ||
| 测设用例名称 | 成功修改医生信息 | ||
| 产品名称 | 医院管理住院系统 | 产品版本 | version 1.0 |
| 功能模块 | 修改医生信息模块 | 测试平台 | 所有 |
| 用例入库时间 | 2017.5.1 | 用例更新时间 | 2017.5.1 |
| 测试功能点 | 先查询要修改的医生信息，然后进行修改 | ||
| 测试目的 | 成功修改医生信息 | ||
表6-5 测试用例表5(续）
| 测试级别 | 详细功能测试 |
| 测试类型 | 单元测试 |
| 预置条件 | 数据库中有相应的要修改的病人信息 |
| 测试步骤 | 1.输入科别+姓名或者病床，查询到要修改的医生信息 2.点击“修改”按钮，对要修改的医生信息进行修改 |
| 预期结果 | 医生信息修改成功 |
| 测试结果 | 系统可以成功修改医生的信息，并对其进行保存 |
表6-6 测试用例表6
| 测试用例ID | TC0006 | ||
| 测设用例名称 | 成功删除医生信息 | ||
| 产品名称 | 医院管理住院系统 | 产品版本 | version 1.0 |
| 功能模块 | 删除医生信息模块 | 测试平台 | 所有 |
| 用例入库时间 | 2017.5.1 | 用例更新时间 | 2017.5.1 |
| 测试功能点 | 先查询要修改的医生信息，然后进行删除 | ||
| 测试目的 | 成功删除医生信息 | ||
| 测试级别 | 详细功能测试 | ||
| 测试类型 | 单元测试 | ||
| 预置条件 | 数据库中有相应的要删除的医生信息 | ||
| 测试步骤 | 1.输入科别+姓名或者编号，查询到要删除的医生信息 2.点击“删除”按钮，删除相应的医生信息 | ||
| 预期结果 | 相应医生信息被删除 | ||
| 测试结果 | 系统可以成功删除医生的信息 | ||
6.3.2 测试模块及案例
注：此处有效等价类以当前创建表为标准，即我个人电脑中数据库中的内容。
（1） 数据库中病人信息表中的信息为：
图6-1 数据库病人信息图
（2）查询病人信息的测试
表6-7 病人信息测试表
| 输入数据 | 有效等价类 | 无效等价类 |
| 姓名 | (1)汉字（上表中的数据） | (2)字母 (3)数字 (4)除表中以外的汉字 (5)空 |
| 用例编号 | 依次输入 | 期望结果 | 覆盖 | 实际结果 |
| 1 | 张三 | 通过验证，显示病人信息 | 1 | 查询成功 |
| 2 | ZHANGSAN | 不通过验证 | 2 | 查询失败 |
| 3 | 数字 | 不通过验证 | 3 | 查询失败 |
| 4 | 张强 | 不通过验证 | 4 | 查询失败 |
| 5 | 不通过验证 | 5 | 查询失败 |
注：此处有效等价类以当前创建表为标准，即我个人电脑中数据库中的内容。
（1） 数据库中医生信息表中的信息为：
图6-2 数据库医生信息图
、（2）查询医生信息的测试
表6-8 医生信息测试表
| 输入数据 | 有效等价类 | 无效等价类 |
| 姓名 | (1)汉字（上表中的数据） | (2)字母 (3)数字 (4)除表中以外的汉字 (5)空 |
| 用例编号 | 依次输入 | 期望结果 | 覆盖 | 实际结果 |
| 1 | 李四 | 通过验证，显示医生信息 | 1 | 查询成功 |
| 2 | LISI | 不通过验证 | 2 | 查询失败 |
| 3 | 数字 | 不通过验证 | 3 | 查询失败 |
| 4 | 张强 | 不通过验证 | 4 | 查询失败 |
| 5 | 不通过验证 | 5 | 查询失败 |
6.3.3 系统性能测试
功能测试是为了某种的最基本需求，性能测试的目的是保证系统正常运转的关键一环。如表6-9所示：
表6-9 性能测试表
| 测试内容 | 测试要求 | 测试结论 |
| 对用户界面的控件以及数据接口的正确性进行测试 | 能不能使客户满意 | 通过 |
| 测试设计的界面是不是受到人们的喜爱 | 突出信息，设计新颖、风格一致 | 通过 |
| 测试系统操作是否简单 | 使客户使用起来比较方便 | 通过 |
| 对网络的安全性进行测试 | 在这个系统中安全软件能不能正常运转，这个系统能不能对不良信息进行过滤，防止不好的软件窃取它的信息。 | 通过 |
| 测试数据安全性 | 系统的数据要做到加密，外来的用户不能够进入这个系统获取这些数据。 | 通过 |
| 性能测试压力测试 | 能够协助人们进行办公。 | 通过 |
| 并发测试 | 当系统增加用户的时候，系统会产生什么样的反应，会不会出现卡顿的情况。 | 通过 |
| 稳定性测试测试系统的稳定性 | 长时间处在运行的状态下，系统能不能保证一直处在一种比较好的运行状态。 | 通过 |
| 测试系统的可靠性 | 当进入这个系统的人过多时，这个系统能不能正常运行。 | 通过 |
| 兼容性测试测试 | 这个系统能不能在不同的环境、操作系统以及浏览器上能不能正常工作。 | 通过 |
| 功能性测试 | 系统上的功能能不能满足医院需要的所有的功能。 | 通过 |
6.4 缺陷分析
经过测试，该程序中没有严重影响系统运行的错误，没有功能缺陷，也没有不影响运行但必须修改的错误。
测试模块都具有较好的交互性，出现错误可以提示用户哪里出错，使用户可以及时修改。
6.5 测试结果
从最终整体的实际运行效果来看，医院管理住院系统在实际的运行中达到了我们的最初设计目标，可以实现所有原先所预期得功能，满足了用户的需求。并且系统操作起来非常简单，十分易于管理，管理人员可以很容易掌握，再加上系统具有很高的安全性、可靠性和扩展性，完全能够达到医院所要求的各项指标，有效的提高了医院的工作效率和管理水平。
6.6 本章小结
本章主要介绍了系统测试方面的内容，并且通过测试进行了缺陷分析，并且得出了测试结果。
