黑盒测试举例.docx
- 文档编号:25049518
- 上传时间:2023-06-04
- 格式:DOCX
- 页数:32
- 大小:29.80KB
黑盒测试举例.docx
《黑盒测试举例.docx》由会员分享,可在线阅读,更多相关《黑盒测试举例.docx(32页珍藏版)》请在冰豆网上搜索。
黑盒测试举例
软件测试分类及介绍:
软件测试是一项复杂的系统工程,从不同的角度考虑可以有不同的划分方法,对测试进行分类是为了更好的明确测试的过程,了解测试究竟要完成哪些工作,尽量做到全面测试。
1,按是否需要执行被测软件的角度
按是否需要执行被测软件的角度,可分为静态测试和动态测试,前者不利用计算机运行待测程序而应用其他手段实现测试目的,如代码审核。
(我认为主要是让测试人员对编译器发现不了的潜在错误进行分析,如无效的死循环,多余的变量等),而动态测试则通过运行被测试软件来达到目的。
2、按阶段划分:
1单元测试
单元测试是对软件中的基本组成单位进行的测试,如一个模块、一个过程等等。
它是软件动态测试的最基本的部分,也是最重要的部分之一,其目的是检验软件基本组成单位的正确性。
因为单元测试需要知道内部程序设计和编码的细节知识,一般应由程序员而非测试员来完成,往往需要开发测试驱动模块和桩模块来辅助完成单元测试。
因此应用系统有一个设计很好的体系结构就显得尤为重要。
一个软件单元的正确性是相对于该单元的规约而言的。
因此,单元测试以被测试单位的规约为基准。
单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
2集成测试
集成测试是在软件系统集成过程中所进行的测试,其主要目的是检查软件单位之间的接口是否正确。
它根据集成测试计划,一边将模块或其他软件单位组合成越来越大的系统,一边运行该系统,以分析所组成的系统是否正确,各组成部分是否合拍。
集成测试的策略主要有自顶向下和自底向上两种。
3系统测试
系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等满足其规约所指定的要求,检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的“先知者问题”。
因此,系统测试应该按照测试计划进行,其输入、输出和其他动态运行行为应该与软件规约进行对比。
软件系统测试方法很多,主要有功能测试、性能测试、随机测试等等。
4验收测试
验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。
它的测试数据通常是系统测试的测试数据的子集。
所不同的是,验收测试常常有软件系统的购买者代表在现场,甚至是在软件安装使用的现场。
这是软件在投入使用之前的最后测试。
5回归测试
回归测试是在软件维护阶段,对软件进行修改之后进行的测试。
其目的是检验对软件进行的修改是否正确。
这里,修改的正确性有两重含义:
一是所作的修改达到了预定目的,如错误得到改正,能够适应新的运行环境等等;二是不影响软件的其他功能的正确性。
6Alpha测试:
在系统开发接近完成时对应用系统的测试;测试后,仍然会有少量的设计变更。
这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。
7Beta测试:
当开发和测试根本完成时所做的测试,而最终的错误和问题需要在最终发行前找到。
这种测试一般由最终用户或其他人员员完成,不能由程序员或测试员完成。
3、按测试方法划分:
1白盒测试
白盒测试也称结构测试或逻辑驱动测试,是指基于一个应用代码的内部逻辑知识,即基于覆盖全部代码、分支、路径、条件的测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
“白盒”法是穷举路径测试。
在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。
贯穿程序的独立路径数是天文数字。
但即使每条路径都测试了仍然可能有错误。
第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。
第二,穷举路径测试不可能查出程序中因遗漏路径而出错。
第三,穷举路径测试可能发现不了一些与数据相关的错误。
白盒测试可以借助一些工具来完成如JunitFramework,Jtest等。
2黑盒测试
黑盒测试是指不基于内部设计和代码的任何知识,而基于需求和功能性的测试,黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。
黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等,主要用于软件确认测试。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。
“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。
实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。
黑盒测试也可以借助一些工具,如WinRunner,QuickTestPro,RationalRobot等。
3ALAC(Act-like-a-customer)测试
ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。
ALAC测试是基于复杂的软件产品有许多错误的原则。
最大的受益者是用户,缺陷查找和改正将针对哪些客户最容易遇到的错误。
软件测试举例:
ATM机操作用例:
一台ATM机器的主角和用例。
下表包含了上图中提款用例的基本流和某些备用流:
本用例的开端是ATM处于准备就绪状态。
准备提款-客户将银行卡插入ATM机的读卡机。
验证银行卡-ATM机从银行卡的磁条中读取帐户代码,并检查它是否属于可以接收的银行卡。
输入PIN-ATM要求客户输入PIN码(4位)
验证帐户代码和PIN-验证帐户代码和PIN以确定该帐户是否有效以及所输入的PIN对该帐户来说是否正确。
对于此事件流,帐户是有效的而且PIN对此帐户来说正确无误。
ATM选项-ATM显示在本机上可用的各种选项。
在此事件流中,银行客户通常选择“提款”。
输入金额-要从ATM中提取的金额。
对于此事件流,客户需选择预设的金额(10美元、20美元、50美元或100美元)。
授权-ATM通过将卡ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程。
对于此事件流,银行系统处于联机状态,而且对授权请求给予答复,批准完成提款过程,并且据此更新帐户余额。
出钞-提供现金。
返回银行卡-银行卡被返还。
收据-打印收据并提供给客户。
ATM还相应地更新内部记录。
用例结束时ATM又回到准备就绪状态。
备选流1-银行卡无效
在基本流步骤2中-验证银行卡,如果卡是无效的,则卡被退回,同时会通知相关消息。
备选流2-ATM内没有现金
在基本流步骤5中-ATM选项,如果ATM内没有现金,则“提款”选项将无法使用。
备选流3-ATM内现金不足
在基本流步骤6中-输入金额,如果ATM机内金额少于请求提取的金额,则将显示一则适当的消息,并且在步骤6-输入金额处重新加入基本流。
备选流4-PIN有误
在基本流步骤4中-验证帐户和PIN,客户有三次机会输入PIN。
如果PIN输入有误,ATM将显示适当的消息;如果还存在输入机会,则此事件流在步骤3-输入PIN处重新加入基本流。
如果最后一次尝试输入的PIN码仍然错误,则该卡将被ATM机保留,同时ATM返回到准备就绪状态,本用例终止。
备选流5-帐户不存在
在基本流步骤4中-验证帐户和PIN,如果银行系统返回的代码表明找不到该帐户或禁止从该帐户中提款,则ATM显示适当的消息并且在步骤9-返回银行卡处重新加入基本流。
备选流6-帐面金额不足
在基本流步骤7-授权中,银行系统返回代码表明帐户余额少于在基本流步骤6-输入金额内输入的金额,则ATM显示适当的消息并且在步骤6-输入金额处重新加入基本流。
备选流7-达到每日最大的提款金额
在基本流步骤7-授权中,银行系统返回的代码表明包括本提款请求在内,客户已经或将超过在24小时内允许提取的最多金额,则ATM显示适当的消息并在步骤6-输入金额上重新加入基本流。
备选流x-记录错误
如果在基本流步骤10-收据中,记录无法更新,则ATM进入“安全模式”,在此模式下所有功能都将暂停使用。
同时向银行系统发送一条适当的警报信息表明ATM已经暂停工作。
备选流y-退出
客户可随时决定终止交易(退出)。
交易终止,银行卡随之退出。
备选流z-“翘起”
ATM包含大量的传感器,用以监控各种功能,如电源检测器、不同的门和出入口处的测压器以及动作检测器等。
在任一时刻,如果某个传感器被激活,则警报信号将发送给警方而且ATM进入“安全模式”,在此模式下所有功能都暂停使用,直到采取适当的重启/重新初始化的措施。
在第一次迭代中,根据迭代计划,我们需要核实提款用例已经正确地实施。
此时尚未实施整个用例,只实施了下面的事件流:
基本流-提取预设金额(10美元、20美元、50美元、100美元)
备选流2-ATM内没有现金
备选流3-ATM内现金不足
备选流4-PIN有误
备选流5-帐户不存在/帐户类型有误
备选流6-帐面金额不足
可以从这个用例生成下列场景
场景1-成功的提款
基本流
场景2-ATM内没有现金
基本流
备选流2
场景3-ATM内现金不足
基本流
备选流3
场景4-PIN有误(还有输入机会)
基本流
备选流4
场景5-PIN有误(不再有输入机会)
基本流
备选流4
场景6-帐户不存在/帐户类型有误
基本流
备选流5
场景7-帐户余额不足
基本流
备选流6
注:
为方便起见,备选流3和6(场景3和7)内的循环以及循环组合未纳入上表。
对于这7 个场景中的每一个场景都需要确定测试用例。
可以采用矩阵或决策表来确定和管理测试用例。
下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表 测试用例的信息。
本示例中,对于每个测试用例,存在一个测试用例 ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。
通过从确定执行用例场景所需的数据元素入手构建矩阵。
然后,对于每个场景,至少要确定包含执行场景所需的适当条件的测试用例。
例如,在下面的矩阵中,V(有效)用于表明这个条件必须是VALID(有效的)才可执行基本流,而 I(无效)用于表明这种条件下将激活所需备选流。
下表中使用的“n/a”(不适用)表明这个条件不适用于测试用例。
测试用例
ID号
场景/条件
PIN
帐号
输入的金额
(或选择的金额)
帐面金额
ATM内的金额
预期结果
CW1.
场景1-成功的提款
V
V
V
V
V
成功的提款。
CW2.
场景2-ATM内没有现金
V
V
V
V
I
提款选项不可用,用例结束
CW3.
场景3-ATM内现金不足
V
V
V
V
I
警告消息,返回基本流步骤6-输入金额
CW4.
场景4-PIN有误(还有不止一次输入机会)
I
V
n/a
V
V
警告消息,返回基本流步骤4,输入PIN
CW5.
场景4-PIN有误(还有一次输入机会)
I
V
n/a
V
V
警告消息,返回基本流步骤4,输入PIN
CW6.
场景4-PIN有误(不再有输入机会)
I
V
n/a
V
V
警告消息,卡予保留,用例结束
在上面的矩阵中,六个测试用例执行了四个场景。
对于基本流,上述测试用例CW1称为正面测试用例。
它一直沿着用例的基本流路径执行,未发生任何偏差。
基本流的全面测试必须包括负面测试用例,以确保只有在符合条件的情况下才执行基本流。
这些负面测试用例由CW2至6表示(阴影单元格表明这种条件下需要执行备选流)。
虽然CW2至6对于基本流而言都是负面测试用例,但它们相对于备选流2至4而言是正面测试用例。
而且对于这些备选流中的每一个而言,至少存在一个负面测试用例(CW1-基本流)。
每个场景只具有一个正面测试用例和负面测试用例是不充分的,场景4正是这样的一个示例。
要全面地测试场景4-PIN有误,至少需要三个正面测试用例(以激活场景4):
*输入了错误的PIN,但仍存在输入机会,此备选流重新加入基本流中的步骤3-输入PIN。
*输入了错误的PIN,而且不再有输入机会,则此备选流将保留银行卡并终止用例。
*最后一次输入时输入了“正确”的PIN。
备选流在步骤5-输入金额处重新加入基本流。
注:
在上面的矩阵中,无需为条件(数据)输入任何实际的值。
以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。
由于只需要查看V和I(或此处采用的阴影单元格),这种方式还易于判断是否已经确定了充足的测试用例。
从上表中可发现存在几个条件不具备阴影单元格,这表明测试用例还不完全,如场景6-不存在的帐户/帐户类型有误和场景7-帐户余额不足就缺少测试用例。
一旦确定了所有的测试用例,则应对这些用例进行复审和验证以确保其准确且适度,并取消多余或等效的测试用例。
测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据:
测试用例
ID号
场景/条件
PIN
帐号
输入的金额
(或选择的金额)
帐面金额
ATM内的金额
预期结果
CW1.
场景1-成功的提款
4987
809-498
50.00
500.00
2,000
成功的提款。
帐户余额被更新为450.00
CW2.
场景2-ATM内没有现金
4987
809-498
100.00
500.00
0.00
提款选项不可用,用例结束
CW3.
场景3-ATM内现金不足
4987
809-498
100.00
500.00
70.00
警告消息,返回基本流步骤6-输入金额
CW4.
场景4-PIN有误(还有不止一次输入机会)
4978
809-498
n/a
500.00
2,000
警告消息,返回基本流步骤4,输入PIN
CW5.
场景4-PIN有误(还有一次输入机会)
4978
809-498
n/a
500.00
2,000
警告消息,返回基本流步骤4,输入PIN
CW6.
场景4-PIN有误(不再有输入机会)
4978
809-498
n/a
500.00
2,000
警告消息,卡予保留,用例结束
以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。
需要的其他测试用例包括:
*场景6-帐户不存在/帐户类型有误:
未找到帐户或帐户不可用
*场景6-帐户不存在/帐户类型有误:
禁止从该帐户中提款
*场景7-帐户余额不足:
请求的金额超出帐面金额
在将来的迭代中,当实施其他事件流时,在下列情况下将需要测试用例:
*无效卡(所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等)
*无法读卡(读卡机堵塞、脱机或出现故障)
*帐户已消户、冻结或由于其他方面原因而无法使用
*ATM内的现金不足或不能提供所请求的金额(与CW3不同,在CW3中只是一种币值不足,而不是所有币值都不足)
*无法联系银行系统以获得认可
*银行网络离线或交易过程中断电
在确定功能性测试用例时,确保满足下列条件:
*已经为每个用例场景确定了充足的正面和负面测试用例。
*测试用例可以处理用例所实施的所有业务规则,确保对于业务规则,无论是在内部、外部还是在边界条件/值上都存在测试用例。
*测试用例可以处理所有事件或动作排序(如在设计模型的序列图中确定的内容),还应能处理用户界面对象状态或条件。
*测试用例可以处理为用例所指定的任何特殊需求,如最佳/最差性能,有时这些特殊需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。
对于负载测试:
TC(测试用例)ID号
工作量
条件
预期结果
PCW1.
1
(单个ATM)
完成提款交易
全部交易(不依赖于主角的时间)在20秒之内完成
PCW2.
2
(1,000个同时运行的ATM)
完成提款交易
全部交易(不依赖于主角的时间)在30秒之内完成
PCW3.
3
(10.000个同时运行的ATM)
完成提款交易
全部交易(不依赖于主角的时间)在50秒之内完成
对于强度测试:
TC(测试用例)ID号
工作量
条件
预期结果
SCW1.
2
(10.000个同时运行的ATM)
数据库锁定-2个ATM请求同一帐户
ATM请求排成队列
SCW2.
2
(1,000个同时运行的ATM)
无法实现银行系统的通信
交易排成队列或超时
SCW3.
2
(10.000个同时运行的ATM)
在交易过程中,银行系统通信被终止
显示警告消息
为安全性/访问控制测试生成测试用例,在ATM用例中,如果主角“银行客户”的卡和帐户有的属于拥有这个ATM机的银行,有的是竞争银行的银行卡(和帐户),或是企图使用该ATM不支持的银行卡,则将对该主角“银行客户”执行不同的用例事件流。
对于功能性测试用例,请同样遵循上面列举的指南。
关于安全性和访问控制测试用例的示例:
TC(测试用例)ID号
条件
卡
(V表明卡有效)
读卡机
(V表明读卡机工作正常)
银行的网络
预期结果
ACW1.
在银行网络之内
V
V
V
所有用例都可用
ACW2.
银行网络之外
V
V
I
只有提款用例可用
ACW3.
无法读卡
I
V
V
警告消息,卡被退出
ACW4.
因被盗,卡已挂失
I
V
V
警告消息,卡予保留
ACW5.
卡已过期
I
V
V
警告消息,卡予保留
手机软件测试举例:
一、等价类分析法
等价类划分方法针对手机状态大致可以归几个大类:
1.按键类(等价法):
有效输入和无效输入(有效输入指UM和菜单指示;无效输入指测试菜单功能此时没有定义的按键和用户动作);
2.外部中断类(等价法):
常用、不常用及无效
2.1.常用:
来电和来消息(短信、彩信、push消息);掀合盖;侧键;耳机&FM;情景模式;电量不足
2.2.不常用:
充电;闹钟&记事本&关机时间&整点报时提示;Icon&动画显示;Icon&动画刷新;编辑界面&pop显示框输入为空或满;编辑界面&pop显示框状态输入法默认&字符编码默认;失效SIM卡;大容量等SIM卡兼容;排序;号码识别;
2.3.无效:
“资料读取中…”;“复制中…”;“请稍后再试”
3.存储器类
3.1.等价法分类:
读或写;不读或不写。
3.2.因果法分类:
先SIM卡后手机;先手机后SIM卡;提示用户选择存储器(对比Nokia)。
3.3.操作分类:
读;写;新增;删除;复制(先删除后新增;先新增后删除)
4.状态类:
正确;错误;变更;用户设定变更
测试如下
单个通话实例的拨打与挂断
测试用例标识
测试阶段:
系统测试
测试项
单个通话实例的拨打与挂断
重要级别
高
测试原因
手机在待机状态下,确保手机能正常拨出电话
预置条件
1.正常信号环境
2.IDLE状态
3.默认原厂参数设定
输入
1.电话号码(手机号码,固定电话,带分机的号码,字符串,特殊号码如:
**21*021xxxxxxxx#,+或00,超短号码,超长号码,拨打一位号码,拨打最大长度号码等)
2.拨号过程中电池低电量提示、来短信、来彩信
3.拨号过程中闹钟时间到、行事历时间到
4.拨号过程中插上充电器
5.拨号过程中突然断电
6.按键加锁
测试执行步骤
IDLE状态拨打号码
按Send键发送
按End键挂断
预期输出结果
1.按Send键可以拨打并显示,按End键可挂断
2.拨打号码过程电池低电量提示、来短信、来彩信拨打界面正常
3.拨打号码过程闹钟时间到、行事历时间到拨打界面正常
4.拨号过程中插上充电器,背光状态及拨打界面正常
5.拨号过程中突然断电,插上充电器重新开机后能正常拨出
6.按键加锁仅可拨打紧急电话号码112
测试用例标识
测试阶段:
系统测试
测试项
单个通话实例的拨打与挂断
测试项属性
A
参照规范
重要级别
高
测试原因
手机在无信号或无网络情形下,手机无法正常拨打电话
预置条件
1.正在搜索网络或正处于注册界面
2.IDLE状态
3.默认原厂参数设定
输入
同上用例
测试执行步骤
IDLE状态拨打号码
按Send键拨号
预期
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 黑盒 测试 举例