餐厅点餐系统开发.doc

餐饮业点餐系统项目报告昆明理工大学管理与经济学院IT项目管理与实践案例分析餐饮业点餐系统项目报告团队编号：001子项目项目背景项目章程进度计划工作分解网络计划经济可行性分析技术可行性分析安全可行性分析操作可行性分析用户特点分析相关人员分析功能需求分析性能分析可用性分析适应性分析概念建模逻辑建模物理建模设计原则设计步骤注意事项运行平台进度计划数据和数据库完整性测试接口测试集成测试功能测试业务周期测试用户界面测试性能测试安全性和访问控制测试故障转移和恢复测试配置测试安装测试进度阶段划分实施详细计划PPT制作审核工作量(%)签名组长签名： 完成日期：2012年6月 7日目录1 项目背景12 项目章程13 项目计划3a) 进度计划3b) 工作分解3c) 网络计划54 项目分析7a) 可行性分析7i. 经济可行性分析7ii. 技术可行性分析9iii. 安全可行性分析9iv. 操作可行性分析9b) 用户需求分析9i. 用户特点分析9ii. 相关人员分析10iii. 功能需求分析10c) 质量标准12i. 性能分析12ii. 可用性分析13iii. 适应性分析135 项目设计14a) 数据库建模14i. 概念建模14ii. 逻辑建模14iii. 物理建模15b) 代码设计16i. 设计原则16ii. 设计步骤17iii. 注意事项17iv. 运行平台186 项目测试19a) 进度计划19b) 测试内容和方法19i. 数据和数据库完整性测试19ii. 接口测试20iii. 集成测试20iv. 功能测试21v. 业务周期测试21vi. 用户界面测试22vii. 性能测试23viii. 安全性和访问控制测试26ix. 故障转移和恢复测试27x. 配置测试29xi. 安装测试307 项目实施31a) 进度阶段划分31b) 实施详细计划331. 项目背景目前，我国酒店餐饮业在日常点菜管理中仍普遍采用手工操作方式，整体科技含量低，随着酒店餐饮业高速发展和餐饮店规模的不断扩大，许多酒店餐饮企业采用连锁经营和集团化运营，手工操作无论是在工作效率、人力成本和决策信息等方面都已经难以适应企业发展的要求，制约了整个酒店餐饮业的规模化发展和整体服务水平的提升。据预测，未来3至5年内，信息数字技术产品在中国饭店与餐饮业的应用将达到一个高峰，市场最大容量可达2300亿元人民币。就点菜系统而言，最普遍的是计算机收银台录入菜单设备、POS点菜系统，除了这种点菜系统，其它的计算机信息系统已经从预订、接待、点菜、菜品上传、厨房分单打印、条码划菜、收银、经理查询等方面在大型餐饮企业全方位地整合起来了。（摘自IT168中国第三方餐饮企业信息化研究）2. 项目章程a) 项目名称：餐饮业点餐系统b) 开发目的：i. 节省人力和财力，提高餐厅工作人员的工作效率ii. 节省候餐者的等待时间iii. 有利于提高综合竞争力c) 项目目标：i. 总目标：开发一套适用大中型营业性餐厅的点餐系统ii. 分目标：开发一套适用于高校风味餐厅的点餐系统d) 项目主要可交付成果软件文档、用户手册e) 项目经理责任计划并执行整个项目，同潜在用户进行交流，需求分析，界面设计f) 项目总体进度计划及主要里程碑i. 项目开始时间：2012-4-15ii. 项目结束时间：2012-iii. 主要里程碑安排1. 2012-4-152012-4-17：项目选择2. 2012-4-182012-4-20：项目计划3. 2012-4-212012-5-4：项目分析4. 2012-5-52012-6-1：项目设计5. 2012-6-22012-6-8：项目测试6. 2012-6-92012-6-15：项目实施3. 项目计划a) 进度计划对项目各工作阶段进行了初步的划分和进度安排，具体如表1： 工作阶段进度安排项目选择2012-4-152012-4-17项目计划2012-4-182012-4-20项目分析2012-4-212012-5-4项目设计2012-5-52012-6-1项目测试2012-6-22012-6-8项目实施2012-6-92012-6-15根据表1转化的甘特图如下图1：b) 工作分解对上表划分的各工作阶段进行了工作分解，并把工作分解的内容列在表2中。项目工作分解清单1项目选择2项目计划2. 1 项目进度计划2. 2 项目工作计划2. 3 项目网络计划3项目分析31 项目可行性分析3. 1. 1 经济可行性分析3. 1. 2 技术可行性分析3. 1. 3安全可行性分析3. 1. 4 操作可行性分析32 用户需求分析3. 2. 1 用户特点3. 2. 2 相关人员3. 2. 3 功能需求3. 3 质量标准3. 3. 1 性能分析3. 3. 2 可用性分析33. 3 适应性分析4项目设计4. 1 数据库建模4. 1. 1 概念建模4. 1. 2 逻辑建模41. 3 物理建模4. 2 代码设计4. 2. 1 设计原则4. 2. 2 设计步骤4. 2. 3 注意事项4. 2. 4 运行平台5. 项目测试6. 项目实施c) 网络计划对项目各项工作任务的工期进行了估计，估计值列于表3中第4列，并且明确各项间的逻辑关系，确定了需要延迟的工作任务及延迟时间，制作了网络计划工作表3：序号任务名称紧后工作工期（天）搭接关系搭接时间（天）A项目选择B3B项目计划C,D,E3C项目进度计划FD项目工作计划FE项目网络计划FF项目分析G,L,P,T14FS2G项目可行性分析H,I,J,K,H经济可行性分析I技术可行性分析J安全可行性分析K操作可行性分析L用户需求分析M,N,O,M用户特点N相关人员O功能需求P质量标准Q,R,S,Q性能分析R可用性分析S适应性分析T项目设计U21FS2U数据库建模V,W,XV概念建模YW逻辑建模YX物理建模YY代码设计Z,a,b,cZ设计原则da设计步骤db注意事项dc运行平台dd项目测试e7FS2e项目实施7FS2根据表3转化的网络图如下图2：4. 项目分析a) 可行性分析：i. 经济可行性分析：经济效益包括了有形效益和无形效益，我们虽然不能直接看到此系统所带来的有形效益，但是，其所带来的不可量化的,包括减少人工成本、增加客流量等无形效益则是不可估量的。关于成本的问题，做如下解释：大型餐厅现在一个普通菜谱的成本为每本400-1000元，每年得更换2-4次，每年一个房间的菜谱成本就是800-4000元，而一个android平板的成本为10002000元，因此成本要低很多的。另外，目前网上的一些项目只是单纯的完成点菜功能而已，或只是PDA移动点餐。所以我们想在平板上实现真真的给予客人点菜的自由权并且在点菜功能实现的前提下，可以加入一些娱乐功能，简单的比如看电影，玩游戏等等。与传统点菜比较：项目传统菜谱电子菜谱外观个性化制作封面个性化制作封面更换菜品每次制作新菜谱时才能更换随时更换菜品清洁贴条或服务器提醒随时设置不可见可不可点菜品信息菜品、价格及简单介绍菜名、价格、做法介绍，可以嵌入大量图文甚至视频附加信息无健康提示、卡路里含量、配餐等推荐菜品制作菜谱时设定随时设定广告植入基本上没有可对自已或合作伙伴的产品进行演示推广（预测可盈利广告宣传费25000/年*公司）自助点菜不能客人点餐可以形成菜单确认后提交服务员外观保持使用久了会出现磨损、脱页等更换封面，贴膜后保持常新风格不更换不可以变换根据酒店风格定制界面，春节、中秋、圣诞、情人节等可以更换不同皮肤，增强节日气氛。也可以根据婚宴、寿宴等不同需求个性化定制，彰显时尚品味制作成本400元/本,3本/年，需要不间段地印刷，累计成本高首次投资成本略高，累计成本低具体成本效益分析如下：以餐厅面积800-1000平米计，餐桌数量约为30桌，每3张餐桌使用1本菜单，每本菜单成本约400元，每年更新3次。配备服务员约30人，年人均成本约2.4万。投入前纸质菜谱成本内容成本纸质菜单印刷400（单价）*10（本）*3（次）=1.2万元/年服务员工资30（人数）*2.4（用工成本）=72万元/年使用点餐系统后节约成本平板/桌平板节约人员工资节件设施，按每个平板2000，需30个平板，则共60000。对于无线路由器,市面价格在180左右,按饭店面积是1000平米左右,一般阻隔小的话8个无线路由器足够了.则一共1440元。显示屏，后厨按1台计算,则价格为:3000*1=3000，前台打印机450。服务器，按照每台3000，则一共67890。点餐系统一次性成本工作说明书第0年A开发成本 ￥10,000.00B硬件成本 ￥67，890.00C用户培训 ￥10，000.00 D其他_ _0一次性成本总计 ￥87,890.00点餐系统多次性成本工作说明书第一年A系统维护 ￥50，000.00B不断增加的数据储存 ￥10，000.00C耗材供应 ￥10，000.00D软件升级 ￥50，000.00E其他 0多次性成本总计 ￥120,000.00点餐系统有形效益工作说明书第一年A.成本降低和取消 ￥372，000.00B灵活性增加 ￥10，000.00C对规划和控制有所改善 ￥10，000.00 D .广告加盟费 ￥50，000.00 E其他_ _0有形效益总计 ￥422,000.00经计算，使用该系统第一年投入207890，同时收益为422000，收益大于成本，故该项目可行。ii. 技术可行性：对现有技术进行评价，以明确能否利用现有技术进行系统开发及系统实施。计算机网络技术的发展和计算机硬件性价比的不断提升，使计算机全面应用于餐饮业管理的各个环节成为可能。各种技术在国内部分餐饮业的信息管理系统开发中已经被广泛采用，实践证明这些技术都非常适合餐营业管理系统的开发。另外，目前基于Web的系统开发技术已经十分成熟，相信随着Internet/Intranet技术的进一步发展，基于Web的信息系统开发将有更为明朗的前景。iii. 安全可行性分析：就管理者而言，关心的是如何处理用户信息，只要把用户的信息放入服务器端的数据库或专门的数据库服务器，管理者就可运行相应的后台程序进行处理。iv. 操作可行性分析：在系统运行后，就用户方而言，由于用户使用本系统时不会也不必关心系统内部的结构及实现方法，即对用户来说是透明的，所以本系统对用户而言是定位在界面友好、操作方便、功能齐全的原则上的，用户只需简单的用鼠标点击各页面上的链接或按钮就能执行相应的功能。目前资源的利用情况和可操作性，只需根据相关需要对数据库中的相应表数据直接操作就可以实现系统的完整、稳定的运行，不会造成系统的巨大压力，可以保证系统的正常运行。b) 用户需求分析i. 用户的特点：本软件的最终用户为食堂、餐厅、饭店、茶楼等服务餐饮行业，使用频率非常之高，且本软件操作较为简单，对顾客和其工作人员的技术要求不高，所以实用性非常好。ii. 使用系统的相关人员：与餐厅点菜相关的人员（可能操作系统的角色）详细情况及需求如下表所示：角色需求描述顾客根据系统操作提示自主进行点菜、退菜操作，系统要能够根据顾客的选择进行自动进行结账计算并显示。服务员根据系统操作提示对已经上桌的菜进行标记。厨房根据系统操作提示对开始烹饪和已经烹饪好的菜品进行标记。系统管理人员对数据库初始数据的设置，系统维护与升级。对数据进行分析，并根据当日材料情况适当修改菜单。权限设置，数据备份。iii. 功能需求：1. 系统管理员：系统管理员通过该部分功能完成酒店点菜管理系统中基础数据的设置工作。主要工作包括：鲁、粤、川、苏等菜系基础数据的设置，包括：图片、口味、价格等的介绍，并根据价格的不同分为高、中、低三档。2. 顾客：顾客可根据菜系、价格、口味进行点菜，菜系分为为鲁、粤、川、苏等五种；并根据价格分为高、中、低三个等级；根据口味可分为酸、甜、辣、咸四种。通过前台可视化界面实现顾客多方面选择。点菜完毕后，系统自动进行菜价统计并显示。如顾客不满意则可进行退选或补选。3. 厨房系统自动记录点菜次数，并对补选的菜进行次数增加，退选的菜进行次数减少，并将最终结果排序。厨师通过系统可知需要烹饪的菜肴，并通过点击标记正在烹饪的菜肴与已经烹饪完成的菜肴。4. 服务员：服务员根据系统操作提示对已经上桌的菜进行标记。顶层数据流图：收银员/一卡通c) 质量标准i. 性能分析：1. 点餐系统运行稳定、安全可靠、界面简洁友好、使用方便。2. 当基础数据发生变化时，系统管理员应该能很方便地维护基础数据，提高系统的灵活性。3. 最大程度的保证点菜数据的准确性。在顾客进行点菜时要实现各种关键基础数据的选择输入，避免大量的文字输入，以便减少点菜时间，提高录入数据的准确度。具体的基础数据项目包括：菜品名称，价格，口味，主要原料，参考图片，所属菜系，这些信息都采用按钮选择方式输入。4. 提高系统的并发性能。本系统平均每天点菜人次约为1000人，按最高峰值1500人，每次点菜时间为5分钟，每天营业时间为8小时，所以系统要保证同时在线的人数为：1500人/（480分钟/5分钟）=15人。5. 尽可能的降低系统运行和维护的成本，以便在餐饮行业中推广本系统，扩大使用范围。ii. 可用性分析：以顾客为关注焦点，采用触摸屏技术，操作简单易学，大按钮的设计方便了顾客可以直接用手指操作，菜品的输入方式有分类、手写输入、和快捷键。iii. 适应性分析：1. 高效点菜：方便更好展示菜品，有效提高消费额，方便顾客自助点菜，有效节约人工，提高服务质量。2. 菜单管理: 包含了饭店所有菜品信息、菜品口感、份量、做法、一目了然， 方便客人选择。3. 超强展示：7英寸液晶屏及简洁界面，方便服务员及顾客点菜，海量信息储存，可时时更新，优越于传统菜谱。4. 准确无误：避免传统手写点菜失误，造成的消费者投诉。5. 无线传输：无线上网功能，无线发送菜品功能，提高服务质量，营造舒适就餐环境。6. 提高效率：点菜、提交、下单同步进行，规范管理；可与现有点菜方式同时使用，弥补传统点菜方式的缺陷，更好提升餐厅管理7. 数据分析：餐厅营业状况一目了然，并兼容现有餐饮管理软件。5. 项目设计a) 数据库建模i. 概念建模送餐顾客n服务员端菜查询菜单顾客编号顾客姓名菜品编号菜单名价格基本描述管理系统管理员管理员编号管理员姓名密码查看订单确定厨师接收订单编号顾客编号总价服务员号服务员姓名厨师编号厨师姓名mm1mnmmn1nnn座位号座位号m收银台管理1m支付1mii. 逻辑建模逻辑结构设计的任务就是把概念模型结构转换成某个具体的DBMS所支持的数据模型。设计逻辑结构时，首先是将概念结构转换为一般的关系、网状、层次模型，其次是将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换，最后是对数据模型进行优化。将餐饮点菜系统的E-R图转换成关系数据模型。关系模式如下：菜单（菜品编号，菜名，类型，单价，状态）；顾客（顾客编号，姓名，座位号）；服务员（编号，姓名）；管理员（编号，名称，密码）；厨师（编号，姓名）。订单（订单编号，顾客编号，总价，菜品编号，菜名，类型，单价，数量）iii. 物理建模数据库的物理结构设计是对于给定的逻辑数据模型，选取一个最合适应用环境的物理结构。数据库的物理结构指的是数据库在物理设备上的存储结构与存取方法，它依赖于给定的计算机系统，是在数据库逻辑结构的基础上设计出一组能够满足实际需求的关系、约束、和索引等信息。餐饮点菜系统的数据库表结构如下：（1） 服务员基本表表3.1 服务员信息表属性中文名称属性名类型长度说明服务员号IDInt20（PK）统一编号，具有唯一性服务员姓名Watiernamechar10服务员名称（2） 订单信息表表3.2 订单信息表属性中文名称属性名类型长度说明订单号IDInt20（PK）统一编号，具有唯一性顾客编号CustomerIDInt20（FK）统一编号，具有唯一性总价TotalPricechar10总消费金额菜品编号DishIDInt20（FK）统一编号，具有唯一性菜名DishNameChar10菜品名称类型DishTypeChar10菜品类型单价DishPriceChar10菜品单价数量Numberint10菜品数量（3） 菜单表表3.3 菜单信息表属性中文名称属性名类型长度说明菜品编号DishIDInt20（PK）统一编号，具有唯一性菜名DishNameChar10菜品名称类型DishTypeChar10菜品类型单价DishPriceChar10菜品单价状态Isselectedint1选中：1；未选：0（4） 管理员基本表表3.4 管理员信息表属性中文名称属性名类型长度说明管理员编号IDInt20（PK）统一编号，具有唯一性管理员名称Usernamechar10管理员名称密码Passwordvarchar50管理员密码（5） 厨师信息表表3.5 厨师信息表属性中文名称属性名类型长度说明厨师编号IDInt20（PK）统一编号，具有唯一性厨师姓名KitchenerNamechar10厨师名称（6）顾客信息表表3.6 顾客信息表属性中文名称属性名类型长度说明顾客编号IDInt20（PK）统一编号，具有唯一性顾客姓名CustomerNamechar10顾客名称b) 代码设计代码是用来表征客观事物实体类型与属性的一个或一组易于计算机识别和处理的特定符号，它可以是字符、数字、某些特殊符号或它们的组合。代码设计就是要把系统中要处理的事物用特定的代码来描述，便于计算机系统识别、处理，便于数据的共享，提高用户使用数据的效率。1代码设计原则（1）标准化、系统化：标准化、系统化的代码具有适合计算机处理，便于实现，提高处理速度等优点。凡已制定了统一标准代码的，均应采用标准代码形式。（2）惟一性：设计代码代表的实体或属性惟一。（3）统一性、直观性、逻辑性：具备这些特点的代码便于记忆，且有助于减少错误。（4）可扩展性：既代码设计要预留足够位置，便于增加实体时，可直接在原代码系统中进行扩充，而不必改变原编码结构。（5）一致性：代码设计要在逻辑上能满足用户要求，在结构上与处理方法相一致。（6）简短性：避免使用易错字符、易混淆字符。2代码设计步骤（1）确定代码编制目的。（2）确定编码对象，包括已在使用的代码对象。（3）确定代码使用场合和使用期限。（4）分析编码对象的使用要求。如使用频率、变更周期、输出要求等。（5）确定具体编码方法，考虑是否采用检验位。（6）针对每种代码编写代码设计书。（7）将总代码设计书归类编写代码薄,并规定代码管理制度。3注意的问题（l）设计的代码在逻辑上必须能满足用户的需要，在结构上应当与处理的方法相一致。（2）一个代码应惟一标志它所代表的事物或属性。（3）代码设计时，要预留足够的位置，以适应不断变化的需要。否则，在短时间内，随便改变编码结构对设计工作来说是一种严重浪费。一般来说，代码愈短，分类、准备、存储和传送的开销愈低;代码愈长，对数据检索、统计分析和满足多样化的处理要求就愈好。但编码太长，留空太多，多年用不上，也是一种浪费。（4）代码要系统化，代码的编制应尽量标准化，尽量使代码结构对事物的表示具有实际意义，以便于理解及交流。（5）要注意避免引起误解，不要使用易于混淆的字符。如0、2、1、S、V与0、2、1、5、U易混;不要把空格作代码;要使用乃小时制表示时间等。(6)要注意尽量采用不易出错的代码结构，例如字母-字母-数字的结构(如WW2)比字母-数字-字母的结构(如W2W)发生错误的机会要少一些。(7)当代码长于4个字母或5个数字字符时，应分成小段。这样人们读写时不易发生错误。如726-499-6135比7264996135易于记忆，并能更精确地记录下来。4系统运行平台客户端最低配置：CPU:528MHz 内存：256MB服务器端：CPU：2GHz 内存：2GB 硬盘：250GAndroid程序作为客户端，Tomcat作为服务器，用于跟Android程序交互，通过Tomcat查询MySQL数据库然后传给Android程序，交给用户选择。MySQL主要用来存储订单信息、账本数据以及各种各样的食品名称，而且需要根据市场适时更新。本系统选用C/S体系架构，即客户端/服务器模式。其中，客户端一方面与用户交互，提供良好的用户界面，另一方面与服务器端进行数据交换。服务器端向客户端提供数据下载、数据上传接口以交换数据。管理员可对数据进行删除、添加、控制等操作。客户端与服务器端通过Http协议进行数据交换。这种体系架构的分布结构见图： 6. 项目测试a) 测试进度安排工作阶段进度安排数据和数据库完整性测试1天接口测试1天集成测试功能测试1天业务周期测试1天用户界面测试1天性能测试安全性和访问控制测试1天故障转移和恢复测试配置测试1天安装测试b) 测试成本分析测试成本分析说明书A硬件设置 ￥12，450.00B线路设施 ￥300.00C其他 _0测试成本总计 ￥12.750.00c) 测试类型和策略i. 数据和数据库完整性测试数据库和数据库进程应作为项目的子系统来进行测试。 在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确保数据库访问方法和进程正常运行，数据不会遭到损坏。测试目标：确保数据库访问方法和进程正常运行，数据不会遭到损坏。方法： 调用各个数据库访问方法和进程，并在其中填充有效的和无效的数据或对数据的请求。 检查数据库，确保数据已按预期的方式填充，并且所有数据库事件都按正常方式出现；或者检查所返回的数据，确保为正当的理由检索到了正确的数据完成标准：所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。需考虑的特殊事项： 测试可能需要 DBMS 开发环境或驱动程序以便在数据库中直接输入或修改数据。 进程应该以手工方式调用。 应使用小型或最小的数据库（其中的记录数很有限）来使所有无法接受的事件具有更大的可见性。ii. 接口测试接口测试主要目的是确保所有硬件接口和软件接口调用的正确性。主要测试方法是通过记录各接口的输入输出数据，并核对其是否为预期值。测试目标：确保所有软件、硬件接口调用的正确性方法：记录输入输出数据完成标准：所有软件、硬件接口的调用正确需考虑的特殊事项：接口的限制条件iii. 集成测试集成测试的主要目的是检测系统是否达到需求，对业务流程及数据流的处理是否符合标准，检测系统对业务流处理是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准及要求。此类型测试基于完成的单元测试。测试目标检测需求中业务流程，数据流的正确性方法：测试需求中明确的业务流程，或组合不同功能模块而形成一个大的功能。利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。完成标准：所计划的测试已全部执行。所发现的缺陷已全部解决。需考虑的特殊事项：确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）iv. 功能测试功能测试应该侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试需求。这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。这种类型的测试基于黑盒方法，即通过图形用户界面 (GUI) 与应用程序交互并分析输出结果来验证应用程序及其内部进程。功能测试的一般方法是利用有效的和无效的数据来执行各个用例、用例流或功能，以核实是否达到预期结果。测试目标：确保测试对象的功能正常，其中包括导航、数据输入、处理和检索等。方法：基于黑盒方法，即通过图形用户界面 (GUI) 与应用程序交互并分析输出结果来验证应用程序及其内部进程。利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容： 在使用有效数据时得到预期的结果。 在使用无效数据时显示相应的错误消息或警告消息。 各业务规则都得到了正确的应用。完成标准： 所计划的测试已全部执行。 所发现的缺陷已全部解决。需考虑的特殊事项：确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）v. 业务周期测试业务周期测试应模拟在一段时间内对项目执行的活动。应先确定一段时间（例如一年），然后执行将在该时段内发生的事务和活动。这种测试包括所有的每日、每周和每月的周期，以及所有与日期相关的事件（如备忘录）。测试目标确保测试对象及后台进程都按照所要求的业务模型和时间表正确运行。方法：通过执行以下活动，测试将模拟若干个业务周期： 将修改或增强对测试对象进行的功能测试，以增加每项功能的执行次数，从而在指定的时段内模拟若干个不同的用户。 将使用有效的和无效的日期或时段来执行所有与时间或日期相关的功能。 将在适当的时候执行或启动所有周期性出现的功能。 在测试中还将使用有效的和无效的数据，以核实以下内容： 在使用有效数据时得到预期的结果。 在使用无效数据时显示相应的错误消息或警告消息。 各业务规则都得到了正确的应用。完成标准： 所计划的测试已全部执行。 所发现的缺陷已全部解决。需考虑的特殊事项： 系统日期和事件可能需要特殊的支持活动 需要通过业务模型来确定相应的测试需求和测试过程。vi. 用户界面测试用户界面（UI）测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合行业的标准。测试目标：核实以下内容： 通过浏览测试对象可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab 健、鼠标移动和快捷键）的使用 窗口的对象和特征（例如：菜单、大小、位置、状态和中心）都符合标准。方法：为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。完成标准：证实各个窗口都与基准版本保持一致，或符合可接受标准需考虑的特殊事项：并不是所有定制或第三方对象的特征都可访问。vii. 性能测试1. 性能评价性能评价是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评价的目标是核实性能需求是否都已满足。实施和执行性能评价的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来进行评价和微调。测试目标：核实所指定的事务或业务功能在以下情况下的性能行为：正常的预期工作量预期的最繁重工作量方法：使用为功能或业务周期测试制定的测试过程。通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代次数。脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多台客户机（虚拟的或实际的客户机，请参见下面的“需考虑的特殊事项”）上重复。完成标准：单个事务或单个用户：在每个事务所预期或要求的时间范围内成功地完成测试脚本，没有发生任何故障。多个事务或多个用户：在可接受的时间范围内成功地完成测试脚本，没有发生任何故障。需考虑的特殊事项：综合的性能测试还包括在服务器上添加后台工作量。 可采用多种方法来执行此操作，其中包括： 直接将“事务强行分配到”服务器上，这通常以“结构化查询语言”(SQL) 调用的形式来实现。通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）客户机。此负载可通过“远程终端仿真”(Remote Terminal Emulation) 工具来实现。 此技术还可用于在网络中加载“流量”。使用多台实际客户机（每台客户机都运行测试脚本）在系统上添加负载。 性能测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。性能测试所用的数据库应该是与实际大小相同或等比例缩放的数据库。2. 负载测试负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。目标：核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。方法： 使用为功能或业务周期测试制定的测试。通过修改数据文件来增加事务数量，或通过修改测试来增加每项事务发生的次数。 完成标准：多个事务或多个用户：在可接受的时间范围内成功地完成测试，没有发生任何故障。需考虑的特殊事项：负载测试应该在专用的计算机上或在专用的机时内执行，以便实现完全的控制和精确的评测。负载测试所用的数据库应该是与实际大小相同或等比例缩放的数据库。3. 强度测试强度测试是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。测试目标：核实测试对象能够在以下强度条件下正常运行，不会出现任何错误：服务器上几乎没有或根本没有可用的内存（RAM 和 DASD）连接或模拟了最大实际（或实际可承受）数量的客户机多个用户对相同的数据/账户执行相同的事务最繁重的事务量或最差的事务组合（请参见上面的“性能测试”）。注：强度测试的目标还可表述为确定和记录那些使系统无法继续正常