当前位置:文档之家› 银行接口业务测试用例(最新)

银行接口业务测试用例(最新)

银行接口业务测试用例(最新)
银行接口业务测试用例(最新)

黑盒测试用例设计案例

黑盒测试用例设计案例 【例1】假设现有以下的三角形分类程序。该程序的功能是,读入代表三角形边长的3个整数,判定它们能否组成三角形。如果能够,则输出三角形是等边、等腰或任意三角形的分类信息。图9.11显示了该程序的流程图和程序图。为以上的三角形分类程序设计一组测试用例。 【解】 第一步:确定测试策略。在本例中,对被测程序的功能有明确的要求,即:

(1)判断能否组成三角形; (2)识别等边三角形; (3)识别等腰三角形; (4)识别任意三角形。因此可首先用黑盒法设计测试用例,然后用白盒法验证其完整性,必要时再进行补充。 第二步:根据本例的实际情况,在黑盒法中首先可用等价分类法划分输入的等价类,然后用边界值分析法和猜错法作补充。 等价分类法: 有效等价类 输入3个正整数: (1)3数相等 (2)3数中有2个数相等,比如AB相等 (3)3数中有2个数相等,比如BC相等 (4)3数中有2个数相等,比如AC相等 (5)3数均不相等 (6)2数之和不大于第3数,比如最大数是A

(7)2数之和不大于第3数,比如最大数是B (8)2数之和不大于第3数,比如最大数是C 无效等价类: (9)含有零数据 (10)含有负整数 (11)少于3个整数 (12)含有非整数 (13)含有非数字符 边界值法: (14)2数之和等于第3数 猜错法: (15)输入3个零 (16)输入3个负数 第三步:提出一组初步的测试用例,如下表所示:

第四步:用白盒法验证第三步产生的测试用例的充分性。结果表明,上表中的前8个测试用例,已能满足对被测程序图的完全覆盖,不需要再补充其他的测试用例。

测试用例设计思路举例(参考)

ECShop2.7.2用例设计思路举例 说明 用例设计方法的运用非常灵活,没有绝对的套路可言,以下用例设计思路仅供参考。 操作流程举例 参考文档: ?ECShop_2.7.2_简易操作手册V1.0, ?B2C商城ECShop需求规格说明书_2.7.2V1.0 设计思路: 根据操作手册,理清业务逻辑前后关系,再结合SRS文档确定具体的流程细节和分支流程。可以通过画流程的方式梳理流程(流程分析法),下面是部分主流程的案例: ?正向订单流程_余额付款 1)前台页面浏览商品->加入购物车->结算中心->余额付款 2)后台管理中心订单查询->配货->生成发货单->确认生成发货单->去发货->发货 3)前台页面确认收货END ?正向订单流程_货到付款 1)前台页面浏览商品->加入购物车->结算中心->货到付款 2)后台管理中心订单查询->配货->生成发货单->确认生成发货单->去发货 ?逆向订单流程 1)前台页面确认收货->后台管理中心退货->填写退货信息点确定按钮->确认退货 ?商品添加流程_新商品 1)后台管理中心商品管理->新建商品类型/新建商品分类/新建商品品牌->添加新商品(通用信息,详细描述,其他信息,商品属性,商品相册,关联商品,配件,关联 文章) 考虑完所有流程后,再补充考虑部分异常情况,例如:流程中的先后顺序发生变化,或者跳过某个步骤后,系统能否完成后续流程作业。(有些流程是不可能调换顺序或跳过的) Q:流程分析法在设计测试用例的时候会经过很多页面,操作很多字段,这些页面和字段该如何取值呢? A:流程分析法一般考虑页面或字段的有效取值(一般取等价类中最不容易出错的值),测试过程中不关注页面输入域的各种取值情况,特别是错误取值的情况。目的是为了确保流程是可用的。 Q:流程分析法既然不能证明某个页面或字段没有问题,那用此法有何意义呢,为何不直接考虑验证每个页面和模块的各种有效和无效的取值?

[方案]编写软件测试用例文档的例子

[方案]编写软件测试用例文档的例子TestCase_LinkWorks_WorkEvaluate 用例编号 LinkWorks 项目名称 WorkEvaluate模块模块名称 研发中心-质量管理部项目承担部门 用例作者 2005-5-27 完成日期 质量管理部本文档使用部门 评审负责人 审核日期 批准日期 注:本文档由测试组提交~审核由测试组负责人签字~由项目负责人批准。 历史版本: 版本/状态作者参与者起止日期备注 V1.1 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI(图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。 项目名称用例标识 LinkWorks_ WorkEvaluate_02 MIIP 陈谦模块名称开发人员 WorkEvaluate 参考信息工作考核系统界面设计(2005_03_28).vsd 用例作者

设计日期测试人员高珍珍测试类型 2014-8-25 黑盒测试日期测试方法 用例描述 前置条件 编号权限测试项测试描述/输入/操作期望结果真实备注 (并列类别结果 关系) 无列导航栏导航浏览\点击导航连接详细正确导航页面所 00001 表测试在位置 页添加删除修添加修改删除按钮是否不可用 00002 面改按钮可用 接受、汇报按1) 不是自己负责的数据不能 钮未考核之前能否接受 \汇报 2) 属于自己负责的未接能 受之前时候是否可以 接受 00003 3) 属于自己负责的数据能 接受后但未考核能否 可以汇报 4) 接受后的数据没有汇不能 报但考核了,是否仍 可以汇报 考核审核按这俩按钮是否可用这两按钮为置灰,不 00004 钮可用 二级联动下功能下拉列表选择 1)默认为“本月由我

关键功能接口测试用例

1.目的 测量手机各关键硬件接口在工作状态的性能符合设计规范,以确保手机性能的稳定性符合设 计要求; 2.适用范围 适用于新开发手机产品在试产阶段的评测及相关功能重大更改时; 3.测试准备和说明: 3.1电池或程控电源,四通道数字示波器,相关机型的原理图及PCB丝印图,万用表(直流电 流档),原配耳机,各种不同类型的SIM卡至少三张以上,不同容量的TF卡至少三张,烙 铁,电批,细导线若干,SIM卡转接座(自制),100欧可调电阻器一个。 3.2各项测试前应确保手机基本功能正常; 3.3测试过程中必须配带静电环,确保静电安全; 3.4测试结果如有必要需附测试波形图; 3.5测试过程中示波器负极应就近接地,如有必要,测试结果应附波形图。 3.6 DP04034数字示波器的使用请参考指导:。 4.内容: 4.1 摄像头回路测试(测试用例编号: 5.1.1) 4.1.1 测试条件: 3.8V电源,示波器,相关机型的原理图及PCB图,细导线,电流表,拍照状态。 4.1.2 测试步骤: 1)手机开壳,根据原理图、PCB图找到摄像头AVDD/DVDD/CMRST脚,将数字示波器CH1,CH2,CH3分别接入手机AVDD,DVDD及CMRST端,负极接地。 2)示波器选用采样直流模式;电压标度设置1V/格,时间标度设为1S/格;添加测量幅值和最大值; 3)手机开机进入拍照模式,记录进入拍照过程中示波器的电压变化情况;测量VCAM-A 上升2/3到CMRST所需时间T1; 4)在VDD供电端串入一个电流表,测量摄像头工作状态的电流并记录。 4.1.3 预期结果: 摄像头工作电压、电流最大不应超过规格书要求的额定功率。 4.2 MIC偏置电压(测试用例编号: 5.1.2) 4.2.1 测试条件: 电源,示波器,原理图及PCB图,细导线,耳机,录音状态。 4.2.2 测试步骤:

测试用例(银行系统)

安徽翰子昂 {银行系统} { 银行系统的功能测试用例}

版本历史

目录 版本历史................................................................................................ 错误!未定义书签。 1.文档介绍................................................................................................... 错误!未定义书签。 文档目的和范围......................................................................................... 错误!未定义书签。 读者对象..................................................................................................... 错误!未定义书签。 术语与缩写解释......................................................................................... 错误!未定义书签。 2.功能测试用例 ........................................................................................... 错误!未定义书签。 被测试对象的介绍..................................................................................... 错误!未定义书签。 测试范围与目的......................................................................................... 错误!未定义书签。银行系统的管理员用户操作和普通用户操作测试环境与测试辅助工具的描述 . 错误!未定义书签。 功能测试用例............................................................................................. 错误!未定义书签。

NGB中间件api接口测试用例设计与实现_电视技术_2014.2(1405061859279)

*1 NGB终端中间件API接口测试用例的设计与实现 张定京,赵良福,付光涛,李小雨,王颖 (国家广播电影电视总局广播科学研究院,北京 100866) 摘要:根据NGB终端中间件标准有关Java API和JS API的接口定义和要求,以及NGB的业务需求,制定了API接口测试用 例的设计原则和设计方案,方案包括自动化和手动两种方式,两类测试相互补充。本文通过以频道搜索和媒体处理两个典型 测试单元为例,介绍了这两类测试用例的软件设计流程和具体实现方法。该方案设计已经过验证,并应用于NGB中间件的 标准符合性测试中。 关键词:下一代广播电视网;中间件;API;测试用例 【中图分类号】TN949.6 【文献标识码】B Design and Implementation of API Test cases for Middleware of NGB receiver ZHANG Ding-jing,ZHAO Liang-fu,FU Guang-tao,LI Xiao-yu,WANG Ying (Academy of Broadcasting Science State Administration of Radio,Film & Television,Beijing 100866,China)Abstract: According to Java API and JS API interface definitions and requirements of NGB receiver middleware specification, as well as NGB business needs, design principles and schemas for API interface test cases are developed, including automated and manual modes, the two types could complement each other. In this paper, the two types of software design processes and implementation methods for test cases are described by two typical testing units-channel scanning and media processing. The design has been validated and applied to NGB middleware standards compliance testing. Key words:Next Generation Broadcasting; middleware; API; test case 1引言 下一代广播电视网(简称NGB)终端中间件是运行在数字电视接收终端中的软件,按功能层次划分 处于接收终端资源层之上、应用层之下;其向下屏蔽了资源层的差异,向上为应用的开发提供一套完整、 统一的应用编程接口(简称API);中间件与资源层协同工作,能承载和支撑各种不同的应用。NGB数字 电视接收终端采用中间件可以提升应用的互操作性,即同一款终端能够运行不同应用提供商开发的应用, 同一个应用能够运行在不同的终端之上[1]。因此,NGB中间件技术对推动NGB和三网融合的整体发展, 加快广电新业态的业务生成和部署,以及跨域业务的互联互通,具有十分重要的意义[2]。 国家广播电影电视总局于2012年10月发布了NGB终端中间件技术规范,标准号为GY/T 267—2012[1]。目前遵循该规范的NGB终端机顶盒已进入研发和生产阶段,接下来产品的测试和认证工作就显得尤为迫切和重要,因此判定产品是否符合中间件技术要求将是亟待解决的问题。 GY/T 267—2012[1]标准对NGB终端中间件的软件架构、协议栈、内容格式、应用信令、应用传输、应用支撑、安全机制、应用编程接口等各个方面的技术要求进行了规定。其中应有编程接口是该标准的核心内容,检验终端产品是否符合中间件标准要求基本可通过对应有编程接口的全方位测试来加以验证。本文将简述中间件API接口要求,描述API接口的测试方法和测试方案,以典型测试单元为例,介绍测试用例的设计和实现方法。 2中间件API NGB终端中间件软件架构示意见图1。 1国家科技支撑计划项目课题No.2012BAH02B01经费资助

测试用例设计练习

一、等价类划分法 例子1: 现在有一个档案管理系统,容许用户通过输入年月对档案文件进行检索,系统对查询条件年月的输入限定为1990年1月-2049年12月,并规定,日期由6位数字组成,前4位表示年,后2位表示月。 1,根据需求进行分析,找出有哪些输入条件 年份:【1990,2049】 月份:【01,12】 字符长度:6位 字符类型:数字 2,画出等价类 输入条件有效等价类边界值分析无效等价类 年份【1990,2049】(1)上点:1990,2049(12) 离点:1989,2050 内点:2016 <1990 (2)>2049 (3) 月份【01,12】(4)上点:01,12(13) 离点:00,13 内点:11 <01 (5)>12 (6) 字符长度6位(7)上点:6 离点:5,7 内点:6 <6 (8)>6 (9) 字符类型数字(10)非数字(11)3,为每个等价类规定一个唯一编号(如上图) 4,转换成测试用例 转换测试用例的原则: A,设计一个测试用例尽可能多的覆盖多个有效等价类; B,设计一个测试用例必须对应覆盖一个无效等价类。 有效等价类用例: 用例1:201611 (1)(4)(7)(10) 无效等价类用例: 用例2:198911 (2) 用例3:205011 (3) 用例4:201600 (5) 用例5:201613 (6) 用例6:20161 (8) 用例7:2016113 (9) 用例8:20161a/abcedf (11) 根据边界值分析法分析后补充测试用例 用例9:199001 (12) 用例10:204912 (13) 5,转成正式格式用例(用例写作的8大要素) 用例编号D1223232_ST_Search_Date_001 项目搜索功能 标题输入正确的日期格式成功搜索

软件测试用例(标准参考)

{ 项目名称} { 测试用例标题} 机构公开信息

版本历史

目录 0. 文档介绍 (5) 0.1文档目的 (5) 0.2文档范围 (5) 0.3读者对象 (5) 0.4参考文献 (5) 0.5术语与缩写解释 (5) 1. 接口-路径测试用例 (6) 1.1被测试对象(单元)的介绍 (6) 1.2测试范围与目的 (6) 1.3测试环境与测试辅助工具的描述 (6) 1.4测试驱动程序的设计 (6) 1.5接口测试用例 (6) 1.6路径测试的检查表 (7) 2. 功能测试用例 (8) 2.1被测试对象的介绍 (8) 2.2测试范围与目的 (8) 2.3测试环境与测试辅助工具的描述 (8) 2.4测试驱动程序的设计 (8) 2.5功能测试用例 (8) 3. 健壮性测试用例 (9) 3.1被测试对象的介绍 (9) 3.2测试范围与目的 (9) 3.3测试环境与测试辅助工具的描述 (9) 3.4测试驱动程序的设计 (9) 3.5容错能力/恢复能力测试用例 (9) 4. 性能测试用例 (10) 4.1被测试对象的介绍 (10) 4.2测试范围与目的 (10) 4.3测试环境与测试辅助工具的描述 (10) 4.4测试驱动程序的设计 (10) 4.5性能测试用例 (10) 5. 图形用户界面测试用例 (11) 5.1被测试对象的介绍 (11) 5.2测试范围与目的 (11)

5.3测试环境与测试辅助工具的描述 (11) 5.4测试驱动程序的设计 (11) 5.5测试人员分类 (11) 5.6用户界面测试的检查表 (11) 6. 信息安全性测试用例 (12) 6.1被测试对象的介绍 (12) 6.2测试范围与目的 (12) 6.3测试环境与测试辅助工具的描述 (12) 6.4测试驱动程序的设计 (12) 6.5信息安全性测试用例 (13) 7. 压力测试用例 (13) 7.1被测试对象的介绍 (13) 7.2测试范围与目的 (13) 7.3测试环境与测试辅助工具的描述 (13) 7.4测试驱动程序的设计 (13) 7.5压力测试用例 (14) 8. 可靠性测试用例 (14) 8.1被测试对象的介绍 (14) 8.2测试范围与目的 (14) 8.3测试环境与测试辅助工具的描述 (14) 8.4测试驱动程序的设计 (14) 8.5可靠性测试用例 (15) 9. 安装/反安装测试用例 (15) 9.1被测试对象的介绍 (15) 9.2测试范围与目的 (15) 9.3测试环境与测试辅助工具的描述 (16) 9.4测试驱动程序的设计 (16) 9.5安装/反安装测试用例 (16) 附录:评审意见 (16)

个人外汇业务监测系统接口验收案例(DOC 40页)

个人外汇业务监测系统接口验收案例(DOC 40页)

个人外汇业务监测系统接口验收案例 一、接口验收要求和说明 接口验收案例用于现场验收过程中测试银行接口是否满足接口接入管理要求,不作为银行办理个人结售汇业务的规范指导。个人结售汇业务办理应依据相关法规进行。 外汇局现场验收过程中,对于案例中成功提交的业务应及时打印结汇/购汇通知单,并标注对应的测试案例编号,用于信息比对和后续测试需要。 个人结售汇业务信息中“业务办理时间、业务类型、证件类型、证件号码、国家/地区、补充证件号码”信息有误,使用撤销操作。其他信息有误,使用修改功能。修改和撤销功能应由具备修改和撤销角色的业务主管操作。 二、接口验收案例类型列表 1、柜台占用额度的结售汇 1.1身份证个人账户资金年度额度内结汇 1.2香港个人外币现钞单笔超额结汇,重点关注对象个人首次办理个人结售汇业务 1.3身份证个人汇入资金结汇超剩余可结汇额度,关注名单个人 1.4身份证个人年度额度内购汇后提钞、汇出、存账户及旅

行支票 1.5 外国护照个人办理购汇业务 2、柜台不占用额度的结售汇 2.1澳门个人提供凭证的经常项目其他结汇,单笔外币现钞结汇超额 2.2身份证个人货物贸易个人结算账户资金结汇 2.3外国护照个人提供凭证的经常项目其他购汇,提钞、存入外汇账户、汇出及旅行支票 3、补录 3.1身份证个人占额度结汇,现钞超额、超年度总额、补录原因为其它 3.2 身份证个人提钞超额、占额度购汇补录,补录原因应急预案启动后补录 3.3中国护照个人资本项目不占用额度购汇汇出补录,补录原因脱机操作 4、修改和撤销 4.1 占额度结汇修改(案例1.1),修改原因为其它 4.2 不占用额度购汇修改(案例 3.3),修改原因为币种错误 4.3 不占额度结汇撤销(案例2.1),撤销原因为其他 5、支付机构结售汇 5.1身份证个人通过支付机构汇入资金结汇

软件测试用例实例(非常详细)

1、兼容性测试 在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。测试目的 配置说明操作系统系统软件外设应用软件结果 服务器Window2000(S) WindowXp Window2000(P) Window2003 用例编号TestCase_LinkWorks_WorkEvaluate 项目名称LinkWorks 模块名称WorkEvaluate模块 项目承担部门研发中心-质量管理部 用例作者 完成日期2005-5-27 本文档使用部门质量管理部 评审负责人 审核日期 批准日期 注:本文档由测试组提交,审核由测试组负责人签字,由项目负责人批准。历史版本: 版本/状态作者参与者起止日期备注 V1.1 1.1. 疲劳强度测试用例 强度测试也是性能测试是的一种,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。 测试目的

测试说明 前提条件连续运行8小时,设置添加10用户并发 测试需求输入/动作输出/响应是否正常运行 功能1 2小时 4小时 6小时 8小时 功能1 2小时 4小时 6小时 8小时 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务 规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则 的实施是否恰当。主要测试技术方法为用户通过GUI(图形用户界面)与应用程序交互,对 交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。 用例标识LinkWorks_ WorkEvaluate_02 项目名称https://www.doczj.com/doc/dc1816434.html, 开发人员模块名称WorkEvaluate 用例作者参考信息工作考核系统界面设计(2005_03_28).vsd 测试类型设计日期2006-9-27 测试人员 测试方法黑盒测试日期 用例描述 前置条件 编号权限 (并列 关系)测试项测试 类别 描述/输入/操作期望结果真实 结果 备注 00001 无列 表 页 面 导航栏导航 测试 浏览\点击导航连接详细正确导航页面所 在位置 00002 添加删除修 改按钮 添加修改删除按钮是否 可用 不可用 00003 接受、汇报按 钮 1)不是自己负责的数据 未考核之前能否接受 \汇报 不能 2)属于自己负责的未接 受之前时候是否可以 接受 能

酒店管理系统-测试用例 ()

酒店管理系统 测试用例 姓名:王运飞 学号:08111423 文件状态: [√] 草稿 [ ] 正式发布 [ ] 正在修改文件标 识: 东华理工大学-酒店管理系统-测试报 告 当前版 本: 2.0 作 者: 王运飞 完成日 期: 2010-10-26 版本/状态作者参与者起止日期备注 1.0 王运 飞 王运飞 2.0 王运 飞王运飞修复了一下bug,程序运 行更加稳定了

目录 0.文档介绍.................................................. 0.1文档目的................................................. 0.2文档范围................................................. 0.3读者对象................................................. 0.4参考文献................................................. 0.5术语与缩写解释........................................... 1. 接口-路径测试用例 ........................................ 1.1被测试对象(单元)的介绍 ................................ 1.2测试范围与目的........................................... 1.3测试环境与测试辅助工具的描述............................ 1.4接口测试用例............................................. 1.5路径测试的检查表 ........................................ 2. 功能测试用例 .............................................. 2.1被测试对象的介绍 ........................................ 2.2测试范围与目的........................................... 2.3测试环境与测试辅助工具的描述............................ 2.4功能测试用例............................................. 3. 健壮性测试用例 ............................................ 3.1被测试对象的介绍 ........................................ 3.2测试范围与目的........................................... 3.3测试环境与测试辅助工具的描述............................ 3.4容错能力/恢复能力测试用例 ............................... 4. 图形用户界面测试用例 ...................................... 4.1被测试对象的介绍 ........................................ 4.2测试范围与目的........................................... 4.3测试环境与测试辅助工具的描述............................ 4.4用户界面测试的检查表 .................................... 5. 信息安全性测试用例 ........................................ 5.1被测试对象的介绍 ........................................ 5.2测试范围与目的........................................... 5.3测试环境与测试辅助工具的描述............................ 5.4测试驱动程序的设计 ...................................... 5.5信息安全性测试用例 ...................................... 6. 压力测试用例 .............................................. 6.1被测试对象的介绍 ........................................ 6.2测试范围与目的........................................... 6.3测试环境与测试辅助工具的描述............................ 6.4测试驱动程序的设计 ......................................

测试用例

《校园一卡通信息系统》 测试用例文档 姓名:20091101136 陈云巧 20091101138 洪福芝 20091101142 刘艳芳 20091101148 陶玫 20091101151 杨艳梅 20091101153 赵艳 20091101154 严蔚 班级:09计科一班 提交日期:2011年12月5日

目录0. 文档介绍 0.1文档目的 0.2文档范围 0.3读者对象 0.4参考文献 1. 接口-路径测试用例 1.1被测试对象(单元)的介绍 1.2测试范围与目的 1.3测试环境与测试辅助工具的描述 1.4测试驱动程序的设计 1.5接口测试用例 1.6路径测试的检查表 2. 功能测试用例 2.1被测试对象的介绍 2.2测试范围与目的 2.3功能测试用例 3. 健壮性测试用例 3.1被测试对象的介绍 3.2测试范围与目的 3.3测试环境与测试辅助工具的描述 3.4测试驱动程序的设计 3.5容错能力/恢复能力测试用例 4. 性能测试用例 4.1被测试对象的介绍 4.2测试范围与目的 4.3性能测试用例 5. 图形用户界面测试用例 5.1被测试对象的介绍 5.2测试范围与目的 5.3用户界面测试的检查表 6. 信息安全性测试用例 6.1被测试对象的介绍 6.2测试范围与目的

6.5信息安全性测试用例 7. 压力测试用例 7.1被测试对象的介绍 7.2测试范围与目的 7.3测试环境与测试辅助工具的描述 7.4压力测试用例 8. 可靠性测试用例 8.1被测试对象的介绍 8.2测试范围与目的 8.5可靠性测试用例 9. 安装/反安装测试用例 9.1被测试对象的介绍 9.2测试范围与目的 9.5安装/反安装测试用例

典型测试用例案例讲解

案例一:三角形判断功能测试 输入三条边,判断能否组成三角形,能组成三角形,继续判断能组成等腰三角形?等边三角形?还是直角三角形? 案例二:用户修改个人信息 要求:电话:11位长数字串 密码:18位以内的字符串(包含18位长) 用户登陆后可以修改个人信息,包含:电话号码、密码。 点击“修改用户信息”控件,系统显示所有用户个人信息: 其中用户名和工号不可修改,不能进行输入。密码分旧密码、新密码、验证新密码, 若需修改密码,系统验证旧密码正确,两个新密码相同,则更新密码,旧密码即失效,其他修改项也生效,并提示“用户信息修改成功”; 若旧密码不正确(旧密码是否正确),则提示“用户密码错”,系统将不修改个人信息;若两个新密码不同(两个新密码是否相同),则提示“新密码与验证新密码不同”,系统将不修改个人信息。 若只修改密码外其他信息(是否修改密码),则不需输入两个新密码,系统只验证旧密码正确,就成功更改个人信息,并提示“用户信息修改成功”;如果系统验证旧密码输入不正确,则提示“用户密码错”。

案例三:读书选择 1、如果觉得疲倦并且对书的内容感兴趣,同时书中的内容让你糊涂的话,回到本章重读 2、如果觉得疲倦并且对书的内容感兴趣,同时书中的内容不让你糊涂,继续读下去 3、如果觉得疲倦并且对书中的内容不感兴趣,同时书中的内容不让你糊涂,停止阅读,请休息 4、如果觉得疲倦并且对书的内容不感兴趣,并且书中的内容让你糊涂,请停止阅读,休息 5、不疲倦,对书的内容感兴趣,书中的内容不糊涂,继续读下去 6、不疲倦,不感兴趣,书中内容不糊涂,跳到下一章去读 7、不疲倦、不感兴趣、且糊涂跳到下一章去读 8、不疲倦、感兴趣,且糊涂回到本章重读 案例四:PPT打印功能测试 PowerPoint软件打印功能描述如下: 打印范围分:全部、当前幻灯片、给定范围共三种情况; 打印内容分:幻灯片、讲义、备注页、大纲视图共四种方式; 打印颜色/灰度分: 颜色、灰度、黑白共三种设置; 打印效果分:幻灯片加框和幻灯片不加框两种方式。 请利用如下正交表设计用例。 下面正交表共四个因子,其中每个因子三状态:

测试用例八大设计方法和实例

测试用例设计方法 1等价类划分 1.1 理论知识 等价类划分是一种典型的黑盒测试方法。这一方法完全不考虑程序的内部结构,只依据程序的规格说明来设计测试用例。 等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭示程序中的错误都是等效的。 等价类合理地假设:某个等价类的代表值,与该等价类的其他值,对于测试来说是等价的。 因此,可以把全部的输入数据划分成若干的等价类,在每一个等价类中取一个数据来进行测试。这样就能以较少的具有代表性的数据进行测试,而取得较好的测试效果。 等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法. 1) 分类: 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能. 无效等价类:与有效等价类的定义恰巧相反. 设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性. 2)划分等价类的方法: 下面给出六条确定等价类的原则: ①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类. ②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效

银行业务测试基本概述

银行软件测试的基本概述 一般的银行系统软件都有一个核心系统,核心系统主要涉及账务的处理、清算、计息等。银行的其它业务系统都会直接或间接的与核心系统进行交互,主要处理一些涉及业务的流程以及系统管理、用户管理等辅助功能。 此外,银行的业务系统也种类繁多。比如:柜面、网上银行、电话银行、呼叫中心、信贷、资产托管、资金风险分析及风险控制系统、外汇买卖、基金、期货、黄金、汇票、信用卡业务以及其它衍生业务等等。各个系统之间都可能有着密切的联系,之间也会涉及到不同系统之间的接口。 因此,在测试过程中,除了对银行的核心系统、业务系统进行测试之外,还会涉及对接口的测试,而接口测试往往需要测试人员构造一定的测试环境与测试数据来模拟各系统之间的交互。 就银行系统软件来说,本身就具有复杂性的特点。银行软件具有不同的客户群,如个人用户、企业用户、银行内部管理人员、业务人员等,因此,银行软件会有针对不同客户所使用的版本或权限控制。此外,对于不同的服务方式,如柜台、电话银行、网上银行等,都必须开发出不同的软件。其次,银行业务种类繁多,业务逻辑也非常复杂,对业务处理要求有很高的安全性和实时性,这些都要借助复杂的技术才能实现。因此,对于测试而言,软件的复杂性也增加了测试的复杂性,对测试者来说要求有相当的经验和测试技术的支持。 由于银行业务的快速发展,当旧的银行软件系统无法满足业务处理的要求时,就必须开发新的系统,对于重新开发的新系统来说,旧系统的用户数据必须保证能在新系统中正常使用,这就涉及到了新旧版本的数据移植问题,由于新旧系统之间数据字典存在差异,数据移植后能否正常,就需要对新旧数据进行比对性测试。比对测试过程往往会涉及数据库的应用及比对工具的开发使用。 软件测试方法及范围分析 以下主要从功能测试、接口测试、数据移植测试、性能测试、安全性测试、风险监控测试、文档审核几个方面来阐述软件的测试方法及范围。以下划分主要为了更清晰了解软件测试所包含的范围,本次分析不涉及白盒测试的内容,主要针对涉及银行业软件业务特性的测试方法及范围进行阐述。 1功能测试 功能测试,主要是对软件的功能进行的验证,对于金融行业软件来说,功能测试主要进行以下功能的验证: 1.1业务验证测试 验证业务系统的功能是否正确实现,测试其业务处理的准确性。 1)业务流程测试 首先关注的是业务的正确性,业务流程要合理、业务处理正确无误,这些往

测试用例设计思路

测试用例设计思路 为了提高我们编写测试用例的质量,以下列出了在拿到一个页面或模块后,编写测试用例的思路。请大家参考,如有遗漏请及时补充。 1.验证系统满足需求或设计中的规定的功能,也就是说首先应该验 证系统满足正常的功能(通过测试)。 2.考虑设计中描述的异常情况处理,验证设计中描述的异常错误处 理是否实现。 3.考虑权限问题,是否能越权操作。(如FIA中的数据权限和操作权 限) 4.考虑必填项和重名的问题。 5.考虑字段类型及长度的问题。 6.考虑web会话问题,如直接输入主页面的url,是否能够直接进入 系统。 7.验证默认值,默认值是否正确合理。 8.文本框值域测试、边界值测试。如对英文单引号、双引号、<>、 &、\的处理。如果是web的话,还需要考虑对html标记的处理,如输入。 9.页面其它控件测试。如下拉列表框、复选框、文本域等。 10.破坏性测试(重启、断电、断网、服务停掉、服务重启等)。 注意:在考虑破坏性测试的时候需要融入边界值思想,有时进行一次操作并不能发现问题,而多试几次问题就会出现。

11.验证业务模块之间的数据流是否正确,考虑各业务模块之间的关 系(模块接口测试)。 注:这个地方应该设计一些接口测试的测试用例,这块内容比较容易遗漏。 12.考虑用户可能操作的各种场景,特殊业务流程,比如不按正常业 务流程进行操作、违规操作(场景测试)。 注:在此需要着重考虑用户可能的操作习惯,切不可按照自己的操作习惯进行测试。 13.考虑在负载较大时的业务处理。 14.考虑数据的安全性及可恢复性。 15.注意考虑用户环境与测试环境的差别,包括客户端环境、服务器 环境。 注:可以与呼怀泽多沟通,询问一下用户那里的环境。 16.注意考虑市场动态,比如目前win2008比较流行,而且很多为64 位,这是就应该考虑产品是否支持,是否需要在此环境上测试。 注:目前linux系统更新较快、火狐浏览器更新较快,这个是否考虑进行支持,并进行测试。

测试用例实例

测试用例实例 1、一个好的用例的表述要点,即用例中应当包含的信息 一个优秀的测试用例,应该包含以下信息: 1)?软件或项目的名称 2)?软件或项目的版本(内部版本号) 3)?功能模块名 4)?测试用例的简单描述,即该用例执行的目的或方法 5)?测试用例的参考信息(便于跟踪和参考) 6)?本测试用例与其他测试用例间的依赖关系 7)?本用例的前置条件,即执行本用例必须要满足的条件,如对数据库的访问权限 8)?用例的编号(ID),如可以是软件名称简写-功能块简写-NO.。 9)?步骤号、操作步骤描述、测试数据描述 10) 预期结果(这是最重要的)和实际结果(如果有BUG管理工具,这条可以省略) 11)开发人员(必须有)和测试人员(可有可无) 12)测试执行日期 2、实例 该测试案例是以一个B/S结构的登录功能点位被测对象,该测试用例为黑盒测试用例。假设用户使用的浏览器为 SP4。 功能描述如下: 1.用户在地址栏输入相应地址,要求显示登录界面; 2.输入用户名和密码,登录,系统自动校验,并给出相应提示信息; 3.如果用户名或者密码任一信息未输入,登录后系统给出相应提示信息; 4.连续3次未通过验证时,自动关闭IE。 表4-1登录界面测试用例

自动取款机取款用例规约和测试用例 取款用例说明: 此用例完成用户利用自动取款机取款的全部流程,分为以下流程:插卡,输入密码,选择金额,取款,取卡等操作。 事件流: 该用例在用户插卡之后启动 1. 系统提示用户插卡; 2. 提示客户输入密码信息; 3. 密码输入完毕后,客户选择“确认”,向系统提交信息; 4. 系统验证客户输入的密码信息,确认正确后,进入选择系统主界面; 5. 用户选择取款选项; 6. 系统进入取款金额界面并提示用户输入金额; 7. 系统验证可以取款并输出钱款; 8. 系统提示用户取卡,操作完成。 基本流: 用户取款。 备选流: 1.用户密码错误 2.取款金额不符合要求。 前置条件: 用户必须插入正确的银行卡才能开始执行用例。 后置条件: 如果系统确认用户信息正确,成功登陆,则系统启动主界面,等待用户发送消息,进行查询和取款等操作。

如何设计接口测试用例

如何设计接口测试用例 接口测试是项目测试的一部分,正如其名,它测试的主要对象是接口,是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。 如何设计接口测试用例? 首先,明确出发点。和所有的测试一样,接口测试出发点是你要证明所测的程序是错误的。以这个出发点为导向,你的设计行为就会尽量朝这个方向发展,更易发现问题,不会出现大方向的偏差。 其次,选择好测试对象。对于一个系统做接口测试选择好的测试对象是接口测试关键。一个系统有无数的接口,每个接口如果分别测试,那将是很痛苦的一件事情,不光繁琐浪费,而且任何一个内部接口的变动,都将导致我们用例的不可用。这里推荐把整个系统作为一个整体,选择整个系统提供给外部使用、交互的最外层接口作为你的测试对象,以此为测试对象的用例将有很好的健壮性,并且更高效。另外,根据数据的流向,又可将这些最外层的接口分为两类:一类是数据进入系统的接口;一类是数据流出系统的接口。进入系统的接口实际是我们用例的执行调用的接口。可通过变化参数对这些接口进行调用,模拟外部的使用;而流出的接口则是我们用例真正该验证的点。数据从哪里流出,流出时的状态如何,此时系统又是什么状态都是我们所应该验证的。 然后,确认完整的测试对象的功能:确认外部接口提供给使用这些接口的外部用户什么样的功能,外部用户真正需要什么样的功能。此两个功能一定要准确详细,用例的设计要严格按照测试对象功能设计才是正确的用例。 最后当出发点、对象、功能都确定了,就可以真正设计用例了。下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。 接口测试用例设计和其他测试用例设计一样,都应该本着尽可能的发现bug的目标。用例设计的内容应该包括:主要测试功能点、测试环境、测试数据、执行操作以及预期结果。 1)接口测试环境分为两种:一种是程序内部的环境;一种是程序的所调用外部接口的环境。用例在设计环境上有一个原则即:设计真实而危险的环境,不忽视偶发环境。真实,即你的用例在测试某种功能时,应该去思考这种情况发生时内部、外部环境是什么,通过各种手段将最准确的环境模拟出来。危险,即在这种环境下系统出问题的概率会很大。在设计用例环境时,如果两种环境都能达到你本用例的要求,更推荐选择更危险的环境。所谓偶发,即这种环境出现的概率很小。不要因为这种环境很少出现就无视它,开发很可能也是这种想法,此处很有可能隐藏着问题。 2)接口测试测试数据分为接口参数数据和用例执行所需系统数据。数据的设计学问大,

相关主题
文本预览
相关文档 最新文档