§6.6面向对象的软件测试.ppt

§ 面向对象的软件测试
测试目标:在现实的时间跨度内应用可管理
的工作量去发现最大可能数量的
错误
基本目标不变,但由于OO程序的性质改变了测试策略
和测试战术
更多的设计模式复用是否将减轻OO系统的繁重测试?
Binder,“Object-Oriented Software Testing”中讨论改问题:
“每次复用是一个新的使用语境,,似乎可能需要更多而不是更少的测试.”
OOA和OOD的模型测试
每个阶段的所有面向对象模型都应被测试。 OOA和OOD的模型不能被执行,对它们不能进行传统意义上的测试。
可通过技术复审检查OOA和OOD的
模型的正确性和一致性。
扩大测试的视角
面向对象测试策略
信息隐蔽对测试的影响
封装和继承对测试的影响
面向对象程序的特点对软件测试的影响:
单元和集成测试策略必须有很大的改变
测试用例的设计必须考虑OO软件的特征
1. OO的单元测试
一个类可以包含一组不同的操作,而一个特定
的操作也可能存在于一组不同的类中。不再孤
立地测试单个操作(这是传统单元测试的视角)
OO软件的类测试等价于传统的单元测试.
传统软件的单元测试关注算法细节和模块接口
间流动的数据
OO软件的类测试是由封装在类中的操作和类的
状态行为驱动的
单元概念的变化—封装的类或对象作为最小
的可测试单位
2. OO的集成测试
OO软件没有层次的控制结构,传统的自顶向
下和自底向上的集成策略没有意义.
OO软件的集成两种策略:
基于线程的测试(thread-based testing)
集成响应系统的一个输入或事件所需的一组类,每个线程被个体地集成和测试,通过回归测试保证没有副作用产生;
基于使用的测试(use-based testing)
通过测试几乎不使用服务器的类(独立类)来开始系统的构造,测试完独立类后,使用独立类按层逐步完成依赖类的测试直至完整的系统被构造;
3. OO的确认测试
在确认和系统测试层次,类连接的细节消失.
和传统的确认测试一样,OO软件的确认关注
用户可见的动作和用户可识别的系统输出.
为辅助确认测试的导出, 应利用分析模型中的
用例图提供的场景来提高交互需求中发现错误
的可能性
OO软件的测试用例设计
每个测试用例应被唯一标识,并应显式地和与被
测试类相关联
测试的目的应被陈述
对每个测试应开发一组测试步骤,包括:
将被测试对象的一组特定状态
将被作为测试的结果使用的一组消息和操作
当对象被测试时可能产生的一组异常
一组外部条件(进行测试必须的软件外部环境的变化)
将辅助理解或实现测试的补充信息
OO软件的测试用例设计还处于成型期.
Binder,“Essays on Object-Oriented Software Engineering”
中建议了对OO软件的测试用例设计的整体方法:
1. OO概念的测试用例设计的含义
封装可能会成为测试的障碍
测试需要报告对象的具体和抽象状态,而封装
使得对象的状态快照难于获得。
继承,特别是多继承使测试复杂化
子类继承或重载的父类成员函数的测试问题
继承的成员函数是否都不需要测试?
对父类中已经测试过的成员函数,两种情况需要
在子类中重新测试:
继承的成员函数在子类中做了改动;
成员函数调用了改动过的成员函数的部分;
例如:
父类Base有两个成员函数Inherited()和Redefined(),
子类Derived只对Redefined() 做了改动.
Derived ∷Redefined() —需要重新测试
Derived ∷Inherited() —如果它调用了Redefined() 的
语句,则需重新测试,否则不必
子类继承或重载的父类成员函数的测试问题
对父类的测试是否能够照搬到子类?
上例中: Base∷Redefined() 和Derived ∷Redefined() 已是两个不同的成员函数, 照理应对Derived ∷Redefined() 重新进行测试分析, 设计测试用例,但由于它们的相似性,只需在Base∷Redefined() 的测试要求和测试用例上添加对Derived ∷Redefined() 的新的测试要求和增补相应的测试用例.