超市管理系统参考案例Word文档下载推荐.docx

1、 102模块子系统结构： 12五、测试 141. 测试过程分析： 142 .测试方案： 154. 测试结果 185. 评估和建议 18六、实现 19七、维护 19八、总结 19一、问题定义1系统开发目的1大大提高超市的运作效率；2通过全面的信息采集和处理，辅助提高超市的决策水平；3使用本系统，可以迅速提升超市的管理水平，为降低经营成本， 提高效益，增强超市扩张力， 提供有效的技术保障。2背景说明21世纪，超市的竞争也进入到了一个全新的领域，竞争已不再是规模的竞争，而是技术的竞争、管理的竞争、人才的竞争。技术的提升和管理的升级是超市业的竞争核心。零售领域目前呈多元发展趋势，多种业态：超市、仓储店

2、、便利店、特许加盟店、专卖店、货仓等相互并存。如何在激烈的竞争中扩大销售额、降低经营成本、扩大经营规模，成为超市营业者努力追求的目标。3项目确立针对超市的特点，为了帮助超市解决现在面临的问题，提高小型超市的竞争力，我们将开发以下系统：前台POS销售系统、后台管理系统，其中这两个子系统又包含其它一些子功能。4应用范围本系统适应于各种超市。5名词定义商品条形码：每种商品具有唯一的条形码，对于某些价格一样的商品，可以使用自定义条形码。交易清单：包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时间、负责本次收银的员工号。商品积压：在一定时期内，远无法完成销售计划的商品会造成积压。促

3、销：在一定时期内，某些商品会按低于原价的促销价格销售。库存告警提示：当商品的库存数量低于库存报警数量时发出提示。盘点：计算出库存、销售额、盈利等经营指标。二、可行性研究1操作可行性分析超市的经营者大多具备电脑基本操作知识，对于必要的专业操作经短期培训即可；管理基础工作和各项管理制度比较健全，执行严格，原始数据采集完整，保存良好。2经济可行性分析超市管理系统的投入，能够提高工作效率，减少工作人员，从而减少人力资本的投入，根据核算，系统投入三个月后，就能够基本收回开发系统的投资，从经济角度来说，本系统开发完全必要。3技术可行性分析（1）硬件：电脑一台（2）软件：操作系统：中文Windows XP

4、开发系统：Microsoft Visual Foxpro 6.0 安装SQL Server 2000的服务器版本系统本身对硬件和软件的要求都不高且系统兼容性很强，平台的移植性也很好，因此无论在系统的硬件及软件上都满足开发的要求。（3）本系统涉及到的技术因素： 管理系统的开发方法。使用面向对象开发方法开发软件系统 网络和通信技术。开发小组有基于C/S开发的经验 C/S机构规划和技术设计。开发小组有应用数据库开发经验 数据库技术。开发小组能使用Visual Foxpro编程（4）运行上的可行性： 操作简单：简单的操作规则使操作人员能轻松掌握。 查询方便：用户可设定任意条件和任意的查询项目进行检索。

5、 统计灵活：任意条件下任意项目的产品入库时间、数量等的统计及查询项目均可进行交叉统计。4.系统初步ER图5可行性研究结论本小组拟开发的管理信息系统操作方便灵活，便于学习，因此，该系统具有可行性。通过经济、技术、和社会等方面的可行性研究，可以确定本系统的开发完全必要，而且是可行的，可以立项开发。三、需求分析1.用户需求分析超市的进销存管理信息系统，首先必须具备的功能是记录仓库存货、销售以及进货情况，通过该系统了解超市进货渠道、商品单价、数量，库存商品的种类、数量，销售商品种类、价格、数量，以便管理员根据以上信息作出经营管理决策。在性能方面要求系统核算准确，使实存商品、销售商品与所记帐目一致，能够

6、被超市长期有效使用。数据主要来自于入库单、发票，超市销售在营业期间内一直发生，数据也就一直变化。销售商品后开出发票，并且要显示商品价格数额。在当天汇总时修改相应文件，注重的是总额、总数量。为减少月末工作量，日常中要对报表数据逐步统计核算。超市数据资料有些属内部资料，不能为外人所知，系统须有保密措施，设置密码。查看资料需输入正确密码，销售人员销售货物需输入代号才能打开收银柜。万一泄露密码，应设修改密码的程序，同时密码不能过于简单2.系统功能分析 （1） 零售前台（POS）管理系统，本系统必须具有以下功能： 商品录入：根据超巿业务特点制定相关功能，可以通过输入唯一编号、扫描条形码、商品名称等来实现

7、精确或模糊的商品扫描录入。该扫描录入方法可以充分保证各种电脑操作水平层次的人员均能准确快速地进行商品扫描录入。 收银业务：通过扫描条形码或者直接输入商品名称（对于同类多件商品采用一次录入加数量的方式）自动计算本次交易的总金额。在顾客付款后，自动计算找零，同时打印交易清单（包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时间、负责本次收银的员工号）。如果顾客是本店会员并持有本人会员卡，则在交易前先扫描会员卡，并对所购物品全部实行95折优惠，并将所购物品的总金额累计到该会员的总消费金额中。 会员卡的有效期限为一年，满一年未续卡者，该会员卡将被注销。 安全性：OS登陆、退出、换班

8、与操作锁定等权限验证保护；断电自动保护最大限度防止意外及恶意非法操作。 独立作业：有的断网收银即在网络服务器断开或网络不通的情况下，收银机仍能正常作业（2） 后台管理系统，本系统必须具备以下功能 进货管理： 根据销售情况及库存情况，自动制定进货计划（亦可手工制定修改），可以避免盲目进货造成商品积压。 按计划单有选择性地进行自动入库登记。 综合查询打印计划进货与入库记录及金额。 销售管理： 商品正常销售、促销与限量、限期及禁止销售控制。 综合查询各种销售明细记录、各地收银员收银记录以及交结账情况等。 按多种方式统计生成销售排行榜，灵活察看和打印商品销售日、月、年报表。 库存管理： 综合查询库存明

9、细记录。 库存状态自动告警提示。如库存过剩、少货、缺货等。软件为您预警，避免库存商品积压损失和缺货。 库存自动盘点计算。 人员管理： 员工、会员、供货商、厂商等基本信息登记管理。 员工操作权限管理。 客户销售权限管理。3.系统结构系统总体结构4.流程图前台管理系统5.系统ER图系统ER图说明：1.商店中的所有用户（员工）可以销售多种商品，每种商品可由不同用户（工）销售；2.每个顾客可以购买多种商品，不同商品可由不同顾客购买；每个供货商可以供应多种不同商品，每种商品可由多个供应商供应。四、设计户类型与职能（1）、员工（营业员）： 通过商品条形码扫描输入商品到购买清单 操作软件计算交易总金额 操作

10、软件输出交易清单 对会员进行会员卡扫描以便打折（2）、超市经理 操作软件录入商品，供货商，厂商 操作软件制定进货计划 查询打印计划进货与入库记录 操作软件控制商品销售与否 查询打印销售情况 操作软件生成销售排行榜 查询库存明细记录 根据软件发出的库存告警进行入货 操作软件进行盘点计算（3）、总经理： 基本信息登记管理 员工操作权限管理 客户销售权限管理零售前台（POS）管理系统用例视图后台管理系统用例视图 （1）. 商品录入功能描述：商品录入子系统要求能快速录入商品，因此必须支持条形码扫描。（2）. 收银业务收银业务子系统能计算交易总额，打印交易清单，并根据会员卡打折。（3）. 进货管理进货管

11、理子系统可以根据库存自动指定进货计划，进货时自动等级以及提供查询和打印计划进货与入库记录的功能。（4）. 销售管理销售管理子系统可以控制某商品是否允许销售，查询每种商品的销售情况并产生年、月、日报表，同时可以生成销售排行榜。（5）. 库存管理库存管理子系统提供查询库存明细记录的基本功能，并根据库存的状态报警，以及自动盘点计算。（6）.人员管理人员管理子系统提供基本信息登记管理，员工操作权限管理，客户权限管理五、测试1.测试过程分析：输入：项目实施计划书；相关规范；测试文档；源代码、可执行代码；需求跟踪矩阵。 活动介绍：构建测试环境，包括系统平台（软硬件平台）的安装、可执行代码或源代码的安装、系

12、统基础数据的准备等。在测试过程中，记录BUG信息，并及时向程序员提交BUG信息。收到BUG信息后进行源代码的修正，并记录处理结果后，返回进行回归测试。在测试过程中，根据测试的功能，补充需求跟踪矩阵相应栏的内容。若测试不通过，且涉及到修改设计阶段的问题，则依据配置管理控制程序中的有关变更控制来执行，直至测试通过。测试结束，根据测试情况，填写测试总结报告。输出：经测试之源代码；经测试之可执行代码；BUG记录（可用BUG管理工具代替）；测试总结报告；修改后的需求跟踪矩阵。2.测试方案：一 范围本文档适用于超市管理系统软件的单元/集成测试。1 系统概述2 文档概述本文档用于对超市管理系统软件的测试工作

13、阶段成果的描述。包括对软件测试的整体描述，软件测试的分类和级别，软件测试的过程描述，软件测试的结果等内容。二 引用文档超市管理系统软件需求规格说明超市管理系统软件设计说明超市管理系统系统接口协议三 测试概述1. 被测软件的基本概况使用的编程语言： 汇编语言程序行数：子程序个数：单行注释行数：注释率：3.测试小结本次测试对超市管理系统软件进行了静态分析和动态测试。测试工作分为两个阶段。第一阶段进行了软件静态分析，软件测试人员和开发人员分别对软件V1.00版本的代码进行走读。在此基础上软件开发人员对代码走查中发现的问题进行了修改，做了代码变更并提交了新版本进行动态测试。在测试过程中针对发现的软件缺

14、陷进行了初步分析，并提交程序设计人员对原软件中可能存在的问题进行考查。在软件测试中首先根据软件测试的规范进行考核，将书写规范，注释等基础问题首先解决，其次考核软件测试中的问题是否存在设计上的逻辑缺陷，如果存在设计缺陷则应分析该缺陷的严重程度以及可能引发的故障。软件开发人员在以上基础上对软件的不足做出相应的修改，同时通过软件回归测试验证软件修改后能够得到的改善结果。在动态测试阶段进行了单元测试和集成测试。此阶段发现的软件问题经软件测试人员修改，提交了新版本，软件测试人员对此版本的软件代码进行了回归测试，确认对前阶段发现的软件问题进行了修改。a. 静态分析小结静态测试采用人工代码走查的方式进行。参

15、加代码走查的软件开发人员有：（略）；参加代码走查的软件测试人员有：（略）。代码走查以代码审查会议的形式进行。静态分析过程中共进行了四次会议审查。静态测试阶段的主要工作内容是： 根据对软件汇编源代码的分析绘制详细的程序流程图和调用关系图； 对照软件汇编源代码和流程图进行程序逻辑分析、算法分析、结构分析和接口分析； 对软件汇编源代码进行编程规范化分析。通过静态测试查找出软件的缺陷n个，其中轻微的缺陷中等的缺陷严重的缺陷b. 动态测试小结动态测试使用的测试工具为超市管理系统软件集成开发环境。总共的测试用例数：全部由测试人员人工设计。其中单元测试用例，集成测试用例。发现的软件缺陷，都是在单元测试过程中

16、发现的。集成测试阶段未发现新的软件缺陷。在发现的软件缺陷中：动态测试中代码覆盖率：代码行覆盖率 分支覆盖率 程序单元调用覆盖率 c. 回归测试小结对软件测试过程中发现的缺陷经软件开发人员确认后进行了代码更改，并对更改后的代码进行了回归测试。本报告中的数据是回归测试后的测试数据。d. 测试分析下面将对此次软件测试中的所有缺陷以及改进设计进行分析。2静态测试中的缺陷分析：a. 4个轻微缺陷属于代码冗余，由于在程序设计中加入了部分调试程序，在程序设计完成后未将这些调试代码注释或删除掉而造成代码冗余，但对程序本身的功能并无影响。修改后程序的效率得到提高。b. 11个中等缺陷属于注释变更，在原程序代码的

17、注释中存在注释不准确的问题，会影响程序员对程序的理解，修改后的程序提高了程序的可读性。c. 重点分析3个严重缺陷：第一个严重缺陷属于XX号的无效判别和相应的处理问题，程序对XX号进行无效判别时，判别界限并不完全，在本跟踪程序中XX号的有效数为01-10（用4位表示），而判别无效时只判了为00的情况，没有判别大于10的情况。而且在为00时也没有作相应的处理，修改后的程序对设计进行了改进。第二个严重缺陷属于程序设计中读取地址错误问题，经分析在调试中读取的数据是正确的，但是读取的地址与设计初衷不相符，修改后问题得到了解决，详见改进设计分析1。第三个严重错误是近区/远区子程序判断与进入条件反了，经分析

18、对程序的影响不大，但与设计初衷不一致，修改后问题得到了解决，详见改进设计。3动态测试中的缺陷分析：a. 中等缺陷1个，在程序的注释中出现错误，将近区注释为远区，修改后问题得到了解决，提高了程序的可读性。b. 严重缺陷1个，在XX号无效的判别中，本应判断大于10，但误设计为0，修改后经回归测试问题得到了解决。4. 测试记录a 测试时间：b 地点：c 硬件配置：AMD 四核 640，内存2G，硬盘320Gd 软件配置：Wondows ，e 被测软件版本号： f 所有测试相关活动的日期和时间、测试操作人员等记录见软件测试记录文档。4.测试结果在两个阶段测试过程中共发现软件缺陷20个，经软件开发人员确

19、认的缺陷为20个，经过改正的代码消除了所有以确认的软件缺陷并通过了回归测试。因测试条件所限，未能进行软件的确认测试和系统测试。5 评估和建议（1）. 软件评估 a. 软件编码规范化评估经过回归测试，未残留的软件编码规范性缺陷。软件代码文本注释率约为42%，代码注释充分，有利与代码的理解和维护。b. 软件动态测试评估被测软件单元的总数：使用的测试用例个数：达到软件测试出口准则的软件单元数，通过率：通过单元和集成测试得知：软件代码逻辑清晰、结构合理、程序单元间接口关系一致，运行稳定。（2）. 改进建议a. 建议在软件开发项目中全面实施软件工程化，加强软件开发的管理工作。b. 建议进一步加强软件需求规格说明、软件设计文档编制以及编写代码的规范化。特别是应该将系统中的硬件研制和软件研制分别管理，软件文档编制的种类和规格按照相关标准执行。c. 尽早开展软件测试工作。在软件研制计划安排上给软件测试留有必要的时间，在资源配置上给软件测试必要的支撑。d. 建议结合系统联试，开展软件的确认和系统测试。六、实现七、维护八、总结