银行系统实验四五报告.docx
《银行系统实验四五报告.docx》由会员分享，可在线阅读，更多相关《银行系统实验四五报告.docx（20页珍藏版）》请在冰豆网上搜索。
银行系统实验四五报告
11 测试计划（廖宇梅）
11.1 引言
11.1.1 编写目的
在开发软件的过程中，要处理非常复杂的问题，软件的开发各个阶段都会不可避免地存在误差，审查也不可能发现所以的误差，因此软件测试是保证软件质量的关键步骤，其目的就是在软件投入生产或交换的用户之前，尽可能多地发现软件的错误并解决。
11.1.2 背景
项目名称：
银行储蓄管理系统
用户：
银行
说明：
通过测试，开发尽可能满足用户需求，而不出现错误的软件
11.1.3 定义
无
11.1.4 参考资料
《软件工程导论（第四版）》张海潘清华大学出版社
《软件工程》任胜兵刑琳北京邮电大学出版社
11.2 计划
11.2.1 软件说明
对软件进行测试必须充分暴露出软件系统肯、可能出现的问题，并加以改进。
11.2.2 测试内容
对银行储蓄管理系统中的“按用户名和ID查询”模块（G6）进行黑盒测试和白盒测试。
11.2.3 “按用户名和ID查询”模块（G6）黑盒测试
11.2.3.1 进度安排
测试进行1周，此间进行观察记录
11.2.3.2 条件
操作系统：
Windows系列Server,linux系列操作系统,Windows系列Workstation
数据库管理系统：
Oracle或SQLSERVER数据库系统
开发环境：
MicrosoftVisualBasic6.0中文版
11.2.3.3 测试资料
测试用例
11.2.4 “按用户名和ID查询”模块（G6）白盒测试
11.2.4.1 进度安排
测试进行1周，此间进行观察记录
11.2.4.2 条件
操作系统：
Windows系列Server,linux系列操作系统,Windows系列Workstation
数据库管理系统：
Oracle或SQLSERVER数据库系统
开发环境：
MicrosoftVisualBasic6.0中文版
11.2.4.3 测试资料
测试用例
11.3 测试设计说明
11.3.1 “按用户名和ID查询”模块（G6）黑盒测试
11.3.1.1 控制
业务员或管理员状态下点击应用程序窗口的查询模块，即可查询操作。
11.3.1.2 输入
按照黑盒测试用例输入用户名和ID
11.3.1.3 输出
输出结果为用户储蓄的各项信息
11.3.1.4 过程
使用测试用例不断进行测试，观察和记录测试结果
11.3.2 “按用户名和ID查询”模块（G6）白盒测试
11.3.2.1 控制
业务员或管理员状态下点击应用程序窗口的查询模块，即可查询操作。
11.3.2.2 输入
按照白盒测试用例输入用户名和ID
11.3.2.3 输出
输出结果为用户储蓄的各项信息
11.3.2.4 过程
使用测试用例不断进行测试，观察和记录测试结果
11.4 评价准则
11.4.1 范围
测试用例能够覆盖满足用户的大多数需求
11.4.2 数据整理
11.4.3 尺度
测试如果能够满足储户的多数需求，并且在运行期间的出错率小于2%，则认为测试通过。
12 测试分析报告（段春林）
测试分析报告的编写是为了把组装测试和确认测试的结果、发现及分析写成文件加发记载，具体的编写内容要求如下：
12.1 引言
12.1.1 编写目的
本测试报告为银行储蓄管理系统的测试报告，目的在于总结测试阶段的测试以及分析测试的结果，描述系统是否符合需求，弄清预期结果与实际结果之间的差别。
为了发现程序中的错误，通过分析错误产生的原因和错误发展的趋势可以帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进。
12.1.2 背景
被测试软件：
银行储蓄管理系统
项目提出者：
老师
开发人员：
耿粉团、袁兴才、廖宇梅、段春林
描述：
该软件的用户主要是小型银行储蓄所，该软件安装于PC机，软件测试环境与运行环境相同，硬件配置差异不大，所以对测试结果没有多大影响。
12.1.3 定义
该软件基于微软提供的开发平台，利用VB编程语言和ACCESS数据库结合开发的应用软件。
12.1.4 参考资料
《软件工程导论》——张海潘（中）
《软件工程—实践者的研究方法》——Pressman（美）
《软件工程案例精讲》——王业龙（中）
《软件工程实验》——狄国强（中）
12.2 测度概要
1.测试组织
角色
姓名
职责
测试管理人员
耿粉团、袁兴才
1.测试策略：
测试人员分不同身份ID根据需求说明书对系统进行全面测试，并记录
2.测试进度：
一周之内完成所有测试
3.资源准备：
实验室的主机及网络。
测试人员
廖宇梅、段春林
测试执行：
根据分工，以自己的身份ID对系统测试并分析结果。
12.3 测试结果及发现
12.3.1 测试1（标识符）
对整个系统的测试情况结果如下
需求/功能
用例个数
执行总数
未执行数
未/漏测分析原因
系统功能
3
3
0
系统安全分析
2
2
0
系统性能
4
4
0
用户界面
4
4
0
运行环境
2
1
1
实验室PC机差异有限
12.3.2 测试2（标识符）
需求覆盖分析
需求项
测试类型
是否通过
备注
系统功能
系统测试
否
缺少完整的系统安装部署实用系统卸载的说明
系统性能
系统测试
是
系统安全分析
系统测试
是
用户界面
系统测试
是
运行环境
内部测试
是
使用WINDOWS提供的系统
用户手册
用户测试
是
用户体验度
12.4 对软件功能的结论
12.4.1 功能1（标识符）
12.4.1.1 能力
登录界面功能测试
输入项
类型
安全性检测
是否通过
用户名
字符型
是否含有非法字符
是
密码
字符型
是否含有非法字符，是否和用户名匹配
是
身份
字符型
选择项不能为空
是
12.4.1.2 限制
1.密码保护措施没有，先进的密码保护策略
2.用户界面美化受到非美学专业技能的限制
3.数据库查询相关信息受到技术条件和平台的限制
12.5 分析摘要
12.5.1 缺陷和限制
分类范畴
子项目
缺陷等级
备注
系统缺陷
程序所引起的死机、非法退出
A
程序死循环
A
程序错误
A
数据缺陷
数据计算错误
B
数据约束错误
B
数据输入、输出错误
B
数据库缺陷
数据库的表、缺省值未加完整性约束等
B
数据库链接错误
B
数据库中的表有过多的空值字段
B
接口缺陷
数据通信错误
B
程序接口错误
B
硬件通信、接口错误
B
业务规范
用例错误
A
默认设置不规范
B
录入错误
出现WINDOWS系统提示
A
系统停止响应
A
数据编辑无效
B
出现非法操作提示或应用程序错误提示
B
.NET错误提示
B
残留编辑信息未及时删除
B
非正常的失败或操作错误提示
B
流程错误
逻辑控制错误或数据控制错误
A
报表和查询出错
报表取数、分级汇总。
数据口径不统一，对报表筛选、过滤等操作出现错误
A
打印错误
打印及打印相关操作错误
B
权限及安全性问题
匿名登陆成功
Ａ
明码登录
Ａ
缺少必要的权限
Ａ
对不可逆的操作缺少安全提示
Ｂ
某操作员没有该权限但能进行操作
Ｂ
只有查询权限的情况下，仍然能编写成功
Ｂ
没有某权限但通过快捷菜单能够绕开
Ｂ
对权限进行多种组合但出现控制出错现象
Ｂ
默认状态下权限设置不合理
Ｃ
数据成批处理没有考虑到与权限设置存在冲突
C
功能出错
程序功能出现错误
Ｂ
程序功能无法实现
Ｃ
建议类错误
功能建议
Ｅ
操作建议
Ｅ
校验建议
Ｅ
说明建议
Ｅ
帮助文件建议
Ｅ
说明：
以上分类缺陷中的内容构成基本缺陷库，根据实际工作总结，将不断扩充完善。
如新增分类则在备注中说明
Ａ
不能执行正常工作或重要功能，程序使系统崩溃或使系统资源不足
Ｂ
严重影响系统要求或基本功能的实现，并没有办法实现
Ｃ
严重影响系统要求或基本功能的实现，但有合理的办法实现
Ｄ
使操作者不方便或遇到麻烦，但不影响系统功能的实现
Ｅ
建议性的改进要求
12.5.3 建议
在使用该系统的基础上继续搜集用户和职员的需求反馈，并参考结合其他业务管理系统的优势，在今后的版本中不断补充和完善系统的功能和性能。
建议当项目组成员确定后，在项目组内部对各事项进行一些约定，如开发，和测试的通用规范等，进一步提高软件的开发效率。
12.5.4 评价
经过项目小组的测试，该系统能够实现需求说明书中所约定的功能，即，能够基本满足用户（职员、客户、管理人员）在前台进行用户登录，信息查询，修改等一系列业务操作。
功能能够较好的实现，数据易于维护。
12.6测试资源消耗
1.占用实验室的网络，软件，硬件等资源
2.消耗大量人力
13 开发进度月报（段春林）
开发进度月报的编制目的是及时向有关管理部门汇报项目开发的进展和情况，以便函及时发现或处理开发过程中出现的问题。
一般地，开发进度月报是以项目组为单位每月编写的。
如果被开发的软件系统规模比较大，整个工程项目被划分给若干个分项目组承担，开发进度月报将以项目组为单位按月编写。
具体的内容要求如下：
13.1 标题
银行储蓄管理系统开发进度报告
13.2 工程进度与状态
13.2.1 进度
项目
计划
人员
可行性研究
小组人员讨论1周之内完成
项目开发计划
由组长根据情况做出计划1—2天完成
软件需求说明书
由所分配到任务的组员讨论分析2周之内完成
数据需求说明书
由所分配到任务的组员讨论分析2周之内完成
概要设计说明书
由所分配到任务的组员讨论分析1周之内完成
详细设计说明书
由所分配到任务的组员讨论分析3周之内完成
数据库设计说明书
由所分配到任务的组员讨论分析3周之内完成
用户手册
由所分配到任务的组员讨论分析1周之内完成
操作手册
由所分配到任务的组员讨论分析1周之内完成
模块开发卷宗
由所分配到任务的组员讨论分析2周之内完成
测试计划
由组长和组员讨论分析1周之内完成
测试分析报告
由所分配到任务的组员讨论分析4周之内完成并写入报告
开发进度报告
由所分配到任务的组员讨论分析1周之内完成
项目开发总结
由组长带领全体组员对整个过程进行全面总结
13.2.2 状态
时间
项目和计划
完成效果
备注
9.13～9.18
小组人员讨论1周之内完成可行性研究
一般
9.18～9.20
由组长根据情况做出计划1—2天完成项目开发计划
良好
9.20～9.30
由所分配到任务的组员讨论分析2周之内完成软件需求分析
良好
10.1～10.10
由所分配到任务的组员讨论分析2周之内完成数据需求分析
良好，数据分析有不足之处
10.10～10.15
由所分配到任务的组员讨论分析1周之内完成概要设计说明书
良好但不够完善
10.15～10.23
由所分配到任务的组员讨论分析3周之内完成详细设计说明书
良好
10.23～11.5
由所分配到任务的组员讨论分析3周之内完成数据库设计说明书
良好
11.5～11.10
由所分配到任务的组员讨论分析1周之内完成用户操做手册
良好
11.10～11.15
由所分配到任务的组员讨论分析1周之内完成用户手册
良好
11.15～11.25
由所分配到任务的组员讨论分析2周之内完成模块开发卷宗
一般
11.25～11.30
由组长和组员讨论分析1周之内完成测试计划
效果良好
11.30～12.20
由所分配到任务的组员讨论分析4周之内完成并写入报告测试分析报告
完成基本测试，软件系统基本稳定
12.20～12.25
由所分配到任务的组员讨论分析1周之内完成开发进度报告
完成效果良好
12.25～12.18
由组长带领全体组员对整个过程进行全面总结
组员都积极参与总结此过程中的很多不足
13.3 资源耗用与状态
13.3.1 资源耗用
13.3.1.1 工时
大概花费3～4个月的工时
13.3.1.2 机时
40～50个机时
13.3.2 状态
实验室有充足的时间和设备资源供小组成员研究使用
13.4 经费支出与状态
13.4.1 经费支出
无
13.4.1.1 支持性费用
无
13.4.1.2 设备购置费
无
13.4.2 状态
无
13.5 下个月的工作计划
无
13.6建议
小组成员在开发过程中把理论和实际结合的过程有很大不足之处，希望以后能够有很大改进。
14 项目开发总结报告（廖宇梅）
项目开发总结报告的编制是为了总结本项目开发工作的经验，说明实际取得的开发结果以及对整个开发工作的各个方面的评价。
具体的内容要求如下：
14.1 引言
14.1.1 编写目的
该项目开发总结报告是对本次系统的开发全部工作的总结，对各个成员的具体工作的总结。
让团队能够全面的认识与掌握自己的优势与缺点。
同时也让上级能够全面的了解整个开发系统的各个步骤及对系统的认识。
本软件测试计划说明的读者对象是系统开发人员，受理任务的人员。
14.1.2 背景
项目名称：
银行储蓄管理系统
说明：
现在的银行储蓄系统工作效率低，越来越不能满足广大储户的需要。
银行与客户都迫切希望能更方便更省时就可以办理储蓄业务。
现代计算机网络的高速发展使越来越多的人更喜欢网上购物、不出门即可交纳各种费用。
在这样的背景下，很明显现行的银行储蓄系统已经不能满足人们越益增长的需求，急切需要建立一个新的、高效的、方便的、互联的银行储蓄系统。
14.1.3 定义
系统：
银行储蓄管理系统
用户：
使用系统的储户
管理员：
使用系统的银行管理着和职员
数据库：
存储数据
14.1.4 参考资料
《软件工程导论》张海潘清华大学出版社
《管理信息系统》薛华成清华大学出版社
《软件项目管理》阳王东中国水利水电出版社
《软件稳档编写》辛明海潘孝铭五晋隆连灿红高等教育出版社
14.2 实际开发结果
14.2.1 产品
产品名称：
银行储蓄管理系统
模块：
融资模块，结算模块，参数模块，接口模块，报表模块，新产品模块
14.2.2 主要功能和性能
①、外部功能：
本软件具有输入、输出、查找、更新等功能
②、内部功能：
该软件集命令、编辑、编程于一身，完成过滤、定位、显示等功能。
存款时，存款人写明存款信息，由业务员处理到系统，生成存款单。
取款时，储户输入密码且密码正确或取款时未留有密码有电子系统自动生成且打印利息清单给储户。
软件有新建、修改、查询、更新等业务的功能，各模块有不同的功能，但是都能完成查询和储蓄功能
③、开户：
名称
开户
功能描述
用户向银行前台工作人员出示身份证，填写姓名、家庭住址、身份证号码，并且决定开始要存入的初始金额；银行工作人员给用户开出账号以及给出密码和开户日期。
操作者
前台工作人员
用户输入
输入用户姓名、初始金额、身份证号
输出
账号、密码、开户日期
④、存款：
名称
存款
功能描述
用户向银行前台工作人员提供账号，并且决定要存入的金额；银行工作人员给用户账号的余额和存款日期。
操作者
前台工作人员
用户输人
账号，存款金额
输出
账号余额和存款日期
⑤、取款：
名称
取款
功能描述
用户向银行前台工作人员提供账号和密码，并且决定要取出的金额；银行工作人员给用户账号的余额和存款日期。
操作者
前台工作人员
用户输人
输入账号、密码，取款金额
输出
账号、密码和取款日期
⑥、查询：
名称
查询
功能描述
用户向银行前台工作人员提供账号和密码，银行工作人员给用户账号的余额和查询日期。
操作者
前台工作人员
用户输入
输入账号、密码
输出
账号、密码和开户日期
⑦、转账：
名称
转账
功能描述
用户向银行前台工作人员提供账号和密码，银行工作人员给用户账号的余额和查询日期。
操作者
前台工作人员
用户输入
输入账号、密码，转账、账号、金额
输出
要转出账号的余额和开转账日期
⑧、修改密码：
名称
修改密码
功能描述
用户向银行前台工作人员提供账号和账号的源密码，然后决定新密码，银行即用新密码代替用户账号原来的密码。
操作者
前台工作人员
用户输入
输入账号、密码和新密码
输出
改密日期
⑨、销户：
名称
销户
功能描述
用户向银行前台工作人员提供账号和密码，并且把账号的余额全部取出，银行撤销这个账号。
操作者
前台工作人员
用户输入
输入账号、密码
输出
销户的日期
14.2.3 基本流程
14.2.4 进度
按要求顺利完成任务
14.2.5 费用
无
14.3 开发工作评价
14.3.1 对生产效率的评价
⑴、开发的反复性比较大
⑵、对客户的需求理解不是很透彻
综合上述：
此项目开发效率不是很高。
14.3.2 对产品质量的评价
对产品功能的评价经过我们各个组员的努力，银行管理系统已经基本完成了客户的业务流要求，但是还是存在这着一些问题，造成这些问题的原因是多方面的。
如：
前期系统数据库的设计缺陷和部分代码的构建缺陷、客户需求的理解上也存在一定的问题，这就需要我们用一定的时间来维护客户使用过程提出的新问题和存在的debug。
总的来说，此系统的功能开发还是一个比较成功的案例。
14.3.3 对技术方法的评价
1VB、Access内在支持多种软件工程工具，功能强大。
2SQLserver体积小，速度快，开放源码。
3Tomcat技术先进、性能稳定、扩展性好。
4StarUML功能强大。
14.3.4 出错原因的分析
①数据库定义中完整性约束与唯一性约束没有做出明确的定义导致数据库连接和获取数据出现错误。
②数据库中的表之间的级联问题会导致对表的操作不便，比如要删除某个数据时会由于它与其它表之间的级联关系会删除不了等一些问题。
③有些数据表之间建立主键与外键的关联。
升级会员 