面向对象的软件测试课件

§5.7面向对象的软件测试OO的系统与使用功能模型开发的系统之间的差别：对象作为一个单独的组件一般要比一个功能模块大由对象到子系统的集成通常是松散耦合的，系统中没有一个明显的“顶层”如果对象被复用，测试者就无法进入组件内部分析其代码测试策略和测试战术的改变白盒测试方法需要扩展到更大粒度的对象上集成测试采用黑盒测试§5.7面向对象的软件测试OO的系统与使用功能模型开发的1面向对象系统的测试可分为四个层次测试与对象关联的单个操作测试单个对象类测试对象集群测试面向对象系统面向对象系统的测试可分为四个层次测试与对象关联的单个操作2

5.7.1对象类的测试用白盒的覆盖测试方法保证所有程序中的语句至少执行一遍，所有的程序路径都要执行到。对象的完全覆盖测试应包括：对象中所有操作被单独隔离测试对象所有属性的设置和访问的测试对象的所有可能状态的测试。所有能引起状态改变的事件都要模拟到。相当于传统的单元测试，单元概念的变化—封装的类或对象作为最小的可测试单位5.7.1对象类的测试用白盒的覆盖测试方法保证所有程序3测试单个类的方法（1）随机测试例:银行系统的account(帐户)类有下列操作：open(打开)setup(建立)deposit(存款)withdraw(取款)balance(余额)summarize(清单)creditLimit(透支限额)close(关闭)系统对操作的限制：必须在应用其它操作之前先打开帐户,在完成了全部操作之后才能关闭帐户;……在限制下还是存在操作的许多排列测试单个类的方法（1）随机测试例:银行系统的account(4一个account类实例的最小行为历史包括下列操作:open.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.deposit.withdraw.deposit.balance.creditLimit.withdraw.close这些和其它的随机顺序测试被进行,以测试不同的类实例的生存历史.一个account类实例的最小行为历史包括下列操作:测试用例5测试单个类的方法（2）划分测试(partitiontesting)

与测试传统软件时采用的等价类划分方法类似.

划分类别的方法:基于状态的划分基于属性的划分基于功能的划分测试单个类的方法（2）划分测试(partitiontest6基于状态的划分根据类操作改变类状态的能力来划分类操作.例：银行系统的account(帐户)类

状态操作包括:deposit(存款)withdraw(取款)

非状态操作包括:balance(余额)summarize(清单)creditLimit(透支限额)测试用例p1(测试改变状态的操作):

open.setup.deposit.deposit..withdraw.close

测试用例p2(测试不改变状态的操作,在最小测试序列中的操作除外):open.setup.deposit.summarize.creditLimit.withdraw.close基于状态的划分根据类操作改变类状态的能力来划分类操作.例7基于属性的划分根据类操作使用的属性来划分类操作.例：account类可根据balance属性来把操作定义划分为三个类别:

使用balance的操作修改balance的操作不使用也不修改balance的操作

为上述每个类别设计测试序列基于属性的划分根据类操作使用的属性来划分类操作.例：ac8基于功能的划分根据类操作所完成的功能来划分类操作.例:account类中的操作按功能可划分为四个类别:

初始化操作(open,setup)计算操作(deposit,withdraw)查询操作(balance,summarize,creditLimit)终止操作(close)

为上述每个类别设计测试序列基于功能的划分根据类操作所完成的功能来划分类操作.例:a9

setupacctaccount类的状态转换图emptyacctdeadacctsetupAaccentbalancecreditacctInfoclosedeposit(initial)depositwithdrawworkingacctopenwithdrawal(final)nonworkingacct测试单个类的方法（3）基于状态的测试setupaccount类的状态转换图empty10测试单个类的方法（4）基于故障的测试(fault_basedtesting)与测试传统软件时采用的错误推测法类似.测试单个类的方法与测试传统软件时采用的错误推测法类似.11

5.7.2

对象的集成测试

OO软件没有层次的控制结构,传统的自顶向下和自底向上的集成策略没有意义.OO软件的两种集成策略:基于使用的测试(用例或基于场景的测试)

基于线程的测试(thread-basedtesting)

集成响应系统的一个输入或事件所需的一组类,每个线程被个体地集成和测试,通过回归测试保证没有副作用产生;对象交互测试

5.7.2对象的集成测试OO软件没有层次12

ATMBank银行系统的类协作图ATMUserInterfaceAccountCashierverifyAcctverifyPINverifyPolicywithdrawReqdepositReqacctInfoReqcardInsertedpassworddepositwithdrawaccentStatusterminatevalidPINvalidAcctcreditLimitaccentTypebalancewithdrawdepositcloseValidationInfoverifyStatusdepositStatusdispenseCaseprintAccentStatreadCardInfogetCaseAmntopenAcctinitialDepositauthorizeCarddeuthorizecloseAcctATMBank银行系统的类协作图ATMAccoun13

OO集成测试方法（1）多个类测试Kirani,S.andW.T.Tsai,在“SpecificationandVerificationofObject-OrientedPrograms”中建议了下面的步骤序列以生成多个类随机测试用例:1.对每个客户类,使用类操作列表来生成一系列随机测试序列,这些操作发送消息给服务器类;2.对生成的每个消息,确定在服务器对象中的协作者类和对应的操作;3.对服务器对象中的每个操作(已经被来自客户对象的消息调用),确定传递的消息;4.对每个消息,确定下一层被调用的操作,并把这些操作结合进测试序列中.OO集成测试方法（1）多个类测试14

ATMBank银行系统的类协作图ATMUserInterfaceAccountCashierverifyAcctverifyPINverifyPolicywithdrawReqdepositReqacctInfoReqvalidPINvalidAcctcreditLimitaccentTypebalancewithdrawdepositcloseopenAcctinitialDepositauthorizeCarddeuthorizecloseAcctValidationInfoverifyStatusdepositStatusdispenseCaseprintAccentStatreadCardInfogetCaseAmntcardInsertedpassworddepositwithdrawaccentStatusterminateATMBank银行系统的类协作图ATMAccoun15银行系统中Bank类和ATM类的操作序列:verifyAcct•verifyPIN•[[verifyPolicy•withdrawReq]|depositReq|acctInfoReq]n对Bank类的随机测试用例可能是:测试用例r3:verifyAcct•verifyPIN•depositReq为了考虑测试中涉及的协作者,需要考虑与测试用例r3中每个操作相关联的消息:Bank必须和ValidationInfo协作以执行depositReq、verifyAcct和verifyPINBank还必须和Account协作以执行deposit因此,测试这些协作的新的测试用例是:测试用例r4:verifyAcctBank•[validAcctValidationInfo]•

verifyPINBank

•[validPINValidationInfo]

•

depositReq

•[depositAccount]银行系统中Bank类和ATM类的操作序列:verifyAcc16

OO集成测试方法（2）从动态模型导出测试用例

设计的测试用例应达到完全的状态覆盖,即操作序列应导致account类的变迁穿越所有允许的状态:测试用例s1:open•setupAccent•deposit(initial)•withdraw(final)•close(最小测试序列)

向最小序列中加入附加的测试序列,例如:测试用例s2:open•setupAccent•deposit(initial)•deposit•balance•credit•withdraw(final)•close测试用例s3:open•setupAccent•deposit(initial)•deposit•withdraw•accntInfo•withdraw(final)•close……导出更多的测试用例以保证该类的所有行为都被适当地测试OO集成测试方法（2）从动态模型导出测试用例向最小序列中加17

5.7.3

OO系统的确认测试在确认和系统测试层次,类连接的细节消失.和传统的确认测试一样,OO软件的确认关注用户可见的动作和用户可识别的系统输出.为辅助确认测试的导出,应利用分析模型中的用例图提供的场景来提高交互需求中发现错误的可能性5.7.3OO系统的确认测试在确认和系统测试层次,类连接18§5.8自动测试和测试工具自动化和工具的好处速度效率准确度和精确度坚持不懈§5.8自动测试和测试工具自动化和工具的好处195.8.1测试工具静态分析工具动态测试工具测试数据自动生成工具集成化测试环境非侵入式工具侵入式工具5.8.1测试工具静态分析工具20测试工作台(下游CASE工具)源代码被测试的程序测试数据规约预测器测试管理器测试预估模拟器文件比较器报告生成器动态分析器测试结果测试结果报告执行报告测试数据生成器测试工作台(下游CASE工具)源代码被测试测试数据规约预测器21查看器和监视器1#计算机软件正在测试2#计算机软件正在测试3#计算机查看测试工具通信线路监听线路通信分析器可以查看两个系统之间传输的原始数据（非侵入）（输入测试用例）（确认产生的通信数据）（检查相应结果）查看器和监视器1#计算机2#计算机3#计算机通信线路监听线路22驱动程序普通系统配置测试驱动配置（在此计算机上编写简单的程序自动产生相应的击键和鼠标移动来测试软件）键盘电缆鼠标电缆一台计算机可以作为驱动程序测试工具取代被测试系统的键盘和鼠标从外部计算机发送击键鼠标的移动信息,被测试软件不被侵入,如果测试软件时在同一系统中执行驱动程序,它就会侵入系统,这种测试情况可能无法接受驱动程序普通系统配置测试驱动配置键盘鼠标一台计算机可以作为23管道和仿真器普通系统配置测试存根配置一台计算机可以充当管道,代替打印机,能够对测试输出进行更有效的分析运行管道软件来代替打印机，对打印数据进行阅读和解释管道和仿真器普通系统配置测试存根配置一台计算机可以充当管道,24其它工具类型:施压工具和增负工具干扰发生器和噪声发生器分析工具其它工具类型:施压工具和增负工具干扰发生器和噪声发生器分25测试工具产品实例JUnit:Java单元测试工具CppUnit：C++单元测试工具Dunit:Delphi的终极测试工具测试工具产品实例JUnit:Java单元测试工具265.8.2测试测试自动化

另一类软件测试工具,可以自动执行测试用例、查找软件缺陷、分析并记录测试结果。5.8.2测试测试自动化另一类软件测试工具,可以27随机测试:猴子测试员只要不停电,偶尔能够得到香蕉,猴子就会永远测试下去一个想法:

“如果让一百万只猴子在一百万只键盘上敲一百万年,它们最终就可能写出莎士比亚话剧等巨著”.随机测试:猴子测试员只要不停电,偶尔能够得到香蕉,猴子就会永28猴子的进步笨猴子:一点也不懂测试软件,只是随机地单击或按键,直至发生两件事情之一:完成循环或系统崩溃.不太笨的猴子:

具有崩溃辨认能力,能够重新启动系统开始测试聪明猴子:能够从它的笨兄弟那里获得随机测试的结果,增加了对环境的认知能力,有目的地敲键盘,不仅限于查找崩溃缺陷,同时查看数据,检查操作结果,找出与预期结果的差别猴子的进步笨猴子:一点也不懂测试软件,只是随机地单击或按键29自动化测试工具实例美国国际软件自动化（ISA）公司的PanoramaforC/C++，j、Java和VB产品，自动化功能包括：软件结构分析与逻辑框图的自动化软件静态分析数据分析复杂性分析与分析结果列表的自动化软件质量分析动态性能分析软件代码分支或条件覆盖率分析软件测试用例有效性分析与测试用例最小集的自动选取软件界面手工操作过程的自动记录与自动再执行(Playback)自动化测试工具实例美国国际软件自动化（ISA）公司30§5.9测试中的可靠性分析

开发过程中，利用测试的统计数据来估算软件的可靠性，以控制软件的质量。推测错误的产生频度推测残留在程序中的错误数评价测试的精确度和覆盖率§5.9测试中的可靠性分析开发过程中，利用测试的统31推测错误的产生频度(推测错误产生的时间间隔)1K(ET/IT-Ec(t)/IT)方法:估算平均故障时间(MTTF估算公式)MTTF＝K:

经验常数ET:

程序中原有的残留错误数IT:

程序长度t:测试时间

Ec(t):在0-t期间内发现的错误总数λ1=当故障率为独立于时间的常量λ:推测错误的产生频度(推测错误产生的时间间隔)1K(ET/IT32推测残留在程序中的错误数错误植入模型Mills将播种模型用于程序中残留错误的估算,称错误植入模型播种模型：

N：程序中原有残留的错误数Nt：新植入的错误数n:测试发现的原有错误数nt:测试发现的植入错误数NNnnt≈tNNnnt=t推测残留在程序中的错误数错误植入模型NNnnt≈tNNn33Hyman对错误植入模型的改进ET:程序中原有的残留错误数E1:1号测试员在某一时间内发现的错误数E2:2号测试员在同一时间内发现的错误数E0:两位测试员共同发现的错误数EEE1≈0=2ETE1E2/E0ETHyman对错误植入模型的改进ET:程序中原有的残留错误数34第六章软件进化遗留系统软件变更策略软件维护体系结构进化软件再工程配置管理第六章软件进化遗留系统35§6.1遗留系统更换遗留系统是有风险的业务策略，因为：遗留系统几乎没有完整的描述业务过程与遗留系统的操作方式紧密相关重要的业务规则隐藏在软件内部开发新软件有风险继续使用遗留系统，进行变更费用更高，因为：系统是由不同团对实现的，程序设计风格不一致系统使用过时的语言编写系统文档不充分、过时经多年维护，系统结构已破坏系统进行过优化，不可读系统数据过时、不完整§6.1遗留系统更换遗留系统是有风险的业务策略，因为：继续36遗留系统评估对遗留系统做现实的评估，做出适当的抉择：彻底抛弃系统继续维护系统采用某种方式转换系统以改善其可维护性以一个新的系统代替该系统遗留系统评估对遗留系统做现实的评估，做出适当的抉择：37§6.2软件维护

四类维护活动：改正性维护适应性维护扩充与完善性维护预防性维护§6.2软件维护四类维护活动：38各种维护所占比例:其它维护5%适应性维护25%改正性维护20%扩充与完善性维护50%改正性维护占全部维护量的比率已从80年代初的20%大幅度下降,90年代初一些公司的产品差错率已接近于零各种维护所占比例:其它维护适应性改正性扩充与完改正性维护占396.2.1软件维护的特点MP+Ke=(c-d)M

:维护工作总工作量P:生产性工作量K

:

经验常数c:复杂度d:对该软件熟悉程度的度量维护的成本6.2.1软件维护的特点MP+Ke=(c-d)M:维护40维护中的典型问题(1)难以跟踪软件版本的进化过程,软件的变化未在文档中反映出来.(2)难以跟踪软件的创建过程.(3)难以读懂他人程序.(4)无文档或不全.(5)软件人员流动性大.(6)设计时未考虑修改需要,修改困难.(7)维护工作无吸引力,缺乏成就感.维护中的典型问题(1)难以跟踪软件版本的进化过程,416.2.2软件的维护任务修改负责人维护申请系统监督员配置管理员维护机构维护人员维护管理员6.2.2软件的维护任务修改维护申请系统监督员配置管理员维42保存维护记录维护过程中作应记录的数据程序标识源程序语句数目机器代码指令条数..............以收集的数据为基础构造维护数据库,供维护评价使用.保存维护记录维护过程中作应记录的数据436.2.3软件维护的实施修改源程序的三个步骤分析和理解程序修改程序重新验证程序6.2.3软件维护的实施修改源程序的三个步骤44修改程序的副作用修改代码的副作用修改数据的副作用修改文档的副作用修改程序的副作用修改代码的副作用45重新验证程序静态确认计算机确认维护后的验收重新验证程序静态确认46从维护角度所需的测试种类：(1)对修改事务的测试(2)对修改程序的测试(3)操作过程的测试(4)应用系统运行过程的测试(5)使用过程的测试(6)系统各部分间接口的测试(7)与系统软件接口的测试(8)安全性测试(9)后备/恢复过程测试……从维护角度所需的测试种类：(1)对修改事务的测试476.2.4软件可维护性软件可维护性的定义：软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。衡量软件质量的几个主要质量特性：可维护性可使用性可靠性6.2.4软件可维护性软件可维护性的定义：48可维护性的度量各类维护中的侧重点改正性维护适应性维护完善性维护可理解性可测试性可修改性可靠性可移植性可使用性效率度量程序可维护性的7个特性可维护性的度量各类维护中的侧重点改正性维护适应性496.2.5提高可维护性的方法

建立明确的软件质量目标和优先级使用提高软件质量的技术和工具进行明确的质量保证审查选择可维护的程序设计语言改进程序的文档开发软件时考虑到维护6.2.5提高可维护性的方法建立明确的软件质量目标和优先506.2.4预防性维护开发和维护者不应等待用户的维护申请,可先选择以下类型程序作为预防性维护对象:预计若干年内将继续使用的程序当今正成功使用的程序最近的将来要进行大修改和完善的程序6.2.4预防性维护开发和维护者不应等待用户的维51§6.3软件再工程(SoftwareReengineering)6.3.1什么是软件再工程

软件再工程是一类软件工程活动，是一个工程过程,它将逆向工程、重构和正向工程组合起来,将现存系统重新构造为新的形式。

软件再工程比其它系统进化方法具有的绝对优势减少软件演化风险降低成本§6.3软件再工程(SoftwareReengineeri52

软件再工程过程模型代码重构数据重构正向工程库存目录分析文档重构逆向工程软件再工程过程模型代码重构数据重构正向工程53再工程过程示意图

需求新需求设计设计代码代码正向工程反向工程（重构）（重构）（重构）再工程过程示意图需求新需求设计设计代码代码正反（重构）（重构54再工程方法

增长的成本自动源代码转换自动结构重构辅之以手工改变结构重构加上体系结构改变自动的程序结构重构程序和数据结构重构再工程方法增长的成本自动源代自动结构重构结构重构加上自动的程55程序转换过程

识别源代码的差异将要再工程的系统设计转换器指令自动转换代码经过再工程的系统手动转换代码将要再工程的系统程序转换过程识别源代将要再工程设计转换自动转换代码经过再工程56逆向工程(反向工程reverseengineering)设计的恢复过程非结构化、无文档的源代码或目标代码软件的文档从现有软件恢复设计信息(有用的维护信息)逆向工程(反向工程reverseengineering)57

逆向工程过程

将要再工程的系统自动分析手工加注释系统信息库文档生成数据结构图程序结构图可追溯矩阵逆向工程过程将要再工程自动分析手工加注释系统文档生成数据程58逆向工程恢复信息的级别:(1)实现级:程序的抽象语法树、符号表等信息(2)结构级:反映程序分量之间相互依赖关系的信息，如调用图、结构图等.(3)功能级:反映程序段功能和段间关系的信息(4)领域级:反映程序分量与应用领域概念间对应关系的信息抽象级别低高信息的抽象级别越高,它与代码距离越远,通过逆向工程恢复的难度越大,自动工具支持的可能性变小逆向工程恢复信息的级别:(1)实现级:程序的抽象语法抽低高信59逆向工程源程序目标代码反汇编、反编译程序分析技术:程序结构分析工具程序功能分析工具

源程序概要设计详细设计概要设计需求分析逆向工程源程序目标代码反汇编、反编译源程序概要设计概要设计需60

数据重构（数据再工程）修改遗留系统的程序时必须同时修改数据数据退化程序内固有的限制体系结构进化

数据再工程的方法方法描述数据清理分析对数据记录和值以改善其质量，通常不需变更程序数据扩展数据和相关程序被再工程数据迁移数据被转移到一个先进的数据库管理系统之上数据重构（数据再工程）修改遗留系统的程序时必须同时修改数据61

数据再工程过程

将要再工程的程序数据分析实体名修改直接量替换对数据定义重新安排文档生成修改过的数据数据重新格式化默认值转换验证规则修改变更汇总表数据分析阶段1阶段2阶段3数据再工程过程将要再工程的程序数据分析实体名修改文档生成修62§5.7面向对象的软件测试OO的系统与使用功能模型开发的系统之间的差别：对象作为一个单独的组件一般要比一个功能模块大由对象到子系统的集成通常是松散耦合的，系统中没有一个明显的“顶层”如果对象被复用，测试者就无法进入组件内部分析其代码测试策略和测试战术的改变白盒测试方法需要扩展到更大粒度的对象上集成测试采用黑盒测试§5.7面向对象的软件测试OO的系统与使用功能模型开发的63面向对象系统的测试可分为四个层次测试与对象关联的单个操作测试单个对象类测试对象集群测试面向对象系统面向对象系统的测试可分为四个层次测试与对象关联的单个操作64

5.7.1对象类的测试用白盒的覆盖测试方法保证所有程序中的语句至少执行一遍，所有的程序路径都要执行到。对象的完全覆盖测试应包括：对象中所有操作被单独隔离测试对象所有属性的设置和访问的测试对象的所有可能状态的测试。所有能引起状态改变的事件都要模拟到。相当于传统的单元测试，单元概念的变化—封装的类或对象作为最小的可测试单位5.7.1对象类的测试用白盒的覆盖测试方法保证所有程序65测试单个类的方法（1）随机测试例:银行系统的account(帐户)类有下列操作：open(打开)setup(建立)deposit(存款)withdraw(取款)balance(余额)summarize(清单)creditLimit(透支限额)close(关闭)系统对操作的限制：必须在应用其它操作之前先打开帐户,在完成了全部操作之后才能关闭帐户;……在限制下还是存在操作的许多排列测试单个类的方法（1）随机测试例:银行系统的account(66一个account类实例的最小行为历史包括下列操作:open.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.deposit.withdraw.deposit.balance.creditLimit.withdraw.close这些和其它的随机顺序测试被进行,以测试不同的类实例的生存历史.一个account类实例的最小行为历史包括下列操作:测试用例67测试单个类的方法（2）划分测试(partitiontesting)

与测试传统软件时采用的等价类划分方法类似.

划分类别的方法:基于状态的划分基于属性的划分基于功能的划分测试单个类的方法（2）划分测试(partitiontest68基于状态的划分根据类操作改变类状态的能力来划分类操作.例：银行系统的account(帐户)类

状态操作包括:deposit(存款)withdraw(取款)

非状态操作包括:balance(余额)summarize(清单)creditLimit(透支限额)测试用例p1(测试改变状态的操作):

open.setup.deposit.deposit..withdraw.close

测试用例p2(测试不改变状态的操作,在最小测试序列中的操作除外):open.setup.deposit.summarize.creditLimit.withdraw.close基于状态的划分根据类操作改变类状态的能力来划分类操作.例69基于属性的划分根据类操作使用的属性来划分类操作.例：account类可根据balance属性来把操作定义划分为三个类别:

使用balance的操作修改balance的操作不使用也不修改balance的操作

为上述每个类别设计测试序列基于属性的划分根据类操作使用的属性来划分类操作.例：ac70基于功能的划分根据类操作所完成的功能来划分类操作.例:account类中的操作按功能可划分为四个类别:

初始化操作(open,setup)计算操作(deposit,withdraw)查询操作(balance,summarize,creditLimit)终止操作(close)

为上述每个类别设计测试序列基于功能的划分根据类操作所完成的功能来划分类操作.例:a71

setupacctaccount类的状态转换图emptyacctdeadacctsetupAaccentbalancecreditacctInfoclosedeposit(initial)depositwithdrawworkingacctopenwithdrawal(final)nonworkingacct测试单个类的方法（3）基于状态的测试setupaccount类的状态转换图empty72测试单个类的方法（4）基于故障的测试(fault_basedtesting)与测试传统软件时采用的错误推测法类似.测试单个类的方法与测试传统软件时采用的错误推测法类似.73

5.7.2

对象的集成测试

OO软件没有层次的控制结构,传统的自顶向下和自底向上的集成策略没有意义.OO软件的两种集成策略:基于使用的测试(用例或基于场景的测试)

基于线程的测试(thread-basedtesting)

集成响应系统的一个输入或事件所需的一组类,每个线程被个体地集成和测试,通过回归测试保证没有副作用产生;对象交互测试

5.7.2对象的集成测试OO软件没有层次74

ATMBank银行系统的类协作图ATMUserInterfaceAccountCashierverifyAcctverifyPINverifyPolicywithdrawReqdepositReqacctInfoReqcardInsertedpassworddepositwithdrawaccentStatusterminatevalidPINvalidAcctcreditLimitaccentTypebalancewithdrawdepositcloseValidationInfoverifyStatusdepositStatusdispenseCaseprintAccentStatreadCardInfogetCaseAmntopenAcctinitialDepositauthorizeCarddeuthorizecloseAcctATMBank银行系统的类协作图ATMAccoun75

OO集成测试方法（1）多个类测试Kirani,S.andW.T.Tsai,在“SpecificationandVerificationofObject-OrientedPrograms”中建议了下面的步骤序列以生成多个类随机测试用例:1.对每个客户类,使用类操作列表来生成一系列随机测试序列,这些操作发送消息给服务器类;2.对生成的每个消息,确定在服务器对象中的协作者类和对应的操作;3.对服务器对象中的每个操作(已经被来自客户对象的消息调用),确定传递的消息;4.对每个消息,确定下一层被调用的操作,并把这些操作结合进测试序列中.OO集成测试方法（1）多个类测试76

ATMBank银行系统的类协作图ATMUserInterfaceAccountCashierverifyAcctverifyPINverifyPolicywithdrawReqdepositReqacctInfoReqvalidPINvalidAcctcreditLimitaccentTypebalancewithdrawdepositcloseopenAcctinitialDepositauthorizeCarddeuthorizecloseAcctValidationInfoverifyStatusdepositStatusdispenseCaseprintAccentStatreadCardInfogetCaseAmntcardInsertedpassworddepositwithdrawaccentStatusterminateATMBank银行系统的类协作图ATMAccoun77银行系统中Bank类和ATM类的操作序列:verifyAcct•verifyPIN•[[verifyPolicy•withdrawReq]|depositReq|acctInfoReq]n对Bank类的随机测试用例可能是:测试用例r3:verifyAcct•verifyPIN•depositReq为了考虑测试中涉及的协作者,需要考虑与测试用例r3中每个操作相关联的消息:Bank必须和ValidationInfo协作以执行depositReq、verifyAcct和verifyPINBank还必须和Account协作以执行deposit因此,测试这些协作的新的测试用例是:测试用例r4:verifyAcctBank•[validAcctValidationInfo]•

verifyPINBank

•[validPINValidationInfo]

•

depositReq

•[depositAccount]银行系统中Bank类和ATM类的操作序列:verifyAcc78

OO集成测试方法（2）从动态模型导出测试用例

设计的测试用例应达到完全的状态覆盖,即操作序列应导致account类的变迁穿越所有允许的状态:测试用例s1:open•setupAccent•deposit(initial)•withdraw(final)•close(最小测试序列)

向最小序列中加入附加的测试序列,例如:测试用例s2:open•setupAccent•deposit(initial)•deposit•balance•credit•withdraw(final)•close测试用例s3:open•setupAccent•deposit(initial)•deposit•withdraw•accntInfo•withdraw(final)•close……导出更多的测试用例以保证该类的所有行为都被适当地测试OO集成测试方法（2）从动态模型导出测试用例向最小序列中加79

5.7.3

OO系统的确认测试在确认和系统测试层次,类连接的细节消失.和传统的确认测试一样,OO软件的确认关注用户可见的动作和用户可识别的系统输出.为辅助确认测试的导出,应利用分析模型中的用例图提供的场景来提高交互需求中发现错误的可能性5.7.3OO系统的确认测试在确认和系统测试层次,类连接80§5.8自动测试和测试工具自动化和工具的好处速度效率准确度和精确度坚持不懈§5.8自动测试和测试工具自动化和工具的好处815.8.1测试工具静态分析工具动态测试工具测试数据自动生成工具集成化测试环境非侵入式工具侵入式工具5.8.1测试工具静态分析工具82测试工作台(下游CASE工具)源代码被测试的程序测试数据规约预测器测试管理器测试预估模拟器文件比较器报告生成器动态分析器测试结果测试结果报告执行报告测试数据生成器测试工作台(下游CASE工具)源代码被测试测试数据规约预测器83查看器和监视器1#计算机软件正在测试2#计算机软件正在测试3#计算机查看测试工具通信线路监听线路通信分析器可以查看两个系统之间传输的原始数据（非侵入）（输入测试用例）（确认产生的通信数据）（检查相应结果）查看器和监视器1#计算机2#计算机3#计算机通信线路监听线路84驱动程序普通系统配置测试驱动配置（在此计算机上编写简单的程序自动产生相应的击键和鼠标移动来测试软件）键盘电缆鼠标电缆一台计算机可以作为驱动程序测试工具取代被测试系统的键盘和鼠标从外部计算机发送击键鼠标的移动信息,被测试软件不被侵入,如果测试软件时在同一系统中执行驱动程序,它就会侵入系统,这种测试情况可能无法接受驱动程序普通系统配置测试驱动配置键盘鼠标一台计算机可以作为85管道和仿真器普通系统配置测试存根配置一台计算机可以充当管道,代替打印机,能够对测试输出进行更有效的分析运行管道软件来代替打印机，对打印数据进行阅读和解释管道和仿真器普通系统配置测试存根配置一台计算机可以充当管道,86其它工具类型:施压工具和增负工具干扰发生器和噪声发生器分析工具其它工具类型:施压工具和增负工具干扰发生器和噪声发生器分87测试工具产品实例JUnit:Java单元测试工具CppUnit：C++单元测试工具Dunit:Delphi的终极测试工具测试工具产品实例JUnit:Java单元测试工具885.8.2测试测试自动化

另一类软件测试工具,可以自动执行测试用例、查找软件缺陷、分析并记录测试结果。5.8.2测试测试自动化另一类软件测试工具,可以89随机测试:猴子测试员只要不停电,偶尔能够得到香蕉,猴子就会永远测试下去一个想法:

“如果让一百万只猴子在一百万只键盘上敲一百万年,它们最终就可能写出莎士比亚话剧等巨著”.随机测试:猴子测试员只要不停电,偶尔能够得到香蕉,猴子就会永90猴子的进步笨猴子:一点也不懂测试软件,只是随机地单击或按键,直至发生两件事情之一:完成循环或系统崩溃.不太笨的猴子:

具有崩溃辨认能力,能够重新启动系统开始测试聪明猴子:能够从它的笨兄弟那里获得随机测试的结果,增加了对环境的认知能力,有目的地敲键盘,不仅限于查找崩溃缺陷,同时查看数据,检查操作结果,找出与预期结果的差别猴子的进步笨猴子:一点也不懂测试软件,只是随机地单击或按键91自动化测试工具实例美国国际软件自动化（ISA）公司的PanoramaforC/C++，j、Java和VB产品，自动化功能包括：软件结构分析与逻辑框图的自动化软件静态分析数据分析复杂性分析与分析结果列表的自动化软件质量分析动态性能分析软件代码分支或条件覆盖率分析软件测试用例有效性分析与测试用例最小集的自动选取软件界面手工操作过程的自动记录与自动再执行(Playback)自动化测试工具实例美国国际软件自动化（ISA）公司92§5.9测试中的可靠性分析

开发过程中，利用测试的统计数据来估算软件的可靠性，以控制软件的质量。推测错误的产生频度推测残留在程序中的错误数评价测试的精确度和覆盖率§5.9测试中的可靠性分析开发过程中，利用测试的统93推测错误的产生频度(推测错误产生的时间间隔)1K(ET/IT-Ec(t)/IT)方法:估算平均故障时间(MTTF估算公式)MTTF＝K:

经验常数ET:

程序中原有的残留错误数IT:

程序长度t:测试时间

Ec(t):在0-t期间内发现的错误总数λ1=当故障率为独立于时间的常量λ:推测错误的产生频度(推测错误产生的时间间隔)1K(ET/IT94推测残留在程序中的错误数错误植入模型Mills将播种模型用于程序中残留错误的估算,称错误植入模型播种模型：

N：程序中原有残留的错误数Nt：新植入的错误数n:测试发现的原有错误数nt:测试发现的植入错误数NNnnt≈tNNnnt=t推测残留在程序中的错误数错误植入模型NNnnt≈tNNn95Hyman对错误植入模型的改进ET:程序中原有的残留错误数E1:1号测试员在某一时间内发现的错误数E2:2号测试员在同一时间内发现的错误数E0:两位测试员共同发现的错误数EEE1≈0=2ETE1E2/E0ETHyman对错误植入模型的改进ET:程序中原有的残留错误数96第六章软件进化遗留系统软件变更策略软件维护体系结构进化软件再工程配置管理第六章软件进化遗留系统97§6.1遗留系统更换遗留系统是有风险的业务策略，因为：遗留系统几乎没有完整的描述业务过程与遗留系统的操作方式紧密相关重要的业务规则隐藏在软件内部开发新软件有风险继续使用遗留系统，进行变更费用更高，因为：系统是由不同团对实现的，程序设计风格不一致系统使用过时的语言编写系统文档不充分、过时经多年维护，系统结构已破坏系统进行过优化，不可读系统数据过时、不完整§6.1遗留系统更换遗留系统是有风险的业务策略，因为：继续98遗留系统评估对遗留系统做现实的评估，做出适当的抉择：彻底抛弃系统继续维护系统采用某种方式转换系统以改善其可维护性以一个新的系统代替该系统遗留系统评估对遗留系统做现实的评估，做出适当的抉择：99§6.2软件维护

四类维护活动：改正性维护适应性维护扩充与完善性维护预防性维护§6.2软件维护四类维护活动：100各种维护所占比例:其它维护5%适应性维护25%改正性维护20%扩充与完善性维护50%改正性维护占全部维护量的比率已从80年代初的20%大幅度下降,90年代初一些公司的产品差错率已接近于零各种维护所占比例:其它维护适应性改正性扩充与完改正性维护占1016.2.1软件维护的特点MP+Ke=(c-d)M

:维护工作总工作量P:生产性工作量K

:

经验常数c:复杂度d:对该软件熟悉程度的度量维护的成本6.2.1软件维护的特点MP+Ke=(c-d)M:维护102维护中的典型问题(1)难以跟踪软件版本的进化过程,软件的变化未在文档中反映出来.(2)难以跟踪软件的创建过程.(3)难以读懂他人程序.(4)无文档或不全.(5)软件人员流动性大.(6)设计时未考虑修改需要,修改困难.(7)维护工作无吸引力,缺乏成就感.维护中的典型问题(1)难以跟踪软件版本的进化过程,1036.2.2软件的维护任务修改负责人维护申请系统监督员配置管理员维护机构维护人员维护管理员6.2.2软件的维护任务修改维护申请系统监督员配置管理员维104保存维护记录维护过程中作应记录的数据程序标识源程序语句数目机器代码指令条数..............以收集的数据为基础构造维护数据库,供维护评价使用.保存维护记录维护过程中作应记录的数据1056.2.3软件维护的实施修改源程序的三个步骤分析和理解程序修改程序重新验证程序6.2.3软件维护的实施修改源程序的三个步骤106修改程序的副作用修改代码的副作用修改数据的副作用修改文档的副作用修改程序的副作用修改代码的副作用107重新验证程序静态确认计算机确认维护后的验收重新