《面向对象的软件测试ppt课件.ppt》由会员分享，可在线阅读，更多相关《面向对象的软件测试ppt课件.ppt（62页珍藏版）》请在三一办公上搜索。
1、5.7 面向对象的软件测试,OO的系统与使用功能模型开发的系统之间的差别：对象作为一个单独的组件一般要比一个功能模块大由对象到子系统的集成通常是松散耦合的，系统中 没有一个明显的“顶层”如果对象被复用，测试者就无法进入组件内部分析 其代码 测试策略和测试战术的改变白盒测试方法需要扩展到更大粒度的对象上集成测试采用黑盒测试,面向对象系统的测试可分为四个层次,测试与对象关联的单个操作测试单个对象类测试对象集群测试面向对象系统,5.7.1 对象类的测试,用白盒的覆盖测试方法保证所有程序中的语句至少执行一遍，所有的程序路径都要执行到。对象的完全覆盖测试应包括：对象中所有操作被单独隔离测试对象所有属性的
2、设置和访问的测试对象的所有可能状态的测试。 所有能引起状态改变的事件都要模拟到。,相当于传统的单元测试，单元概念的变化 封装的类或对象作为最小 的可测试单位,测试单个类的方法,（1）随机测试,例:银行系统的account(帐户)类有下列操作：open(打开)setup(建立)deposit(存款)withdraw(取款)balance(余额)summarize(清单)creditLimit(透支限额)close(关闭)系统对操作的限制：必须在应用其它操作之前先打开帐户,在完成了 全部操作之后才能关闭帐户;,在限制下还是存在操作的许多排列,一个account类实例的最小行为历史包括下列操作:op
3、en . setup . deposit . withdraw . close account类的最小测试序列大量的其它行为可能在下面序列中发生:open . setup . deposit . deposit | withdraw | balance | summarize | creditLimit n . withdraw . close 一系列不同的操作序列可以随机地产生,例如:,测试用例r1: open.setup.deposit.deposit.balance. summarize.creditLimit.withdraw.close 测试用例r2: open.setup.depo
4、sit.withdraw.deposit. balance. creditLimit.withdraw.close 这些和其它的随机顺序测试被进行,以测试不同的类实例的生存历史.,测试单个类的方法,（2）划分测试(partition testing) 与测试传统软件时采用的等价类划分方法类似. 划分类别的方法:基于状态的划分基于属性的划分基于功能的划分,基于状态的划分,根据类操作改变类状态的能力来划分类操作.,例：银行系统的account(帐户)类 状态操作包括: deposit(存款) withdraw(取款) 非状态操作包括:balance(余额) summarize(清单) credit
5、Limit(透支限额)测试用例p1(测试改变状态的操作): open.setup.deposit.deposit.withdraw.close 测试用例p2 (测试不改变状态的操作,在最小测试序列中 的操作除外) : open.setup.deposit.summarize. creditLimit.withdraw.close,基于属性的划分,根据类操作使用的属性来划分类操作.,例：account类可根据balance属性来把操作 定义划分为三个类别: 使用balance的操作 修改balance的操作 不使用也不修改balance的操作 为上述每个类别设计测试序列,基于功能的划分,根据类操
6、作所完成的功能来划分类操作.,例:account类中的操作按功能可划分为四个类别: 初始化操作(open, setup) 计算操作(deposit, withdraw) 查询操作(balance, summarize, creditLimit) 终止操作(close) 为上述每个类别设计测试序列,set upacct,account类的状态转换图,emptyacct,deadacct,setup Aaccent,balance creditacctInfo,close,deposit(initial),deposit,withdraw,workingacct,open,withdrawal(f
7、inal),nonworkingacct,测试单个类的方法（3）基于状态的测试,测试单个类的方法（4）基于故障的测试(fault_based testing),与测试传统软件时采用的错误推测法类似.,5.7.2 对象的集成测试,OO软件没有层次的控制结构,传统的自顶向下和自底向上的集成策略没有意义.,OO软件的两种集成策略:基于使用的测试(用例或基于场景的测试) 基于线程的测试(thread-based testing) 集成响应系统的一个输入或事件所需的一组类,每个线程被个体地集成和测试,通过回归测试保证没有副作用产生;对象交互测试,ATM,Bank,银行系统的类协作图,ATMUserInt
8、erface,Account,Cashier,verifyAcctverifyPINverifyPolicywithdrawReqdepositReqacctInfoReq,cardInsertedpassworddepositwithdrawaccentStatusterminate,validPINvalidAcct,creditLimitaccentTypebalancewithdrawdepositclose,ValidationInfo,verifyStatusdepositStatusdispenseCaseprintAccentStatreadCardInfogetCaseAmn
9、t,openAcctinitialDepositauthorizeCarddeuthorizecloseAcct,OO集成测试方法,（1）多个类测试 Kirani,S.and W.T.Tsai,在“Specification and Verification of Object-Oriented Programs” 中建议了下面的步骤序列以生成多个类随机测试用例:1.对每个客户类,使用类操作列表来生成一系列随机测试序列,这些操作发送消息给服务器类;2.对生成的每个消息,确定在服务器对象中的协作者类和对应的操作;3.对服务器对象中的每个操作(已经被来自客户对象的消息调用),确定传递的消息;4.对
10、每个消息,确定下一层被调用的操作,并把这些操作结合进测试序列中.,ATM,Bank,银行系统的类协作图,ATMUserInterface,Account,Cashier,verifyAcctverifyPINverifyPolicywithdrawReqdepositReqacctInfoReq,validPINvalidAcct,creditLimitaccentTypebalancewithdrawdepositclose,openAcctinitialDepositauthorizeCarddeuthorizecloseAcct,ValidationInfo,verifyStatusde
11、positStatusdispenseCaseprintAccentStatreadCardInfogetCaseAmnt,cardInsertedpassworddepositwithdrawaccentStatusterminate,银行系统中Bank类和ATM类的操作序列:,verifyAcct verifyPIN verifyPolicy withdrawReq | depositReq | acctInfoReqn对Bank类的随机测试用例可能是:测试用例r3: verifyAcct verifyPIN depositReq,为了考虑测试中涉及的协作者,需要考虑与测试用例r3中每个操
12、作相关联的消息:Bank必须和ValidationInfo协作以执行depositReq 、 verifyAcct和verifyPINBank还必须和Account协作以执行deposit,因此,测试这些协作的新的测试用例是: 测试用例r4:verifyAcctBank validAcctValidationInfo verifyPINBank validPINValidationInfo depositReq depositAccount,OO集成测试方法,（2）从动态模型导出测试用例 设计的测试用例应达到完全的状态覆盖,即操作序列应导致account类的变迁穿越所有允许的状态:测试用例s1
13、: opensetupAccent deposit(initial) withdraw(final) close(最小测试序列),向最小序列中加入附加的测试序列,例如:测试用例s2:opensetupAccent deposit(initial) deposit balance credit withdraw(final) close测试用例s3:opensetupAccent deposit(initial) deposit withdraw accntInfo withdraw(final) close 导出更多的测试用例以保证该类的所有行为都被适当地测试,5.7.3 OO系统的确认测试,
14、在确认和系统测试层次,类连接的细节消失.,和传统的确认测试一样,OO软件的确认关注 用户可见的动作和用户可识别的系统输出.为辅助确认测试的导出, 应利用分析模型中的 用例图提供的场景来提高交互需求中发现错误 的可能性,5.8 自动测试和测试工具,自动化和工具的好处速度效率准确度和精确度坚持不懈,5.8.1 测试工具,静态分析工具动态测试工具测试数据自动生成工具集成化测试环境非侵入式工具侵入式工具,测试工作台(下游CASE工具),源代码,被测试的程序,测试数据,规约,预测器,测试管理器,测试预估,模拟器,文件比较器,报告生成器,动态分析器,测试结果,测试结果报告,执行报告,测试数据生成器,查看器
15、和监视器,1#计算机软件正在测试,2#计算机软件正在测试,3#计算机查看测试工具,通信线路,监听线路,通信分析器可以查看两个系统之间传输的原始数据,（非侵入）,（输入测试用例）,（确认产生的通信数据）,（检查相应结果）,驱动程序,普通系统配置,测试驱动配置（在此计算机上编写 简单的程序自动产 生相应的击键和鼠 标移动来测试软件）,键盘电缆,鼠标电缆,一台计算机可以作为驱动程序测试工具取代被测试系统的键盘和鼠标,从外部计算机发送击键鼠标的移动信息, 被测试软件不被侵入, 如果测试软件时在同一系统中执行驱动程序, 它就会侵入系统, 这种测试情况可能无法接受,管道和仿真器,普通系统配置,测试存根配置
16、,一台计算机可以充当管道,代替打印机,能够对测试输出进行更有效的分析,运行管道软件来代替打印机，对打印数据进行阅读和解释,其它工具类型:,施压工具和增负工具,干扰发生器和噪声发生器,分析工具,测试工具产品实例,JUnit: Java单元测试工具 CppUnit： C+单元测试工具 Dunit: Delphi的终极测试工具,5.8.2 测试测试自动化,另一类软件测试工具,可以自动执行测试用例、查找软件缺陷、分析并记录测试结果。,随机测试:猴子测试员,只要不停电,偶尔能够得到香蕉,猴子就会永远测试下去,一个想法: “如果让一百万只猴子在一百万只键盘上敲一百万年,它们最终就可能写出莎士比亚话剧等巨著
17、”.,猴子的进步,笨猴子:一点也不懂测试软件, 只是随机地单击或按键, 直至发生两件事情之一:完成循环或系统崩溃.,不太笨的猴子: 具有崩溃辨认能力, 能够重新启动系统开始测试,聪明猴子:能够从它的笨兄弟那里获得随机测试的结果, 增加了对环境的认知能力, 有目的地敲键盘, 不仅限于查找崩溃缺陷,同时查看数据,检查 操作结果,找出与预期结果的差别,自动化测试工具实例,美国国际软件自动化（ISA）公司的Panorama for C/C+，j、Java和VB产品，自动化功能包括：软件结构分析与逻辑框图的自动化软件静态分析数据分析复杂性分析与分析结果列表的自动化软件质量分析动态性能分析软件代码分支或条
18、件覆盖率分析软件测试用例有效性分析与测试用例最小集的自动选取软件界面手工操作过程的自动记录与自动再执行 (Playback),5.9 测试中的可靠性分析,开发过程中，利用测试的统计数据来估算软件的可靠性，以控制软件的质量。推测错误的产生频度推测残留在程序中的错误数评价测试的精确度和覆盖率,推测错误的产生频度(推测错误产生的时间间隔),1,K(ET/IT- Ec(t)/IT),方法:估算平均故障时间(MTTF估算公式),MTTF,K : 经验常数ET : 程序中原有的残留错误数IT : 程序长度t: 测试时间 Ec(t):在0-t期间内发现的错误总数,1,=,当故障率为独立于时间的常量:,推测残
19、留在程序中的错误数,错误植入模型 Mills将播种模型用于程序中残留错误的估算,称错误植入模型播种模型： N： 程序中原有残留的错误数 Nt：新植入的错误数 n: 测试发现的原有错误数 nt :测试发现的植入错误数,N,N,n,n,t,t,N,N,n,n,t,=,t,Hyman对错误植入模型的改进,ET: 程序中原有的残留错误数E1: 1号测试员在某一时间内发现的错误数E2: 2号测试员在同一时间内发现的错误数E0: 两位测试员共同发现的错误数,E,E,E,1,0,=,2,E,T,E,1,E,2,/E,0,E,T,第六章 软件进化,遗留系统软件变更策略软件维护体系结构进化软件再工程配置管理,6
20、.1 遗留系统,更换遗留系统是有风险的业务策略，因为：遗留系统几乎没有完整的描述业务过程与遗留系统的操作方式紧密相关重要的业务规则隐藏在软件内部开发新软件有风险,继续使用遗留系统，进行变更费用更高，因为：系统是由不同团对实现的，程序设计风格不一致系统使用过时的语言编写系统文档不充分、过时经多年维护，系统结构已破坏系统进行过优化，不可读系统数据过时、不完整,遗留系统评估,对遗留系统做现实的评估，做出适当的抉择：彻底抛弃系统继续维护系统采用某种方式转换系统以改善其可维护性以一个新的系统代替该系统,6.2 软件维护,四类维护活动：改正性维护适应性维护扩充与完善性维护预防性维护,各种维护所占比例:,其
21、它维护 5 %,适应性维 护 25%,改正性维 护 20%,扩充与完善性维护 50%,改正性维护占全部维护量的比率已从80年代初的20%大幅度下降, 90年代初一些公司的产品差错率已接近于零,6.2.1软件维护的特点,M,P+K,e,=,(c-d ),M : 维护工作总工作量P : 生产性工作量K : 经验常数c : 复杂度d : 对该软件熟悉程度的度量,维护的成本,维护中的典型问题,(1)难以跟踪软件版本的进化过程, 软件的变化未在文档中反映出来.(2)难以跟踪软件的创建过程.(3)难以读懂他人程序.(4)无文档或不全.(5)软件人员流动性大.(6)设计时未考虑修改需要,修改困难.(7)维护
22、工作无吸引力,缺乏成就感.,6.2.2软件的维护任务,修改负责人,维护申请,系统监督员,配置管理员,维护机构,维护人员,维护管理员,保存维护记录,维护过程中作应记录的数据程序标识源程序语句数目机器代码指令条数.以收集的数据为基础构造维护数据库,供维护评价使用.,6.2.3 软件维护的实施,修改源程序的三个步骤分析和理解程序修改程序重新验证程序,修改程序的副作用,修改代码的副作用修改数据的副作用修改文档的副作用,重新验证程序,静态确认计算机确认维护后的验收,从维护角度所需的测试种类：,(1) 对修改事务的测试(2) 对修改程序的测试(3) 操作过程的测试(4) 应用系统运行过程的测试(5) 使用
23、过程的测试(6) 系统各部分间接口的测试(7) 与系统软件接口的测试(8) 安全性测试(9) 后备/恢复过程测试 ,6.2.4 软件可维护性,软件可维护性的定义： 软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。 衡量软件质量的几个主要质量特性：可维护性可使用性可靠性,可维护性的度量,各类维护中的侧重点,度量程序可维护性的7个特性,6.2.5 提高可维护性的方法,建立明确的软件质量目标和优先级 使用提高软件质量的技术和工具 进行明确的质量保证审查 选择可维护的程序设计语言 改进程序的文档 开发软件时考虑到维护,6.2.4 预防性维护,开发和维护者
24、不应等待用户的维护申请, 可先选择以下类型程序作为预防性维护对象:预计若干年内将继续使用的程序当今正成功使用的程序最近的将来要进行大修改和完善的程序,6.3软件再工程(Software Reengineering),6.3.1 什么是软件再工程,软件再工程是一类软件工程活动，是一个工程过程, 它将逆向工程、重构和正向工程组合起来,将现存系统重新构造为新的形式。,软件再工程比其它系统进化方法具有的绝对优势减少软件演化风险降低成本,软件再工程过程模型,代码重构,数据重构,正向工程,库存目录分析,文档重构,逆向工程,再工程过程示意图,需求,新需求,设计,设计,代码,代码,正向工程,反向工程,（重构）
25、,（重构）,（重构）,再工程方法,增长的成本,自动源代码转换,自动结构重构辅之以手工改变,结构重构加上体系结构改变,自动的程序结构重构,程序和数据结构重构,程序转换过程,识别源代码的差异,将要再工程的系统,设计转换器指令,自动转换代码,经过再工程的系统,手动转换代码,将要再工程的系统,逆向工程(反向工程reverse engineering),设计的恢复过程,非结构化、无文档的源代码或目标代码,软件的文档,从现有软件恢复设计信息(有用的维护信息),逆向工程过程,将要再工程的系统,自动分析,手工加注释,系统信息库,文档生成,数据结构图,程序结构图,可追溯矩阵,逆向工程恢复信息的级别:,(1)实现
26、级:程序的抽象语法 树、符号表等信息(2)结构级:反映程序分量之间 相互依赖关系的信 息，如调用图、结 构图等.(3)功能级:反映程序段功能和 段间关系的信息(4)领域级:反映程序分量与应 用领域概念间对应 关系的信息,抽象级别,低,高,信息的抽象级别越高, 它与代码距离越远, 通过逆向工程恢复的难度越大, 自动工具支持的可能性变小,逆向工程,源程序,目标代码,反汇编、反编译程序分析技术:程序结构分析工具 程序功能分析工具,源程序,概要设计详细设计,概要设计,需求分析,数据重构（数据再工程）,修改遗留系统的程序时必须同时修改数据数据退化程序内固有的限制体系结构进化,数据再工程的方法,数据再工程过程,将要再工程的程序,数据分析,实体名修改直接量替换对数据定义重新安排,文档生成,修改过的数据,数据重新格式化默认值转换验证规则修改,变更汇总表,数据分析,阶段1,阶段2,阶段3,
