银行储蓄系统测试报告

《银行储蓄系统》测试计划

目录1.引言

1.1编写目的

1.2背景

1.3定义

1.4参考资料

2.计划

2.1软件说明

2.2测试内容

2.3测试1（标识符）

2.3.1进度安排

2.3.2条件

2.3.3测试资料

2.3.4测试培训

2.4测试2（标识符）

3. 测试设计说明

3.1测试1（标识符）

3.1.1控制

3.1.2输入

3.1.3输出

3.1.4过程

3.2测试2（标识符）

4．评价准则

4.1范围

4.2数据整理

4.3尺度

第一章引言

1.1编写目的

基于不同的立场，存在着两种完全不同的测试目的。从用户的角度出发，普遍希望通过软件测试暴露出软件中陷藏的错误和缺陷，以考虑是否可以接受该产品。而从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立用户对软件质量的信心。

因为在程序中往往存在着许多预料不到的问题，可能会被疏漏，许多隐藏的错误只有在特定的环境下才可能暴露出来。如果不把着眼点放在尽可能查找错误这样一个基础上，这些隐藏的错误和缺陷就查不出来，会遗留到运行阶段中去。如果站在用户的角度替他们设想，就应当把测试活动的目标对准揭露程序中存在的错误。在选取测试用例时，考虑那些易于发现程序错误的数据。

下面这些规则也可以看作是测试的目的或定义：

1. 测试是为了发现程序中的错误而执行程序的过程；

2. 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；

3. 成功的测试是发现了至今为止尚未发现的错误的测试。

从上述规则可以看出，测试的正确定义是“为了发现程序中的错误而执行程序的过程”。这和某些人通常想象的“测试是为了表明程序是正确的”，“成功的测试是没有发现错误的测试”等等是完全相反的。正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计。如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；相反，如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。

由于测试的目标是暴露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不恰当的。因此，在综合测试阶段通常由其他人员组成测试小组来完成测试工作。此外，应该认识到测试决不能证明程序是正确的。即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在程序中。测试只能查找出程序中的错误，不能证明程序中没有错误。

1.2背景

a．所开发的系统名称：银行储蓄系统

b．任务提出者：楚雄州农业银行

c．开发者：陈强

d．用户：银行职员、中国公民

e．安装此软件的计算中心：楚雄农业银行

d．测试环境：windows xp + sql server 2000

对于这个具有庞大的企业，我开发了《银行储蓄系统》是为了楚雄市农业银行的管理机制提出的。开发该产品的目标是：使目前银行管理更方便、更快捷、更简单、更安全，同时满足不同用户的需求，储蓄者可以随时查询本金和利息，贷款者可以快捷的贷款和还款，一般用户可以到银行开通帐户，同时可以完成储蓄和转账操作，更方便的提供查询、挂失和密码修改，总之旨在完善目前银行储蓄系统，使之能跟上时代的发展。同时通过实践来提高自己的动手能力。

在开发之前，我认真做了该项目的需求分析，然后接着就是系统的设计，其中刚开始的时候我做的是过程化的分析和设计，但是经过我仔细考虑和老师的指导，我重新思考了我的问题，对于开发该软件，如果用过程化的设计方法，那样将使我以后的工作有章可循，但是，在实现的时候还要重新进行构思一遍，因为我是用的是面向对象开发的工具。所以最后我有写出了面向对象的开发与设计计划，这样使我以后的编码实现变得更简单。

1.3定义

[1].开户：只要是中国公民都可以到中国农业银行填写一张开户申请表，然后提交两张身份证复印件，银行职员把客户的信息录入计算就，并把一张农行卡号输入计

算机，然后有客户输入一个密码，这样客户就可以在全国农业银行或者是标有银联字样的自动取款机凭密码进行取款、查询、存款、密码修改等操作；

[2].客户：客户是指已经到农业银行开户的中国公民，客户可以进行存款、取款、查询、密码修改、转账、挂失、销户等操作；

[3].账号：账号是有银行卡管理机构制定的有19位阿拉伯数字组成，中国范围内账号是不相同的，账号是客户身份的主要识别方式；

[4].密码：银行卡的密码是有六位阿拉伯数组成，初始密码有客户输入，以后客户还可以在自动取款机上修改，客户需要凭密码和银行卡才可以进行取款、转账、查询、挂失、密码修改等操作，客户可以不用密码就可以进行存款操作，客户销户要到农业银行进行，自动取款机上不能进行销户；

[5].查询：查询是指客户可以在自动柜员机查询出自己账户上的余额，同时可以查询出存款记录和取款记录等信息；

[6].转账：转账是客户之间账户上的货币可以任意的进行转移，转账操作只需要输入对方账号和转账金额就可以进行转账；

[7].存款：存款是客户可以在自动柜员机上插入银行卡然后输入存款金额并在出纳接口放入相应金额的货币，系统自动将该账户的余额上增加相应的货币；

[8].取款：取款是指客户在自动柜员机上插入卡后输入密码验证正确后输入取款金额后系统取出相应金额货币给客户；

[9].密码修改：客户如果不想要原来的密码或者是原来密码已经泄漏，这样客户需要重新修改密码，以保证本卡的安全性，修改密码时客户需要两次输入新密码并且两次输入的密码一致才可以进行密码修改；

[10].挂失：挂失是只当客户的银行卡丢失或损坏时可以进行挂失操作，挂失后客户不可以再进行该卡的任何操作，然后在规定的时间后银行重新给客户办一张农行卡，

但是该卡上的余额不会减少；

[11].销户：销户是客户不想在想在使用农业银行提供的服务时进行销户，销户时会退给客户所有余额，销户必须到农业银行进行；

1.4参考资料

[1].《软件测试技术》，贺平编著，机械工业出版社，2004年；

[2]. 《软件测试》Software Testing Second Edition（英文版第2版）（美），Ron Patton著，机械工业出版社，2006年;

[3]. 《软件测试方法和技术》，朱少民编著，清华大学出版社， 2005年;

[4]. 《软件测试自动化技术与实例详解》， [美] Mark Fewster & Dorothy Graham 著，电子工业出版社， 2000年;

[5]. 实用软件测试方法与应用》，飞思科技产品研发中心编著，电子工业出版社， 2003年;

[6]. 《软件能力成熟度模型集成(CMMI)》，罗运模等编，清华大学出版社，2003年;

[7]. 《面向对象的软件测试》，杨文宏，李心辉等译，中信出版社， 2002

第二章计划

2.1软件说明

我开发的《银行储蓄系统》是为了楚雄市农业银行的管理机制提出的。开发该产品的目标是：使目前银行管理更方便、更快捷、更简单、更安全，同时满足不同用户的需求，储蓄者可以随时查询本金和利息，贷款者可以快捷的贷款和还款，一般用户可以到银行开通帐户，同时可以完成储蓄和转账操作，更方便的提供查询、

挂失和密码修改，总之旨在完善目前银行储蓄系统，使之能跟上时代的发展。同时通过实践来提高自己的动手能力。

《银行储蓄系统》实现以下有以下功能：

1.开户：只要是中国国籍的公民和海外华人、华侨都可以在中国农业银行进行

开户，开户的同时，银行向用户提供一张有中国农业银行字样的农行卡；

2.存款：已经开户的用户可以到农业银行进行存款操作，并可以享受相应的利

息，存款类型可以是活期和定期，有用户根据自己的需要自由选择；

3.取款：已经开户并且存款的用户可以在中国农业银行取款，也可以到标有银

联字样的自动取款机进行取款，用户可以根据自己的需要决定取款金额，但

是用户的取款数目不得超过帐户余额，若超过余额则有系统自动取消本次操

作；

4.转账：用户可以方便、快捷、准确、安全的把自己帐户上的金额转到另外一

个帐户，方便人民币的流通；

5.查询：用户可以随时到农行查询自己的余额、取款明细、存款明细，同时可

以打印发票；

6.修改密码：为了保证用户账号的安全，用户可以更改自己帐户的密码；

7.挂失：如果用户的银行卡丢失或损坏，用户可以到开卡党委进行挂失，挂失

时用户需要提供居民身份证和其他有效证件，三天之后用户可以重新开户，

即使这样用户的余额不会减少，让用户用得放心；

8.消户：当用户不想再使用中国农行提供的服务可以到农行进行消户；

9. 系统应符合银行账户管理的规定，满足银行相关人员日常使用的需要，并达到操作过程中的直观、方便、实用安全等要求；

10. 系统采用模块化程序设计方法，即便于系统功能的各种组合和修改，又便于未参与开发的技术维护人员补充、维护；

11. 系统应具备数据库维护功能，及时根据用户需求进行数据的添加、删除、备份等操作；

12. 尽量采用现有软硬软硬件环境及先进的管理系统开发方案，从而达到充分利用现在有资源，提高系统开发水平和应用效果的目的。

2.2测试内容

软件缺陷是有以下几种：

软件未达到产品说明书表明的功能。

软件出现了产品说明书指名不会出现的错误。

软件功能超出产品说明书指名范围。

软件未达到产品说明书虽未指出但应达到的目标。

软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

组装测试：

步骤一: 按照概要设计规格说明，明确有哪些被测模块。在熟悉被测模块性质的基础上对被测模块进行分层，在同一层次上的测试可以并行进行，然后排出测试活动的先后关系，制定测试进度计划。图2给出了自底向上的组装测试过程中各测试活动的拓扑关系。利用图论的相关知识，可以排出各活动之间的时间序列关系，处于同一层次的测试活动可以同时进行，而不会相互影响。

步骤二: 在步骤一的基础上，按时间线序关系，将软件单元组装为模块，并测试在组装过程中出现的问题。这里，可能需要测试人员开发一些驱动模块来驱动组装活动中形成的被测模块。对于比较大的模块，可以先将其中的某几个软件单元组装为子模块，然后再组装为一个较大的模块。

步骤三: 将各软件模块组装为子系统（或分系统）。检测各自子系统是否能正常工作。同样，可能需要测试人员开发少量的驱动模块来驱动被测子系统。

步骤四: 将各子系统组装为最终用户系统，测试是否存在各分系统能否在最终用户系统中正常工作。

确认测试：

事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。

α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

2.3测试1（标识符）

a:测试系统：银行储蓄系统

b．测试地点：楚雄师范学院

c．测试者：陈强

2.3.1进度安排

2009年6月：进行测试资料的阅读，重点阅读[1].《软件测试技术》，贺平编著，机械工业出版社，2004年；

2009年7月上旬：进行测试数据的准备；

2009年7月下旬：进行测试；

2.3.2条件

所用到的设备：服务器一台、主机一台

所用平台：windows xp + sql server2000

测试人员：陈强、具体用户

2.3.4测试培训

从网上下载一些关于测试的各种技能和注意事项；

2.4测试2（标识符）

所用到的设备：服务器一台、主机一台

所用平台：windows xp + sql server2000

第三章测试设计说明

3.1测试1（标识符）

对于测试1中我的思路是这样的，在windows xp 下进行单元测试，单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。

关于单元测试（Unit Test），目前已经有了一些专用的工具来完成测试工具，这对于开发人员来说当然是好事。我认为具备单元测试方面的知识和技能，是当今开发人员的基本要求，进一步地，利用TDD（Test Driven Development）——测试驱动开发的思想来指导自己的开发是开发人员迈向更高层次的阶石。

3.1.1控制

此测试使用人工输入数据和人工记录结果的控制方法。

首先，有人手工输入测试数据；

其次，记录运行结果；

再次，改正错误；

3.1.2输入

类测试阶段

确保类实例满足类的设计描述；

测试驱动：使用Junit实现独立的测试类；

类的实例方法没有和任何类交互的确保覆盖100％；

先测试没有交互的类，然后逐步组合测试；

使用Code Coverage工具进行类代码覆盖测试；

类测试用例确定方法之一：根据前置和后置状态确定测试用例（前置条件中可指定输入值，包括常见值和边界值，来增加测试用例的测试覆盖率），

根据前置和后置条件的不同组合方式产生不同的测试用例具体测试方法

体；

类测试用例确定方法之二：根据代码确定测试用例。所有Public声明的方法都需要被测试（确定的）；Protected和Frendly声明的方法有所选择的被

测试（模糊的）；所有Private声明的方法都被禁止测试（确定的）。

类测试用例确定方法之三：根据状态转换确定测试用例。

用例命名方式：1、根据用例方法命令；2、根据前置条件和后置状态命名。

尽量使测试代码不依赖于数据（不要因为外部数据不同而产生不同结果）。

进行语句覆盖率分析。

3.1.3输出

1.特殊字符错误

与提示限制条件不一致。如提示说只允许输入*号，但实际可以输入＋号；保存成功，但其他接口调用提示错误。

最常出错的字符有’”><%|-+.

2.极限值错误虽然极限值是测试中最为常见的测试项目，但往往在测试验证阶段仍然会出现错误。

通常的错误有几种：

与提示限制条件不一致。如提示说只允许输入20位，但实际可以输入25位前台界面限制条件与数据库存储不一致。录入50字符，保存提示异常。

3. 界面控制错误

大小写控制错误。界面控制区分字符大小写，但保存到数据库时数据库并不区分大小写，导致保存出错。逆操作失效。比如审核单据可以成功，但取消审核提示错误。按钮状态控制不严格。比如单据审核后，提交按钮需要置灰，但是没控制导致报错显示的规范性,比方说同一界面或不同界面的字体大小等. 如输入数字型的字段时，要考虑整数位和小数位的长度控制.要注意界面、提示、菜单、按钮上没有错别字和病句,且汉字要显示完整，不能出现一半汉字的情况产品的统一风格,如:备选框和选入框之间的选择,有的用"选择",有的用"<<",最好各界面都比较统一,特殊情况除外保证基本功能的使用,特别是接口功能,如预算的控制,接口选择不出来预算项目或口径等这些基本功能,往往很耽误以后的测试进程

4. 与其他产品接口错误

与接口档案定义字段不一致。比如存货规格允许输入5位，但程序是按照4位来判断，导致错误。产品内不同接口显示不一致。比如某指标一个模块定义了一种经济含义，但在另一个模块显示该指标时，显示的是另一种经济含义。控制接口有误。

5．希望尽量减少复问题的比例，特别是影响重大的反复问题，如不能登录产品，修改后功能失效等严重影响测试工作进度的问题。

3.1.4过程

1、理解需求和设计

理解设计是很重要的，特别是要搞清楚被测试模块在整个软件中所处的位置，这对测试的内容将会有很大的影响。需要记住的一个原则就是：好的设计，各模块只负责完成自己的事情，层次与分工是很明确的。在单元测试的时候，可以不用测

试不属于被测试模块所负责的功能，以减少测试用例的冗余，集成测试的时候会有机会测试到的。

举例：

/*

* 判断用户余额是否满足用户的取款余额

* 返回值：true-是；false-否

*/

bool isyue (double a, double b);

/*

bool isLegal(int a, int b, int c);

所以，单元测试主要是关注本单元的内部逻辑，而不用关注整个业务的逻辑，因为会有别的模块去完成相关的功能。

2、概览源代码

浏览一下源代码，主要任务：

（1）初步检查源代码的编码风格与规范

（2）大致估算测试工作量，比如：需要多少的测试用例、需要写多少的驱动模块和装模块等。

（3）确定模块的复杂程度，初步制定测试的优先级等。

3、精读源代码

认真阅读和分析代码，主要任务：

（1）理解代码的业务逻辑。

（2）检查代码与设计是否相符，如果详细设计没有该模块的流程图的话，先去画出流程图。

（3）仔细研究逻辑复杂的模块

（4）可以采用一些检查列表来检查程序可能会出现的问题。如果没有检查列表，那么，可以根据程序的特点，有针对性地检查容易出问题的地方（记得把经验总结下来供下次使用）。

4、设计测试用例

综合运用白盒测试方法（和结合黑盒测试方法）来设计测试用例，包括功能测试、性能测试等，要达到一定的测试覆盖率。在设计测试用例的过程中，流程图或控制流图是分析的好帮手。

5、搭建单元测试环境

使用XUnit或自己写的框架将有助于单元测试的实施。在这个阶段主要就是写桩模块和驱动模块，第4步所设计的测试用例是通过驱动模块传递给被测试模块的，然后驱动模块想办法获取被测试模块对数据的处理结果，并判定返回的实际结果与测试用例的预期结果是否一致，通过测试框架来记录执行的结果，对于出现的错误，还需要统计错误的信息，供执行完之后分析。

搭建单元测试环境要避免在main函数中使用printf和scanf函数来跟测试人员交互来达到获取测试用例数据的信息。这样的测试还是没有摆脱手工测试方式，效率是低下的。同时，对于测试结果是否通过测试也不要使用printf方式打印被测试函数的返回结果值，避免要人工去检查结果。

6、执行测试

运行写好的驱动模块完成对被测试模块的测试。

7、补充和完善测试用例

单元测试也是个循序渐进的过程，可能一开始考虑的不够全面，或预期的覆盖标准太低，需要在测试过程中不断补充测试用例，直到满足要求为止。

8、分析结果，给出评价

根据测试的结果分析、查找错误的原因，并找到解决的办法。测试结束之后，根据测试过程的数据统计，给出被测试对象评价。

3.2测试2（标识符）

系统测试的策略：功能测试，性能测试，外部接口测试，界面测试，强度测试，冗余测试，可靠性测试，恢复测试等设计系统测试计划需要参考的项目文档有软件测试计划、软件需求工件、和迭代计划。利用因果图导出测试用例需要经过的一般步骤

1.分析程序规格说明的描述中，哪些是原因，哪些是结果。

2.分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的因果图

3.在因果图上使用若干个特殊的符号标明特定的约束条件

4.把因果图转换成判定表

5.把判定表中每一列表示的情况写成测试用例阶段评审与同行评审的区别同行评审目的:发现小规模工作产品的错误,只要是找错误;

第四章评价准则

4.1范围

1.特殊字符错误

与提示限制条件不一致。如提示说只允许输入*号，但实际可以输入＋号；保存成功，但其他接口调用提示错误。

最常出错的字符有’”><%|-+.

2.极限值错误虽然极限值是测试中最为常见的测试项目，但往往在测试验证阶段仍然会出现错误。

通常的错误有几种：

与提示限制条件不一致。如提示说只允许输入20位，但实际可以输入25位前台界面限制条件与数据库存储不一致。录入50字符，保存提示异常。

3. 界面控制错误

大小写控制错误。界面控制区分字符大小写，但保存到数据库时数据库并不区分大小写，导致保存出错。逆操作失效。比如审核单据可以成功，但取消审核提示错误。按钮状态控制不严格。比如单据审核后，提交按钮需要置灰，但是没控制导致报错显示的规范性,比方说同一界面或不同界面的字体大小等. 如输入数字型的字段时，要考虑整数位和小数位的长度控制.要注意界面、提示、菜单、按钮上没有错别字和病句,且汉字要显示完整，不能出现一半汉字的情况产品的统一风格,如:备选框和选入框之间的选择,有的用"选择",有的用"<<",最好各界面都比较统一,特殊情况除外保证基本功能的使用,特别是接口功能,如预算的控制,接口选择不出来预算项目或口径等这些基本功能,往往很耽误以后的测试进程

4. 与其他产品接口错误

与接口档案定义字段不一致。比如存货规格允许输入5位，但程序是按照4位来判断，导致错误。产品内不同接口显示不一致。比如某指标一个模块定义了一种

经济含义，但在另一个模块显示该指标时，显示的是另一种经济含义。控制接口有误。

5．希望尽量减少复问题的比例，特别是影响重大的反复问题，如不能登录产品，修改后功能失效等严重影响测试工作进度的问题。

4.2数据整理

在性能测试中，我们经常会涉及到测试数据，对于测试数据我们可以为两种：一种是执行测试用例中使用的测试数据；另一种是在大数据量下测试时需要的测试基础数据。两者的主要区别是在于是否会在测试中直接用于测试执行。测试基础数据可以转化为测试数据。在这里主要说明测试基础数据。

一个系统经常会规划多年的业务规模，并对其性能提出要求。在测试设计时就需要测试在系统运行了多年时的性能，此时数据库中会有大量的历史数据，我们在测试时需要首先构造这些历史数据，我们称之为基础数据，这种情况的测试称为大数据量测试。由于构造数据的量级不同，我们会考虑采用不同的构造数据的方法。

常用构造基础数据的方法有：

1、使用自动化测试工具；

2、使用专用的测试数据产生工具；

3、使用数据库脚本语言直编写存储过程等产生；

4、使用其他的辅助工具产生；

4.3尺度

1.特殊字符错误

与提示限制条件不一致。如提示说只允许输入*号，但实际可以输入＋号；保存成功，但其他接口调用提示错误。

最常出错的字符有’”><%|-+.

2.极限值错误虽然极限值是测试中最为常见的测试项目，但往往在测试验证阶段仍然会出现错误。

通常的错误有几种：

与提示限制条件不一致。如提示说只允许输入20位，但实际可以输入25位前台界面限制条件与数据库存储不一致。录入50字符，保存提示异常。

3. 界面控制错误

大小写控制错误。界面控制区分字符大小写，但保存到数据库时数据库并不区分大小写，导致保存出错。逆操作失效。比如审核单据可以成功，但取消审核提示错误。按钮状态控制不严格。比如单据审核后，提交按钮需要置灰，但是没控制导致报错显示的规范性,比方说同一界面或不同界面的字体大小等. 如输入数字型的字段时，要考虑整数位和小数位的长度控制.要注意界面、提示、菜单、按钮上没有错别字和病句,且汉字要显示完整，不能出现一半汉字的情况产品的统一风格,如:备选框和选入框之间的选择,有的用"选择",有的用"<<",最好各界面都比较统一,特殊情况除

外保证基本功能的使用,特别是接口功能,如预算的控制,接口选择不出来预算项目或口径等这些基本功能,往往很耽误以后的测试进程

4. 与其他产品接口错误

与接口档案定义字段不一致。比如存货规格允许输入5位，但程序是按照4位来判断，导致错误。产品内不同接口显示不一致。比如某指标一个模块定义了一种经济含义，但在另一个模块显示该指标时，显示的是另一种经济含义。控制接口有误。

5．希望尽量减少复问题的比例，特别是影响重大的反复问题，如不能登录产品，修改后功能失效等严重影响测试工作进度的问题。