第七章 测 试 (Testing) 防不胜防的软件错误 —— 例2：1996年，美国 Washington Post 报导

Presentation on theme: "第七章 测 试 (Testing) 防不胜防的软件错误 —— 例2：1996年，美国 Washington Post 报导"— Presentation transcript:

1 第七章 测 试 (Testing) 防不胜防的软件错误 —— 例2：1996年，美国 Washington Post 报导
例1：1963年, 美国, 飞往火星的火箭爆炸, 损失$ 10 million 原因: FORTRAN循环 DO 5 I = 1, 3 误写为 DO 5 I = 1.3 例2：1996年，美国 Washington Post 报导 Dallas, Aug. 23 — The captain of an American Airlines jet that crashed in Colombia last December entered an incorrect one-letter computer command that sent the plane into a mountain, the airline said today.

2 第七章 测 试. The crash killed all but four of the 163 people aboard. American’s investigators concluded that the captain of the Boeing 757 apparently thought he had entered the coordinates for the intended destination, Cali. But on most South American aeronautical charts, the one-letter code for Cali is the same as the one for Bogota, 132 miles in the opposite direction. The coordinates for Bogota directed the plane toward the mountain, according to a letter by Cecil Ewell, American’s chief pilot and vice president for flight. The codes for Bogota and Cali are different in most computer databases, Ewell said.

3 例3：[摘自Pfleeger 书中的“REAL-TIME EXAMPLE”]
第七章 测 试. 例3：[摘自Pfleeger 书中的“REAL-TIME EXAMPLE”] Our real-time example is based on the embedded software in the Ariane-5, a space rocket belonging to the European Space Agency (ESA). On June 4, 1996, on its maiden flight, the Ariane-5 was launched and performed perfectly for approximately 40 seconds. Then, it began to veer off course. At the direction of an Ariane ground controller, the rocket was destroyed by remote control. The destruction of the uninsured rocket was a loss not only of the rocket itself, but also of the four satellites it contained; the total cost of the disaster was $500 million.

4 第七章 测 试. The business impact of the incident went well beyond the $500 million in equipment. In 1996, the Ariane-4 rocket and previous variants held more than half of the world’s launch contracts, ahead of American, Russian, and Chinese launchers. Thus, the credibility of the program was at stake, as well as the potential business from future Ariane rockets. Cause: There was no discussion in the SRI (Inertial Reference System) requirements documents of the ways in which the Ariane-5 trajectory would be different from Ariane-4.

5 第七章 测 试. 软件测试是保证软件质量的关键步骤，是对软件规格说明、设计和编码的最后复审，其工件量约占总工作量40%以上（对于人命关天的情况，测试相当于其它部分总成本的3 — 5倍）。

6 §1. 基本概念 1、定义：测试是为了发现程序中的错误而执行程序的过程。 注意：① 只能尽可能查错，不能证明程序中 没有错；
② 测试员与程序员不应是同一个人。 2、黑盒和白盒测试  黑盒测试(black-box , or closed-box testing): Make sure that every kind of input is submitted, and the output observed matches the output expected —— Functional testing

7  白盒测试(white-box , or open-box, clear-box testing):
§1. 基本概念  白盒测试(white-box , or open-box, clear-box testing): Use the structure of the program to test —— Structural testing 主要问题：穷尽测试(complete test)通常是不可能的。 例：(Black-box) 程序要求输入3个整形数据。若字长16位，则各种可能输入的排列组合共有 （种） 若程序执行需10-3秒，则对于所有合法输入的测试大约需用一万年，而且还应测试输入非法数据的情况。

8 例：(White-box) 下图所示的程序中共有 5201014条可能的执行通路，显然，每条通路都执行一遍是不现实的。
§1. 基本概念 例：(White-box) 下图所示的程序中共有 5201014条可能的执行通路，显然，每条通路都执行一遍是不现实的。 循环20次

9 §1. 基本概念 3、测试步骤： (1) Component testing —— program design & coding bugs
(2) Subsystem testing —— connections between modules (3) System testing —— requirements & system design (4) Acceptance testing —— customer joins in (5) Parallel running —— compare the new system with the old one. Integration testing 测试阶段的信息流： 测试 评价 调试 可靠性 模型 软件配置 测试配置 测试结果 可靠性预测 错 误 正 确 错误率数据 预期结果

10 §2. 单元测试（白盒） 主要测试以下五个方面： 1、模块接口： 2、局部数据结构：
§2. 单元测试（白盒） 主要测试以下五个方面： 1、模块接口：  内部检查：传输参数的数目、属性、单位、次序是否匹配；全程变量的定义是否一致；只做输入的变元有无被修改，等等。  外部检查：打开、结束、关闭文件的操作；文件和属性；I\O错误处理；输出拼写，等等。 2、局部数据结构： 数据说明(declaration)；初始化与缺省值的设置；变量名拼写；数据类型的相容性；上\下溢出及地址异常，等等。

11 由于穷尽测试不可能，故通常针对最常见的错误设计测试方案。较常见的错误有： 计算次序问题 不同类型混合运算（例：比较类型不同的量）
§2.单元测试 3、重要的执行通路： 由于穷尽测试不可能，故通常针对最常见的错误设计测试方案。较常见的错误有： 计算次序问题 不同类型混合运算（例：比较类型不同的量） 初值设置错误 精度问题（例：精度不够导致两变量不可能相等，而程序中等待相等条件的出现） 表达式错误 循环终止条件错误（例：次数差1，或陷入死循环）

12 预见出现错误的条件，设置处理。较常见的问题有：
§2.单元测试 4、出错处理通路： 预见出现错误的条件，设置处理。较常见的问题有：  输出的错误信息难以理解，不能确定错误位置  描述的错误与实际错误不符  处理之前系统已经干预  处理不正确

13 轻松一分钟  — True Tech Support Stories
§2.单元测试 轻松一分钟  — True Tech Support Stories A tech once calmed a woman who was enraged because "her computer had told her she was bad and an invalid." The tech patiently explained that the computer's "bad command" and "invalid" responses shouldn't be taken personally. A guy was perplexed by an error that would appear every time he tried to print. The computer would say, "Looking for LaserWriter" and after a while, "Can't find LaserWriter." His solution? He turned the Mac so that the screen faced the printer. 5、边界条件 —— 单元测试中最后，也可能是最重要的任务，因为软件常在其边界失效。

14 1、代码审查(code inspection)
§2.单元测试 单元测试的主要手段 ： 1、代码审查(code inspection)  Walk-through: 例如 Lucent Technologies 的测试策略，是由三人一组(包括 author, reader, 和recorder)，逐行检查源代码。  Rehearsal：由人扮演computer，模拟执行情况。 优点: 一次审查可发现多个错误，不必改一个测一个。 2、制做测试软件：Stub （存根）和 Driver（驱动）软件的编写，属额外开支。模块高内聚可简化这一过程。

15 §3. 集成测试 (Integration Testing)
1、非渐增式测试 (Big-bang testing) Test A, B, C, D Test A B C D

16 2、渐增式测试 (Incremental testing)
§3.集成测试 2、渐增式测试 (Incremental testing) 两种方式的比较：  Incremental testing 可以较早发现模块间的接口错误；Big-bang testing 最后才组装，因此错误发现得晚。  Big-bang testing 中发现错误后难以诊断定位； Incremental testing 中，出现的错误往往跟最新加入的模块有关。  Incremental testing 在不断集成的过程中使模块不断在新的条件下受到新的检测，测试更彻底。  Incremental testing 较 Big-bang testing 费时。 Big-bang testing 可以同时并行测试所有模块，能充分利用人力。

17 3、Incremental testing 的几种策略
§3.集成测试 3、Incremental testing 的几种策略 ⑴ Top-down testing 第1步：测试顶端模块，用存根程序(stub)代替直接附属的下层模块 Stub: to simulate the activity of the component which is not yet tested. M S1 S2

18 第2步：根据深度优先或宽度优先的策略，每次用一个实际模块代换一个stub。
§3.集成测试 第2步：根据深度优先或宽度优先的策略，每次用一个实际模块代换一个stub。 M M1 S1 S2 S2 M2 S3 S4 第3步：在结合进一个模块的同时进行测试。 第4步：回归测试(regression testing)——全部或部分地重复以前做过的测试。

19 NOT DOING REGRESSION TESTING
§3.集成测试 THE CONSEQUENCES OF NOT DOING REGRESSION TESTING Seligman (1997) and Trager (1997) reported that 167,000 Californians were billed $667,000 for unwarranted local telephone calls because of a problem with software purchased from Northern Telecom. A similar problem was experienced by customers in New York City. The problem stemmed from a fault in a software upgrade to the DMS-100 telephone switch. The fault caused the billing interface to use the wrong area code in telephone company offices that used more than one area code. As a result, local calls were billed as long-distance toll calls. When customers complained, the local telephone companies told their customers that the problem rested with the long-distance carrier; then the long-distance carrier sent the customers back to the local phone company! It took the local phone companies about a month to find and fix the cause of the problem. Had Northern Telecom performed complete regression testing on the software upgrade, including a check to see that area codes were reported properly, the billing problem would not have occurred.

20 优点：在早期即对主要控制及关键的抉择进行检验。
§3.集成测试 优点：在早期即对主要控制及关键的抉择进行检验。 问题：Stub只是对低层模块的模拟，测试时没有重要的数据自下往上流，许多重要的测试须推迟进行，而且在早期不能充分展开人力。 ⑵ Bottom - up testing 第1步：把低层模块组合成族，每族实现一个子功能。 第2步：用驱动程序(Driver)协调测试数据的I\O，测试子功能族。 D M1 M2 Driver: to call a particular component and passes a test case to it.

21 第3步：去掉Driver，自下而上把子功能族合成更大的子功能族。
§3.集成测试 第3步：去掉Driver，自下而上把子功能族合成更大的子功能族。 M D 注意：两种策略的优、缺点刚好互补，但单用其中任一种都不实际，通常根据软件的特点将二者混用。 M D D M D M D M D M M M M M

22 §3.集成测试 ⑶ Sandwich testing Top-down Target layer Bottom-up

23 §4. 验收测试(Acceptance testing)
任务：验收软件的有效性（功能和性能达标）。 手段：黑盒测试；用户参与；主要用实际数据进行测试。 内容：按合同规定审查软件配置； 设计测试计划，使通过测试保证软件能满足所有功能、性能要求； 文档与程序一致，具有维护阶段所必须的细节； 严格按用户手册操作，以检查手册的完整性和正确性。

24 §5. 设计测试方案(Plan of testing)
任务：①预定要测试的功能 ②设计输入的测试数据(test cases) ③列出预期结果(expected output) 主要技术： 1、逻辑覆盖(Logical coverage) —— 适用于白盒测试 覆盖程度由弱到强顺次为： ⑴ 语句覆盖(Statement coverage):每个语句至少执行一次。

25 问题：若AND错写为OR，或X>1错写为X<1,则错误无法由上例测出。
§5. 设计测试方案 例：P.140 图7.6 入口 A > 1 AND B=0 T A=2 OR X > 1 X = X / A X = X + 1 返回 F Test case : A=2 , B=0 , X=4. 问题：若AND错写为OR，或X>1错写为X<1,则错误无法由上例测出。

26 ⑵判定覆盖(Branch coverage)：在⑴的基础上，每个判定的每个分支至少执行一次。
§5. 设计测试方案 ⑵判定覆盖(Branch coverage)：在⑴的基础上，每个判定的每个分支至少执行一次。 入口 A > 1 AND B=0 T A=2 OR X > 1 X = X / A X = X + 1 返回 F Test cases: ①A=3 , B=0 , X=3 ②A=2 , B=1 , X=1 问题：若X>1错写为X<1,仍然无法被测出。

27 ⑶ 条件覆盖(Condition coverage)：在⑴的基础上，使每个判定表达式的每个条件都取到各种可能的结果。
§5. 设计测试方案 ⑶ 条件覆盖(Condition coverage)：在⑴的基础上，使每个判定表达式的每个条件都取到各种可能的结果。 入口 A > 1 AND B=0 T A=2 OR X > 1 X = X / A X = X + 1 返回 F Test cases: ①A=2 , B=0 , X=4 （满足A>1, B=0; A=2, X>1) ②A=1, B=1, X=1 (满足A1, B0; A 2, X1） 问：条件覆盖 ？ 判定覆盖 答: 不一定。 反例: ①A=2, B=0, X=1 ②A=1, B=1, X=2 ⑷判定/条件覆盖：即判定覆盖条件覆盖

28 ⑸ 条件组合覆盖：每个判定表达式中条件的各种可能组合都至少出现一次。
§5. 设计测试方案 ⑸ 条件组合覆盖：每个判定表达式中条件的各种可能组合都至少出现一次。 全部可能的条件组合为： ① 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 入口 A > 1 AND B=0 T A=2 OR X > 1 X = X / A X = X + 1 返回 F Test cases: ① A=2, B=0, X=4 (T T) ② A=2. B=1, X=1 (F T) ③ A=1, B=0, X=2 (F T) ④ A=1, B=1, X=1 (F F) 问题：没有测试到（T F）的情形

29 考察control flow graph 的角度，还可考虑下述覆盖： ⑹ 点覆盖 = 语句覆盖
§5. 设计测试方案 考察control flow graph 的角度，还可考虑下述覆盖： ⑹ 点覆盖 = 语句覆盖 ⑺ 边覆盖 =判定覆盖 ⑻ 路径覆盖(Path coverage): 每条可能的路径都至少执行一次，若图中有环，则每个环至少经过一次。 Test cases: ① A=1 , B=1 , X=1 ② A=1 , B=1 , X=2 ③ A=3 , B=0 , X=1 ④ A=2 , B=0 , X=4 ⑼ 路径覆盖  条件组合覆盖 作业：P.162 #1 (3) , #2

30 2、等价划分(Equivalence Partitioning)
§5. 设计测试方案 2、等价划分(Equivalence Partitioning) —— 适用于黑盒测试 An equivalence class represents a set of valid or invalid states for input conditions , so that there is no particular reason to choose one element over another as a class representative. ⑴ 划分经验  当规定了输入范围时： 无效类 有效类 无效类  当规定了输入的一组值，且对不同值做不同处理时：例：教工分房方案中，按教授、副教授、讲师、助教分别计分  有效类4个；无效类1个

31 §5. 设计测试方案  当规定了输入的规则时： 例：(PASCAL) 语言规定，每个语句以“ ；” 结 束 有效类1个；无效类若干（以“ ，”结束、以“ ：”结束、以空格结束等等）  当输入为整型时：有效类可分为Z+、0、Z— 三种  当处理表格时：有效类可分为空表、含一项的表、含多项的表等 注：① 以上经验亦适用于输出数据； ② 不需要测试编译程序肯定能发现的错误。

32 ⑵ 设计步骤 §5. 设计测试方案  设计一个新方案以尽可能多地覆盖尚未被覆盖的有效等价类；重复这一步骤直到所有有效类都被覆盖为止。
 设计一个新方案以覆盖一个且仅一个尚未被覆盖的无效等价类；重复这一步骤直到所有无效类都被覆盖为止。（通常程序执行一个错误后即不继续检测其它错误，故每次只测一个无效类）

33 function StrToInt (dstr : shortstr) : integer;
§5. 设计测试方案 例：考察一个把数字串转变成整数的函数。用二进制补码表示整数，机器字长16位，即整数范围最小为 ，最大为32767。函数及参数的PASCAL说明如下： function StrToInt (dstr : shortstr) : integer; type shortstr = array [1..6] of char; 要求被处理的数字串是右对齐的，即在少于6个字符的串左边补空格。负号在最高位数字左边一位。 试用等价划分法设计测试方案。

34 解：首先根据规格说明划分等价类。考虑到PASCAL编译器的固有检错功能，测试时不需要使用长度不等于6的数组，也不需要用非字符数组类型的参数。
§5. 设计测试方案 解：首先根据规格说明划分等价类。考虑到PASCAL编译器的固有检错功能，测试时不需要使用长度不等于6的数组，也不需要用非字符数组类型的参数。 有效输入类： ①1~6个数字字符组成的数字串（最高位非0）； ②最高位为0的数字串； ③最高位左邻负号的数字串； 无效输入类： ④空字符串（6位空格）；⑤左边补位的既非0亦非空格； ⑥最高位右边含有空格； ⑦最高位右边含有其它非数字字符； ⑧负号与最高位间有空格；

35 ①1~6个数字字符组成的数字串，最高位非0；输出 为合法正整数。 输入： 预期输出：1
§5. 设计测试方案 有效输出类： ⑨ 在合法范围内的负整数； 10 11 0 ； 在合法范围内的正整数； 无效输出类： 小于 的负整数； 大于 32767正整数。 12 13 下面根据等价划分，设计出一套测试方案： ①1~6个数字字符组成的数字串，最高位非0；输出 为合法正整数。 输入： 预期输出：1 1 ②最高位为0的数字串，输出为合法正整数。 输入： 预期输出：1 1

36 ③负号与最高位数字相临；输出合法负整数。 输入： 预期输出：-1
§5. 设计测试方案 ③负号与最高位数字相临；输出合法负整数。 输入： 预期输出：-1 - 1 ④最高位为0；输出0。 输入： 预期输出：0 ⑤太小的负整数。 输入： 预期输出：“错误，无效输入” - 3 2 7 6 9 ⑥太大的正整数。 输入： 预期输出：“错误，无效输入” 3 2 7 6 8

37 - ⑦空字符串。 输入： 预期输出：“错误：没有数字” ⑧左边补位的非0也非空格。 输入： 预期输出：“错误：非法填充”
§5. 设计测试方案 ⑦空字符串。 输入： 预期输出：“错误：没有数字” ⑧左边补位的非0也非空格。 输入： 预期输出：“错误：非法填充” a 1 ⑨最高位右边也含空格。 输入： 预期输出：“错误：无效输入” 1 2 ⑩最高位右边含其它非数字字符。 输入： 预期输出：“错误：无效输入” 1 x 2 负号与最高位间有空格。 输入： 预期输出：“错误：负号位置非法” 11 - 1 2

38 3、边界值分析(Boundary Value Analysis) 注意：① 程序最容易在边界发生错误； ② 通常与等价划分结合进行。
§5. 设计测试方案 3、边界值分析(Boundary Value Analysis) 注意：① 程序最容易在边界发生错误； ② 通常与等价划分结合进行。 4、错误推测(Failure Prediction) 思路：① 列出可能有的错误； ② 列出容易发生错误的特殊情况。 以此为基础设计测试方案。 根据：直觉、经验 工具：常见错误清单、判定表等。

39 80%。 5、实用策略(Practical Strategies) 黑盒设计  白盒补充 ① 在任何情况下都应该使用边界值分析的方法；
§5. 设计测试方案 5、实用策略(Practical Strategies) 黑盒设计  白盒补充 ① 在任何情况下都应该使用边界值分析的方法； ② 必要时用等价划分法补充； ③ 必要时再用错误推测法补充； ④ 对照程序逻辑，检查测试方案。可根据对程序可靠性的要求采用不同的逻辑覆盖标准，必要时补充一些测试方案。 注: 即使用上述综合策略设计测试方案，仍不能保证发现一切错误。例如Lucent公司经过包括逐行检查源代码在内的多方面测试之后，其软件能达标运行的成功率为 80%。

40 §6.调 试(Debugging) 测试 —— 发现错误 调试 —— 改正错误 第1步：确定错误的位置(95%工作量)； 第2步：改正错误。
第1步：确定错误的位置(95%工作量)； 第2步：改正错误。 Failure（外错误）is the departure of a system from its required behavior. Fault（故障、内错误、error、bug）is resulted by human error in some software product. A program’s failure is clear symptom of the presence of a fault ; but not every fault corresponds to a failure , since the conditions under which a fault results in system failure may never be met.

41 Debugging §6.调 试 Test cases Debugging Execution of cases
Results Test cases Additional tests Suspected causes Regression tests Debugging Corrections Identified causes Debugging

42 ① 输出存储器内容(memory dump): 以八进制或十六进制的形式印出存储器的内容。 缺点：
§6.调 试 1、调试技术 ① 输出存储器内容(memory dump): 以八进制或十六进制的形式印出存储器的内容。 缺点：  输出信息量极大， 不易解读且大多无用；  输出的是程序在某一 时刻的静态情况，且 往往不是出错时的状态。

43 ② 插入“watch points”(或称“spy points”)
§6.调 试 ② 插入“watch points”(或称“spy points”)  人工插入打印 缺点：  改动源代码，增加了出错机会；  打印信息可能太多。  自动调试工具 —— 无须打印额外信息，且不改 动源代码

44 2、调试策略 调试过程的关键不是调试技术，而是用来推断错误原因的基本策略。主要有：
§6.调 试 2、调试策略 调试过程的关键不是调试技术，而是用来推断错误原因的基本策略。主要有： ① 试探法，凭经验猜测。 ② 回溯法：由症状(symptom)最先出现的地方，沿control flow向回检查。适用于小型程序。 ③ 对分法：在关键点插入变量的正确值，则： 输出正确 错误在前半段 错误在后半段 N Y

45 ④ 归纳法：从错误症状中找出规律，推断根源。
§6.调 试 ④ 归纳法：从错误症状中找出规律，推断根源。 不能 收集数据 组织数据 研究数据 间的关系 提出假设 不 能 能 证明假设 能 纠正错误

46 例：学生考试评卷报告。要求输出成绩排名、平均分、试题分析报告。
§6.调 试 例：学生考试评卷报告。要求输出成绩排名、平均分、试题分析报告。 发现错误：对51个学生评分  中间值为26（期望值80） 对1个学生评分  中间值为1 观察分析：取奇数时出错？ 打印的是中间学生的编号而非分数？ 加测试来验证上述推测。

47 ⑤ 演绎法：普通  特殊 从假设中逐步排除、精化，从而导出错误根源。
§6.调 试 ⑤ 演绎法：普通  特殊 从假设中逐步排除、精化，从而导出错误根源。 列举可能 的原因 排除不正确 的假设 精化余下 的假设 证明 假设 有剩余 能 无剩余 不能 收集更多数据 纠正 错误

48 §7. 软件可靠性(Reliability) 1、基本概念
 可用性(Usability)：程序在给定的时间点，按照说明书的规定，成功地运行的概率。  正确性(Correctness)：程序的功能正确。 Correctness Reliability Usability

49   设系统故障停机时间为td1, td2, …; 正常运行时间为tu1, tu2, … ; 则系统的“稳态可用性”为 §7. 软件可靠性
Availability = (Shooman, 1983) 其中 MTTF = Mean Time To Failure = MTTR = Mean Time To Repair =   tu1 td1 tu2 td2 t

50 EC( )为时间从0至 期间改正的错误数。
§7. 软件可靠性 2、估算 MTTF： MTTF = 其中：K为经验常数（典型值约在200左右）； ET为测试前故障总数； IT为程序长度（机器指令总数）；  为测试（包括调试）时间； EC( )为时间从0至 期间改正的错误数。 前提假设： ① ET / IT  Constant （通常为0.5 ~ 2%） ② 调试中没有引入新故障（即ET与时间无关） ③MTTF与剩余故障成反比

51 意义：可根据对软件平稳运行时间的要求，估算需改正多少个错误后才能结束测试。
§7. 软件可靠性 换个角度看问题 意义：可根据对软件平稳运行时间的要求，估算需改正多少个错误后才能结束测试。 还有一个问题 —— ET = ? 估算方法： ① 植入故障法： 人为植入NS个故障，测后发现ns个植入故障和n个原有故障，则设

52 §7. 软件可靠性 ② Hyman 分别测试法： 二人（组）分别独立测试同一程序，甲测得故障总数为B1，乙测得为B2，其中有bc是相同的，设以甲的测试结果为基准（即相当于①中的植入故障），则设 一般多测几个 取平均。

53 但是：即使有了正确性证明程序，软件测试也仍然是需要的。
§7. 软件可靠性 3、正确性说明 目标：研究能证明程序正确性的自动系统。 原理： a(i):断言(assertion) p1 p2 p3 pn-1 pn a(1) = input a(2) a(3) a(n-1) a(n) = output 证明：对任一个i，执行了pi到pi+1之间的语句后，可将a(i)变为a(i+1)，则证明由a(1)可导出a(n)。若a(1)和a(n)正确，且程序确定可终止，则证明程序正确。 … 但是：即使有了正确性证明程序，软件测试也仍然是需要的。 因为：①正确性证明只证明程序功能正确，但不能验证动态特性； ②证明过程本身也可能发生错误。

54 §8.日立预测法 日立预测法 —— 测试期间绘制并检查两种曲线 1、测试完成率曲线： 经验：
测试用例完成率 = 已完成用例 / 全部用例 100% 50% 经验： 工程的成败取决于第一阶段向第二阶段转移断点的位置，一般成功的工程其转折点位于15%；若超过55%则破产不可避免。 测试时间使用率 = 所用时间 / 总时间 第一阶段 第二阶段 第三阶段

55 2、错误发现率曲线： §8.日立预测法 经验： 刚过峰值点后曲线的导数关系到工程的成败。若导数值大于- 0.3，则失败不可避免。
错误发现率 = 单位时间内发现的错误数 时间 极坏的工程 成功的工程 失败的工程 峰值时间

56 其它可靠性预测模型(reliability prediction model)：
§8.日立预测法 其它可靠性预测模型(reliability prediction model)： 最早：Jelinski - Moranda model (1972) 最广泛应用：Musa model (1990) 最近：Fenton - Pfleeger model (1997)

57 §9. 自动测试工具 1、测试数据生成程序(Test case generator)： 功能：自动生成大量输入数据
主要用于：  测试系统在实际环境中的性能（例如测试数据 库管理系统）  自动校核系统输出(若输出数据的语法可以被形 式地说明) 缺点：不能自动生成预期的输出，因此用途有限。

58 2、动态分析程序(Dynamic analyzer) 功能：分析程序中每个语句的执行次数。
§9. 自动测试工具 2、动态分析程序(Dynamic analyzer) 功能：分析程序中每个语句的执行次数。 组成：  检测部分：插入检测语句，负责收集、整理语句执行次数；  显示部分：以容易理解的形式印出收集的信息。 用途：  发现测试中没有执行的语句，以增加相应的测试用例；  发现不按要求终结的循环；  发现不应执行却执行了的代码，及应执行而未执行的代码。

59 3、静态分析程序(Static analyzer) 不执行程序，仅扫描程序的正文，从中寻找可能导致错误的异常情况。
§9. 自动测试工具 3、静态分析程序(Static analyzer) 不执行程序，仅扫描程序的正文，从中寻找可能导致错误的异常情况。 4、文件比较程序(File inspector) 主要步骤： ⑴ 建立一个文件存放预期的正确结果； ⑵ 执行测试，将输出数据存进另一个文件； ⑶ 使用文件比较程序来比较上述两个文件，印出两者之差异。 作业：P.164 # 7