银行存储系统测试总结报告Word文档格式.docx
《银行存储系统测试总结报告Word文档格式.docx》由会员分享，可在线阅读，更多相关《银行存储系统测试总结报告Word文档格式.docx（10页珍藏版）》请在冰豆网上搜索。
2.1进度回顾5
2.2测试执行6
2.3测试用例6
2.3.1功能性6
2.3.2易用性6
3测试环境7
3.1.1软硬件环境7
3.1.2网络拓扑7
4测试结果8
4.1Bug趋势图8
4.2BUG引入阶段8
4.3Bug引入原因9
5测试结论10
5.1功能10
5.2易用性10
5.3可靠性11
6分析摘要11
6.1建议11
7度量12
8典型缺陷引入原因分析12
1引言
对于银行存储系统这一类项目，如果在软件使用中出错，往往会给用户带来难以预料的后果。
为了使由于软件自身原因而带来的损失减到最小，在完成软件的设计后，按照软件工程的一般要求对软件进行测试。
软件测试是软件开发过程中的一个重要步骤，对软件的安全性等各个方面具有特殊的意义。
1.1编写目的
编写该测试总结报告主要有以下几个目的：
1.通过对测试结果的分析，得到对软件质量的评价。
2.分析测试的过程，产品，资源，信息，为以后制定测试计划提供参考。
3.评估测试，测试执行和测试计划是否符合。
4.分析系统存在的缺陷，为修复和预防bug提供建议。
1.2背景
伴随着社会经济的飞速发展，互联网、金融业等行业的发展市场现在也发展得越来越快。
尤其是中国加入了WTO后，网络银行、各银行间金融机构的竞争变得愈发激烈，储蓄类业务的办理方式也不断变化，渐渐成为全球各大银行所关注的重点。
各种机构针对储蓄系统的研究与开发，投入了很大的资金。
但是银行存储系统因为庞大的用户群体而产生一些使用中的bug，因此在银行存储系统必须做一些测试性的报告来保证软件的质量，以保证软件的正常运作。
若银行还使用手工的方式办理储蓄业务，则需花费大量的时间，以致于浪费用户的资源。
因此，东神银行为简化银行储蓄业务的办理程序，需要开发全新的计算机储蓄系统，解决一些网络金融的问题。
使银行工作人员将计算机技术应用到储蓄业务的办理中，以便计算机储蓄体系在工作人员使用电脑办理业务时，变得方便、实用、安全灵活。
1.3用户群
主要读者：
东神项目管理人员，东神项目测试经理。
其他读者：
东神项目相关人员。
1.4测试定义
严重bug:
出现以下缺陷，测试定义为严重bug
√系统无响应，处于死机状态，需要其他人工修复系统才可复原。
√点击某个菜单后出现“Thepagecannotbedisplayed”或者返回异常错误。
√进行某个操作（增加、修改、删除等）后，出现“Thepagecannotbedisplayed
”或者返回异常错误。
√当对必填字段进行校验时，未输入必输字段，出现“Thepagecannotbedisplayed”或者返回异常错误。
√系统定义不能重复的字段输入重复数据后，出现“Thepagecannotbedisplayed”或者返回异常错误。
1.5测试对象
按照全生命周期的软件测试概念，测试对象应该包括软件设计开发的各个阶段的内容，一般有走查,单元测试、集成测试、确认测试和系统测试及开发版测试，用于整个开发过程中的不同阶段。
1.6测试阶段
系统测试
1.7测试工具
1、机能测试对象：
LoadRunner；
2、主动化测试对象：
QTP；
3、安然性测试对象：
AppScan；
4、缺点治理对象：
TestLink+Mantisbt+Bugzilla（缺陷管理系统）；
1.8参考资料
《东神银行存储系统需求和设计说明书》
《东神银行存储系统数据字典》
《东神银行存储系统后台管理系统测试计划》
《东神银行存储系统后台管理系统测试用例》
《东神银行存储系统项目计划》
2测试概要
东神银行存储管理系统测试从2016年5月1日开始到2016年6月9日结束，
共持续39天，测试功能点180个，执行2500个测试用例，平均每个功能点执行测试用例13.8个，测试共发现320个bug，其中严重级别的bug68个，无效bug44个，平均每个测试功能点2.2个bug。
东神银行存储管理系统总共发布11个测试版本，其中T1—T5为计划内迭代开发版本（针对项目计划的基线标识），B1—B3为回归测试版本。
计划内测试版本，T1—T4测试进度依照项目计划时间准时完成测试并提交报告，其中T4版本推迟发布2天，测试增加2个人口，准时完成测试。
T4—T10为计划外回归测试版本，测试增加5个工作日的资源，准时完成测试。
东神银行存储系统测试通过TestLink+Mantisbt+Bugzilla缺陷工具进行缺陷跟踪管理，T1—T4测试阶段都有详细的bug分析表和阶段测试报告。
2.1进度回顾
版本/时间
计划开始时间
实际开始时间
计划完成时间
实际完成时间
是否加班
增加资源
T1
2016.5.20
否
T2
2016.5.21
T3
2016.5.22
1个人/天
2个人日
T4
2016.5.23
2个人/天
T5
2016.5.24
1个人日
B1
B2
3个人/天
3个人日
B3
6个人/天
6个人日
T10
合计
个人/12天
12个人日
2.2测试执行
此次测试严格按照项目计划和测试计划执行，按时完成了测试计划规定的测试对象的测试，针对测试计划规定的测试策略，在测是执行中都有体现，在测试执行过程中，一句测试计划和测试用例，对系统进行了完整的测试。
2.3测试用例
2.3.1功能性
系统服务器端实现的主要功能：
查询、添加、修改、删除。
系统客户端实现的主要功能：
查询、存款、取款、开户、贷款、销户。
2.3.2易用性
操作按钮提示信息正确性，一致性，可理解性。
限制条件提示信息正确新，一致性，可理解性。
必填性标识。
输入方式可理解性。
中文界面下数据语言与界面语言的一致性。
3测试环境
3.1.1软硬件环境
硬件环境
应用服务器
数据库服务器
客户端
硬件配置
CPU:
Intel（R）Celerom（R）
CPU：
2.4GHz
Memory:
1048256k
HD:
ST380817AS
Intel（R）Celerom（F）
软件配置
80G
SATA
OS:
CentOS4.2
80GSATA
MySQL5.7.1
Windows10Professional
IE12
网络环境
Apache2.2.0
Tomcat5.5.15
10MLAN
3.1.2网络拓扑
4测试结果
4.1Bug趋势图
此次黑盒测试总共发布12个版本，T1—T5为计划内迭代开发版本（针对项目计划的基线标识），B1—B3为进行的回归测试版本，bug版本趋势图如下图所示：
第一阶段，增量确认测试。
第二阶段，BUG验证和功能回归确认测试。
4.2BUG引入阶段
4.3Bug引入原因
1.需求及设计相关错误。
2.后台编码错误。
3.数据库相关结构及数据错误。
4.易用性。
5多语言。
6测试理解错误。
5测试结论
5.1功能
《银行计算机储蓄系统》应该实现的功能：
1.开户：
只要是中国国籍的公民和海外华人、华侨都可以在银行进行开户，开户的同时，银行向用户提供一张有银行字样的银行卡。
2.存款：
已经开户的用户可以到相关银行进行存款操作，并可以享受相应的利息，存款类型可以是活期和定期，有用户根据自己的需要自由选择。
3.取款：
已经开户并且存款的用户可以在中国银行取款，也可以到标有银联字样的自动取款机进行取款，用户可以根据自己的需要决定取款金额，但是用户的取款数目不得超过帐户余额，若超过余额则有系统自动取消本次操作。
4.转账：
用户可以方便、快捷、准确、安全的把自己帐户上的金额转到另外一个帐户，方便人民币的流通。
5.查询：
用户可以随时到农行查询自己的余额、取款明细、存款明细，同时可以打印发票。
6.修改密码：
为了保证用户账号的安全，用户可以更改自己帐户的密码。
7.挂失：
如果用户的银行卡丢失或损坏，用户可以到开卡党委进行挂失，
挂失时用户需要提供居民身份证和其他有效证件，三天之后用户可以重新开户，即使这样用户的余额不会减少，让用户用得放心。
8.消户：
当用户不想再使用中国农行提供的服务可以到农行进行消户。
9.系统应符合银行账户管理的规定，满足银行相关人员日常使用的需要，并达到操作过程中的直观、方便、实用安全等要求。
5.2易用性
现有系统有如下易用性：
1.系统采用模块化程序设计方法，即便于系统功能的各种组合和修改，又便于未参与开发的技术维护人员补充、维护。
2.系统应具备数据库维护功能，及时根据用户需求进行数据的添加、删除、备份等操作。
3.尽量采用现有软硬软硬件环境及先进的管理系统开发方案，从而达到充分利用现在有资源，提高系统开发水平和应用效果的目的。
现有系统有如下易用性缺陷：
界面排版不美观。
输入输出字段的可理解性差。
输入缺少解释性说明。
中英文对应的正确性。
中英文混排。
5.3可靠性
现有系统的可靠性控制不够严密，很多控制是通过页面控制实现的，如果页面控制失效，可以向数据库插入数据u，引发错误。
现有系统的容错性不高，如果系统出现错误，返回错误类型为找不到页面错误，无法回复到出错前的状态。
6分析摘要
6.1建议
1.在项目开始的时候应该制定编码标准，数据库标准，需求变更标准，开发和测试人员都严格按照标准进行，可以在后期减少因为开发，测试不一致而导致的问题，同时也可以降低沟通成本。
2.开发人员解决bug的时候，填写bug原因以及解决方式，方便bug的跟踪。
3.开发人员在开发版本上发现bug，可以通知测试人员，因为开发人员发现的bug很有可能在测试版本上出现，而测试人员和开发人员的思路不同，有可能测试人员没有发现该bug，而且，这样可以保证发现的bug都能够被跟踪。
7度量
测试时间
2016年5月1日至6月9日，共39天
测试人力
1X12+12=24人/天
硬件资源
服务器：
PC2台
客户端：
8典型缺陷引入原因分析
测试过程中发现的缺陷主要有以下几个方面：
1.需求定义不明确
2.功能性错误
3.页面设计和需求不一致
4.多语言数据问题
5.页面设计易用性缺陷
6.开发人员疏忽引起的缺陷
升级会员 