银行测试用例分类
银行测试用例分类
银行测试用例可以根据不同的功能和需求进行分类，以下是一些常见的银行测试用例分类：
1. 用户管理用例：
- 用户注册：测试用户注册功能是否正常，包括输入验证、账号唯一性验证等。
- 用户登录：测试用户登录功能是否正常，包括账号密码验证、登录失败处理等。
- 用户信息更新：测试用户信息更新功能是否正常，包括修改密码、绑定手机号等。
2. 账户管理用例：
- 账户开户：测试账户开户功能是否正常，包括输入验证、账户创建时间等。
- 账户查询：测试账户查询功能是否正常，包括查询余额、账户流水等。
- 账户关闭：测试账户关闭功能是否正常，包括账户余额清零、关闭状态验证等。
3. 转账用例：
- 转账操作：测试转账功能是否正常，包括输入验证、账户余额验证等。
- 转账状态查询：测试转账状态查询功能是否正常，包括查询转账历史、转账成功与失败验证等。
4. 存取款用例：
- 存款操作：测试存款功能是否正常，包括输入验证、账户
余额变动验证等。
- 取款操作：测试取款功能是否正常，包括输入验证、账户
余额变动验证等。
5. 汇款用例：
- 汇款操作：测试汇款功能是否正常，包括输入验证、手续
费计算等。
- 收款确认：测试收款确认功能是否正常，包括收款金额验证、手续费验证等。
6. 网银交易用例：
- 网银交易操作：测试网银交易功能是否正常，包括购买理
财产品、支付账单等。
- 网银交易记录查询：测试网银交易记录查询功能是否正常，包括查询交易流水、交易状态验证等。
以上仅是一些常见的银行测试用例分类，具体的用例还可根据实际情况进行增减和细分。
银行信贷测试用例
银行信贷测试用例在客户经理一的操作下，先发起客户B的100万元短期流动资金贷款抚度授信流程并成功放款后，再发起客户D的50万元长期固定资产贷款抚度授信流程（综合授信），期限36个月，由客户D自有的抵押物进行担保，录入抵押物信息，发起授信，授信逐级审批通过。
发起客户D的50万元的放款申请，逐级审批通过。
授信申请成功发起。
抵押关系建立审批流程正确。
合同生成正确押品信息生成正确。
生成授信额度查询功能中可以查询此笔业务相关内容。
放款成功2.2客户经理二2.2.1单一授信客户经理二，发起客户E的50万元短期流动资金贷款抚度授信流程（单一授信），期限12个月，由客户E自有的抵押物进行担保，录入抵押物信息，发起授信，授信逐级审批通过。
发起客户E的50万元的放款申请，逐级审批通过。
授信申请成功发起。
抵押关系建立审批流程正确。
合同生成正确押品信息生成正确。
生成授信额度查询功能中可以查询此笔业务相关内容。
放款成功2.2.2综合授信客户经理二，发起客户F的100万元短期流动资金贷款抚度授信流程（综合授信），期限12个月，由客户F自有的抵押物进行担保，录入抵押物信息，发起授信，授信逐级审批通过。
发起客户F的100万元的放款申请，逐级审批通过。
授信申请成功发起。
抵押关系建立审批流程正确。
合同生成正确押品信息生成正确。
生成授信额度查询功能中可以查询此笔业务相关内容。
放款成功3贷后管理测试3.1客户经理三客户经理三，对客户B的贷后管理进行测试，包括贷款还款、贷款展期、贷款提前还款等操作，均操作成功，并且系统正确记录相关信息。
3.2客户经理四客户经理四，对客户E的贷后管理进行测试，包括贷款还款、贷款展期、贷款提前还款等操作，均操作成功，并且系统正确记录相关信息。
客户经理一再次发起客户B的100万元短期流动资金贷款授信流程，这次是综合授信，由客户B自己的其他抵押物进行担保。
如果系统存在缺陷，综合授信将无法发起或者第二笔无法发起。
银行测试面试知识
银行测试面试知识1. 前言银行测试是一项关键的工作，它确保了银行系统的安全、稳定和可靠运行。
在银行测试面试中，了解银行测试的基本知识和技巧是非常重要的。
本文档将为您介绍银行测试面试中常见的问题和答案，帮助您在面试中更好地展示自己的能力和专业知识。
2. 银行测试的概念银行测试是指对银行系统进行功能、性能和安全等方面的测试，以验证系统的正确性和稳定性。
银行测试旨在确保银行系统能够按照设计要求正常运行，并保护银行和客户的利益。
3. 银行测试的类型银行测试可以分为以下几种类型：3.1 功能测试功能测试是对银行系统功能的测试，包括用户登录、账户管理、交易处理等功能的验证。
功能测试旨在确保银行系统的各项功能符合设计要求。
3.2 性能测试性能测试是对银行系统性能的测试，包括系统的响应时间、并发处理能力、吞吐量等指标的测试。
性能测试旨在评估银行系统在不同负载情况下的性能表现。
3.3 安全测试安全测试是对银行系统安全性的测试，包括用户身份验证、数据加密、防止恶意攻击等方面的测试。
安全测试旨在确保银行系统的安全性，防止客户信息泄露和金融欺诈等风险。
3.4 兼容性测试兼容性测试是对银行系统在不同操作系统、浏览器和设备上的兼容性进行测试。
兼容性测试旨在确保银行系统能够在各种环境下正常运行。
4. 银行测试的流程银行测试的流程通常包括以下几个阶段：4.1 需求分析在需求分析阶段，测试人员与业务分析师和开发人员合作，了解系统的需求和设计。
测试人员需要仔细阅读需求文档，理解系统的功能和业务流程。
4.2 测试计划在测试计划阶段，测试人员制定测试策略和测试计划。
测试策略包括测试的目标、范围和方法，测试计划包括测试环境的建立、测试用例的设计和执行等。
4.3 测试设计在测试设计阶段，测试人员根据需求文档和测试计划设计测试用例。
测试用例应该覆盖系统的各个功能和业务流程，以确保系统的完整性和正确性。
4.4 测试执行在测试执行阶段，测试人员按照测试计划执行测试用例。
测试银行提款机上的提款功能
测试银行提款机上的提款功能一、课题叙述黑盒测试又称为功能测试或数据驱动测试，是从用户观点出发，主要以软件规格说明书为依据，对程序功能和程序接口进行的测试，是软件测试技术中最基础的方法之一，在各类测试中都有广泛的应用。
本课题要求测试银行提款机上的提款功能，用户输入的提款金额的有效数值为50~2000，并以50为最小单位，且小数点后为00，除小数点外不可以出现数字以外的任何符号和文字，需用不同的方法设计该测试用例。
黑盒测试的各种方法中，应用较为广泛的测试方法有，等价类划分法、边界值分析法、决策表法及因果图法。
这些方法是比较实用的，在项目中具体采用什么方法，在设计具体的测试方案时自然要针对开发项目的特点对测试方法进行适当的选择。
二、程序流程图三、程序代码（1）前台界面设计（2）后台功能代码设计using System;using System.Collections.Generic;using System.Linq;using System.Web;using System.Web.UI;using System.Web.UI.WebControls;using System.Text.RegularExpressions;public partial class_Default : System.Web.UI.Page{protected void Page_Load(object sender, EventArgs e){}//判断字符串是否为浮点数public static bool IsFloat(string str){string regextext = @"^\d+\.\d+$";Regex regex = new Regex(regextext,RegexOptions.None);return regex.IsMatch(str.Trim());}protected void Button1_Click(object sender, EventArgs e){if (TextBox1.Text != ""){if (IsFloat(TextBox1.Text)){if (TextBox1.Text.IndexOf("0") == 0){Label1.Text = "对不起！该数字金额首位不能为0！"; }else{if (stIndexOf(".00",TextBox1.Text.Length - 1, 3) == TextBox1.Text.Length - 3){if(Convert.ToDouble(TextBox1.Text) >= 50.00 && Convert.ToDouble(TextBox1.Text) <= 2000.00){if(Convert.ToDouble(TextBox1.Text) % 50 == 0){Label1.Text = "输入成功！";}else{Label1.Text = "对不起！您输入的金额不是50的倍数！";}}else{Label1.Text = "对不起！您输入的金额不在50~2000之间！";}}else{Label1.Text = "对不起！您输入的金额小数点后不是'.00'！";}}}else{Label1.Text = "对不起！您输入的不是浮点型数字金额！"; }}else{Label1.Text = "请先输入提款金额！";}}protected void Button2_Click(object sender, EventArgs e){TextBox1.Text = "";Label1.Text = "";}}四、不同方法设计测试用例（1）等价类划分法测试用例的设计方法不是单独存在的，具体到每个测试项目里都会用到多种方法。
银行用例
一：处理存款用例1：用例名：存款2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：客户（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：存储存款信息，更新信息，生成票据8：主事件流：（1）：客户领取排队号码牌（2）：填取存款单（3）：带卡或存折，则排队等候，等到叫号时，带着相关证件到柜台（4）：银行职员打开银行管理系统（5）：银行职员扫描银行卡信息到存款界面（6）：客户输入密码进行银行卡认证（7）：客户向银行职员递交所存现金（8）：银行职员确认存款信息并向客户确认（9）：银行系统保存存款信息（10）：生成存款信息并打印，客户签字确认9：备用事件流（1）：客户所带证件不齐全（2）：客户忘记密码二：处理取款用例1：用例名：取款2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：客户（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：存储存款信息，更新信息，生成票据8：主事件流（1）：客户领取排队号码牌（2）：填取取款单（3）：带卡或存折，则排队等候，等到叫号时，带着相关证件到柜台（4）：银行职员打开银行管理系统（5）：银行职员扫描银行卡信息到存款界面（6）：客户输入密码进行银行卡认证（7）：银行职员向客户确认取款金额（8）：银行职员提取现金给客户（9）：保存信息并打印，客户签字确认9：备用事件流（10）：客户所带证件不齐全（11）：客户忘记密码三：处理贷款用例1：用例名：贷款2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：贷款人（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：存储存款信息，更新信息，生成票据8：主事件流（1）：贷款人向银行提出借款申请（2）：银行对贷款人的信用等级进行评估（3）：银行对贷款人的合法性、安全性、盈利性进行调查（4）：银行按审贷分离、分级审批的贷款管理制度进行贷款审批（5）：银行与贷款人签订贷款合同（6）：银行职员登录到贷款界面（7）：银行职员录入贷款人信息（8）：保存贷款信息（9）：银行按贷款合同规定按期发放贷款（10）：银行对贷款人执行贷款合同情况及贷款人经营情况进行追踪和检查（11）9:备用事件流（12）：未达到贷款条件（13）：相关手续不齐全四：处理银行卡开户用例1：用例名：银行卡开户2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：客户（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：在账户库中增加了一个新账户，得到一张新存折8：银行卡开户主事件流（1）：客户领取排队号码牌（2）：填取开户申请单（3）：排队等候，等到叫号时，带着相关证件到柜台（4）：银行职员打开银行管理系统中的开户界面（5）：输入客户信息（姓名、地址、身份证号）（6）：银行职员取出一张新的银行卡并进行激活（7）：客户输入密码（8）：客户再次输入密码进行确认（9）：如果两次输入密码不一致，则返回第七步（10：银行系统保存客户信息（11）：银行职员向客户交还银行卡9:备用事件流（1）：相关手续不齐全五：处理存折开户用例1：用例名：存折开户2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：客户（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：在账户库中增加了一个新账户，得到一张新存折8：银行卡开户主事件流（1）：客户领取排队号码牌（2）：填取开户申请单（3）：排队等候，等到叫号时，带着相关证件到柜台（4）：银行职员打开银行管理系统中的开户界面（5）：输入客户信息（姓名、地址、身份证号）（6）：从账户管理系统获取新的账户（7）：客户输入密码（8）：客户再次输入密码进行确认（9）；如果两次输入密码不一致，则返回第七步（9）：在账户库中添加新账户（10）：打印存折（10）：银行职员向客户交还银行卡9:备用事件流（1）：相关手续不齐全六：处理用户挂失用例1：用例名：用户挂失2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：客户（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：该银行卡暂时不能使用，但是账户信息依旧保存8：主事件流：（1）：客户领取排队号码牌（2）：填取挂失单（3）：排队等候，等到叫号时，带着相关证件到柜台（4）：银行职员打开银行管理系统（5）：银行职员打开用户挂失界面（6）：银行职员选择要挂失的银行卡（7）：银行职员对客户进行身份验证（8）：银行职员向客户确认确认要挂失的银行卡（9）：银行系统保存挂失信息9：备用事件流（1）：客户所带证件不齐全（2）：手机号码变更过（3）：挂失所在地与开户所在地不同七：处理用户注销用例1：用例名：用户注销2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：客户（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：该银行卡失效并且删除银行卡信息8：主事件流：（3）：客户领取排队号码牌（4）：填取注销单（3）：排队等候，等到叫号时，带着相关证件到柜台（4）：银行职员打开银行管理系统（5）：银行职员打开用户注销界面（6）：银行职员选择要注销的银行账户（7）：系统检索并显示该用户详细资料（8）：系统管理员确认删除（9）：系统删除该用户信息9：备用事件流（1）：客户所带证件不齐全（2）：注销所在地与开户所在地不同八：处理用户修改密码用例1：用例名：用户修改密码2：范围：银行管理系统3：级别：用户目标/用户使用4：主要参与者：银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户5：涉众及其关注点：（1）：银行职员（2）：客户（3）：银行6：前置条件：银行职员必须经过确认和认证7：后置条件：用户修改原来密码，账户信息不变8：主事件流：（1）：客户领取排队号码牌（2）：填取密码修改单（3）：排队等候，等到叫号时，带着相关证件到柜台（4）：银行职员打开银行管理系统（5）：银行职员打开用户密码修改界面（6）：银行职员选择要修改的银行账户（7）：对客户进行身份验证（8）：客户输入原密码（9）：客户输入新密码（10）：客户确认新密码（11）：系统保存该用户的新信息，替换旧信息9：备用事件流（1）：客户所带证件不齐全（2）：忘记原密码。
银行测试知识点
银行测试知识点：1、金融分类：银行、证券、保险、2、银行分类：（中央银行、商业银行、政策性银行）国有银行（工、农、中、建）、国有股份制银行（交行、中信、招行）、地域银行和农信舍3、（中行）银行系统测试：4、外包、外派优劣点：5、测试流程：6、测试工具：开源测试管理工具：Bugfree、Bugzilla、TestLink、mantis zentaopms开源功能自动化测试工具：Watir、Selenium[1]、MaxQ、WebInject开源性能自动化测试工具：Jmeter、OpenSTA、DBMonster、TPTEST、Web Application Load Simulator禅道测试管理工具：功能比较全面的测试管理工具，功能涵盖软件研发的全部生命周期，为软件测试和产品研发提供一体化的解决方案。
是一款优秀的国产开源测试管理工具。
Quality Center：基于Web的测试管理工具，可以组织和管理应用程序测试流程的所有阶段，包括指定测试需求、计划测试、执行测试和跟踪缺陷。
QuickTest Professional：用于创建功能和回归测试。
LoadRunner[2]：预测系统行为和性能的负载测试工具。
其他测试工具与框架还有Rational Functional Tester、Borland Silk系列工具、WinRunner、Robot等。
国内免费软件测试工具有：AutoRunner和T estCenter。
国内介绍软件测试工具比较好的网站为：51Testing软件测试论坛6、测试用例:7、缺陷管理：见下文8、架构B/S C/S：9、工作划分标准：模块划分、10、核心、外围：12、项目几大阶段：13、载体：14、信管系统：缺陷管理：缺陷管理本词条缺少信息栏，补充相关内容使词条更完整，还能快速升级，赶紧来编辑吧！缺陷管理/软件缺陷管理（Defect Management）是在软件生命周期中识别、管理、沟通任何缺陷的过程（从缺陷的识别到缺陷的解决关闭），确保缺陷被跟踪管理而不丢失。
银行申购产品的测试用例
银行申购产品的测试用例1、测试需求分析，得到测试点在测试需求分析阶段，我们只有需求文档，所以编写测试用例的唯一依据就是需求文档，因此在进行用例编写之前一定要进行需求分析，需求分析的主要工作就是：了解需求的整个实现背景；分析需求的合理性；明确需求的范围，挖掘需求文档中隐藏的需求；在通过需求交底的过程，确定开发的初步实现思路和方法，随着测试需求分析的深入，列出需求的框架，包括测试范围即各个功能点，测试的场景等；确定一些测试可以提前介入的工作等；需要说明的是对于需求中的问题一定要记录下来，找需求确认，需求漏掉的或者存在问题的地方，开发和测试更容易漏掉，而且遗漏的需求很有可能会使得项目整体业务逻辑发生变化，一定要及时提前确认。
2、分析得到用例优先级得到了需求的各个测试点后，应该先将这些测试点简单的分配一下优等级，一般分为高中低三个优先级，我认为得到优先级后可以让需求用例的设计更有侧重和着重点。
3、细化测试点变成可执行case根据测试需求分析得到的需求框架，梳理细化测试点，这里的测试点虽然粗，但是不应该有遗漏，这是进行测试点细化的前提。
根据测试点，细化出具体的测试用例，要注意各个点的组合测试的情况，还要注意各个测试点的反向测试的情况。
在细化测试点的时候，我们可以要参考以前写好的公共测试用例，甚至可以直接引用，这样既可以避免一些不必要的时间浪费，但是参考不等于照搬，在引用的同时，也一定要思考本次需求自己特有的测试点。
4、及时更新测试用例需求分析和用例编写阶段，是主要的细化用例时间，这段时间的目标是梳理出可指导执行测试的用例，但是需求会有变动，需求会有维护，用例也一样，所以用例是需要持续维护的，所以在需求变动的同时，我们也要及时维护测试用例，否则的话，测试用例很可能成为一个错误的指导。
另外测试用例完成后就会进入一个用例评审的阶段，在用例评审阶段，会有用例评审人，针对你的用例作出的评审，主要检查你的用例是否有测试点遗漏，场景遗漏，测试case描述模糊，测试结果输出模糊等问题，针对用例评审人提出的问题，我们也要及时的更改我们的用例。
银行转账等价类划分法测试用例设计
银行转账等价类划分法测试用例设计银行转账是我们日常生活中不可避免的一个应用场景，通常我们会通过网银或者POS等渠道进行转账操作。
而在软件测试中，针对银行转账的功能模块，我们需要通过等价类划分法进行测试用例的设计。
下面将介绍等价类划分法以及如何设计银行转账的测试用例。
一、等价类划分法介绍等价类划分法是一种测试用例设计方法，它将所有可能的输入值划分为几个等价类，并且将每个等价类看作是等效于其他等价类的。
这种方法可以让我们更加全面地测试每一个输入情况，而不是测试所有可能的输入值。
通过这种方法设计测试用例，能够显著提高测试效率。
二、如何进行等价类划分在使用等价类划分法进行测试用例设计时，我们需要先明确输入变量的范围和限制条件，然后推导出所有可能存在的输入值。
接下来，我们根据等价类的定义，将这些输入值归入不同的等价类。
最后，我们只需要设计一些具有代表性、既能覆盖所有等价类的测试用例，就可以对应用程序进行系统的测试。
三、银行转账测试用例设计银行转账是一项涉及到财务数据的高风险操作，因此我们需要足够全面和严格的测试来保证操作的安全性和正确性。
下面我们按照等价类划分法的思路，设计一些可行的银行转账测试用例。
1.转账金额等价类测试用例。
转账金额是一个必填字段，因此我们需要分别针对正确的金额、小于0的金额以及大于余额的金额进行测试。
根据等价类划分法，我们可以将这些输入值视为不同的等价类，并选择一些具有代表性的测试用例来覆盖这些等价类，包括：输入金额为1000元，期望转账成功；输入金额为-1000元，期望提示金额错误；输入金额大于余额，期望提示余额不足。
2.转账账户等价类测试用例。
转账账户也是必填的字段，我们需要对正确的账户、错误格式的账户以及不存在的账户进行测试。
根据等价类划分法，我们可以将这些输入值视为不同的等价类，并选择一些具有代表性的测试用例来覆盖这些等价类，包括：输入正确的银行卡号和账户，期望转账成功；输入错误格式的卡号和账户，期望提示格式错误；输入不存在的卡号和账户，期望提示账户不存在。
银行接口业务测试用例(最新)
6 会员账户余额上传不成功 单击左下角【上传数据】
1 解约成功
2 解约成功
3 解约成功
3 解约成功
4 解约成功 22
5 解约成功 6 解约成功
会员登录交易前台，单击我的平台-资金管理-账户明细 点击【申请解约】 如该会员在交易中心账户中的余额为0，单击【申请解约】 登录交易后台，单击结算管理-结算银行-会员解约申请审核 选择该条申请信息，单击左下角【审核通过】按钮 点击【审核】按钮 单击结算管理-结算银行-会员解约申请复核
选择该条预付款信息，单击左下角【审核】按钮 单击【确认】按钮
13 6 与供应商结算成功 7 与供应商结算成功 8 与供应商结算成功 9 与供应商结算成功
10 与供应商结算成功
单击结算管理-凭证管理-凭证审核 选择该条预付款信息，单击左下角【审核】按钮 单击【确认】按钮 选择该条预付款信息，单击左下角【审核】按钮
11
8 会员出金成功 9 会员出金成功 10 会员出金成功
1 会员出金不成功 2 会员出金不成功 3 会员出金不成功 4 会员出金不成功 5 会员出金不成功 12 4 会员出金不成功 5 会员出金不成功 6 会员出金不成功 7 会员出金不成功 8 会员出金不成功 9 会员出金不成功 10 会员出金不成功
选
银
行：服务仍处于开启状态，可以进行出入金
操作
进入出入金明细对账页面
接case11出金成功 接case11出金成功 接case15签退成功
显示会员当日出入金信息 下载成功，正常显示数据 进入出入金明细对账页面 显示会员当日出入金信息
下载成功，但有数据显示为红色，根据错误 描述如描述为【银行存在成功记录，交易没 有收到消息】时可进行手工调账 进入系统日结界面 提示划转成功 提示日结成功 进入会员账户余额上传页面 显示会员账户当日信息 交易中心：不显示数据 进入会员账户余额上传页面 显示会员账户当日信息 显示红色异常数据 进入账户明细页面 进入申请解约页面 提示申请成功 进入会员解约申请审核页面 弹出申请单信息 审核成功 进入会员解约申请复核页面
测试用例(银行系统)
安徽翰子昂
{银行系统}
{ 银行系统的功能测试用例}
版本历史
目录
版本历史 (2)
1.文档介绍 (4)
1.1文档目的和范围 (4)
1.2读者对象 (4)
1.3术语与缩写解释 (4)
2.功能测试用例 (4)
2.1被测试对象的介绍 (4)
2.2测试范围与目的 (4)
银行系统的管理员用户操作和普通用户操作2.3测试环境与测试辅助工具的描述 (4)
2.4功能测试用例 (5)
1.文档介绍
加入用例图，并讲述了每一块模块的异常事件和可选事件，供参考使用。
1.1 文档目的和范围
文档仅提供相关测试人员做功能测试用例。
1.2 读者对象
测试此系统的所有人员
1.3 术语与缩写解释
2.功能测试用例
2.1 被测试对象的介绍
银行系统是一款b/s模式的存取款的系统，基于方便简洁的页面，给用户提供方便快捷的存取款服务。
2.2 测试范围与目的
银行系统的管理员用户操作和普通用户操作
2.3 测试环境与测试辅助工具的描述
系统环境：Windows xp
2.4 功能测试用例。
银行测试案例模板
银行测试案例模板一般系统中的栏位大致可以分为：1、输入项；2、选输项；3、跳过项；4、回显项；5、选择项（下拉框形式）。
下面将对各中栏位的一般规则做详细的说明。
1、输入项：该种栏位一般是输入卡号，账号，金额，凭证等。
这类的栏位，首先明确栏位的相关控制，然后再加上相对应的错误。
例如一般的交易都会涉及到金额这个输入项。
除去一些栏位的特殊要求，在编写案例的时候，都应该考虑到金额的边界值，负数，除数字之外的字母，符号以及这个栏位的最大输入字符数等等。
2、选输项：这种栏位一般可输入，也可不输入。
遇到类似的情况，首先考虑该栏位要是输入的话，是否有限制，是只输入汉字，还是只输入数字等；是否有规定最大的字符数。
其次我们考虑应该是若不输入，是不是对交易的完成进行有影响。
最后一般交易都会涉及到打印这个操作，我们也应考虑交易完成之后，针对该栏位打印出的结果是否能够正确显示3、跳过项：该种栏位都会同一交易页面的某个栏位会有一定的联系。
这类交易只需根据对应关系即可，当触发这个关系的是，看该栏位能否正确跳过就可以。
4、回显项：这种栏位跟上面跳过项有点类似，在涉案例的时候，我们除了考虑能否回显之外，还能考虑的是回显的内容是否正确，以及格式，排版方面是否美观等等5、选输项：选输项的栏位分两种情况，第一种是根据之前的输入来选择该栏位的内容；第二中是该栏位不同的选择会影响之后栏位的内容。
遇到这种栏位的时候，通常会用到等价类的方法来划分可选择的项，当然前提还是得先捋清楚这个栏位跟其他栏位的关联关系。
最后需要补充一点的是，上面的所说的内容都是单纯从单一交易来说的，在设计案例的时候，我们也应该考虑交易的一些后续操作。
如：开了一个通存通兑的账户，你得去验证该账户是否可以进行通存通兑的交易；做了一笔转账交易，应该考虑到去查看下涉及账号的变化是否正确，以及系统中的流水记录是否准确等等。