第四章 软件实现

1. 第四章 软件实现 • §4.1 编码 • §4.2 软件测试概述 • §4.3 软件测试的策略 • §4.4 测试用例的设计 • §4.5 面向对象的软件测试 • §4.6 软件调试 • §4.7 软件可靠性 • §4.8 软件测试CASE工具 主讲教师：李刚

2. 机器语言 低级语言 汇编语言 程序设计语言 基础语言 高级语言 结构化语言 专用语言 §4.1 编码 • 程序设计语言 • 1 程序设计语言的分类 主讲教师：李刚

3. §4.1 编码 • 2 程序设计语言的选择 • 一般来说，选择程序设计语言优先考虑高级语言。 • 在选择高级语言时以下因素是需要考虑的： • 1）语言自身的特点 • 2）软件的应用领域 • 3）软件的开发方法 • 4）软件的开发和执行环境 • 5）算法和数据结构的复杂性 • 6）软件的可移植性 • 7）软件开发人员的知识 • 8）用户的要求 主讲教师：李刚

4. §4.1 编码 • 编码风格 • 编码风格又称为编程风格，指的是编程的基本原则，良好的编码风格使编 • 写的程序在保证正确性和有效性前提下，易读易懂，便于维护。 • 编程的基本原则： • 1）源程序文档化 • 2）数据说明 • 3）语句构造 • 4）输入/输出 • 5）效率 • 6）提高重用性 • 7）提高可扩充性 • 8）提高健壮性 主讲教师：李刚

5. §4.1 编码 • 1 源程序文档化 • 程序内部的文档包括： • 1）恰当的标识符（变量和标号）的名字： 标识符包括模块名、变量名、常量名、标号名、子程序名以及数据区 名、缓冲区名等。这些名字的选取应含义鲜明，能正确地提示程序对象所 代表的实体。这对于帮助阅读者理解程序是很重要的。例如，表示次数用 times，表示总量用total等。名字的长度不应限制，但也不宜过长，太长了 容易出错，应选择精炼且意义明确的名字，这样才能简化程序语句，改善 对程序功能的理解。如果名字使用缩写，那么缩写规则应该一致，并且应 该给每个名字加上注解，以方便阅读。 主讲教师：李刚

6. §4.1 编码 • 2）适当的注释：序言性注释和功能性注释。 序言性注释: 安排在每个程序模块的起始部分，它是对程序的整体说明，对于理解程序 本身具有引导作用。 其格式如下： 有关本模块功能说明； 主要算法； 接口描述：包括调用形式，参数描述以及子模块清单； • 有关数据描述：包括重要的变量及其用途、约束或限制条件，以及其它有 • 关信息； • 模块位置：在哪一个源文件中，或隶属于哪一个软件包； • 开发简历：包括模块设计者姓名，复审人姓名，复审日期，修 改日期及有 • 关说明等。 主讲教师：李刚

7. §4.1 编码 • 功能性注释： • 嵌入在源程序体内，用以描述其后的语句或程序段的处理功能。 • 书写功能性注释，要注意以下几点： • 描述的对象是一段程序，而不是每一个语句； • 适当使用缩进和空行，使程序与注释容易区别； • 注释一定要准确。不精确的甚至是错误的注释不仅对理解程序毫无帮助，反而会妨碍对程序的理解。 主讲教师：李刚

8. §4.1 编码 • 程序的视觉组织 程序中代码的布局对于程序的可读性也有很大影响。适当的利用空格、 空行和移行能使程序的逻辑结构更加清晰。空格的合理应用还可以突出运 算的优先性，避免发生运算的错误。 主讲教师：李刚

9. §4.1 编码 2 数据说明 • 为了使数据更容易理解和维护，应遵循一些简单的原则： • （1）数据说明的次序应当规范化。 • （2）当多个变量名在一个语句中说明时，应该按字母顺序排列这些变量。 • （3）如果设计时使用了一个复杂的数据结构，则应注解说明用程序设计语 • 言实现这个数据结构的方法和特点。 主讲教师：李刚

10. §4.1 编码 • 3 语句构造 语句构造应遵循的原则是：每条语句应该简单而直接，不应为了片面追求 效率而使代码变得过于复杂。 • 人们在长期的实践中总结了以下一些规则： • 不要为了节省空间而把多个语句写在同一行； • 用空格或可读的符号使语句的内容更加清晰； • 尽量避免复杂的条件测试； • 尽量避免使用“非”条件的条件语句； • 避免过多使用循环嵌套和条件嵌套； • 利用括号使逻辑表达式或算术表达式的运算次序清晰直观； • 尽可能使用库函数； • 让编译程序作简单的优化。 主讲教师：李刚

11. §4.1 编码 • 4 输入／输出 • 在设计和程序编码时，应考虑输入和输出风格原则： • 对所有输入数据都进行校验，以保证每个数据的有效性； • 检查重要的输入项组合的合法性； • 使得输入的步骤和操作尽可能简单，并保持简单的输入格式； • 输入一批数据时，使用输入结束指示符，不要要求用户说明输入项数； • 在以交互式输入／输出方式进行输入时，要指明可以使用的选择值或界限值； • 应允许缺省值； • 当程序设计语言对输入／输出格式有严格要求时，应保持输入格式与输入语句的要求一致； • 给所有的输出加注释，并设计输出报表格式。 主讲教师：李刚

12. §4.1 编码 • 5 效率 • 通常，效率主要指占用处理器时间和存储器两个方面。好的编码可以提高 • 效率，在我们进一步讨论这个问题之前，应该记住三条原则： • 第一、效率是一个性能要求，因而应该在需求分析阶段确定代码效率方面 • 的要求； • 第二、通过好的设计可以提高效率； • 第三、程序的效率和程序的简明程度是一致的，不应该为了提高代码效率] • 而牺牲程序的清晰性和可读性。 • 具体包括：1、代码效率 2、存储效率 3、输入／输出的效率 主讲教师：李刚

13. §4.1 编码 • 6 重用性：提高代码中方法的内聚，减小方法的规模，保持方法的一致 • 性，把策略与实现分开，尽量不使用全局信息等等。 • 7 可扩充性：提高可重用性的同时也能提高程序的可扩充性，还要考虑模 • 块的耦合程度 • 8 健壮性：应该预防用户的操作错误，检查参数的合法性，等等 • 提高程序从错误中恢复的能力 主讲教师：李刚

14. §4.2 软件测试概述 • 测试的定义：为了发现程序中的错误而执行程序的过程。具体地说，软件 • 测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计出一 • 批测试用例，并利用测试用例来运行程序，以发现程序错误的过程。 • G.J.Myers给出了以下的观点： • （1）测试是为了发现程序中的错误而执行程序的过程； • （2）好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； • （3）成功的测试是发现了至今为止尚未发现的错误的测试。 主讲教师：李刚

15. §4.2 软件测试概述 • 软件测试涉及的概念： 错误 、缺陷、故障 • 软件测试的基本原则： • （1）所有测试都应该能追溯到用户需求 • （2）应该在测试前就制定出测试计划 • （3）应该从“小规模”测试开始，并逐步进行“大规模”测试 • （4）穷举测试是不可能的。 • （5）应该由独立的第三方从事测试工作。 主讲教师：李刚

16. §4.2 软件测试概述 • 软件测试的手段 • 1、代码审查 • 人工测试源程序可以由编写者本人非正式地进行，也可以由审查小组正式 • 进行，后者称为代码审查。 • 审查小组的组成： • （1）组长 一个很有能力的程序员 • （2）程序的设计者 • （3）程序的编写者 • （4）程序的测试者 主讲教师：李刚

17. §4.2 软件测试概述 • 3.计算机测试 • 存根程序：是被测试模块单元所调用模块的代替模块，在模块调 • 用接口、相关数据处理、控制返回等方面对被代替模块进行“模拟” • 驱动程序：调用测试单元的“主程序”，它接受测试数据，把这些数 • 据传送给被测试的模块并打印有关结果。 单元测试的测试环境 测试用例 测试结果 驱动模块 被测模块 桩模块 桩模块 桩模块 主讲教师：李刚

18. 集成测试、组装测试、联合测试； • 重点在于测试模块之间的接口； 模块测试 子系统测试 目的：保证每个模块作为一个单元能够正确运行，又称为单元测试 • 有用户参加的系统测试； • 验证是否满足用户的需要； • 主要使用实用数据。 系统测试 • 将经过测试的子系统装配成一个完整的系统来测试； • 发现设计和编码的错误，验证系统是否满足需求说明所定义的功能及其动态特性； • 也称为集成测试。 验收测试 平行运行 同时运行新旧两个系统，并且对处理的结果进行比较，以确定新系统是否满足相关性能指标。 主讲教师：李刚

19. §4.2 软件测试概述 正确 调试 包括需求说明书、设计说明书、源程序清单等 错误 软件配置 评价 测试结果 测试 可靠性预测 可靠性模型 错误率数据 预期结果 测试配置 包括测试计划和测试方案 主讲教师：李刚

20. §4.3 软件测试的策略 • 单元测试 • 单元测试又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行 • 正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差 • 错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平 • 行地独立进行单元测试。 测试重点：在单元测试时，测试者需要依据详细设计说明书和源程序清 单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用 例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输 入，都能鉴别和响应。 主讲教师：李刚

21. §4.3 软件测试的策略 (1) 模块接口测试 • 主要进行的测试项目有以下几方面： • 所测模块的形式参数和调用该模块的实际输入参数在参数数目、属性和顺序上是否匹配； • 是否修改了只做输入用的形式参数； • 输出给被调用模块的参数在数目、属性和顺序上是否正确； • 全程变量的定义和用法在各个模块中是否一致。 • 若模块中有外部的I/O操作，还应该进行以下的测试项目： • 文件属性是否正确； • 打开文件语句和关闭语句是否正确； • 格式说明书与输入／输出语句是否一致； • 缓冲区的大小与记录长度是否匹配； • 使用文件之前是否先打开了文件； • 文件操作结束后是否关闭了文件； • 是否进行了输入／输出错误检查并进行了相应的处理。 主讲教师：李刚

22. §4.3 软件测试的策略 • (2) 局部数据结构测试 • 不正确或不一致的数据类型说明 • 使用尚未赋值或尚未初始化的变量 • 错误的初始值或错误的缺省值 • 变量名拼写错或书写错 • 不一致的数据类型 • 全局数据对模块的影响 • (3) 路径测试 • 选择适当的测试用例，对模块中重要的执行路径进行测试。 • 应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流 • 而导致的错误。 • 对基本执行路径和循环进行测试可以发现大量的路径错误. 主讲教师：李刚

23. §4.3 软件测试的策略 • (4) 错误处理测试 • 出错的描述是否难以理解 • 出错的描述是否能够对错误定位 • 显示的错误与实际的错误是否相符 • 对错误条件的处理正确与否 • 在对错误进行处理之前，错误条件 • 是否已经引起系统的干预等 • (5) 边界测试 • 注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。 • 如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素 主讲教师：李刚

24. §4.3 软件测试的策略 • 集成测试是组装软件的系统技术；组装测试 、联合测试 • 通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需 • 要考虑的问题是： • 在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失； • 一个模块的功能是否会对另一个模块的功能产生不利的影响； • 各个子功能组合起来，能否达到预期要求的父功能； • 全局数据结构是否有问题； • 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。 • 子系统的组装测试特别称为部件测试，它所做的工作是要找出组装后的子系统 • 与系统需求规格说明之间的不一致。 • 通常，把模块组装成为系统的方式有两种 • 一次性组装方式：又称为非渐增式测试； • 增殖式组装方式：其中又分为自顶向下、自底向上和两种方法混合测试方式 在单元测试的同时可进行组装测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。 主讲教师：李刚

25. §4.3 软件测试的策略 1.一次性组装方式(big bang) • 它是一种非增殖式组装方式。也叫做整体拼装。 • 使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。 整体组装 系 统结构图 单元测试 主讲教师：李刚

26. §4.3 软件测试的策略 2. 渐增法 • 首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统 • 在组装的过程中边连接边测试，以发现连接过程中产生的问题 • 通过增殖逐步组装成为要求的软件系统。 (1) 自顶向下的渐增方式 • 这种组装方式将模块按系统程序结构，沿控制层次自顶向下进行组装。 • 自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。 • 选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能。 主讲教师：李刚

27. §4.3 软件测试的策略 (2) 自底向上的渐增方式 • 自顶向下增殖的方式和自底向上增殖的方式各有优缺点。 • 一般来讲，一种方式的优点是另一种方式的缺点。 • 这种组装的方式是从程序模块结构的最底层的模块开始组装和测试。 • 因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括 子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试 过程中需要从子模块得到的信息可以直接运行子模块得到。 主讲教师：李刚

28. §4.3 软件测试的策略 • 非渐增式和渐增式测试方法的优缺点比较： • 非渐增式方法要对每个模块编写驱动模块和桩模块，工作量较大；而渐增式 方法可以利用部分已测试过的模块作为测试软件； • 非渐增式方法发现模块间的接口错误较晚，而渐增式方法则要早一些； • 非渐增式方法发现错误后较难定位；而渐增式方法则要容易一些； • 非渐增式方法可以并行测试所有模块，可充分利用人力，加快工程进度； • 渐增式方法接近全真运行环境，需要较多的测试运行时间，但对程序模块的 测试较为彻底。 主讲教师：李刚

29. §4.3 软件测试的策略 • 确认测试—验证软件的有效性 • 软件的有效性：如果软件的功能和性能满足用户的需求，则软件是有效的 • 软件有效性的标准：需求分析阶段所产生的准确的系统需求文档； • 测试方法：一般用黑盒方法； • 结果：功能和性能均与用户要求一致，软件是可以接受的；否则软件是不可接受的。 • Alpha和Beta测试 主讲教师：李刚

30. 语句覆盖 判定覆盖 条件覆盖 判定－条件覆盖 条件组合覆盖 路径覆盖。 §4.4 测试用例的设计 测试方案：包括预定要测试的功能，应该输入的测试数据和预期的结果。其中最困难的设计测试用的输入数据（称为测试用例）。 测试用例设计技术：黑盒测试的等价划分、边界值分析、错误推测法； 白盒测试的逻辑覆盖法； 1. 逻辑覆盖 逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。它属白盒测试。 主讲教师：李刚

31. I. A=2, B= 0, X=4 ---- sacbed PROCEDURE Example(A,B:real; X:real ); Begin IF (A>1) AND (B=0) THEN X:= X / A; IF ( A=2 ) OR (X>1) THEN X:=X+1 END; 语句覆盖 S 1 a T 4 (A>1)and(B=0) c F X = X / A 2 5 b (A=2)or(X>1) T 6 e F X=X+1 3 语句覆盖 所有的语句至少执行一次！ 7 d 主讲教师：李刚

32. I: A=3, B=0,X=3: sacbd II: A=2, B=1,X=1: sabed 判定覆盖 每个判定的每种可能都至少执行一次！ 即每个判定的每个分支都至少执行一次！ 判定覆盖 S 1 a T 4 (A>1)and(B=0) c F X = X / A 2 5 b (A=2)or(X>1) T 6 e F X=X+1 满足判定覆盖的测试用例一定满足语句覆盖：判定覆盖比语句覆盖强。 3 7 d 主讲教师：李刚

33. s 1 a T 4 (A>1)and(B=0) c F X = X / A 2 5 b (A=2)or(X>1) T 6 e F X=X+1 7 3 d 条件覆盖 每个语句至少执行一次，而且判定表达式中的每个条件都要取得各种可能的结果。 条件覆盖 S (A>1) (A≤1) (B=0) (B≠0) (A=2) (A≠2) (X>1) (X≤1) I: A=2, B=0,X=4: sacbed II: A=1, B=1,X=1: sabd I: A=2, B=0,X=1: sacbed 条件覆盖一般情况下比判定覆盖要强，但是也有满足条件覆盖但不能满足判定覆盖的情况。 II: A=1, B=1,X=1: sabed 主讲教师：李刚

34. 判定/条件覆盖 S 1 a (A>1) (A≤1) T 4 (A>1)and(B=0) c (B=0) (B≠0) F X = X / A 2 (A=2) (A≠2) 5 b (X>1) (X≤1) (A=2)or(X>1) T 6 e I: A=2, B=0,X=4: sacbed F X=X+1 7 II: A=1, B=1,X=1: sabd 3 d 主讲教师：李刚

35. 覆盖路径 I: sacbed II: sabed III: sabed IV: sabd 条件组合覆盖要求选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次 条件组合覆盖 S 1 a (A>1) (B=0) I. A=2,B=0,X=4 T 4 (A>1)and(B=0) (A≤1) (B≠0) II. A=2,B=1,X=1 F X = X / A 2 5 (A=2) (X>1) b (A=2)or(X>1) T (A≠2) (X≤1) 6 F X=X+1 III. A=1,B=0,X=2 7 3 满足条件组合覆盖标准的测试数据，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。 IV. A=1,B=1,X=1 d 主讲教师：李刚

36. 点覆盖： • 如果连通图 G 的子图G´是连通的，而且包含G的所有节点，则称G´是G • 的点覆盖。 • 与语句覆盖标准相同。 • 边覆盖： • 如果连通图 G 的子图G´是连通的，而且包含G的所有边，则称G´是G • 的边覆盖。 • 通常与判定覆盖标准相同。 • 路径覆盖： • 选取足够多的测试数据，使程序的每条 可能路径都至少执行一次（如果程序图 中有环，则要求每个环至少经过一次） • 路径覆盖是较强的逻辑覆盖标准。 1 4 2 5 I: A=1,B=1,X=1 (1-2-3) ; II: A=1,B=1,X=2 (1-2-6-7) III: A=3,B=0,X=1 (1-4-5-3); IV: A=2,B=0,X=4 (1-4-5-6-7) 6 3 7 主讲教师：李刚

37. 2. 控制结构测试 • 现有的多种白盒测试技术，是根据程序的控制结设计测试数据的技 • 术，常用的控制结构测试技术有 • 1）基本路径测试 • 2）条件测试 • 3）循环测试 主讲教师：李刚

38. 7.7黑盒测试技术测试人员将程序看成是一个“黑盒”，即不关心程序内部是什么，只要检查程序是符合它的“功能说明”。7.7黑盒测试技术测试人员将程序看成是一个“黑盒”，即不关心程序内部是什么，只要检查程序是符合它的“功能说明”。 • N个等价类 • 每个等价类中的一组具代表性的测试数据 • 等 价 划 分 • 等价分类法是将输入数据的可能值分成若干“等价类”，每一类以一个代表性的测试数据进行测试，这个数据就等价于这一类中的其它数据。 • 该法的关键在于如何将输入数据分类。 • 例如：输入的数据范围是1~999，我们可以划分三类：x<1，1≦x ≦ 999，x>999 主讲教师：李刚

39. 2 等 价 划 分 (2) Type ShortStr = array[1..6] of char; Function StrToInt(dstr: ShortStr): integer; • 计算机能表示的最小负整数和零之间的负整数； • 零； • 计算机能表示的最大正整数和零之间的正整数； • 1—6个数字字符组成的数字串（最高位不是零）； • 最高位是零的数字串； • 最高位数字左邻是负号的数字串； 合法输出的等价类 有效输入的等价类 把 数 字 串转换成整数 非法输出的等价类 无效输入的等价类 • 比计算机能表示的最小负整数还小的负整数； • 计算机能表示的最大正整数还大的正整数； • 空字符串（全是空格）； • 左部填充的字符既不是零也不是空格； • 最高位数字右边由数字和空格混合组成； • 最高位数字右边由数字和其他字符混合组成； • 负号与最高位数字之间有空格。 主讲教师：李刚

40. 主讲教师：李刚

41. 3 边 界 值 分 析 • 经验表明：处理边界情况时程序最容易发生错误；下标、数据结构、循环等边界 • 对等价划分法中的不同等价类的边界情况进行重点测试； 4 错 误 推 测 • 不同类型不同特点的程序通常有一些特殊的容易出错的情况； • 有时测试数据的组合数量也是非常多，难于覆盖所有情况； • 经验数据 主讲教师：李刚

42. b 例：程序Triangle读入三个整数值，这三个整数代 表同一个三角形三条边的长度，程序根据这三个 值判断三角形属于不等边、等腰或等边三角形中 的那一种。 a 三角形的类型？ c Triangle a,b,c 黑盒测试（等价划分） 黑盒测试（边界值分析） 黑盒测试（错误推测） 主讲教师：李刚

43. start 程序图 F a<b+c? 程序流程图 T F b<a+c? T F c<a+b? T F F a=b? a=c? T T T b=c? F b=c? F T 印出 “不等边三角形” 印出 “不是三角形” 印出 “等边三角形” 印出 “等腰三角形” 主讲教师：李刚 stop

44. §4.5 面向对象的软件测试 • Smith和Robson建议，面向对象的测试应该针对4个不同的层次：功能、 • 类、聚类（彼此协作的对象的交互群）和整个系统。在面向对象的每个不 • 同测试阶段，都有其不同层次的侧重点。 • 1 面向对象的单元测试： • 面向对象的单元测试主要是对每个类进行单元测试。在对对象类进行测试 • 时，可从2个层次来进行：测试与对象关联的单个操作；测试单个对象类。 • 对象关联的单个操作是一些函数或程序，可以使用白盒测试方法和黑盒测 • 试方法来进行测试。对于单个对象类应该把操作作为类的一部分来测试， • 不能再孤立地测试单个操作。 主讲教师：李刚

45. §4.5 面向对象的软件测试 • 2 面向对象的集成测试 • 一组对象类通过组合行为提供一组服务，它们应该一起测试．即所谓集群 • 测试（cluster testing）。 • 基于线程的测试（thread based testing）：基于线程的测试根据系统对 • 特别输入或一组输入事件的响应来进行。面向对象的系统通常是事件驱动 • 的，因此这是一个特别合适的测试形式。为了使用这个方法需要了解清楚 • 事件处理是如何在系统中进行的。 • 基于使用的测试（use based testing）：这种方法首先测试几乎不使用服 • 务器类的那些类（称为独立类），把独立类都测试完之后，再测试使用独 • 立类的下一个层次的类（称为依赖类）。对依赖类的测试一个层次一个层 • 次地持续进行下去，直至把整个软件系统构造完成为止。 主讲教师：李刚

46. §4.5 面向对象的软件测试 • 3 面向对象的系统测试 • 在系统测试层次，面向对象的系统测试集中检查用户可见的动作和用户可 • 识别的输出，不再考虑类之间相互连接的细节。系统测试时的用例生成可 • 使用上节介绍的黑盒测试方法，但是，基于用例或场景的测试是面向对象 • 系统测试的主要方法。 • 基于用例或场景的测试是根据用例或场景对系统使用的描述来制定测试用 • 例。基于用例或场景的测试通常是最有效的方法，因为它是这样组织测试 • 过程的，先测试那些最平常的场景，不寻常的或异常的场景故在稍后测 • 试。这样做符合测试的基本原理，即最大的测试努力应诙用于系统最常用 • 到的部分。此外，测试用例还可以从动态模型中导出。 主讲教师：李刚

47. §4.5 面向对象的软件测试 • 面向对象的测试用例设计 • 1 类的测试方法 • 对面向对象的软件来说，单元测试着重测试单个类和类中封装的方法。测 • 试单个类的方法主要有随机测试、划分测试和基于故障的测试等3种。 • 随机测试 • 划分测试 • 基于故障的测试 • 2 类间测试方法 主讲教师：李刚

48. §4.6 软件调试 • 调试（也称为纠错）作为成功测试的后果出现，即调试是在测试发现错误 • 后，排除错误的过程。 调试过程 • 调试过程由两个部分组成：首先，确定程序中错误的确切性质和位置；然 • 后，对程序代码进行分析，确定问题的原因，并设法改正这个错误。 • 具体地说，由以下步骤组成： • （1）从错误的外部表现入手，确定程序中出错的位置； • （2）分析有关程序代码，找出错误的内在原因； • （3）修改程序代码，排除这个错误； • （4）重复进行暴露了这个错误的原始测试以及某些回归测试，以确保该错 • 误确实被排除且没有引入新的错误； • （5）如果所作的修正无效，则撤消这次改动，重复上述过程，直到找到一 • 个有效的办法为止。 主讲教师：李刚

49. §4.6 软件调试 • 调试途径 • 1、强行排错 • 这是目前使用较多但效率较低的一种调试方法。具体地说，通常有三种措 • 施：（1）输出存储器内容（2）打印语句（3）自动调试工具 • 2、回溯法 • 采用回溯法排错时，调试人员首先分析错误征兆，确定最先出现“症状”的 • 位置。然后人工沿程序的控制流程往回追踪源程序代码，直到找到错误根 • 源或确定错误产生的范围为止。 • 实践证明，回溯法是一种可以成功地用在小程序中的很好的纠错方法。通 • 过回溯，我们往往可以把错误范围缩小到程序中的一小段代码，仔细分析 • 这段代码，不难确定出错的准确位置。但是，随着程序规模的扩大，由于 • 回溯的路径数目越来越多，回溯法会变得很困难，以至于完全不可能实现 主讲教师：李刚

50. 不能设置错误原因 设置相应测试数据 组织错误线索 研究线索关系 设置错误原因 不能证明错因 错误原因 错误线索 线索关系 个别数据错 解释证明 证明错误 纠正错误 §4.6 软件调试 • 3、归纳法 • 归纳法就是从线索（错误征兆）出发，通过分析这些线索之间的关系而找 • 出故障的一种系统化的思考方法。这种方法主要包括下述四个步骤： • （1）收集有关的数据（2）组织数据（3）提出假设（4）证明假设 主讲教师：李刚