面向对象的软件测试

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

5.8.2 测试测试自动化
另一类软件测试工具,可以自动执行测试用 例、查找软件缺陷、分析并记录测试结果。
随机测试:猴子测试员
一个想法: “如果让
一百万只猴 子在一百万 只键盘上敲 一百万年, 它们最终就 可能写出莎 士比亚话剧 等巨著”.
只要不停电,偶尔能够得到香蕉,猴子就会永远测试下去
猴子的进步
查看器和监视器
1#计算机 软件正在测试
通信线路
2#计算机 软件正在测试
(输入测试用例)
监听线路 (检查相应结果)
(确认产生的通信数据) 3#计算机 查看测试工具(非侵入)
通信分析器可以查看两个系统之间传输的原始数据
驱动程序
从外部计算机发
普通系统配置 送击键鼠标的移
动信息, 被测试
键盘 鼠标 电缆 电缆
划分类别的方法:
•基于状态的划分 •基于属性的划分 •基于功能的划分
基于状态的划分
根据类操作改变类状态的能力来划分类操作.
例:银行系统的account(帐户)类
状态操作包括: deposit(存款) withdraw(取款)
非状态操作包括:balance(余额) summarize(清单) creditLimit(透支限额)
§5.7 面向对象的软件测试
OO的系统与使用功能模型开发的系统之间的差别:
•对象作为一个单独的组件一般要比一个功能模块大 •由对象到子系统的集成通常是松散耦合的,系统中
没有一个明显的“顶层”
•如果对象被复用,测试者就无法进入组件内部分析
其代码
测试策略和测试战术的改变
•白盒测试方法需要扩展到更大粒度的对象上 •集成测试采用黑盒测试
5.7.3 OO系统的确认测试
在确认和系统测试层次,类连接的细节消失.
•和传统的确认测试一样,OO软件的确认关注
用户可见的动作和用户可识别的系统输出.
•为辅助确认测试的导出, 应利用分析模型中的
用例图提供的场景来提高交互需求中发现错误 的可能性
§5.8 自动测试和测试工具
自动化和工具的好处
•速度 •效率 •准确度和精确度 •坚持不懈
笨猴子:一点也不懂测试软件, 只是随机地单击或按键,
直至发生两件事情之一:完成循环或系统崩溃.
不太笨的猴子: 具有崩溃辨认能力,
能够重新启动系统开始测试
聪明猴子:能够从它的笨兄弟那里获得随机测试的结果,
与测试传统软件时采用的错误推测法类似.
5.7.2 对象的集成测试
OO软件没有层次的控制结构,传统的自顶向 下和自底向上的集成策略没有意义.
•OO软件的两种集成策略: 基于使用的测试(用例或基于场景的测试)
•基于线程的测试(thread-based testing)
集成响应系统的一个输入或事件所需的一组类,每个线 程被个体地集成和测试,通过回归测试保证没有副作用产 生;
•对象交互测试
cardInserted password
verifyAcct verifyPIN
deposit withdraw
verifyPolicy withdrawReq
accentStatus
depositReq
validPIN
ATM User
terminate ATM acctInfoReq Bank validAcct
ห้องสมุดไป่ตู้
ATM User
cardInserted
verifyAcct
password deposit withdraw
verifyPIN verifyPolicy withdrawReq
accentStatus terminate
ATM
depositReq acctInfoReq
Bank
validPIN validAcct
Interface verifyStatus depositStatus dispense Case printAccent Stat
openAcct initialDeposit authorize Card deuthorize closeAcct
creditLimit accentType balance withdraw deposit
对象的完全覆盖测试应包括:
•对象中所有操作被单独隔离测试 •对象所有属性的设置和访问的测试 •对象的所有可能状态的测试。
所有能引起状态改变的事件都要模拟到。
测试单个类的方法
(1)随机测试
例:银行系统的account(帐户)类有下列操作:
•open(打开) •setup(建立) •deposit(存款) •withdraw(取款) •balance(余额) •summarize(清单) •creditLimit(透支限额) •close(关闭)
5.8.1 测试工具
•静态分析工具 •动态测试工具 •测试数据自动生成工具 •集成化测试环境
•非侵入式工具 •侵入式工具
测试工作台(下游CASE工具)
测试数据生成器
规约
源代码 测试管理器 测试数据 预测器
动态分析器
被测试 的程序
测试结果 测试预估
执行报告
模拟器
文件比较器 报告生成器
测试结 果报告
测试用例p1(测试改变状态的操作):
open.setup.deposit.deposit..withdraw.close
测试用例p2 (测试不改变状态的操作,在最小测试序列中 的操作除外) :
open.setup.deposit.summarize. creditLimit.withdraw.close
readCardInfo
close
getCaseAmnt Cashier Account Validation
银行系统的类协作图
Info
OO集成测试方法
(1)多个类测试
Kirani,S.and W.T.Tsai,在“Specification and Verification of Object-Oriented Programs” 中建议了下面的步骤序列以 生成多个类随机测试用例:
系统对操作的限制:
•必须在应用其它操作之前先打开帐户,在完成了 •…全…部操作之后才能关闭帐户;
在限制 下还是 存在操 作的许 多排列
一个account类实例的最小行为历史包括下列操作: open . setup . deposit . withdraw . close account类的最小测试序列
测试用例r2: open.setup.deposit.withdraw.deposit. balance. creditLimit.withdraw.close
这些和其它的随机顺序测试被进行,以测试不 同的类实例的生存历史.
测试单个类的方法
(2)划分测试(partition testing)
与测试传统软件时采用的等价类划分方法类似.
Bank还必须和Account协作以执行deposit
因此,测试这些协作的新的测试用例是:
测试用例r4:verifyAcctBank• [validAcctValidationInfo] • verifyPINBank • [validPINValidationInfo] • depositReq •
1.对每个客户类,使用类操作列表来生成一系列随机测 试序列,这些操作发送消息给服务器类;
2.对生成的每个消息,确定在服务器对象中的协作者类 和对应的操作;
3.对服务器对象中的每个操作(已经被来自客户对象的 消息调用),确定传递的消息;
4.对每个消息,确定下一层被调用的操作,并把这些操作 结合进测试序列中.
OO集成测试方法
(2)从动态模型导出测试用例
设计的测试用例应达到完全的状态覆盖,即操作 序列应导致account类的变迁穿越所有允许的状态: 测试用例s1: open•setupAccent •deposit(initial) •
withdraw(final) •close(最小测试序列)
向最小序列中加入附加的测试序列,例如:
• 初始化操作(open, setup) • 计算操作(deposit, withdraw) • 查询操作(balance, summarize, creditLimit) • 终止操作(close)
为上述每个类别设计测试序列
测试单个类的方法(3)基于状态的测试
empty
set up
open acct setup Aaccent acct
基于属性的划分
根据类操作使用的属性来划分类操作.
例:account类可根据balance属性来把操作
定义划分为三个类别:
• 使用balance的操作 • 修改balance的操作 • 不使用也不修改balance的操作
为上述每个类别设计测试序列
基于功能的划分
根据类操作所完成的功能来划分类操作.
例:account类中的操作按功能可划分为四个类别:
Interface verifyStatus depositStatus dispense Case printAccent Stat
openAcct initialDeposit authorize Card deuthorize closeAcct
creditLimit accentType balance withdraw deposit
deposit(initial)
balance credit acctInfo
working
acct
deposit withdraw
withdrawal(final)
dead acct
close
nonworking acct
account类的状态转换图
测试单个类的方法
(4)基于故障的测试(fault_based testing)
测试用例s2:open•setupAccent •deposit(initial) •
deposit •balance •credit • withdraw(final) •close
测试用例s3:open•setupAccent •deposit(initial) •
deposit •withdraw •accntInfo •withdraw(final) •close …… 导出更多的测试用例以保证该类的所有行为都被适当地 测试
对Bank类的随机测试用例可能是:
测试用例r3: verifyAcct • verifyPIN • depositReq
为了考虑测试中涉及的协作者,需要考虑与测试用例r3中 每个操作相关联的消息: Bank必须和ValidationInfo协作以执行depositReq 、
verifyAcct和verifyPIN
普通系统配置
测试存根配置
一台计算机可以充当管道,代替打印机, 能够对测试输出进行更有效的分析
其它工具类型:
•施压工具和增负工 具•干扰发生器和噪声发生 器•分析工具
测试工具产品实例
• JUnit: Java单元测试工具 • CppUnit: C++单元测试工具 • Dunit: Delphi的终极测试工具
大量的其它行为可能在下面序列中发生:
open . setup . deposit . [deposit | withdraw | balance | summarize | creditLimit] n . withdraw . close
一系列不同的操作序列可以随机地产生,例如:
测试用例r1: open.setup.deposit.deposit.balance. summarize.creditLimit.withdraw.close
软件不被侵入,
如果测试软件时
在同一系统中执 行驱动程序, 它 就会侵入系统, 这种测试情况可 能无法接受
测试驱动配置
(在此计算机上编写 简单的程序自动产 生相应的击键和鼠 标移动来测试软件)
一台计算机可以作为驱动程序
测试工具取代被测试系统的键盘和鼠标
管道和仿真器
运行管道软件来 代替打印机,对 打印数据进行阅 读和解释
面向对象系统的测试可分为四个层次
•测试与对象关联的单个操作 •测试单个对象类 •测试对象集群 •测试面向对象系统
5.7.1 对象类的测试
相当于传统的单元测试, 单元概念的变化 — 封装的类或对象作为最小
的可测试单位
用白盒的覆盖测试方法保证所有程序中的语句至 少执行一遍,所有的程序路径都要执行到。
readCardInfo
close
getCaseAmnt
Cashier Account Validation
银行系统的类协作图
Info
银行系统中Bank类和ATM类的操作序列:
verifyAcct • verifyPIN • [[verifyPolicy • withdrawReq] | depositReq | acctInfoReq]n
相关文档
最新文档