第八章 编码和测试 编码概述 编码语言与编码工具 编码示例 测试的基本概念 黑盒测试和白盒测试 测试用例设计 多模块程序的测试策略

Presentation on theme: "第八章 编码和测试 编码概述 编码语言与编码工具 编码示例 测试的基本概念 黑盒测试和白盒测试 测试用例设计 多模块程序的测试策略"— Presentation transcript:

1 第八章 编码和测试 编码概述 编码语言与编码工具 编码示例 测试的基本概念 黑盒测试和白盒测试 测试用例设计 多模块程序的测试策略
面向对象系统的测试

2 1. 编码概述 编码的目的 编码 设计模型---->源程序--可执行代码 (不可执行的) (可执行的) 编码的过程
　　　 编码 设计模型---->源程序--可执行代码 (不可执行的)　　　 (可执行的) 编码的过程 熟悉所选语言的功能和程序开发环境 仔细阅读设计模型 弄清要编码的模块的外部接口与内部过程 编码产生的源程序，应该简明清晰，具有较高的效率

3 8.1.2 编码的风格 ( Coding Style ) ●编码风格又称程序设计风格，指一个人编制程序时所表现出来的特点、习惯、逻辑思路等。 ●从追求“聪明”和“技巧” 变为 提倡“简明”和“直接” 结构化的程序设计要求：清晰第一，效率第二 编码中，要坚持简明清晰的原则，养成良好的编码风格

4 ●编码风格的要求： 1. 使用标准的控制结构：在编码中采用单入口、单出口的标准结构，即采用顺序、选择和循环 这 3 种基本控制结构。

5 2. 实现源程序的文档化(Code Documentation; 又称内部文档， Internal Documentation ) (1)采用有意义的变量名（Use Meaningful Variable Name）。 变量名即标识符，包括模块名、变量名、常量名、数组名等。这些名字应能反映它所代表的实际东西，应有一定实际意义。例如，表示次数的变量用times，表示总量用total，表示平均值用average，表示“和”用sum等。

6 (2) 适当的注释(Appropriate Comment )。 注释是程序员与日后的程序读者之间通信的重要手段。充分的注释对提高程序的可读性有很大的帮助。

7 ●源程序的注释分为2类： ①序言性注释 ( Prologue Comment ; 又称头部注释块，Header Comment Block)： 置于每一个模块的开始处，说明模块的名称、用途、功能、参数含义、调用形式等； ②功能性注释( Functional Comment ; 又称程序注释，Program Comments )： 嵌入在源程序内部，说明重要的或难懂的程序段的功能、数据的状态等。 ●修改程序时，注释应随之修改，以保持注释和代码的一致性。

8 (3) 标准的书写格式 （增进理解的格式, format to enhance understanding ） ①用分层缩进（缩格）的写法显示嵌套结构的层次。例如，二层嵌套选择结构，写成下面的缩进形式，层次就清楚得多。 if（…） …… else …… else ……

9 ③在注释段与程序段之间、不同程序段之间插入空行； ④每行只写一条语句；
②在注释段的周围加上边框； ③在注释段与程序段之间、不同程序段之间插入空行； ④每行只写一条语句； ⑤书写表达式时，适当地使用空格或圆括号等作为隔离符。例如 ，将表达式 a＜17 && b＜＝49||c>5 写成 (a＜17) && ( b＜＝49) || (c>5) 更容易理解。

10 3.满足用户友好（User Friendly）的输入输出风格 ●程序的运行要考虑人的因素，尽量做到对用户友善。 (1)输入方面: ①对输入数据进行有效性检验； ②输入格式力求简单、一致，尽可能采用自由格式输入； ③输入一批数据时, 最好使用输入结束标志，而不要由用户来计算输入数据数目； ④向用户显示“请输入¨¨¨”的提示信息，同时指明允许的选择范围和边界值； ⑤检查输入项的各种组合的合理性。

11 (2)输出方面: ①给所有的输出加注解，进行必要的说明； ②使报表具有良好的格式。 对于具有大量人-机交互的系统，尤其要注意良好的输入输出风格。Wasserman曾著文论述这个问题，并称之为"用户软件工程（User SE）"。他提出的主要观点有：

12    ①当用户使用程序时，能对用户做到"在线"帮助；    ②对可能产生重大后果的请求，给出醒目的提示，待用户再次确认后在执行；    ③使程序具有"防狼（bulletproof）"功能，不致因用户的偶然错误使程序发生非正常的中断；    ④区别对待不同类的用户（例如专业人员与非专业人员，领导干部与一般工作人员），使程序的输入要求和输出形式适应用户的习惯与水平；    ⑤发生错误时，能迅速恢复正常。

13 ●按照软件工程的观点,编码语言的发展已经历了 4 代、3个阶段，如图8.2所示。
8.2 编码语言与编码工具 编码语言的发展 ●按照软件工程的观点,编码语言的发展已经历了 4 代、3个阶段，如图8.2所示。 面向机器 的语言 高级语言 (第三代) 甚高级 语言 机器语言 (第一代) 汇编语言 (第二代) 基础 语言 结构化 语言 面向对象 语言 第四代 语言 图 编码语言的发展和分类

14 1. 面向机器的语言： 包括第一代机器语言和第二代汇编语言。 2
1.面向机器的语言： 包括第一代机器语言和第二代汇编语言。 2.高级语言（第三代语言，面向过程的语言）： ●1956年，第一个高级语言FORTRAN在美国诞生。 ●1970年，第一个体现结构化编程思想的语言PASCAL在欧洲瑞士诞生。 ●1973年，C语言在美国诞生，它既有高级语言的特点，又具有汇编语言的特点。 ●面向对象语言：C++ (诞生于1983年)、Java (诞生于1995年) 等 。

15 3.第四代语言（4GL,面向问题的语言）： 如：PowerBuilder、Oracle、SQL Server等。4GL应具有以下特征: (1)具有很强的数据库管理能力; (2)提供一组高效的、非过程化的命令。编程时只需用这些命令说明“做什么”，不必描述实现的细节“怎么做” 。 (3)能满足多功能、一体化的要求。能自动生成报表、表格、图形等。

16 常用的编码语言 基础语言 结构化语言 面向对象语言 FORTRAN COBOL BASIC Pascal C Ada C++ Java C#
(1)C++语言：诞生于1983年。C++既可以进行过程化程序设计，也可以进行面向对象程序设计。 (2)Java语言：诞生于1995年。它是一种面向对象、跨平台、分布式的语言。 (3)C#语言：微软于2000年提出的一种源于C++、类似于Java的面向对象编程语言，适合于分布式环境中的组件开发。C# 是专门为.NET设计的，也是.NET编程的首选语言。

17 编码语言的选择 程序设计语言的选择 要为待开发项目选择合适的程序设计语言，应充分考虑到项目的各种需求，结合各种语言的心理特性、工程特性、技术特性以及应用特点，尽量选取实现效率高且易于理解和维护的语言。

18 适用各类应用领域的语言 年代 应用领域 主要语言 其他语言 20世纪60年代 商业 COBOL Assembler 科学计算 FORTRAN
ALGOL,BASIC,APL 系统 Forth 人工智能 LISP SNOBOL 现代 COBOL、C++、Java、电子表格 C、PL/1 FORTRAN、C、C++、Java BASIC C、C++、Java Ada、Modula LISP、Prolog

19 编码工具 基于4GL的编码工具 Eclipse NetBeans Visual Studio Delphi Powerbuilder

20 4. 测试的基本概念 软件测试 测试的目的与任务 纠错的目的与任务 动态查找程序代码中的各类错误和问题的过程 目的：发现程序的错误；
任务：通过在计算机上执行程序，暴露程序中潜在的错误。 纠错的目的与任务 目的：定位和纠正错误； 任务：消除软件故障，保证程序的可靠运行。

21 测试和纠错信息流程 测试用例 期望结果 测试 评价 纠错 软件 测试结果 错误信息 改正信息

22 测试的特性 挑剔性 复杂性 不彻底性 经济性 只有抱着为证明程序有错的目的去测试，才能把程序中潜在的大部分错误找出来
设计测试用例是一项需要细致和高度技巧的工作 不彻底性 程序测试只能证明错误的存在，但不能证明错误不存在 经济性 选择一些典型的、有代表性的测试用例，进行有限的测试

23 测试的种类 静态分析器 （自动工具） 代码评审 “办公桌”检查 （人工方式） 会审 静态测试 走查（排查） （程序不执行） 动态测试
软件测试方法的分类 软件测试 静态测试 （程序不执行） 动态测试 （程序执行） “办公桌”检查 会审 走查（排查） 静态分析器 （自动工具） 代码评审 （人工方式） 黑盒测试（测试功能） 白盒测试（测试结构）

24 8.4.4 测试的文档 ●测试阶段的主要文档：测试计划和测试报告。 (1)测试计划(Testing Plan):主体是测试内容说明，包括测试项目名称、各项测试的目的、步骤、进度以及测试用例的设计等。 (2)测试报告(Testing Report):主体是测试结果说明，包括测试项目名称、实测结果与期望结果的比较，发现的问题，以及测试达到的效果等。 ●测试用例＝{测试数据 + 期望结果} ●测试结果={测试数据 +期望结果 + 实际结果}

25 软件测试过程 测试过程和项目开发过程完全平行，并有机地交互 将测试出的问题纳入项目的风险和进度分析中，以调整下一步的开发和测试活动
先做测试需求和设计，再后才是测试实施

26 5. 黑盒测试和白盒测试 黑盒测试 白盒测试 根据被测试程序功能来进行测试 以程序结构为依据的测试方法 等价分类法 边界值分析法 错误猜测法
逻辑覆盖法 路径测试法

27 8.5.1 黑盒测试( Black Box Testing )
1. 等价分类法 （Equivalence Partitioning , 又称等价类划分） ●等价分类法就是把输入数据的所有可能值划分为若干等价类，使每类中的任何一个测试用例，都能代表同一等价类中的其他测试用例。

28 (1)划分等价类不仅要考虑代表有效输入值的有效等价类,还须考虑代表无效输入值的无效等价类。
●划分等价类要注意两点： (1)划分等价类不仅要考虑代表有效输入值的有效等价类,还须考虑代表无效输入值的无效等价类。 (2)每一个无效等价类至少要用一个测试用例，不然就可能漏掉该类错误；但允许若干有效等价类合用同一个测试用例。

29 例8.1 某工厂招工报名程序。规定报名者的年龄应在16周岁至35周岁之间（算到2008年3月30日止，即出生年月在1973年2月至1992年3月之间；出生年月由6位数字组成，前4位代表年份，后2位代表月份）。系统对输入的报名者出生年月进行处理，若输入的出生年月不在上述范围内，显示输入错误信息。

30 解:第一步:划分等价类。 表1 等价分类表 输入条件 有效等价类 无效等价类 出生年月 ① 6位数字字符 ② 有非数字字符
表 等价分类表 输入条件 有效等价类 无效等价类 出生年月 ① 6位数字字符 ② 有非数字字符 ③ 少于6个数字字符 ④ 多于6个数字字符 数值对应 范围 ⑤ 在197302～ 之间 ⑥ <197302 ⑦ >199203 月份对应 ⑧ 在01～12之间 ⑨ 等于0 ⑩ >12

31 表2 测试用例表 测试数据 期望结果 测试范围 197511 输入有效 ① ⑤ ⑧ MAY, 75 19755 1978011 195512
表2 测试用例表 测试数据 期望结果 测试范围 197511 输入有效 ① ⑤ ⑧ MAY, 75 19755 195512 199606 198200 197522 输入无效 年龄不合格 ② ③ ④ ⑥ ⑦ ⑨ ⑩

32 ●划分等价类的几条准则： (1)如果规定了输入数据必须遵守的规则，则可以确定一个有效等价类（符合规则）和 若干个无效等价类(从不同角度违反规则)。 (2)如果输入条件规定了取值范围，则可以确定一个有效等价类（输入值在此范围内）和两个无效等价类（小于最小值或大于最大值）。

33 第二步:设计一个测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类；重复这一步，直到所有的有效等价类都被覆盖为止；
第三步:设计一个测试用例，使其仅覆盖一个无效等价类；重复这一步,直到所有的无效等价类都被覆盖为止。

34 黑盒测试 边界值分析法(boundary value analysis) 使被测程序在边界值及其附近运行，从而更有效地暴露程序中潜藏的错误

35 表8.6 “出生年月”的测试用例（边界值分析法）
表8.6 “出生年月”的测试用例（边界值分析法） 输入条件 测试用例说明 测试数据 期望结果 选取理由 出生年月 1个数字字符 5个数字字符 7个数字字符 有1个非数字字符 全部是非数字字符 6个数字字符 5 19705 19705A AUGUST 197302 输入无效 输入有效 仅有1个合法字符 比有效长度少1 比有效长度多1 非法字符最少 非法字符最多 类型与长度均有效 数值对应 范围 35周岁 16周岁 >35周岁 <16周岁 199203 197301 199204 合格年龄 不合格年龄 最大合格年龄 最小合格年龄 恰大于合格年龄 恰小于合格年龄 月份对应范围 月份为1月 月份为12月 月份< 1月 月份> 12月 197401 199112 197300 197413 最小月份 最大月份 恰小于最小月份 恰大于最大月份

36 错误猜测法 错误猜测法(error guessing) 猜测被测程序在哪些地方容易出错 针对可能的薄弱环节来设计测试用例
●以招工报名程序为例，在等价分类法和边界值分析法设计过的测试用例的基础上，再用错误猜测法补充一些例子： (1)输入出生年月均为“0”，即“000000”。 (2)输入的年月次序颠倒,如将“197512”误输为“121975”等。

37 8.5.2 白盒测试(White Box Testing)
●白盒测试：以程序的结构为依据来进行测试，又称结构测试（Structural Testing ）。 1.　逻辑覆盖测试法 （Logic Coverage Testing） ●逻辑覆盖测试法是以程序内部的逻辑结构（流程图）为基础来设计测试用例的技术。

38 逻辑覆盖测试由弱到强分为 5 种覆盖标准: 1. 语句覆盖 （ Statement Coverage ） 2. 判定覆盖（ Judgement Coverage ） 3. 条件覆盖（ Condition Coverage ） 4. 判定／条件覆盖（ Judgement /Condition Coverage ） 5. 条件组合覆盖（ Condition Combination Coverage ）

39 表8.7 逻辑覆盖测试的 5 种标准 语句覆盖 每条语句至少执行一次 判定覆盖 每一判定的每个分支至少执行一次 条件覆盖
表8.7 逻辑覆盖测试的 5 种标准 语句覆盖 每条语句至少执行一次 判定覆盖 每一判定的每个分支至少执行一次 条件覆盖 每个判定中的每个条件的“真”、“假”至少各执行一次 判定／条件 覆盖 同时满足判定覆盖和条件覆盖的要求 条件组合覆盖 每个判定中所有条件的各种可能组合值至少执行一次

40 表8.8 5种逻辑覆盖标准示例 覆盖 标准 程序结构 举例 测试用例应 满足的条件 语句覆盖 ① A∧B= .T. 测试用例取:
表 种逻辑覆盖标准示例 注：①A和B表示“条件表达式”,比如：A为 “a>1”,B 为 “b=0”; ②∧（或and ）表示“逻辑与”，比如 A∧B 或(a>1)and(b=0) 。 覆盖 标准 程序结构 举例 测试用例应 满足的条件 语句覆盖 ① A∧B= .T. 测试用例取: a=2, b=0 A∧B T F

41 注：条件表达式：A 为 （a>1）, B 为 （b=0）;
覆盖 标准 程序结构 举例 测试用例应 满足的条件 判定 ① A∧B= .T. a=2, b=0 ② A∧B= .F. a=2, b=1 A∧B F T

42 注：条件表达式：A 为 （a>1）, B 为 （b=0）;
覆盖 标准 程序结构 举例 测试用例应 满足的条件 条件 ① A= .T. , B= .T. a=2, b=0 ② A= .F. , B= .F. a=1, b=1 或 ① A= .T. , B= .F. a=2, b=1 ② A= .F. , B= .T. a=1, b=0 A∧B T F

43 注：条件表达式：A 为 （a>1）, B 为 （b=0）;
覆盖 标准 程序结构 举例 测试用例应 满足的条件 判定／ 条件 ① A= .T. , B= .T. A∧B= .T. a=2, b=0 ② A= .F. , B= .F. A∧B= .F. a=1, b=1 A∧B T F

44 注：条件表达式：A 为 （a>1）, B 为 （b=0）;
覆盖 标准 程序结构 举例 测试用例应 满足的条件 条件 组合 ① A= .T. , B= .T. a=2, b=0 ② A= .T. , B= .F. a=2, b=1 ③ A= .F. , B= .T. a=1, b=0 ④ A= .F. , B= .F. a=1, b=1 A∧B T F

45 表8.8 覆盖标准 测试数据 条件 a>1 b=0 判定 语句覆盖 ① a=2, b=0 T T T 判定覆盖 a=2, b=0
(a>1) and (b=0) F 3 覆盖标准 测试数据 条件 a>1 b=0 判定 语句覆盖 ① a=2, b=0 T T T 判定覆盖 a=2, b=0 a=2, b=1 T F F 条件覆盖(1) (满足判定覆盖) a=1, b=1 F F 条件覆盖(2) (不满足判定覆盖) a=1, b=0 F T

46 表8.8 覆盖标准 测试数据 条件 a>1 b=0 判定 判定/条件覆盖 a=2, b=0 a=1, b=1 T T F F T F
(a>1) and (b=0) F 表8.8 3 覆盖标准 测试数据 条件 a> b=0 判定 判定/条件覆盖 a=2, b=0 a=1, b=1 T T F F T F 条件组合覆盖 a=2, b=1 a=1, b=0 T F F T

47 ●5 种覆盖标准发现错误的能力 （弱 －> 强）: 语句覆盖 < 判定覆盖 <
●5 种覆盖标准发现错误的能力 （弱 －> 强）: 语句覆盖 < 判定覆盖 <? 条件覆盖 < 判定/条件覆盖 < 条件组合覆盖

48 补充例: c = d = 0 输入 a, b, x 1 2 T (a>1) and (b=0) 3 F c = 1 T
(a=2) or (x>1) 4 5 F d = 1 输出 c, d

49 1. 语句覆盖的测试用例为: (1) a=2 , b=0 , x=3 (通过路径124，期望结果：c=1,d=1 ) 2
1.语句覆盖的测试用例为: (1) a=2 , b=0 , x=3 (通过路径124，期望结果：c=1,d=1 ) 2.判定覆盖的测试用例为: (1) a=3 , b=0 , x=1 (通过路径125，期望结果：c=1,d=0 ) (2) a=2 , b=1 , x=2 (通过路径134，期望结果：c=0,d=1 )

50 3.条件覆盖的测试用例为: (1) a=2 , b=0 , x=2 (满足a＞1, b＝0, a＝2,x ＞1; 通过路径124) (2) a=1 , b=1 , x=1 (满足a≤1, b≠0, a≠2, x≤1; 通过路径135) 这两组用例,既满足条件覆盖,也满足判定覆盖。但若选择另两组用例: (1) a=1 , b=0 , x=2 (满足a≤1, b＝0, a≠2, x＞1 ; 通过路径134) (2) a=2 , b=1 , x=1 (满足a＞1, b≠0, a＝2, x≤1 ; 通过路径134) 这两组用例, 满足条件覆盖,但不满足判定覆盖。所以，满足条件覆盖不一定满足判定覆盖。 4.判定／条件覆盖的测试用例为:

51 5.条件组合覆盖是指：设计测试用例，使得每个判定的所有可能的条件取值组合至少执行一次。 上述程序中，共有2个判定。每个判定有2个条件，条件取值组合为 22=4 组。2个判定的所有可能的条件取值组合为 8 组： ① a＞1, b＝0 ② a＞1, b≠0 ③ a≤1, b＝0 ④ a≤1, b≠0 ⑤ a＝2, x＞1 ⑥ a＝2, x≤1 ⑦ a≠2, x＞1 ⑧ a≠2, x≤1 下面 4 组测试用例可以满足条件组合覆盖标准: (1) a=2 ,b=0 ,x=2 (覆盖条件组合①和⑤) (2) a=2 ,b=1 ,x=1 (覆盖条件组合②和⑥) (3) a=1 ,b=0 ,x=2 (覆盖条件组合③和⑦) (4) a=1 ,b=1 ,x=1 (覆盖条件组合④和⑧)

52 2. (基本)路径测试法 ( Basic Path Testing ) ●路径测试是对程序中每一条可能的执行路径至少测试一次。 ●基本路径测试是通过分析程序图的环路复杂性，导出基本路径集合，使集合中的每一条独立路径至少测试一次。

53 (1) 程序图 (Program Graph）, 又称程序控制流图（Control Flow Graph)
●程序图是一种简化了的程序流程图。 ●程序图中，符号○为结点，表示程序流程图中不同形状的框；箭头为边，表示控制流的方向。

54 (a) 流程图 (b) 程序图 图 程序图和流程图的对照

55 ①顺序执行的多个结点，在程序图中可以合并画成一个结点。 ●以上画法表明，程序图关心的是程序中的判定框，而不是顺序执行部分的细节。
两点需要说明: ①顺序执行的多个结点，在程序图中可以合并画成一个结点。 图 合并结点的程序图 ●以上画法表明，程序图关心的是程序中的判定框，而不是顺序执行部分的细节。

56 ②含有复合条件的判定框，先分解成几个简单条件判定框，再画程序图。
T F T F A≥B A＞B P Q T A=B F P P Q 图8.8 分解复合条件的结点

57 图8.5 冒泡排序(插入排序)的程序流程图 排序开始 A[1] A[2] A[3] A[4] 流程图中，K为数组元素的个数 8 6 9 4
流程图中，K为数组元素的个数 I = 2 T I = I +1 I > K F T A[I] ≥A[I-1] F J = I 排序结束 T J < 2 F T A[J] ≥A[J-1] J = J-1 F A[J] 交换A[J-1] 图8.5 冒泡排序(插入排序)的程序流程图

58 (AE) (AE) (AE) (AE) (a) (b) 图 根据图8.5流程图导出的程序图

59 (2)路径测试的特征 ①路径测试可以满足结构测试的最低要求 ●语句覆盖加判定覆盖是对白盒测试的最低要求。 ●在程序图上，语句覆盖称为点覆盖，判定覆盖称为边覆盖，同时满足点覆盖和边覆盖的覆盖称为完全覆盖。 ●满足了路径测试，就必然满足完全覆盖。

60 图 8.10 设计测试路径 测试路径 覆盖结点／边 覆盖标准 acd ①, ②, ③, ④ 点覆盖 acd, be
a, b, c, d, e 边覆盖 ae, bcd 路径覆盖 1 a b 2 c 3 e d (b) 4 图 设计测试路径 (a)

61 (补充： 路径测试举例) 下面 4 组测试用可以满足路径覆盖标准: a=2 , b=0 , x=2 （通过路径124）
（通过路径134） a=3 , b=0 , x=1 （通过路径125） a=1 , b=1 , x=1 （通过路径135） c = d = 0 输入 a, b, c 1 T 2 (a>1) and (b=0) 3 F c = 1 T (a=2) or (x>1) 4 5 F d = 1 输出 c, d

62 (2) 设计该程序的测试用例(结合边界值)，要求满足判定覆盖。
10. 设有下列程序 START INPUT（A, B, C） IF A＞５ THEN X=10 ELSE X=1 ENDIF IF B＞0 THEN Y=20 ELSE Y=2 IF C＞５ THEN Z=30 ELSE Z=3 PRINT （X, Y, Z） STOP (1) 画出该程序的程序流程图。 (2) 设计该程序的测试用例(结合边界值)，要求满足判定覆盖。 测试用例的格式如下 测试数据 覆盖的判定 输出 A>5 B>0 C>5

63 7. 多模块程序的测试策略 测试的层次性 单元(模块)测试（unit testing）
组装(集成)测试（integration testing） 确认测试（validation testing） 系统测试（system testing） (1)单元测试：测试每个单独的模块，又称模块测试。 (2)集成测试：通过了单元测试的模块，按照一定的策略组装为完整的程序，在组装过程中进行测试，又称组装测试。 （3）确认测试：用于确认组装完毕的程序确能满足用户的全部需求。 （4）系统测试：检查当被测程序安装到系统上以后，与系统的其他软、硬件能否协调工作，并完成系统说明书规定的任务。

64 图 8.16 层次测试的信息流程 软件 设计信息 被测 模块 系统其他成分 软件需求 信息 单元 测试 被测 模块 单元 测试 集成 测试
确认 测试 系统 测试 已集 成的 软件 已确 认的 软件 可运行的系统  已经过 测试的 模块 被测 模块 单元 测试 (1)单元测试：测试每个单独的模块，又称模块测试。 (2)集成测试：通过了单元测试的模块，按照一定的策略组装为完整的程序，在组装过程中进行测试，又称组装测试。 （3）确认测试：用于确认组装完毕的程序确能满足用户的全部需求。 （4）系统测试：检查当被测程序安装到系统上以后，与系统的其他软、硬件能否协调工作，并完成系统说明书规定的任务。 图 层次测试的信息流程

65 单元测试 目的 任务 通过模块测试，使其代码达到模块说明书的需求 (1) 对模块代码进行编译，发现并纠正其语法错误；
(2) 进行静态分析，验证模块结构及其内部调用序列是否正确； (3) 确定模块的测试策略，并据此设计一组测试用例和必要的测试软件； (4) 用选定的测试用例对模块进行测试，直至满足测试终止标准为止； (5) 编制单元测试报告。 单元测试是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。

66 (1)由单元的编码者负责实施。优点是，他对单元的结构与功能最熟悉，容易设计出符合需要的测试用例。
2.实施步骤 ●单元测试的实施步骤简述为： 静态分析器检查 编译 代码评审 动态测试 ●单元测试的人员： (1)由单元的编码者负责实施。优点是，他对单元的结构与功能最熟悉，容易设计出符合需要的测试用例。 (2)由单元的设计者负责实施。他同样对单元比较熟悉，又可以避开编码者怕揭露自己程序弊病的心理。 3.代码评审： ●包括代码会审、代码走查和办公桌检查(桌前检查)。组织良好的代码评审可以发现30%～70%的设计和编码错误。 桌前检查（Desk Checking）:由程序员自己检查自己编写的程序。 代码会审（Code Reading Review）:由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。 走查（Walkthroughs）:走查小组集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。

67 ●模块不是独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些替身模块去模拟与被测模块相联系的其他模块。
4.测试模块 ●模块不是独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些替身模块去模拟与被测模块相联系的其他模块。 (1)驱动模块 (Driver):代替上级模块的替身模块。 (2)桩模块 (Stub)：代替下级模块的替身模块。 替身模块应该是真实模块的简化，仅需模拟与被测模块直接相关的一部分功能。

68 测试用例 驱动模块 测试结果 被测模块 桩模块 桩模块 桩模块

69 ●目的：将通过了单元测试的模块组装成具有良好一致性的完整的系统。
1.集成测试的目的与任务 ●目的：将通过了单元测试的模块组装成具有良好一致性的完整的系统。 ●任务： ①制定集成测试的实施策略(自顶向下、或由底向上、或二者混合)。 ②确定集成测试的实施步骤，设计测试用例。 ③进行测试。 2. 策略与步骤 通过了单元测试的模块，要按照一定的策略组装为完整的程序，在组装过程中进行的测试，称为集成测试或组装测试。 为什么模块经过了单元测试，组装中还会出现问题呢？因为： ① 单元测试中使用了替身模块，它们与所代表的模块并不完全等效。 ② 各模块之间可能有比较复杂的接口,各模块连接起来的时候，穿越模块接口的数据可能会丢失； ③在单个模块中可以允许的误差，组装后的累积误差可能会放大，从而达到不能容忍的程度。

70 (1)自顶向下测试：从顶模块开始，沿结构图逐步向下测试。
①先广后深（宽度优先）： 组装顺序为： M1 — M2 — M3 — M4 — M5 — M6 — M7 — M8 ②先深后广（深度优先） M1 — M2 — M5 — M8 — M6 — M3 — M4 — M7 M1 M2 M3 M4 M5 M6 M7 M8 图8.17 一个简单的多模块SC图

71 ●自顶向下测试要使用桩模块 。图8.18显示了采取“先深后广”步骤时所需桩模块的配置情况。（Si表示桩模块）
M1 M1 S3 M2 S3 S4 S2 S4 S5 S6 M1 M2 S3 S4 M1 M2 M3 M4 M5 S6 M5 M6 S7 S8 图8.18 先深度后广度的测试 M8

72 ①从下层模块中找出一个没有下级模块的模块，由下向上地逐渐增加新模块,组成一个子系统或模块“群”。
(2)自底向上测试：从程序模块结构的最底层的模块开始集成和测试。其步骤为： ①从下层模块中找出一个没有下级模块的模块，由下向上地逐渐增加新模块,组成一个子系统或模块“群”。 ②从另一个子系统或模块“群”中选出一个没有下级模块的模块，仿照前一步组成又一个子系统。 ③重复上一步，直至得出所有的子系统，再把它们组装为完整的系统。 M1 模块组装顺序可能是： M8 — M5 — M6 — M2; M7 — M4 — M3 — M1; 再合并以上两个群。 M2 M3 M4 M5 M6 M7 M8

73 ●自底向上测试要使用驱动模块。下图显示自底向上测试所需驱动模块的配置情况。(di表示驱动模块)
(a) (b) (c) d1 d2 d5 M2 M5 M6 M8 M5 M6 M8 M8 (e) (f) M1 (d) d1 M2 M3 M4 d4 M3 M4 M7 M5 M6 M7 M7 M8

74 (3)混合式测试(Sandwich Testing, 三明治测试)：它是上述两种测试方式的结合。其步骤为： ①对上层模块采用自顶向下测试；
②对关键模块或子系统采用由底向上测试。 集成测试的人员： 由独立于开发人员的测试小组负责实施。 ●以上3种测试的策略都是从一个模块开始，测一次添一个模块，使组装程序像“滚雪球”一样越滚越大，所以统称为“渐增式测试 ( Incremental Testing )”。 ●早期的小规模的程序也使用过“非渐增式测试(Non-Incremental Testing)”的策略，即把已通过单元测试的所有模块，一次性地组装在一起，进行集成测试。

75 优点：能较早显示整个程序的轮廓，向用户展示程序的概貌，取得用户的理解和支持。
3. 几种策略的比较 (1)自顶向下测试 优点：能较早显示整个程序的轮廓，向用户展示程序的概貌，取得用户的理解和支持。 缺点：需要设计较多的桩模块，桩模块很难模拟出真实模块的全部功能，因此许多测试要推迟到换上真实模块后，在补充测试。 (2)自底向上测试 优点：不需要设计桩模块，只需要设计驱动模块，驱动模块的设计比较容易，设计测试用例也比较容易。 缺点：在测试的早期不能显示整个程序的轮廓。 (3)混合测试的优点：综合了以上两种策略的长处。

76 8.7.4 确认测试（Validation Testing) ●确认测试首先要进行有效性测试和软件配置复审，然后进行验收测试。
1.有效性测试（黑盒测试）和配置复审 (1)有效性测试：有效性测试是在模拟环境 (开发环境) 下，运用黑盒测试的方法，确认组装完毕的程序是否满足软件需求规格说明书的要求。 (2)配置复审( Configuration Review )：查明文档是否配齐，以及文档内容的一致性等。 有效性测试和配置复审由独立的测试小组负责实施。

77 2. 验收测试(Acceptance Testing)
在通过了系统的有效性测试及配置审查之后，就应开始系统的验收测试。验收测试是以用户为主的测试（但软件开发人员人员也应参加），由用户设计测试用例，使用生产中的实际数据进行测试。

78 (1) α测试： α测试是在受控环境(模拟环境、开发环境)下，由用户在开发者的指导下进行的测试，由开发者负责记录错误和使用中出现的问题。
3. α与β测试 (1) α测试： α测试是在受控环境(模拟环境、开发环境)下，由用户在开发者的指导下进行的测试，由开发者负责记录错误和使用中出现的问题。 (2) β测试： β测试是由用户在自己的场所(真实环境下)进行的，开发者通常不在场，测试中遇到的问题均由用户记录，并定期报告给开发者，由开发者对软件进行最后的修改。 通过β测试后，就可以发布最终的软件产品。 3. α与β测试 ●如果一个软件是给很多客户使用的（例如Office 软件），让每一个客户都进行验收测试显然是不切合实际的，则可采用α测试与β测试。

79 系统测试 目的 任务 软件安装到系统中以后，能否与系统的其余部分协调运行 测试是否与硬件协调运行 测试是否和原来就有的其它软件协调运行
测试是否完成SRS对它的要求 ●系统测试是将通过确认测试的软件，作为整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行的测试。 ●系统测试的目的在于通过与系统的需求定义作比较,发现软件与系统需求不符合或与之矛盾的地方。 ●系统测试是验收工作的一部分，由用户单位组织实施。

80 终止测试的标准 规定测试策略和应达标准 规定至少要查出的错误数量
白盒测试时一般可规定以完全覆盖为标准语句覆盖率和判定覆盖率必须分别达到100% 黑盒测试时，可选择一或数种方法设计测试用例，当所有测试用例全部用完后便可终止 规定至少要查出的错误数量 把查出预定数量的错误，作为某类应用程序的测试终止标准

81 小结 编码的目的是把详细设计的结果翻译成用选定的语言书写的源程序；编码的风格和使用的语言，对编码质量也有重要的影响。
软件测试是一个与项目开发过程并行的过程 测试的目的是发现程序的错误，而不是证明程序没有错误 设计测试用例错，是搞好软件测试的关键技术 ，选择测试用例的目标，是用尽可能少的测试数据，达到尽可能大的程序覆盖面，发现尽可能多的软件错误和问题

82 例题补充1 假设汽车的车牌号可由车主人在规定范围内自选，若规定为： （1） 车牌上应有7个字符； （2） 为首的字符限定为汉字“京”；
（1） 车牌上应有7个字符； （2） 为首的字符限定为汉字“京”； （3）第2字符可任选一字母（A～Z）； （4）第3～7字符可选任意数字。 请为相关的处理程序所采用的等价类划分方法设计等价类表及相应的测试用例。

83 例题补充2 2．某商场在“五一”期间，顾客购物时收费有4种情况：普通顾客一次购物累计少于100元，按A类标准收费（不打折），一次购物累计多于或等于100元，按B类标准收费（打9折）；会员顾客一次购物累计少于1000元，按C类标准收费（打8折），一次购物累计等于或多于1000元，按D类标准收费（打7折）。 (1)画出被测模块的程序流程图 （2）测试对象是按以上要求计算顾客收费模块，按照路径覆盖法设计测试用例。