本科毕业设计论文饭店点菜系统测试计划.docx
《本科毕业设计论文饭店点菜系统测试计划.docx》由会员分享，可在线阅读，更多相关《本科毕业设计论文饭店点菜系统测试计划.docx（22页珍藏版）》请在冰点文库上搜索。
本科毕业设计论文饭店点菜系统测试计划
软件工程测试计划文档
饭店点餐管理系统的分析与设计
学院名称
信电工程学院
专业名称
计算机科学与技术
所属学期
2015-2016
（一）
小组名单
班级
学号
姓名
任课教师
2015年12月24日
目录
K.1引言2
K.1.1编写目的2
K.1.2背景2
K.1.3定义3
K.1.4参考资料3
K.2计划4
K.2.1软件说明4
K.2.2测试内容5
K.2.3制菜智能统筹5
测试项目：
菜品提示功能5
测试项目：
制菜的统筹功能7
测试项目：
无食材提示8
测试项目：
新菜录入9
测试项目：
评分机制9
K.2.4点菜服务13
测试项目：
桌号录入13
测试项目：
点菜与写备注14
测试项目：
生成点菜表与提交制菜统筹系统15
测试项目：
退菜16
测试项目：
催菜17
K.2.5评价管理19
测试项目：
判断付款状态20
测试项目：
评价添加20
测试项目：
评价删除21
测试项目：
评价查看22
K.3评价准则24
K.3.1范围24
K.3.2数据整理25
K.3.3尺度25
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.2测试内容
模块功能测试：
测试各个模块功能是否符合要求。
组装测试：
测试各个模块之间的接口和联系是否正确
运行时间测试：
测试软件运行时间是否符合要求
数据存储测试：
测试软件和数据库之间的联系
K.2.3制菜智能统筹
测试编号：
1-1-1
项目属性：
A
测试项目：
菜品提示功能
测试子项目：
识别身份分别提示
测试目的：
验证系统提示厨师和学徒的状态
测试预置条件：
厨师和学徒登录客户端并且在线，处于待机状态，喇叭，电源，网络信号正常
正确的顺序/步骤：
1）厨师端屏幕为开启状态，观察屏幕显示及声音
2）厨师端屏幕为关闭状态，观察屏幕显示及声音
3）学徒端屏幕为开启状态，观察屏幕显示及声音
4）学徒端屏幕为关闭状态，观察屏幕显示及声音
5）按下完成建时，观察界面显示同时听声音
6）数据库中没有菜品时，观察屏幕显示及声音
7）当数据库中菜品一种多份时，观察厨师屏幕菜品份数显示
8）当数据库中菜品一种多份时，观察学徒屏幕配菜份数显示
预期结果及判定原则：
1）厨师和学徒界面无论开启还是关闭皆显示正常，提示音正常
2）厨师完成键按下，提示音正常，界面显示为下一道菜菜名
3）学徒完成键按下，提示音正常，界面显示为下一道菜菜名
4）数据库无菜品时，屏幕提示没有菜品，提示音正常
5）数据库中菜品一种多份时
测试编号：
1-1-2
项目属性：
A
测试项目：
制菜的统筹功能
测试子项目：
无
测试目的：
验证统筹系统的正确性
测试预置条件：
顾客（模拟）、厨师和学徒登录客户端并且在线，处于待机状态，喇叭，电源，网络信号正常。
正确的顺序/步骤：
1）顾客（模拟）开5桌进行点菜（如果这一步骤出现错误，则转到点菜服务进行测试）
2）顾客（模拟）进行点菜，每桌点十道菜，每一桌的点菜的时间均不同
3）开启厨师端（已经测试完毕），查看菜品信息
4）开启学徒端（已经测试完毕）查看菜品信息
5）顾客（模拟）中途继续进行点菜
6）查看学徒端和厨师端的屏幕变化
预期结果及判定原则：
1）厨师和学徒界面显示的菜品顺序为正确顺序，按照点菜时间和菜品名以及桌号的逻辑进行显示
2）中途添加的点菜信息也能正确的添加到点菜信息表中
测试编号：
1-1-3
项目属性：
A
测试项目：
无食材提示
测试子项目：
后厨向顾客发送通知
测试目的：
验证后厨能否想顾客端发送提示信息
测试预置条件：
顾客（模拟）、厨师和学徒登录客户端并且在线，处于待机状态，喇叭，电源，网络信号正常，顾客已点菜
正确的顺序/步骤：
1）顾客（模拟）进行点菜（如果这一步骤出现错误，则转到点菜服务进行测试）
2）开启厨师端（已经测试完毕），查看菜品信息,并点击无食材提示
3）顾客端屏幕为关闭状态，观察顾客端的提示和声音
4）顾客端屏幕为开启状态，观察顾客端的提示和声音
5）在顾客端查看点菜信息
6）在顾客端查看菜单信息
7）在厨师端查看点菜信息
预期结果及判定原则：
1）顾客端不管屏幕的状态，可以正确及时的收到信息
2）厨师点击无食材提示之后可以从点菜信息将这道菜删去，可以将菜单中的这道菜设置为不可见的状态
测试编号：
1-1-4
项目属性：
A
测试项目：
新菜录入
测试子项目：
客户端与数据库的链接
测试目的：
验证顾客能否查询新增菜品的信息，学徒能否查询新增配菜信息
测试预置条件：
顾客（模拟）、管理员、学徒登录客户端并且在线，处于待机状态，电源，网络信号正常。
正确的顺序/步骤：
1）管理根据厨师提供的信息向系统录入新菜品的信息，录入新菜品的配菜信息
2）顾客刷新菜单，查询新菜并点菜
3）查看学徒端的信息
预期结果及判定原则：
1）顾客端可以查询得到新菜信息
2）学徒端可以查看新菜的配菜信息
测试编号：
1-1-5
项目属性：
A
测试项目：
评分机制
测试子项目：
智能排序
测试目的：
验证系统能否根据顾客的评分动态的调整菜单信息
测试预置条件：
顾客（模拟）登录客户端并且在线，处于待机状态，电源，网络信号正常。
正确的顺序/步骤：
1）顾客（模拟）进入评分界面，录入分数
2）一周（模拟）后计算平均分，并智能排序
预期结果及判定原则：
1）顾客端可以录入分数到数据库
2）系统可以计算平均分
3）系统可以根据评分对菜品进行排序
K.2.3.1进度安排
给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境、培训、准备输入数据等）。
测试日期：
程序完成后第二天立刻进行
工作内容：
操作简单容易上手，几乎不需要培训。
准备一份详细的真实菜单和相应的配菜信息录入数据库
录入桌号信息表
分配测试角色：
顾客、厨师和学徒的角色安排
K.2.3.2条件
a）设备：
5台及以上安卓机或者IOS机，至少两台Pad以及一台PC机使用时间至测试结束
b）软件：
单元测试工具Nanit、功能测试工具WinRunner、性能测试工具LoadRunner
c）人员：
要求能够操作上述电子设备，具备一定的测试知识
K.2.3.3测试用例
测试项
输入用例
是否有效等价类
预期结果
菜品提示
完成按钮按下
是
顾客、服务员收到提示
制菜的统筹功能
点菜信息
是
后厨能看到正确的制菜顺序
无食材提示
无食材按钮按下
是
顾客收到提示，点菜信息中菜品被删除、菜单中菜品被置为不可见
菜名录入
干豆角烧肉
是
菜单中显示干豆角烧肉
干豆角烧肉@#
否
提示有非法字符
干豆角烧肉123456
否
提示菜名长度过长
干豆角烧肉12345@
否
提示菜名长度过长
菜价录入
30.0
是
菜单中显示价格
-1
否
提示价格不能为负数
Hah
否
提示菜价只能是正数
菜类别的录入
1
是
菜单中显示菜的种类
制作时间录入
15
是
菜单中可以查看制作时间
15.5
否
提示制作时间不可为小数
-1
否
提示制作时间不可为负数
Hihf
否
提示制作时间只可以是正整数
配菜名称录入
猪肉
是
配菜表中可以查看
猪肉123456789
否
提示名称过长
猪肉%￥#
否
提示有非法字符
猪肉%23456789
否
提示名称过长
配菜质量的录入
500
是
配菜表中可以查看
-1
否
提示质量不能为负数
Ahfu
否
提示质量只能是正数
评分录入
4
是
将分数写入到数据库
-1
否
提示分数不能为负数
6
否
分数必须小于5
4.5
否
分数必须为正整数
5.1
否
分数必须小于5
K.2.3.4测试培训
操作简单容易上手，几乎不需要培训。
K.2.4点菜服务
测试编号：
2-1-1
项目属性：
A
测试项目：
桌号录入
测试子项目：
数据库表遍历
测试目的：
验证能否成功开桌
测试预置条件：
顾客、管理员打开客户端并且在线，处于待机状态，喇叭，电源，网络信号正常
正确的顺序/步骤：
1）顾客录入所在桌号
2）观察顾客屏幕提示
3）观察管理员屏幕提示
4）查看数据库状态
预期结果及判定原则：
1）提示顾客开桌成功
2）提示管理员哪桌已开
3）数据库表中把桌子的信息置为正在用餐
测试编号：
2-1-2
项目属性：
A
测试项目：
点菜与写备注
测试子项目：
该模块与数据库的链接
测试目的：
验证顾客是否能够进行点菜
测试预置条件：
顾客（模拟）、厨师和学徒登录客户端并且在线，处于待机状态，喇叭，电源，网络信号正常。
正确的顺序/步骤：
1）顾客（模拟）开桌进行点菜
2）顾客（模拟）进行点菜，点十道菜，进行备注
3）开启厨师端（已经测试完毕），查看菜品信息
4）开启学徒端（已经测试完毕）查看菜品配菜信息
5）顾客（模拟）中途继续进行点菜
6）查看学徒端和厨师端的屏幕变化
7）查看数据库的数据变化
预期结果及判定原则：
1）厨师和学徒界面显示的菜品顺序为正确顺序，按照点菜时间和菜品名以及桌号的逻辑进行显示
3）中途添加的点菜信息也能正确的添加到点菜信息表中
测试编号：
2-1-3
项目属性：
A
测试项目：
生成点菜表与提交制菜统筹系统
测试子项目：
向数据库提交信息
测试目的：
验证系统能否生成报表提交到数据库提示信息
测试预置条件：
顾客（模拟）、厨师和学徒登录客户端并且在线，处于待机状态，喇叭，电源，网络信号正常。
正确的顺序/步骤：
1）顾客（模拟）进行点菜，并写备注
2）点击完成按钮
3）查看顾客屏幕
4）在管理员端查看数据库表
5）在厨师端查看点菜信息
6）在学徒端查看点菜信息
预期结果及判定原则：
1）成功将点菜信息、备注写入数据库
2）顾客端有点菜完成的提示
3）管理员可以查看点菜信息
4）厨师可以查看点菜信息
5）学徒可以查看点菜信息
测试编号：
2-1-4
项目属性：
A
测试项目：
退菜
测试子项目：
客户端对数据库的操作
测试目的：
验证顾客能否删去点菜信息
测试预置条件：
顾客（模拟）、管理员登录客户端并且在线，处于待机状态，电源，网络信号正常。
顾客点菜已经完成。
正确的顺序/步骤：
1）顾客选中显示正在排队的菜，点击退菜
2）查看顾客屏幕
3）在管理员端查看数据库表
预期结果及判定原则：
1）顾客端有退菜成功的提示
2）数据库里删去了这一道菜的点餐信息
测试编号：
2-1-5
项目属性：
A
测试项目：
催菜
测试子项目：
信息的拦截
测试目的：
验证系统能否能够拦截顾客的催菜请求
测试预置条件：
顾客（模拟）、厨师登录客户端并且在线，处于待机状态，电源，网络信号正常。
正确的顺序/步骤：
1）顾客（模拟）连续点击催菜按钮
2）观察厨师端的提示
3）观察顾客端的提示
预期结果及判定原则：
1）顾客端提示催菜成功
2）厨师端一小时只收到3次催菜提示
3）厨师端提示催菜
K.2.4.1进度安排
给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境、培训、准备输入数据等）。
测试日期：
程序完成后第二天立刻进行
工作内容：
操作简单容易上手，几乎不需要培训。
准备一份详细的真实菜单和相应的配菜信息录入数据库
录入桌号信息表
分配测试角色：
顾客、厨师和学徒的角色安排
K.2.4.2条件
d）设备：
5台及以上安卓机或者IOS机，至少两台Pad以及一台PC机使用时间至测试结束
e）软件：
单元测试工具Nanit、功能测试工具WinRunner、性能测试工具LoadRunner
f）人员：
要求能够操作上述电子设备，具备一定的测试知识
K.2.4.3测试用例
测试项
输入用例
是否有效等价类
预期结果
桌号录入
002
是
开桌成功，数据库该桌信息置为不可用
2
否
桌号太短
0002
否
桌号太长
002（第二次）
否
该桌已开
#￥@
否
有非法字符
%%%%2
否
长度太长
点菜信息录入
点击菜名
是
顾客已点菜单可以显示
写备注
不放辣
是
菜单中显示干豆角烧肉
不放辣@#
否
提示有非法字符
不放辣。
。
。
（超过20个字）
否
提示菜名长度过长
退菜
点击退菜按钮
是
将数据库表中的信息删除，，提示删除成功
催菜
点击催菜按钮
是
提示催菜成功，提示后厨催菜，一小时三次
K.2.4.4测试培训
操作简单容易上手，几乎不需要培训。
K.2.5评价管理
测试编号：
3-1-1
项目属性：
A
测试项目：
判断付款状态
测试子项目：
无
测试目的：
判断顾客付款状态从而进行评价
测试预置条件：
顾客和管理员登录客户端并且在线，处于待机状态，喇叭，电源，网络信号正常
正确的顺序/步骤：
1）顾客选择评价
2）系统判断顾客付款状态
3）观察顾客屏幕显示
预期结果及判定原则：
1）如果未付款就提示请先付款
2）若付款则跳到评价界面
3）管理员界面可以查看顾客付款状态和付款金额
测试编号：
3-1-2
项目属性：
A
测试项目：
评价添加
测试子项目：
无
测试目的：
验证统筹系统的正确性
测试预置条件：
顾客（模拟）和管理员登录客户端并且在线，处于待机状态，喇叭，电源，网络信号正常。
正确的顺序/步骤：
1）顾客（模拟）进入评价界面
2）输入评价信息
3）观察管理员界面显示
预期结果及判定原则：
1）顾客和管理员在数据库中可以查看评价信息
2）管理员界面会提示顾客评价信息已生成
测试编号：
3-1-3
项目属性：
A
测试项目：
评价删除
测试子项目：
无
测试目的：
验证客户能不能删除评价
测试预置条件：
顾客（模拟）和管理员登录客户端并且在线，处于待机状态，喇叭，电源，网络信号正常。
正确的顺序/步骤：
1）顾客（模拟）选中自己的评价
2）顾客点击删除
3）管理员端查看屏幕显示
4）顾客端查看屏幕显示
预期结果及判定原则：
1）顾客端显示删除成功的提示
2）管理员端显示顾客删除的提示信息
测试编号：
3-1-4
项目属性：
A
测试项目：
评价查看
测试子项目：
无
测试目的：
验证顾客和管理员可以查看顾客给的评价
测试预置条件：
顾客（模拟）和登录客户端并且在线，处于待机状态，电源，网络信号正常。
正确的顺序/步骤：
1）顾客点击评价记录按钮
2）观察顾客屏幕显示
3）管理员点击全部评价按钮
4）观察管理员屏幕显示
预期结果及判定原则：
1）顾客端会显示自己的评价记录
2）管理员屏幕会显示所有顾客的评价
K.2.3.1进度安排
给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境、培训、准备输入数据等）。
测试日期：
程序完成后第二天立刻进行
工作内容：
操作简单容易上手，几乎不需要培训。
准备一份详细的真实菜单和相应的配菜信息录入数据库
录入桌号信息表
分配测试角色：
顾客、厨师和学徒的角色安排
K.2.3.2条件
g）设备：
5台及以上安卓机或者IOS机，至少两台Pad以及一台PC机使用时间至测试结束
h）软件：
单元测试工具Nanit、功能测试工具WinRunner、性能测试工具LoadRunner
i）人员：
要求能够操作上述电子设备，具备一定的测试知识
K.2.3.3测试用例
测试项
输入用例
是否有效等价类
预期结果
评价等级输入
5
是
能够写入数据库评价界面能显示评价等级
-1
否
提示评级不能为负分
6
否
提示评级不能超过5
4.5
否
提示评价不能为小数
#￥#
否
提示评价只能为正整数
评价内容输入
饭菜很好，服务员态度也好，价格也很实惠，总的来说非常不错的
是
在管理员端和顾客端可以查看评价
*****（不文明用语）
否
提示有非法字符，评价无效
&*部分阿虎8198
否
提示无效评价
饭菜。
。
。
。
（超过50字）
否
提示评价过长
K.2.3.4测试培训
操作简单容易上手，几乎不需要培训。
K.3评价准则
K.3.1范围
客户端界面，弹窗提示对于设备横竖屏的处理是否合理；
是否有最大最小字符限制，边界值输入情况是否报错，最大最小限制的提示是否合理；特殊字符的输入，显示，输入框内的展示，展示页面的展示；
输入页面，对于空格字符的录入，空格在首位，末尾的处理和展示，只输入空格时的处理；输入过长时候是否有折行，显示是否合理；
输入框和展示页面，对于换行是否有合理展示和处理；
设备重启前后，应用数据不丢失，状态及策略执行情况正常；
K.3.2数据整理
（1）、删除过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统,这些测试用例就会过时.例如,某个变量的界限发生了改变,原来针对边界值的测试就无法完成对新边界测试.所以,在软件的每次修改后都应进行相应的过时测试用例的删除.
（2）、改进不受控制的测试用例
随着软件项目的进展,测试用例库中的用例会不断增加,其中会出现一些对输入或运行状态十分敏感的测试用例.这些测试不容易重复且结果难以控制,会影响回归测试的效率,需要进行改进,使其达到可重复和可控制的要求.
（3）、删除冗余的测试用例
如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试,那么这些测试用例是冗余的.冗余测试用例的存在降低了回归测试的效率.所以需要定期的整理测试用例库,并将冗余的用例删除掉.
（4）、增添新的测试用例
如果某个程序段、构件或关键的接口在现有的测试中没有被测试,那么应该开发新测试用例重新对其进行测试.并将新开发的测试用例合并到基线测试包中.
K.3.3尺度
说明用来判断测试工作是否能通过的评价尺度，如合理的输出结果的类型、测试输出结果与预期输出之间的容许偏离范围，允许中断或停机的最大次数。
升级会员 