K.1 引言

K.1.1  编写目的

为了更好的满足广大消费者的多元化消费需求和不同层次的消费水平，提高酒店的服务管理质量，提高酒店工作人员的工作效率，我开发小组在多方面考察、分析、研究现有酒店点菜管理系统的基础之上，以提高消费者的满意程度及商家的服务水平和市场竞争力为目标，致力于开发出一套可视化程度高、功能全面、集分析管理于一体的酒店管理系统，极具有市场价值。 

本文档详细介绍了医院住院管理信息系统的需求说明，为用户和领导描述出一个具体的产品模型，为软件设计、开发及测试人员提供下步工作的依据。 

编写本文档的目的主要是为了给小组成员、用户描述出一个具体的产品模型，为软件设计、开发及测试人员提供下步工作的依据。,本测试说明书主要是提交给用户和小组成员参考,以便最终实现用户的要求,给用户一份满意的答卷。

K.1.2  背景

a、饭店点餐管理系统

b、随着我国市场经济的不断发展，国民生活水平的不断提高，进入饭店等高等消费场所的人数也与日俱增。传统的手工点菜方式由于其难计算、难查找、难更改、易出错、效率低等缺点已逐渐退出了酒店等高等消费场所的服务管理平台。层出不穷的各类酒店点菜管理系统也应运而生，呈现出多元化的发展。 

目前，我国饭店餐饮业在日常点菜管理中仍普遍采用手工操作方式，整体科技含量

低，随着饭店餐饮业高速发展和餐饮店规模的不断扩大，许多饭店餐饮企业采用连锁经经营和集团化运营，手工操作无论是在工作效率、人力成本和决策信息等方面都已经难以适应企业发展的要求，制约了整个饭店餐饮业的规模化发展和整体服务水平的提升，如向阳渔港、张生记等. 在中国饭店协会颁布的中国餐饮业产业贡献奖和学术贡献奖中，联想集团、神州数码、清华同方及中国网通等国内知名IT企业也榜上有名，这些IT企业都已瞄准了饭店餐饮业信息技术应用市场的巨大潜力。据预测，未来3至5年内，信息数字技术产品在中国饭店与餐饮业的应用将达到一个高峰，市场最大容量可达2300亿元人民币。就点菜系统而言，最普遍的是计算机收银台录入菜单设备、POS点菜系统，除了这种点菜系统，其它的计算机信息系统已经从预订、接待、点菜、菜品上传、厨房分单打印、条码划菜、收银、经理查询等方面在大型餐饮企业全方位地整合起来了。 

本文主要介绍了“饭店点菜管理系统”的编码测试过程。该系统主要功能包括以下几个模块:系统登录模块、菜单管理模块、顾客点餐管理模块、后厨管理等模块等。该测试时说明书主要从顾客点餐管理模块和后厨管理模块出发，体现了清晰的点菜系统管理流程,完成了基本的饭店点餐管理要求，是一个典型的信息管理系统。该系统大大地简化了操作流程，提高了饭店的工作效率。

K.1.3  定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

K.1.4  参考资料

《实用软件工程》，郑人杰等著，清华大学出版社； 

《软件工程》第二版，李代平等著，清华大学出版社； 

《软件工程第六版》，Roger S．Pressman著，机械工业出版社； 

《软件工程课程实验指导书》，山东交通学院计算机科学与工程系；  

《数据库系统概论》（第四版）,萨师煊 著, 高等教育出版社； 

《软件工程导论》（第五版）,张海藩 著，清华大学出版社

K.2 计划

K.2.1  软件说明

模块功能测试：测试各个模块功能是否符合要求。

组装测试：测试各个模块之间的接口和联系是否正确

运行时间测试：测试软件运行时间是否符合要求

数据存储测试：测试软件和数据库之间的联系

K.2.3 制菜智能统筹

给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境、培训、准备输入数据等）。

测试日期：程序完成后第二天立刻进行

工作内容：

操作简单容易上手，几乎不需要培训。

准备一份详细的真实菜单和相应的配菜信息录入数据库

录入桌号信息表

分配测试角色：顾客、厨师和学徒的角色安排

K.2.3.2  条件

a)设备：5台及以上安卓机或者IOS机，至少两台Pad以及一台PC机使用时间至测试结束

b)软件：单元测试工具Nanit、功能测试工具WinRunner、性能测试工具LoadRunner

c)人员：要求能够操作上述电子设备，具备一定的测试知识

K.2.3.3  测试用例

操作简单容易上手，几乎不需要培训。

K.2.4点菜服务

给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境、培训、准备输入数据等）。

测试日期：程序完成后第二天立刻进行

工作内容：

操作简单容易上手，几乎不需要培训。

准备一份详细的真实菜单和相应的配菜信息录入数据库

录入桌号信息表

分配测试角色：顾客、厨师和学徒的角色安排

K.2.4.2  条件

d)设备：5台及以上安卓机或者IOS机，至少两台Pad以及一台PC机使用时间至测试结束

e)软件：单元测试工具Nanit、功能测试工具WinRunner、性能测试工具LoadRunner

f)人员：要求能够操作上述电子设备，具备一定的测试知识

K.2.4.3  测试用例

操作简单容易上手，几乎不需要培训。

K.2.5 评价管理

给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境、培训、准备输入数据等）。

测试日期：程序完成后第二天立刻进行

工作内容：

操作简单容易上手，几乎不需要培训。

准备一份详细的真实菜单和相应的配菜信息录入数据库

录入桌号信息表

分配测试角色：顾客、厨师和学徒的角色安排

K.2.3.2  条件

g)设备：5台及以上安卓机或者IOS机，至少两台Pad以及一台PC机使用时间至测试结束

h)软件：单元测试工具Nanit、功能测试工具WinRunner、性能测试工具LoadRunner

i)人员：要求能够操作上述电子设备，具备一定的测试知识

K.2.3.3  测试用例

操作简单容易上手，几乎不需要培训。

K.3  评价准则

K.3.1  范围

客户端界面，弹窗提示对于设备横竖屏的处理是否合理；

是否有最大最小字符，边界值输入情况是否报错，最大最小的提示是否合理；特殊字符的输入，显示，输入框内的展示，展示页面的展示；

输入页面，对于空格字符的录入，空格在首位，末尾的处理和展示，只输入空格时的处理；输入过长时候是否有折行，显示是否合理；

输入框和展示页面，对于换行是否有合理展示和处理；

设备重启前后，应用数据不丢失，状态及策略执行情况正常；

K.3.2  数据整理

(1)、删除过时的测试用例　

因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统,这些测试用例就会过时.例如,某个变量的界限发生了改变,原来针对边界值的测试就无法完成对新边界测试.所以,在软件的每次修改后都应进行相应的过时测试用例的删除.

(2)、改进不受控制的测试用例

随着软件项目的进展,测试用例库中的用例会不断增加,其中会出现一些对输入或运行状态十分敏感的测试用例.这些测试不容易重复且结果难以控制,会影响回归测试的效率,需要进行改进,使其达到可重复和可控制的要求.

(3)、删除冗余的测试用例

如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试,那么这些测试用例是冗余的.冗余测试用例的存在降低了回归测试的效率.所以需要定期的整理测试用例库,并将冗余的用例删除掉.

(4)、增添新的测试用例

如果某个程序段、构件或关键的接口在现有的测试中没有被测试,那么应该开发新测试用例重新对其进行测试.并将新开发的测试用例合并到基线测试包中. 

K.3.3  尺度

说明用来判断测试工作是否能通过的评价尺度，如合理的输出结果的类型、测试输出结果与预期输出之间的容许偏离范围，允许中断或停机的最大次数。下载本文