校园卡管理系统-教学实习报告

《校园卡管理系统-教学实习报告》由会员分享，可在线阅读，更多相关《校园卡管理系统-教学实习报告（60页珍藏版）》请在装配图网上搜索。

1、天津农学院计算机科学与信息工程系实用软件文档书写教学实习报告实习名称： 校园卡管理系统 专 业： 软件工程 成 绩： 2015年 6或22 月目 录一、可行性研究3二、需求分析8三、概要设计16四、详细设计26五、软件测试36六、软件测试报告49七、系统用户说明54八、系统操作手册58一、可行性研究1.引言1.1编写目的 校园卡管理系统模块是为了实现学生生活的优化和校园服务的简洁和智能而设计的，通过试用本系统，学生可以更加有效的管理自己的生活和日常安排，使学生的校园生活更加方便。1.2背景 随着我国大学生的扩招，大学生的数量越来越多，因此给校园学生的衣食住行等生活服务带来了诸多不便，所以在此背

2、景下，校园卡管理系统就形成了，我们在校园卡的设计上目的很明确，并按照学生在校园中的生活习惯来开发的，充分考虑了学生和学校的要求而设计的。 项目名称：校园卡管理系统 项目提出者及用户：天津农学院 项目开发者：软件工程系3、4班1.3定义DFD (Data Flow Diagram) 系统数据流程图E-R图 (Entity-Relationship Diagram) 实体关系图1.4参考资料1）ASP.NET 从入门到精通；2）实用软件文档写作 肖刚 古辉 等编著，北京大学出版社，2005年2月。2.可行性研究的前提2.1要求2.11功能a.可以实现用户登录b.能够认证登录用户 .学生 .商家 .

3、财务处c.系统管理 .学生 1.充值金额 2.学生个人信息 3.消费记录 .商家 1.查询订单 2.管理商品 .财务处 1.查询校园卡交易记录 2.修改和删除、增加学生 3.查看邮件2.12性能1）系统的整体性 系统开发的需要管理内部的整体性，需要与各个阶段和各个模块相互结合，不可分割。2）系统的实用性 该卡将应用到实际的情况中，在校区的学生都可以使用，可以用来购物、充值等多种功能。3）系统的适应性 该系统除了在本校使用，也可以运用到其他各高校，使用方便简单快捷，便于学生使用。4）系统的可靠性 该系统比较稳定，数据都有备份，能够自我恢复。可靠性是该系统的首要条件。5）系统的标准化 该系统使用的

4、代码标准化和程序设计的规范化。软件按国家标准设计，便于人们交流和系统的连接。6）人机系统使用人机系统，人与计算机的结合，便于管理，更加智能化。2.13安全性与保密性 所有的信息都有相应的密码保护，使用者的信息只有使用者自己知道，其余人没有查看别人信息的功能。2.14本系统相连接的其他系统本模块由系统主界面调入，实现校园卡的所有功能。2.15完成期限该系统将在本学期内完成。2.2目标现在学校里的老师和学生手里都有很多卡，携带起来都非常的不方便，而且容易出错，校园卡就因此能够取代各种卡，便于老师和学生的日常生活，同时也提高学校的管理水平。2.3可行性研究的方法 通过在学校里做的调查，咨询同学们的建

5、议，我们添加相应的功能，使该系统能得到了同学们的认可，就说明该系统可行。2.4评价尺度 评价尺度是看用户用该卡是否方便和安全，管理人员管理起来是否简便和它的出错情况以及该软件的安全性。3.对现有系统的分析3.1设备.计算机.饭卡识别器.条码识别器3.2局限性.数据的更新速度差、准确度低.该系统需要的人员较多，需要的设备也多，造成不必要的浪费。4.所建议的系统4.1对所建议系统的说明 校园卡管理系统的设计符合学生和学校管理的需求，利用计算机技术和数据库技术实现以计算机为主要工具的人机交互，数据存储的系统。可以存储持卡人信息，持卡人具有充值、购物等功能。4.2改进之处 在没有该系统之前，学生采用多

6、卡是管理的模式，给学生带来了诸多不便，此校园卡管理系统解决了学生的这一问题，使学生校园生活更加便捷，同时也利于高校的管理。4.3影响.对设备的影响 仍可以使原来的数据信息，设备没影响。.对软件的影响 无影响.对用户的影响 更便于用户的使用，使用户更容易接受。.对开发的影响 需要用户的和高校的支持。 需要使用到学生信息的数据库，有可能丢失数据信息。4.4技术方面的可行性 在多种限制的条件下，使用目前的技术开发该系统，需要有一下决策：.尽可能的使用可靠地开发工具。.采用成熟的软件。.保证资源的信息的安全性。.用户参与，更好的与用户结合。5.结论 从以上所有条件下来看，该系统都是可行的，可以立即筹备

7、开发新系统。二、需求分析1.引言： 本需求分析文档就是为了说明校园卡管理系统最终所运行的条件，性能要求及要实现的功能，为进一步的设计与实现打下良好的基础。本文档以文档的形式将用户对系统的需求明确下来，是与同学们沟通了解的成果。2.开发背景：系统名称：校园卡管理系统需求背景： 由于电子管理系统的多功能化，各大校园纷纷使用电子记账卡对大学生的消费进行管理，因此对合理、高效的校园卡管理系统有着迫切的需求。系统用途： 本系统为各大校园的大学生在学校内的各类基础消费（饮食、购物、书籍借阅查询等）使用。 系统开发人员：本系统由3班王凯、潘玉珠、胡礼、张方玉，4班许帅杰、许勇共同完成。3.系统设计分析本系统

8、适用于各大校园，其功能主要分为：1)用户管理：用于对用户的注册、查询信息、修改等。2)借阅管理：用于对图书馆的图书的查询，方便查看记录。3)消费管理：用于对用户的消费限制、查询。4)财务管理：用于管理者对用户的信息录入、账目明细查询、异常处理等。5)商城管理：用于商家对商品的上下架管理、财务查询管理、商品信息管理。4.具体需求分析 1)学生：学生可通过进入校园卡管理系统进行消费记录查询、余额查询、图书是否借出查询、借阅日期记录查询及修改信息等。2)图书管理员：管理员可在网上对学生的校园卡进行管理、查看对比之下更加便捷。3)财务管理员：对学生充值及消费信息进行汇总查看、管理4)商城管理员：对商品

9、的增、删、查、改、对商品能进行审查、能够查询账目明细。5)系统管理员：对校园卡管理系统进行权限分配6)校园卡充值管理员：能接受和处理校园卡的挂失、网上及实地的充值、能查询个人信息及消费记录情况。5.用例图： 图1 校园卡用例图6.数据流图：学生信息表学生信息录入借阅书籍信息数据库借阅信息录入管理员消费信息数据表消费信息录入商品信息数据表商品信息录入 图2 整体数据流图用户基本信息提交用户信息姓名性别系别班级要求信息完整信息完整？用户基本信息录入 数据库分配学号录入数据库（初始密码为学号，用户自己修改）创建新用户 图3 信息录入数据流图用户存款确认金额无误数据库更新校园卡信息 图4充值流图数据库

10、用户申请挂失/解锁重新输入输入用户学号及卡号验证学号和密码是否正 确对校园卡用户进行挂失/解锁 图5 校园卡挂失/解锁流图输入用户ID及密码数据库显示校园卡信息用户ID密码正确？ 图6 校园卡信息查询流图输入用户ID及密码用户ID密码正确？显示校园卡信息密码修改输入旧密码密码正确？输入新密码 再次输入数据库修改成功 图7 密码修改流图7.数据字典名字：学生信息学号 = 数字姓名 = 汉字性别 = 男|女名字：校园卡信息校园卡ID = 数字余额= 数字锁=true|false名字：校园卡历史校园卡ID = 数字时间=时间格式款额=数字操作=存款|消费名字：校园卡挂失/解挂校园卡ID = 数字名字

11、：校园卡刷卡消费校园卡ID= 数字限定金额=30数字30余额= 数字锁=true|false名字：存款校园卡ID=数字充值额=数字余额= 数字锁=true|false名字：校园卡借书记录校园卡ID=数字借出 = 汉字日期 = 数字名字：修改用户信息校园卡ID=数字学号 = 数字姓名 = 汉字性别 = 男|女8.数据字典卡片：8.1学生信息名字：学生信息 描述：记录学生相关信息定义：学生信息=学号+姓名+性别+位置：数据库8.2校园卡信息名字：校园卡信息 描述：显示校园卡的信息定义：校园卡信息 =校园卡ID+余额+锁位置：数据库8.3校园卡历史信息名字：校园卡历史信息 描述：记录校园卡使用历史的

12、信息定义：校园卡历史信息=校园卡ID+时间+款额+操作位置：数据库8.4校园卡挂失/解挂名字：校园卡挂失/解锁 描述：学生向管理员提出申请，进行校园卡的挂失或者解锁定义：校园卡挂失/解锁=校园卡ID+密码位置：数据库8.5校园卡刷卡消费名字：校园卡刷卡消费 描述：学生刷卡消费的情况定义：校园卡刷卡消费=校园卡ID+密码+限定金额+锁位置：数据库 管理系统/刷卡器8.6存款名字：存款 描述：学生向校园卡存款定义：存款=校园卡ID+密码+充值额+锁位置：数据库8.7校园卡借书记录名字：校园卡借书记录 描述：学生借书定义：校园卡借书记录=校园卡ID+密码+学号位置：数据库8.8修改密码信息名字：修改

13、密码信息 描述：学生修改个人密码信息定义：修改密码信息=校园卡ID+密码+学号位置：数据库三、概要设计1.1 编写目的本设计文档就是为了说明校园卡管理系统最终所运行的条件，性能要求及要实现的功能，将项目开发进程中或者项目结束后提供给双方人员使用，同时也可以作为实施后期的维护人员使用。1.2 项目背景由于电子管理系统的多功能化，各大校园纷纷使用电子记账卡对大学生的消费进行管理，因此对合理、高效的校园卡管理系统有着迫切的需求。1.3 定义B/S ：(Browser/Server结构）结构即浏览器和服务器结构。需求： 用户解决问题或达到目标所需的条件和功能；系统或系统部要满足合同、标准，规范或其他正

14、式文档所需具有的条件及权能。1.4 参考资料实用软件文档写作清华大学出版社2 任务概述2.1 目标校园卡管理系统的功能有：用户管理，借阅管理，消费管理，财务管理，商城管理等。数据初始录入，修改，信息统计，盘点管理，审核管理和数据的导入功能。密码设置，权限设置，系统日志及系统退出这主要是系统管理的功能。2.2 运行环境主机：PC兼容机内存256M以上，显示分辨率800*600以上操作系统：window98，window2000，WindowXP及Win7等。2.3 需求概要要求系统操作简单，流畅，拥有对并发，恶意攻击等异常处理。页面设计要简单，得体。不同用户群的权限一定要分清界明，以免操作不当引

15、起不必要或者不可挽回的损失。对于借阅的还书时间有必要的提醒，对于丢失校园卡情况能够及时的反馈处理，商城有详细的评价和服务体系，以保证学生对系统有很好的体验，解决实际问题等等。2.4 限制描述设计应当是模块化的，即该软件应当从逻辑上被划分成多个部件，分别实现各种特定功能和子功能。学生的学号是贯穿所有系统的属性，是连接各个模块的桥梁，保证它的唯一性和不可替代，修改性非常重要。校园卡的ID（编号）也是唯一的，由学校发放，且与一个学号绑定，如需换绑，解绑向管理员申请。学生可以在网上进行对校园卡的挂失以保证财产安全，避免财产损失。但为防止恶意，或者虚假挂失，保证系统，及用户使用安全，解挂需到管理员处申请

16、解挂。每一个用户群体不能越权，高级功能和权限必须由高级管理员分配和处理。，一般用户只具有对数据的只读属性，不能更改和删除。设计最终应当给出具体的模块（例如子程序或过程），这些模块就具有独立的功能特性。3 总体设计3.1 模块外部设计登录模块： 用户输入学号/相应各级管理员账号/商家账号和相对应匹配的密码进行验证登录，实现对自己权限内的信息进行管理。挂失模块：验证详细的用户信息及口令，密码，校园卡信息，以及消费密码，以完成对校园卡的挂失处理。校园卡管理模块：对自己消费信息的查询，明细查询，充值，限额消费，消费密码的设置，修改，丢失找回，图书借阅与归还情况一览。购物车模块：学生对购物车进行管理，具

17、有增、删、查、改操作权限。订单管理模块：学生对订单进行增、删、查、改操作。商家物品上架模块：商家对物品进行上架处理，包括对页面的布局更改。具有对此模块数据的商城管理员对商家上架物品的审核模块：商城管理员对商家上架的物品进行上架前审核，防止出现假推销，假宣传，恶意竞争，以及对不良商家的再次变向上架打击处理，具有对所有商家及商家上架的产品的全部操作权限，可以增、删、查、改涉及的相关数据。财务管理模块：学校财务管理员定期对每个商家的收入情况，学生的支出情况进行管理汇总，对其中出现的问题进行维护处理。商品展示模块：系统的界面设计人员对界面进行设计管理，拥有对相应功能及部件的增、删、查、改操作权限。后台

18、支付交付处理模块：调用外部接口，与各大银行和支付平台合作完成网上支付交易。3.2 基本设计概念和处理流程系统的总体处理数据流程如下图：学生信息表学生信息录入借阅书籍信息数据库借阅信息录入管理员消费信息数据表消费信息录入商品信息数据表商品信息录入3.3 功能分配：整体的功能模块图：校园卡管理系统系统管理员用户管理商城管理消费管理财务管理借阅管理4 接口设计4.1 用户接口管理员，商家的录入界面学生，管理员，商家的登录界面学生，管理员，商家的查询页面学生，管理员，商家的信息修改界面学生校园卡的充值界面 学生校园卡的挂失/解挂界面学生的购物车结算，订单处理界面4.2 外部接口快捷支付网上银行支付系统

19、；打印机打印系统所需要打印的表格内容4.3 内部接口登录模块的调用基础信息维护模块的数据挂失模块的调用基础信息维护模块的数据借阅管理模块的调用基础信息维护模块的数据校园卡管理模块的调用的基础信息维护模块的数据和借阅管理模块的数据购物车模块的调用的基础信息维护模块的数据和商家上架物品模块信息的数据订单管理模块调用的基础信息维护模块的数据，后台支付处理模块的数据以及商家上架物品模块的数据财务管理模块的调用的基础信息维护模块的数据，后台支付处理模块的数据以及商家上架物品模块的数据5 数据结构设计5.1 逻辑结构设计因为数据库表比较多,现在写出一些重要的表来记录（1）学生信息 Student列名数据类

20、型可否为空说明StuNumint(11)NOT NULL学生学号（主键）StuPwdvarchar(24)NOT NULL登陆密码BuyPwdvarchar(6)NULL消费密码StuClassvarchar(30)NULL行政班级STuTelvarchar(20)NULL联系电话StuCommentvarchar(200)NULL注释StuNameVarchar(20)NULL姓名StuSexBOOLBULL性别ScdIDint(11)NOT NULL校园卡ID或言编号（外键）（2）校园卡信息 SchoolCard列名数据类型可否为空说明ScdIDint(11)NOT NULL校园卡ID或言

21、编号（主键）ScdTolMonyfloatNULL校园卡余额StuNumint(11)NOT NULL学生学号（外键）ScdLSteBOOLNULL锁状态ScdByTimeSmalldate()NULL产生消费行为的时间ScdByMonyfloatNULL消费的金额ScdByGoodsVarchar(20)NULL购买的物品名称ScdOpraSteBOOLNULL校园卡的操作：充值或消费ScdCocmeLimtInt(30)NULL限制单次消费数额（3）图书借阅信息 Library 列名数据类型可否为空说明BookNamevarchar(30)NULL书的名称BorrowTimefloatNU

22、LL借阅日期ShouldBTimeDate()NULL理论归还日期FactBTimeDate()NULL实际归还日期ScdIDint(11)NOT NULL校园卡ID或言编号（主键）BackSteBOOLNULL书的归还状态（4）商品信息 GoodsInfo 列名数据类型可否为空说明GoodsIDInt(30)NOT NULL商品ID （主键）GoodsTypevarchar(20)NULL商品类型GoodsPricefloatNUL商品价格GoodsAmountInt(30)NULL库存数量GoodsBrandVarchar(20)NULL品牌GoodsNamevarchar(40)NULL

23、商品名称SellersNameVarchar(20)NULL商家姓名SellersIDInt(30)NOT NULL商品ID （外键）（5）商家信息 SellersInfo 列名数据类型可否为空说明SellersIDInt(30)NOT NULL商品ID （主键）SellersNameVarchar(20)NULL商家姓名SellersShopNamevarchar(20)NULL商家店铺名称SellersIncomefloatNULL商家当月销售额SellersGodsTypeVarchar(20)NULL销售商品类型GoodsIDInt(30)NOT NULL商品ID （外键）Seller

24、sLicencevarchar(40)MULL营业执照（营业许可）SellersBankcardvarchar(18)NULL商家银行卡号SellersCrdMacNumInt(30)NULL商家刷卡机编号5.2 物理结构设计密码： 是以加密的形式存放的于数据库中的,并且是以参数化进行处理和访问。编号和ID：是由系统生成（用户可以自定义）长度为30,学生学号和校园卡ID号是是11位长度。 5.3 数据结构与程序的关系系统的数据结构由标准数据库语言SQL生成。具体的例如创建部门信息表格的程序用SQL表示就是：create table Student(StuNum int(11) Primary

25、Key, NOT NULL,StuPwd varchar(24) NULL,BuyPwd varchar(6) NULL,StuClass varchar(30) NULL, STuTel varchar(30) NULL, StuComment varchar(30) NULL, StuName varchar(30) NULL, StuSex BOOL,NULL, foreign key (ScdID) references int(11),NOT NULL,6 运行设计6.1 运行模块的组合具体软件的运行模块组合为程序多窗口的运行环境，各个模块在软件运行过程中能较好的交换信息，处理数据。

26、6.2 运行控制软件运行时有较友好的界面，基本能够实现用户的数据处理要求。6.3 运行时间系统的运行时间基本可以达到用户所提出的要求。7 出错处理设计7.1 出错输出信息在用户使用错误的数据或访问没有权限的数据后，系统给出提示：“对不起，你非法使用数据，没有权限！”而且用户的密码管理可以允许用户修改自己的密码，不允许用户的匿名登录。7.2 出错处理对策由于数据在数据库中已经有备份，故在系统出错后可以依靠数据库的恢复功能，并且依靠日志文件使系统再启动，就算系统崩溃用户数据也不会丢失或遭到破坏。但有可能占用更多的数据存储空间，权衡措施由用户来决定。7.3系统恢复设计如果当前系统出现一些异常,而影响

27、了用户的正常使用,因为数据库有备份,程序代码也有备份,软件开发人员应尽快发现问题的原因,及时改正过来,以保证系统的正常运行。8 安全保密设计系统的系统用户管理保证了只有授权的用户才能进入系统进行数据操作，而且对一些重要数据，系统设置为只有更高权限的人员方可读取或是操作。系统安全保密性较高。9 维护设计由于系统较小没有外加维护模块，因为维护工作比较简单，仅靠数据库的一些基本维护。四、详细设计1.引言1.1 编写目的校园卡系统详细设计是设计的第二个阶段。本说明在概要设计中产生的功能模块经进行过程描述，设计功能模块的内部细节，包括算法和详细数据结构，为编写源代码提供必要的说明。具体的说，模块设计就是

28、要为已经产生的校园卡管理各子系统设计详细的算法。但这并不同于系统实现阶段用具体的语言编码，它只是对实现细节作精确的描述，这样编码阶段可以将详细设计中对功能实现的描述，直接翻译、转化为程序设计语言书写程序。软件开发小组的产品实现成员应该阅读和参考本说明进行代码编写、测试。1.2 项目背景根据XX学校希望能够充分利用现代科技来提高校园卡的管理效率。由于电子管理系统的多功能化，各大校园纷纷使用电子记账卡对大学生的消费进行管理，因此对合理、高效的校园卡管理系统有着迫切的需求。1.3 定义 VS 2010：开发工具 ASP.NET：软件开发技术 Windows 2007/Xp/10: 运行环境 SQL

29、server：数据库管理软件1.4 参考资料软件工程导论第五版 张海藩著 清华大学出版社实用软件工程 LeszeK.Maciaszek Bruc Lee Liong 著2 程序系统的结构系统结构图:学生图书管理员财务管理员系统管理员校园卡充值管理 员卡信息查询卡信息录入卡挂失/解锁卡密码修改存款财 务 管 理商品 增删查改 书 籍 输 入用户退出商城管理员用户类别登录系统共由十个模块组成：登录模块、挂失模块、校园卡管理模块、购物车模块、订单管理模块、商家商品上架模块、商城管理员对商家商家物品的审核模块、财务管理模块、商品展示模块、后台支付模块3 程序设计说明3.1 登录模块学生3.1.1 功能

30、流图：图书管理员财务管理员选择登录人类别系统管理员系统管理员校园卡充值管理员商城管理员3.1.2功能描述：（1）功能描述：提高系统的安全性（2）前提业务：无（3）功能约束：权限约束（4）操作权限：以登录人的身份确定3.13界面设计3.2 挂失模块3.2.1 功能流图：系统管理员校园卡的挂失处理校园卡充值管理员3.2.2 功能描述：（1）功能描述：验证详细的用户信息及口令，密码。校园卡信息及消费密码，完成对校园卡的挂失处理（2）前提业务：系统管理员或校园卡管理登录系统（3）功能约束操作：权限限制（4）操作权限：系统管理员、校园卡管理员卡信息查询3.3 校园卡管理模块3.3.1 功能流图：学生登录

31、后卡密码修改存款3.3.2 功能描述：（1）功能描述：对自己消费信息的查询，明细查询，充值，限额消费，消费密码的设置，修改，丢失找回，图书借阅与归还情况一览。（2）前提业务：学生登录系统（3）功能约束操作：权限限制（4）操作权限：学生3.4 购物车模块3.4.1 功能流图：购物操作学生登录3.4.2 功能描述：（1）功能描述：学生对购物车进行增删改查操作。（2）前提业务：学生登录系统，进行商品购买（3）功能约束操作：权限限制（4）操作权限：学生3.5 订单管理模块3.5.1 功能流图：订单管理购物操作学生登录3.5.2 功能描述：（1）功能描述：学生对购物订单进行增删改查操作。（2）前提业务：

32、学生登录系统，进行商品购买后（3）功能约束操作：权限限制（4）操作权限：学生3.6 商家物品上架模块3.6.1 功能流图：商品上架商家登录3.6.2 功能描述：（1）功能描述：商家对物品进行上架处理，包括对页面的布局更改。具有对此模块数据的增删查改。（2）前提业务：商家登录（3）功能约束操作：权限限制（4）操作权限：商家3.7 商城管理员对商家商家物品的审核模块3.7.1 功能流图：商城管理员 审核商品3.7.2 功能描述：（1）功能描述：商城管理员对商家上架的物品进行上架前审核，防止出现假推销，假宣传，恶意竞争，以及对不良商家的再次变向上架打击处理，具有对所有商家及商家上架的产品的全部操作权

33、限，可以增、删改、查涉及的相关数据。（2）前提业务：商场管理员登陆（3）功能约束操作：权限限制（4）操作权限：商场管理员3.8 财务管理模块财务管理3.8.1 功能流图：财务管理员登陆商品管理及账单查询3.8.2 功能描述：（1）功能描述：学校财务管理员定期对每个商家的收入情况，学生的支出情况进行管理，对其中出现的问题进行维护。（2）前提业务：财务管理员 （3）功能约束操作：权限限制（4）操作权限：系统管理员、校园卡管理员3.9 商品展示模块3.9.1 功能流图：校园卡操作系统管理人员3.9.2 功能描述： （1）功能描述：系统管理人员实现对校园卡的信息查询、信息录入、卡的挂失和解锁。以及系统

34、界面的设计管理，拥有相对应功能及部件的增删查改操作权限。（2）前提业务：系统管理员（3）功能约束操作：权限限制（4）操作权限：系统管理员3.10 后台支付交付处理模块3.2.1 功能流图：支付学生购买学生登录3.2.2 功能描述：（1）功能描述：调用外部接口，与各大银行和支付平台合作完成网上支付交易。（2）前提业务：学生登录系统，实现商品购买 （3）功能约束操作：权限限制（4）操作权限：学生3.11 接口3.12 测试要点3.12.1 测试范围：3.12.2 测试方法 功能性测试：黑盒测试。五、软件测试1.引言 本需测试报告文档就是为了说明校园卡管理系统最终所运行的条件，性能要求及实现的功能的

35、测试，从测试中发现和改进问题。让系统更加完善。1.2编写目的编写该测试总结报告主要有以下几个目的：通过对测试结果的分析，得到对软件质量的评价分析测试的过程，用户体验，资源，信息，为以后制定测试计划提供参考评估测试测试执行和测试计划是否符合分析系统存在的缺陷，为修复和预防bug提供建议1.3背景根据XX学校希望能够充分利用现代科技来提高校园卡的管理效率。由于电子管理系统的多功能化，各大校园纷纷使用电子记账卡对大学生的消费进行管理，因此对合理、高效的校园卡管理系统有着迫切的需求。1.4用户群主要读者：校园卡管理项目管理人员，校园卡管理项目测试经理其他读者：校园卡项目相关人员。1.5定义严重bug：

36、出现以下缺陷，测试定义为严重bug系统无响应，处于死机状态，需要其他人工修复系统才可复原。点击某个菜单后出现“The page cannot be displayed”或者返回异常错误。进行某个操作（增加、修改、删除等）后，出现“The page cannot be displayed” 或者返回异常错误当对必填字段进行校验时，未输入必输字段，出现“The page cannot be displayed” 或者返回异常错误系统定义不能重复的字段输入重复数据后，出现“The page cannot be displayed” 或者返回异常错误1.6测试对象略1.7测试阶段1.8参考资料校园卡管

37、理系统需求和设计说明书校园卡管理系统数据字典校园卡管理系统后台管理系统测试计划校园卡管理系统后台管理系统测试用例校园卡管理系统项目计划2.测试概要校园卡管理系统测试从2015年5月20日开始到2015年6月2日结束，持续14天，测试功能点校园卡管理系统测试从2007年7月2日开始到2007年8月10日结束，共持续39天，测试功能点13个，执行130个测试用例，平均每个功能点执行测试用例10个，测试共发现5个bug，其中严重级别的2个，无效bug3个，平均每个测试功能点0.4个bug。校园卡管理系统总共发布11个测试版本，其中B1B5为计划内迭代开发版本（针对项目计划的基线标识），B6B8为回归

38、测试版本。计划内测试版本，B1B4测试进度依照项目计划时间准时完成测试并提交报告，其中B4版本推迟一天发布版本，测试通过增加一个人日，准时完成测试。B5版本推迟发布2天，测试增加2个人日，准时完成测试。B6B11为计划外回归测试版本，测试增加5个工作人日的资源，准时完成测试。XX测试通过Bugzilla缺陷管理工具进行缺陷跟踪管理，B1B4测试阶段都有详细的bug分析表和阶段测试报告。2.1进度回顾版本/时间计划开始时间实际开始时间计划完成时间实际完成时间加班增加资源B12015.5.202015.5.202015.5.212015.5.21否否B22015.5.212015.5.212015

39、.5.222015.5.22否否B32015.5.22.2015.5.222015.5.242015.5.24否2个人日B42015.5.242015.5.242015.5.262015.5.261个人1天1个人2天2个人日B52015.5.262015.5.262015.5.272015.5.27否2个人日B62015.5.272015.5.282015.5.282个人1天2个人日B72015.5.282015.5.292015.5.291个人1天1个人日B8B92015.5.302015.5.302015.6.22015.6.2否2个人日B10合计1个人6天11个人日2.2测试执行此次测试

40、严格按照项目计划和测试计划执行，按时完成了测试计划规定的测试对象的测试。针对测试计划规定的测试策略，在测试执行中都有体现，在测试执行过程中，依据测试计划和测试用例，对系统进行了完整的测试2.3测试用例2.3.1功能性用户管理，借阅管理，消费管理，财务管理，商城管理等。数据初始录入，修改，信息统计，盘点管理，审核管理和数据的导入功能。密码设置，权限设置，系统日志及系统退出这主要是系统管理的功能。 需求规定的输入输出字段，以及需求规定的输入限制2.3.2易用性操作按钮提示信息正确性，一致性，可理解性限制条件提示信息正确性，一致性，可理解性必填项标识输入方式可理解性中文界面下数据语言与界面语言的一致

41、性3.测试环境3.1.1软硬件环境硬件环境应用服务器数据库服务器客户端硬件配置CPU：Intel(R) Celeron(R) CPU 2.40GHz stepping 01Memory： 1048256kHD：ST380817AS 80G SATACPU：Intel(R) Celeron(R) CPU 2.40GHz stepping 01Memory： 1048256kHD：ST380817AS 80G SATACPU：Intel(R) Celeron(R) CPU 2.40GHz stepping 01Memory： 1048256kHD：ST380817AS 80G SATA网络环境10

42、M LAN10M LAN10M LAN 3.1.2网络拓扑4.测试结论4.1功能性系统正确实现了通过数据字典管理基础数据的功能，实现了数据内容的多语言功能，实现了中英文界面。实现了基础数据管理，酒店集团管理，酒店基础信息管理，渠道管理，代理管理，用户管理的查询，添加，修改，删除的功能，系统还实现了将权限控制细化到菜单按钮的功能。系统在实现用户管理下的权限管理功能时，存在重大的缺陷，权限控制不严密，权限设计有遗漏。4.2易用性 现有系统实现了如下易用性： 查询，添加，删除，修改操作相关提示信息的一致性，可理解性 输入限制的正确性 输入限制提示信息的正确性，可理解性，一致性现有系统存在如下易用性缺

43、陷： 界面排版不美观 输入，输出字段的可理解性差 输入缺少解释性说明 中英文对应的正确性 中英文混排4.3可靠性现有系统的可靠性控制不够严密，很多控制是通过页面控制实现的，如果页面控制失效，可以向数据库插入数据，引发错误。现有系统的容错性不高，如果系统出现错误，返回错误类型为找不到页面错误，无法回复到出错前的状态4.4兼容性现有系统支持window下的IE浏览器和傲游浏览器，支持linux系统下的IE浏览器和火狐浏览器。现有系统未进行其他兼容性测试4.5安全性现有系统控制了以下安全性问题： 把某一个登录后的页面保存下来，不能单独对其进行操作不进行登录 直接输入某一页面的Url能否打开页面并进行

44、操作不应该允许。现有系统未控制以下安全性问题： 用户名和密码应对大小写敏感 登陆错误次数限制5.分析摘要5.1覆盖率此次测试，所有测试用例都是在中文界面下执行，未在英文界面下执行，测试不包括英文界面下的测试，也不包括正对英文翻译的测试。此次测试，部分页面需求描述无明确的定义，对输入限制无详细定义，无明确的测试依据，在测试过程中，测试是根据输入字段含义，测试人员理解，以及和项目经理，开发人员沟通获得测试依据，无法保证测试依据的正确性和完整性，因此，没有进行完整的，正确的无效数据的测试，测试覆盖率不够，无法保证测试的有效性和正确性下面为此次测试测试用例覆盖率分析图：5.2遗留缺陷的影响 1 缺陷描

45、述：校园卡管理商品项添加页面， “距离”字段无单位，建议增加单位缺陷影响：距离字段无单位说明，无衡量标准，用户易用性不好推迟原因：需求定义无单位定义，统一在升级版本中解决2 缺陷描述：数据字典种类修改，默认值设置后，在调用该数据字典种类的数据字典，默认值无显示缺陷影响：数据字典种类的默认值设置后，不能显示设置的默认值，相当于数据字典种类默认值设置功能未实现推迟原因：该功能暂时不好实现，需要和和系统的默认语种一起处理。3 缺陷描述：担保政策管理页面，“Edposit Due”缺少解释行输入描述信息缺陷影响：缺少解释性输入描述信息，用户不理解应该输入什么内容推迟原因：需求没有描述，需要解释性说明文

46、字由项目经理整理后，在升级版本中添加4 缺陷描述：校园卡管理渠道绑定关系权限控制出现权限异常错误缺陷影响：a权限控制易用性不好，会引起用户误操作;b权限控制错误推迟原因：B9版本发现该权限，B10版本未通过验证。该模块后台无insert权限,只有Update权限，与其他模块不同，需要重新设置权限控制方式。5.3建议 在项目开始的时候应该制定编码标准，数据库标准，需求变更标准，开发和测试人员都严格按照标准进行，可以在后期减少因为开发，测试不一致而导致的问题，同时也可以降低沟通成本。 发布版本的时候，正确布置测试环境，减少因为测试环境，测试数据库数据的问题而出现的无效bug。 开发人员解决bug的

47、时候，填写bug原因以及解决方式，方便bug的跟踪。 开发人员在开发版本上发现bug，可以通知测试人员，因为开发人员发现的bug很有可能在测试版本上出现，而测试人员和开发人员的思路不同，有可能测试人员没有发现该bug，而且，这样可以保证发现的bug都能够被跟踪。6.度量6.1资源消耗测试时间2015年5月20日至2015年6月2日共14天测试人力1人7天1人35天42人天硬件资源服务器：PC 2台客户端：PC 2台7.典型缺陷引入原因分析测试过程中发现的缺陷主要有以下几个方面：1 需求定义不明确需求文档中，存在功能定义错误，输入输出字段描述错误，输入输出字段限制定义错误，输入输出限制定义缺失这

48、几种类型的缺陷。使得开发人员根据需求进行设计时，没有考虑相关功能的关联性，以及需求错误的地方，在测试过程中，需求相关的问题表现出来。需求做改正，设计必须跟着做改动，浪费时间和影响开发人员的积极性，降低开发人员对需求的信任，可能会导致开发人员不按照需求进行设计而根据自己的经验来进行设计。2.功能性错误 功能没有实现，导致无法进行需求规定的功能的测试。主要是无法进入酒店设施管理，会议室管理页面，酒店安全项管理无法保存信息，地区，房型删除功能缺失。 功能实现错误，实现了需求未定义的功能，执行需求定义的功能时系统出现错误。主要是角色拥有不属于自己的权限，酒店联系人删除页面跳转错误等。 3.页面设计和需

49、求不一致页面设计没有根据需求进行，输入，输出字段文字错误，用户无法理解字段含义。页面设计没有完成需求规定的输入限制验证，导致用户可以输入错误的或者无效的数据，这些数据有可能会引起功能性错误。4.多语言数据问题 系统中很多输入字段是通过调用数据字典的方式输入，但是现有系统中，很多数据字典的多语言信息没有完成，导致使用多语言的时候，显示空白字段。 系统中很多地方使用多语言，由于多语言编码不统一导致页面设计和数据设计使用语言编码不一致，由此引起的多语言数据无法显示的缺陷。5.页面设计易用性缺陷 页面设计不友好，系统中很多页面的输入字段无明确的输入提示，用户无法理解何种输入是正确的，但是用户输入错误后

50、，系统提示出错，增加用户负担。 提示信息错误，不同模块相同结果的提示信息不一致，用户操作后，相应的提示信息不明确，引起用户误解。 提示信息一致性，用户在不同页面执行相同的操作，提示信息不同。6.开发人员疏忽引起的缺陷因为开发人员的疏忽，导致系统需要验证的地方，调用了错误的验证，系统需要进行输入控制的地方没有进行相应的控制。六、软件测试报告1.项目概述1.1项目背景 由于电子管理系统的多功能化，各大校园纷纷使用电子记账卡对大学生的消费进行管理，因此对合理、高效的校园卡管理系统有着迫切的需求。1.2参考资料编写本验收报告时主要参考了如下的资料和文献：1. 校园图书管理系统合同书（主合同）2. 校园

51、卡理系统软件开发合同书3. 软件工程系统需求分析技术应用研究4. 校园卡管理系统总体设计说明书5. 校园卡管理系统详细设计说明书6. ISO9000质量体系文件7. 校园卡管理系统管理员操作手册2验收定义2.1验收方式本系统的验收仅有客户双方的参与。主要参与者有： 项目经理 王凯：协调客户手机最终使用者提出的问题，并安排项目组成员解决；协调客户对测试方案进行确认核实，协调客户安排测试；调整肯能存在的测试遗留问题；对项目机型验收总结；向客户移交合同要求的验收阶段的全部文档，并签署文档移交备忘。 技术负责人 许勇：负责解决和解释验收前客户提出的系统问题；和客户方技术人员一起执行验收测试，并对测试结

52、果签字确认；根据测试结果提出可能的验收遗留问题；整理需要提交的各种文档。 实施人员 胡礼： 协助解决项目相关的技术问题，或协助解释澄清一些项目内部的问题。2.2验收依据校园图书管理系统合同书（主合同）校园卡管理系统软件开发合同书软件工程系统需求分析技术应用研究2.3验收环境校园卡管理系统实际运行的环境为验收环境。 服务器：新浪服务器客户机：PC2.4验收标准2.4.1系统功能标准严重程度 描 述A校园卡管理系统由于出现问题不能继续运转。校园卡管理系统的数据出现错误。如不同用户群的权限混乱B某项业务无法进行。如信息查找等。校园卡管理系统产生的数据出现错误。如与查找数据不相符。C校园卡管理系统中某

53、项操作不能继续运转或错误，但不影响系统的进行。（有替代办法）如：某些查询数据出现重复。D其他校园卡管理系统在某种状态下产生的错误，不影响管理及正常业务。如果各模块验收测试结果如下表所述则视为验收合格，否则将进行修改，以进行再次验收评审。严重程度关系发生个数A=0B =102.4.2性能标准 要求系统操作简单，流畅，拥有对并发，恶意攻击等异常处理。页面设计要简单，得体。不同用户群的权限一定要分清界明，以免操作不当引起不必要或者不可挽回的损失。对于借阅的还书时间有必要的提醒，对于丢失校园卡情况能够及时的反馈处理，商城有详细的评价和服务体系，以保证学生对系统有很好的体验，解决实际问题等等。3.验收范

54、围根据校园图书管理系统合同书（主合同）、校园卡管理系统软件开发合同书划定的验收范围为： 登录模块： 用户输入学号/相应各级管理员账号/商家账号和相对应匹配的密码进行验证登录，实现对自己权限内的信息进行管理。挂失模块：验证详细的用户信息及口令，密码，校园卡信息，以及消费密码，以完成对校园卡的挂失处理。 校园卡管理模块：对自己消费信息的查询，明细查询，充值，限额消费，消费密码的设置，修改，丢失找回，图书借阅与归还情况一览。购物车模块：学生对购物车进行管理，具有增、删、查、改操作权限。 订单管理模块：学生对订单进行增、删、查、改操作。商家物品上架模块：商家对物品进行上架处理，包括对页面的布局更改。具

55、有对此模块数据的 商城管理员对商家上架物品的审核模块：商城管理员对商家上架的物品进行上架前审核，防止出现假推销，假宣传，恶意竞争，以及对不良商家的再次变向上架打击处理，具有对所有商家及商家上架的产品的全部操作权限，可以增、删、查、改涉及的相关数据。财务管理模块：学校财务管理员定期对每个商家的收入情况，学生的支出情况进行管理汇总，对其中出现的问题进行维护处理。商品展示模块：系统的界面设计人员对界面进行设计管理，拥有对相应功能及部件的增、删、查、改操作权限。 后台支付交付处理模块：调用外部接口，与各大银行和支付平台合作完成网上支付交易。3.验收人员单位 人员职责/任务联系方式/Email备注学校后勤部赵老师 生活部部长12345678891学校后勤部张老师 生活部副部长123456789904.验收时间2015年6月8号5.遗留问题 在购物车阶段，如果学生在购买产品后，再次登录。放在购物车中的物品将会被取消。 在后续的系统中会解决此问题。6交付物清单6.1文档提交清单可行性分析报告立项通知书项目评审表项目任务书预审问题清单软件需求规格说明书用户需求列表项目开发计划书风险管理计划质量保证计划模块设计数据库表结构设计界面设计阶段进度报告集成测试用例系统测试用例实现与测试计划校园卡管理系统需求说明书校园卡管理系统概要设计说明书校园卡管理系统详细说名书用户操作手册7验收结论经过测验，