Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 软件测试 顾庆南大计算机系 2001 年 4 月 7 日. 2 一、测试的概念 b 定义:验证被测程序确实是按照事先预 定的目标和规则执行的一个信心建立过 程- Hetzal 。 b 两个要求: 程序的正确性 程序的正确性 测试过程的可信程度 测试过程的可信程度.

Similar presentations


Presentation on theme: "1 软件测试 顾庆南大计算机系 2001 年 4 月 7 日. 2 一、测试的概念 b 定义:验证被测程序确实是按照事先预 定的目标和规则执行的一个信心建立过 程- Hetzal 。 b 两个要求: 程序的正确性 程序的正确性 测试过程的可信程度 测试过程的可信程度."— Presentation transcript:

1 1 软件测试 顾庆南大计算机系 2001 年 4 月 7 日

2 2 一、测试的概念 b 定义:验证被测程序确实是按照事先预 定的目标和规则执行的一个信心建立过 程- Hetzal 。 b 两个要求: 程序的正确性 程序的正确性 测试过程的可信程度 测试过程的可信程度

3 3 一、测试的概念 b 什么是程序的正确性 狭义:程序运行符合规约的要求: 狭义:程序运行符合规约的要求: – 功能 – 性能 – 输入和输出 – 对环境的影响 – 同标准、约定( convention )的一致性等

4 4 一、测试的概念 b 什么是程序的正确性 广义:测试工程,覆盖需求、概要设计、详 细设计、编码等软件开发各个阶段 广义:测试工程,覆盖需求、概要设计、详 细设计、编码等软件开发各个阶段 – 各阶段文档的一致性 – 向前 / 向后兼容性 – 同其他应用程序的协作、接口等

5 5 一、测试的概念 b 什么是验证过程的可信度 选择测试用例的充分性准则 选择测试用例的充分性准则 – 结点覆盖准则 / 边覆盖准则 – 可靠性-多个测试用例集得到一致的结果 – 正确性-程序不正确,至少有一个测试用例能检 测出来

6 6 二、测试的基本原理 b 测试对象:程序的行为(程序的执行过 程) b 程序行为的三个不同视角( View ): 规约:程序应该做什么 规约:程序应该做什么 结构:程序能够做什么 结构:程序能够做什么 测试:程序做了什么 测试:程序做了什么 b Venn_ 图: 4 S P T 1 2 3 56 7 S -规约视角 P -结构视角 T -测试视角

7 7 二、测试的基本原理 b 测试的两个基本类型: 目的:选择测试用例 目的:选择测试用例 规约视角+测试视角:功能测试 & 黑箱测试 规约视角+测试视角:功能测试 & 黑箱测试 结构视角+测试视角:结构测试 & 白箱测试 结构视角+测试视角:结构测试 & 白箱测试 b 测试的经验定律: %20 的代码导致 %80 的错误%20 的代码导致 %80 的错误

8 8 二、测试的基本原理 b 描述程序规约的五个基本要素 数据:由程序或程序模块创建并使用的信息。 数据:由程序或程序模块创建并使用的信息。 端口:程序 / 模块同外部环境的接口,包括输入和输出。 端口:程序 / 模块同外部环境的接口,包括输入和输出。 动作:程序状态的变迁,一般对应于程序流图的节点 或边。 动作:程序状态的变迁,一般对应于程序流图的节点 或边。 事件:程序 / 模块同外部环境的交互,可以理解为通过 端口的程序动作。 事件:程序 / 模块同外部环境的交互,可以理解为通过 端口的程序动作。 线索:动作序列,一般起始于一个输入动作,并终止 于一个输出动作。 线索:动作序列,一般起始于一个输入动作,并终止 于一个输出动作。

9 9 二、测试的基本原理 b 五个基本要素间的关系:传统串行程序 事件 动作 数据 端口 程序 / 模块 线索

10 10 二、测试的基本原理 b 五个基本要素间的关系:分布式程序 线索 动作 2 数据 2 端口 2 分布单元 2 事件 2 动作 1 数据 1 端口 1 分布单元 1 事件 1

11 11 二、测试的基本原理 b 测试用例的基本形式: 单纯的程序输入,适于单个模块的测试。 单纯的程序输入,适于单个模块的测试。 程序的功能脚本- profile ,适于多个模块合 作的测试 程序的功能脚本- profile ,适于多个模块合 作的测试 程序的线索- thread ,适于 GUI 等的测试。动 作序列  事件序列:分布式程序测试 程序的线索- thread ,适于 GUI 等的测试。动 作序列  事件序列:分布式程序测试

12 12 b 白箱测试: 程序流图( Flow Graph Notation ) 程序流图( Flow Graph Notation ) – 结点-程序语句 +条件选择语句 –if (a or b) then x else y : 三、测试方法和技术 a x b F T T F x y Predicate node

13 13 三、测试方法和技术 b 白箱测试 Cyclomatic Complexity = number of independent path ,记为 V(G)Cyclomatic Complexity = number of independent path ,记为 V(G) V(G) = E – N +2 = P + 1V(G) = E – N +2 = P + 1 –E – number of edges –N – number of nodes –P – number of predicate nodes

14 14 三、测试方法和技术 b 白箱测试 控制流测试: 控制流测试: – 结点覆盖 – 分支覆盖-选择独立路径 – 路径覆盖-考虑循环 – 基本路径覆盖(结点不重复出现) – 简单路径覆盖(边不重复出现) –K 度回路覆盖(循环重复不超过 K 次)

15 15 三、测试方法和技术 b 白箱测试 数据流测试: 数据流测试: – 两类结点: – 变量定义结点-定义性出现 – 变量使用结点-引用性出现:谓词引用 / 计算引用 – 定义-使用路径( definition-use chain ) – 覆盖准则: – 定义覆盖:定义到某一相关引用 – 引用覆盖:定义到所有引用 – 定义-引用覆盖:定义 × 引用 – 程序片:其他对引用有影响的结点

16 16 三、测试方法和技术 b 白箱测试 数据流测试 数据流测试 – 其他覆盖准则: –K 元数据交互链: »def(v1) … def(v2) use v1…def(v3) use v2……use vk – 构造类型数据、动态数据(对象绑定)覆盖-各属性 的定义和引用 – 过程间数据流(参数传递)

17 17 三、测试方法和技术 b 白箱测试 循环的测试 循环的测试 – 单个循环( simple loop ):执行次数- 0 、 1 、 2 、 n-1 、 n 、 n+1 – 嵌套循环( nested loop ):由内向外 –Concatenated loops : dependent loops

18 18 三、测试方法和技术 b 黑箱测试 边界值分析 边界值分析 – 输入边界: x: min(x), max(x) ; y: min(y), max(y) –,, –,, – 考虑 min+1, max-1, min-1, max+1 – 输出边界:定义 f -1

19 19 三、测试方法和技术 b 黑箱测试 等价类划分: for every input x - 等价类划分: for every input x - –Specific value: 1 valid + 2 invalid class –Set: 1 valid + 1 invalid class –Range: 1 valid + 2 invalid class –Boolean: 1 valid + 1 invalid – 决策表- classes 1 × classes 2 ×……

20 20 三、测试方法和技术 b 黑箱测试 Graph-based Testing MethodsGraph-based Testing Methods –Nodes + edges –Transaction Flow -结点: steps in transaction ;边- logical connection between steps –Finite state -结点: observable states ;边: transition between states –Data flow -结点: data objects ;边: transformation between data objects –Timing -结点: program objects ;边: sequential connections

21 21 三、测试方法和技术 b 黑箱测试 Graph-based Testing MethodsGraph-based Testing Methods – 覆盖准则: – 结点覆盖 – 边覆盖 – 路径覆盖(输入路径覆盖、输出路径覆盖)

22 22 四、面向对象测试技术 b 对象技术的影响: Class – objectsClass – objects Snapshot of states of an objectSnapshot of states of an object InheritanceInheritance Polymorphism – exactly which code gets exercised can only be determined at runtimePolymorphism – exactly which code gets exercised can only be determined at runtime b Surface structure or deep structure Surface structure: externally observable structure of an OO program—object interactionsSurface structure: externally observable structure of an OO program—object interactions Deep structure: internal details of a class and an object—inheritance hierarchy, attributes, private data, operationsDeep structure: internal details of a class and an object—inheritance hierarchy, attributes, private data, operations

23 23 四、面向对象测试技术 b 单个类的测试方法 Random Testing:Random Testing: –Operation(method) sequence of the class Partition Testing:Partition Testing: –State-based partitioning –Attribute-based partitioning – attributed used or affected –Category-based partitioning – generic function performed, such as 初始化、查询、终止、计算等

24 24 四、面向对象测试技术 b 涉及多个类的测试方法 Multiple classes:Multiple classes: –1 class operations  messages  collaborator class –Random or Partition Testing based Behavioral model:Behavioral model: –State-transition diagram (STD) –One STD – state or transition based coverage –Multiple STD – track the behavioral flow of the system: 深度优 先或广度优先

25 25 四、面向对象测试技术 b 涉及多个类的测试方法 Scenario-based:Scenario-based: –Use pattern – what the user does? –From design – which interaction subjects to failure

26 26 五、 Client/Server 系统的测试 b 测试考虑: 3 个层次 Client applicationsClient applications Client + serverClient + server Client + server + network operations & performanceClient + server + network operations & performance b User scenarios: address Who: type of userWho: type of user Where: system interactionWhere: system interaction What: transactionsWhat: transactions Why: domain specificWhy: domain specific b Operational profiles: pattern of usage

27 27 五、 Client/Server 系统的测试 b 测试方法(不同的侧重): Application functionApplication function Server test – include performance & coordination & data managementServer test – include performance & coordination & data management Database test – integrity of data, inquiry accuracyDatabase test – integrity of data, inquiry accuracy Transaction test – class of transactions, including performance & interactionsTransaction test – class of transactions, including performance & interactions Network communication test – performance, security, correctness etc.Network communication test – performance, security, correctness etc.

28 28 五、 Client/Server 系统的测试 b 其他方面 Configuration testing: in all of known hardware/software environmentsConfiguration testing: in all of known hardware/software environments Compatibility testing: functionally consistent interface across hardware & software platformsCompatibility testing: functionally consistent interface across hardware & software platforms

29 29 六、分布式程序测试 b 分布式程序测试所面临的问题:两个方 面 分布式程序本身的问题-分布单元间的并发 所导致的不确定性。 分布式程序本身的问题-分布单元间的并发 所导致的不确定性。 同运行环境合作的问题-分布单元间的协作 (通信+同步)需要底层系统的支撑。 同运行环境合作的问题-分布单元间的协作 (通信+同步)需要底层系统的支撑。

30 30 六、分布式程序测试 b 分布式程序自身的问题-并发 Irreproducibility effect -执行过程不可重复Irreproducibility effect -执行过程不可重复 – 程序 p 执行输入 x , 1~n 次正确不代表 p 执行 x 正确。 – 执行出错时, debug 时难以再重复该执行过程。 – 回归测试时不能保证查错的正确性。 解决方案: 解决方案: –Record&Replay -记录程序的执行过程。目前多 采用事件序列。并根据事件序列以确定的方式执 行(重现)被测程序。

31 31 六、分布式程序测试 Completeness problem -并发路径的覆盖Completeness problem -并发路径的覆盖 –Sequentialize 并发路径将导致指数级的路径数。 – 竞争条件( race conditions )决定并发路径的选 择。 解决方案: 解决方案: – 找出并控制竞争条件,实现确定性测试。 – 合理的测试充分性准则-确定有限的路径集(引 申为事件序列集)是否是充分的。如 “use profile”

32 32 六、分布式程序测试 b 分布式程序同运行环境协作的问题 网络的协议架构( TCP/IP +上层应用),分布式程 序=建立在通信平台上的分布式应用。 网络的协议架构( TCP/IP +上层应用),分布式程 序=建立在通信平台上的分布式应用。 建立在通信平台上的分布式程序支撑系统-协议框 架+服务构件:如 JVM ( Java Virtual Machine )、 CORBA ( Common Object Request Broker )、 DCOM ( Distributed Common Object Model )-实现互操作、 平台无关性等。 建立在通信平台上的分布式程序支撑系统-协议框 架+服务构件:如 JVM ( Java Virtual Machine )、 CORBA ( Common Object Request Broker )、 DCOM ( Distributed Common Object Model )-实现互操作、 平台无关性等。 运行环境=通信平台+支撑系统 运行环境=通信平台+支撑系统

33 33 六、分布式程序测试 测试时需考虑: 测试时需考虑: – 运行环境(支撑系统)的正确性 – 程序单元同运行环境合作的正确性 – 同运行环境合作的性能 解决方法: 解决方法: – 测试功能的分层+测试工具间的合作  分布式程 序的测试模型 – 分层指测试不同层次的构件和模块。 – 合作指针对不同构件的测试工具(构件来自不同 的产商)间的协作。

34 34 六、分布式程序测试 b 分布式程序的测试方法:目前多考虑程序本身。 如果考虑运行环境,可参照 Client/Server 系统 的测试。 b 从测试过程和手段划分: 不确定性测试-给定输入 x 让程序 p 自由运行,再观 察对应的输出结果,目的是尽可能多地了解程序运 行的可行结果,即 Feasible(p, x) 。 不确定性测试-给定输入 x 让程序 p 自由运行,再观 察对应的输出结果,目的是尽可能多地了解程序运 行的可行结果,即 Feasible(p, x) 。 确定性测试-给定输入 x ,根据 Valid(p, x) 或 inValid(p, x) 人为干预程序的执行,使其向预想的状 态转移或者执行预定的动作,以检测可能的错误; 目的是检测规约行为即 Valid(p, x) 的可行性。 确定性测试-给定输入 x ,根据 Valid(p, x) 或 inValid(p, x) 人为干预程序的执行,使其向预想的状 态转移或者执行预定的动作,以检测可能的错误; 目的是检测规约行为即 Valid(p, x) 的可行性。

35 35 六、分布式程序测试 两者的结合: 两者的结合: – 先按照不确定性测试方法执行分布式程序 p ,到达一定覆 盖程度后再使用确定性测试。 – 在单元和集成测试阶段程序规模较小时采用确定性测试, 到系统测试阶段采用不确定性测试。 –Prefix-based Testing ( Prefix-based Replay ),纵向划分。 首先确定同步序列的前缀 s’ ,利用确定性测试到达被测程 序的某一中间状态 st’ ,再执行不确定性测试到程序结束。 –Event-subset Testing ,横向划分。将程序 p 按分布单元或共 享数据(一般由 Server 单元管理)分成两个部分,其中之 一执行确定性测试,另外一个则执行不确定性测试。 如 p 分两个模块 a 和 b ,测试时按 “a.e 1, a.e 2, …, a.e n ” ,中间穿插 b 的 事件。

36 36 六、分布式程序测试 b 按测试用例的选择方法划分: 基于有限状态机(如可达图或并发图)的覆盖策略: T 方案- 每个变迁至少遍历一次; D 方案-针对每个中间状态 st ,选择 输入使其执行一个不同的到达终止状态的变迁序列; U 方案- 针对每个中间状态 st ,确定输入使其执行一 “ 独特 ” 的变迁序列; W 方案-进一步考虑错误状态,基于 U 方案选择输入 / 输出序列。 基于有限状态机(如可达图或并发图)的覆盖策略: T 方案- 每个变迁至少遍历一次; D 方案-针对每个中间状态 st ,选择 输入使其执行一个不同的到达终止状态的变迁序列; U 方案- 针对每个中间状态 st ,确定输入使其执行一 “ 独特 ” 的变迁序列; W 方案-进一步考虑错误状态,基于 U 方案选择输入 / 输出序列。 基于抽象程序表示( abstract programs ):首先采用时序逻辑 或进程代数等表示分布式程序,如 LOTOS , Estelle , FSP 等, 再根据这些抽象程序表示选择测试用例。 基于抽象程序表示( abstract programs ):首先采用时序逻辑 或进程代数等表示分布式程序,如 LOTOS , Estelle , FSP 等, 再根据这些抽象程序表示选择测试用例。 基于同步序列约束( sequencing constraints ):当给定程序 p 和 输入 x 时,穷举 Valid(p, x) 一般在计算上不可行。一种解决办法 是定义同步序列约束如 CSPE ( Constraints on Succeeding and Preceding Events ),它规定前后两个同步动作间的顺序依赖 关系以及这种关系的或然性。可以根据对这些约束的覆盖要 求选择测试用例。 基于同步序列约束( sequencing constraints ):当给定程序 p 和 输入 x 时,穷举 Valid(p, x) 一般在计算上不可行。一种解决办法 是定义同步序列约束如 CSPE ( Constraints on Succeeding and Preceding Events ),它规定前后两个同步动作间的顺序依赖 关系以及这种关系的或然性。可以根据对这些约束的覆盖要 求选择测试用例。

37 37 七、测试过程 b Policy – 原则 Design&coding – constructive, while testing – destructive == need ITG (Independent test group)Design&coding – constructive, while testing – destructive == need ITG (Independent test group) Verification & ValidationVerification & Validation –Verification – correctly implements a specific function. –Validation – traceable to customer requirements

38 38 七、测试过程 b Testing Strategy Coding = unit testingCoding = unit testing Design = integration testingDesign = integration testing Requirements = validation testingRequirements = validation testing System = system testingSystem = system testing b When suffice? Software reliability model: 一些经验模型Software reliability model: 一些经验模型

39 39 七、测试过程 b 单元测试( Unit Testing ) 考虑因素: 考虑因素: –Interface –Local data structure –Boundary conditions –Independent paths –Error handling paths 要素: 要素: –Driver – code calling this unit –Stub – dummy function called by this unit

40 40 七、测试过程 b 集成测试( Integration Testing ) Interfacing & InteractionsInterfacing & Interactions Incremental integrationIncremental integration 集成方法: 集成方法: –Top-down – stubs –Bottom-up – drivers –Regression testing – subset of previous tests, play back –Sandwich testing – top down while bottom up

41 41 七、测试过程 b 验证测试( Validation Testing ) Configuration review (audit)Configuration review (audit) Alpha & Beta testingAlpha & Beta testing –Alpha: at developer’s site, used by customer –Beta: at the selected customer sites b 系统测试( System Testing ) Cooperate with other system elements Recovery testing = fault toleranceRecovery testing = fault tolerance Security testingSecurity testing Stress testingStress testing


Download ppt "1 软件测试 顾庆南大计算机系 2001 年 4 月 7 日. 2 一、测试的概念 b 定义:验证被测程序确实是按照事先预 定的目标和规则执行的一个信心建立过 程- Hetzal 。 b 两个要求: 程序的正确性 程序的正确性 测试过程的可信程度 测试过程的可信程度."

Similar presentations


Ads by Google