软件工程-结构化实现讲解

《软件工程-结构化实现讲解》由会员分享，可在线阅读，更多相关《软件工程-结构化实现讲解（101页珍藏版）》请在金锄头文库上搜索。

1、第5章 结构化实现 通常把编码和测试统称为实现。 所谓编码就是把软件设计翻译成计算机可以理解 的形式用某种程序设计语言书写的程序。作为软 件工程过程的一个阶段，编码是设计的自然结果，因 此，程序的质量主要取决于软件设计的质量。但是， 所选用的程序设计语言的特点和编码风格也会对程序 的可靠性、可读性、可测试性和可维护性产生深远的 影响。 退出退出 无论怎样强调软件测试的重要性和它对软件可靠 性的影响都不过分。在开发大型软件系统的漫长过程 中，面对着极其错综复杂的问题，人的主观认识不可 能完全符合客观现实，与工程密切相关的各类人员之 间的通信和配合也不可能完美无缺，因此，在软件生 命周期的每个阶段

2、都不可避免地会产生差错。我们力 求在每个阶段结束之前通过严格的技术审查，尽可能 早地发现并纠正差错；但是，经验表明审查并不能发 现所有差错，此外在编码过程中还不可避免地会引入 新的错误。如果在软件投入生产性运行之前，没有发 现并纠正软件中的大部分差错，则这些差错迟早会在 生产过程中暴露出来，那时不仅改正这些错误的代价 更高，而且往往会造成很恶劣的后果。测试的目的就 是在软件投入生产性运行之前，尽可能多地发现软件 中的错误。目前软件测试仍然是保证软件质量的关键 步骤，它是对软件规格说明、设计和编码的最后复审 。 软件测试在软件生命周期中横跨两个阶段。通常 在编写出每个模块之后就对它做必要的测试(

3、称为单元 测试)，模块的编写者和测试者是同一个人，编码和单 元测试属于软件生命周期的同一个阶段。在这个阶段 结束之后，对软件系统还应该进行各种综合测试，这 是软件生命周期中的另一个独立的阶段，通常由专门 的测试人员承担这项工作。 大量统计资料表明，软件测试的工作量往往占软 件开发总工作量的40%以上，在极端情况，测试那种关 系人的生命安全的软件所花费的成本，可能相当于软 件工程其他步骤总成本的35倍。因此，必须高度重 视软件测试工作，绝不要以为写出程序之后软件开发 工作就接近完成了，实际上，大约还有同样多的开发 工作量需要完成。 仅就测试而言，它的目标是发现软件中的错误， 但是，发现错误并不是

4、我们的最终目的。软件工程的 根本目标是开发出高质量的完全符合用户需要的软件 ，因此，通过测试发现错误之后还必须诊断并改正错 误，这就是调试的目的。调试是测试阶段最困难的工 作。 在对测试结果进行收集和评价的时候，软件 所达到的可靠性也开始明朗了。软件可靠性模型使用 故障率数据，估计软件将来出现故障的情况并预测软 件的可靠性。 5.1 5.1 编码编码 5.2 5.2 软件测试基础软件测试基础 5.3 5.3 逻辑覆盖逻辑覆盖 5.4 5.4 控制结构测试控制结构测试 5.5 5.5 黑盒测试技术黑盒测试技术 5.6 5.6 测试策略测试策略 5.7 5.7 调试调试 5.8 5.8 软件可靠性

5、软件可靠性 5.9 5.9 小结小结 5.1 编码 5.1.1 选择程序设计语言 总的说来。高级语言明显优于汇编语言，因此， 除了在很特殊的应用领域(例如，对程度执行时间和使 用的空间都有很严格限制的情况；需要产生任意的甚 至非法的指令序列；体系结构特殊的微处理机，以致 在这类机器上通常不能实现高级语言编译程序)，或者 大型系统中执行时间非常关键的(或直接依赖于硬件的 )一小部分代码需要用汇编语言书写之外，其他程序应 该一律用高级语言书写。 为了使程序容易测试和维护以减少生命周期的总 成本，选用的高级语言应该有理想的模块化机制，以 及可读性好的控制结构和数据结构；为了便于调试和 提高软件可靠性

6、，语言特点应该使编译程序能够尽可 能多地发现程序中的错误；为了降低软件开发和维护 的成本，选用的语言应该有良好的独立编译机制。上 述这些要求是选择语言的理想标准，但是在实际选用 语言时不能仅仅考虑理论上的标准，还必须同时考虑 实用方面的各种限制。 5.1.2 编码风格 源程序代码的逻辑简明清晰、易读易懂是好程序 的一个重要标准，为了做到这一点，应该遵循下述规 则。 1. 程序内部的文档 所谓程序内部的文档包括恰当的标识符、适当的 注解和程序的视觉组织等等。 2. 数据说明 虽然在设计期间已经确定了数据结构的组织和复 杂程度，然而数据说明的风格却是在写程序时确定的 。为了使数据更容易理解和维护，

7、有一些比较简单的 原则应该遵循。 3. 语句构造 构造语句时应该遵循的原则是，每个语句都应该 简单而直接，不能为了提高效率而使程序变得过分复 杂。 4输入/输出 在设计和编写程序时应该考虑下述有关输入/输出风格的 规则： 对所有输入数据都进行检验； 检查输入项重要组合的合法性； 保持输入格式简单； 使用数据结束标记，不要要求用户指定数据的数目； 明确提示交互式输入的请求，详细说明可用的选择或 边界数值； 当程序设计语言对格式有严格要求时，应保持输入格 式一致； 设计良好的输出报表； 给所有输出数据加标志。 5. 效率 效率主要指处理机时间和存储器容量两个方面。 虽然值得提出提高效率的要求，但是

8、在进一步讨论这 个问题之前应该记住三条原则：首先，效率是性能要 求，因此应该在需求分析阶段确定效率方面的要求。 软件应该像对它要求的那样有效，而不应该如同人类 可能做到的那样有效。其次，效率是靠好设计来提高 的。第三，程序的效率和程序的简单程度是一致的。 不要牺牲程序的清晰性和可读性来不必要地提高效率 。 5.2 软件测试基础 5.2.1 测试目标 G.Myers给出了关于测试的一些规则，这些规则也 可以看作是测试的目标或定义： 测试是为了发现程序中的错误而执行程序的过 程； 好的测试方案是极可能发现迄今为止尚未发现 的错误的测试方案； 成功的测试是发现了至今为止尚未发现的错误 的测试。 由于

9、测试的目标是暴露程序中的错误，从心理学 角度看，由程序的编写者自己进行测试是不恰当的。 因此，在综合测试阶段通常由其他人员组成测试小组 来完成测试工作。 5.2.2 黑盒测试和白盒测试 对于软件测试而言，黑盒测试法把程序看成一个 黑盒子，完全不考虑程序的内部结构和处理过程。也 就是说，黑盒测试是在程序接口进行的测试，它只检 查程序功能是否能按照规格说明书的规定正常使用， 程序是否能适当地接收输入数据产生正确的输出信息 ，并且保持外部信息(如，数据库或文件)的完整性。 黑盒测试又称为功能测试。与黑盒测试法相反，白盒 测试法的前提是可以把程序看成装在一个透明的白盒 子里，也就是完全了解程序的结构和

10、处理过程。这种 方法按照程序内部的逻辑测试程序，检验程序中的每 条通路是否都能按预定要求正确工作。白盒测试又称 为结构测试。 5.2.3 测试准则 为了能设计出有效的测试方案，软件工程师必须 充分理解并正确运用指导软件测试的基本准则。主要 的测试准则如下所述。 所有的测试都应该能追溯到用户需求。 应该在测试开始之前的相当长时间，就制定出 测试计划。 把Pareto原理应用于软件测试。Pareto原理告 诉我们，测试发现的错误中的80%很可能是由程序中 20%的模块造成的。 测试应该从“小规模”开始，并逐步进行“大规模” 测试。 穷举测试是不可能的。 为了达到最佳的测试效果，应该由独立的第三方

11、来从事测试工作。 5.2.4 流图 在设计测试方案时，往往需要仔细分析程序的控 制流。为了突出表示程序的控制流，可以使用流图(也 称为程序图)。流图仅仅描绘程序的控制流程，它完全 不表现对数据的具体操作以及分支或循环的具体条件 。 在流图中用圆表示节点，一个圆代表一条或多条 语句。程序流程图中的一个处理框序列和一个菱形判 定框，可以映射成流图中的一个节点。流图中的箭头 线称为边，它和程序流程图中的箭头线类似，代表控 制流。在流图中一条边必须终止于一个节点，即使这 个节点并不代表任何语句(实际上相当于一个空语句) 。由边和节点围成的面积称为区域，当计算区域数时 应该包括图外部未被围起来的那个区域

12、。 图5.1 举例说明把程序流程图映射成流图的方 法。 图5.1 把程序流程图映射成流图 (a)程序流程图；(b)流图 PDL procedure:sort 1：do while records remain read record; 2：if record field 1=0 3：then process record; store in buffer； incremert counter; 4：elseifrecardfield2=0 5：then reset counter; 6：else process record; store in file; 7a：end if endif 7b

13、：enddo 8：end 图5.2 由PDL翻译成的流图 图5.3 由包含复合条件的PDL映射成的流图 5.3 逻辑覆盖 逻辑覆盖是设计白盒测试方案的一种技术。设计 测试方案是测试阶段的关键技术问题。所谓测试方案 包括具体的测试目的(例如，要测试的具体功能)，应 该输入的测试数据和预期的输出结果。通常又把测试 数据和预期的输出结果称为测试用例。 不同的测试数据发现程序错误的能力差别很大， 为了提高测试效率降低测试成本，应该选用高效的测 试数据。因为不可能进行穷尽的测试，选用少量“最 有效的”测试数据，做到尽可能完备的测试就更重要 了。 有选择地执行程序中某些最有代表性的通路是对 穷尽测试的唯一

14、可行的替代办法。所谓逻辑覆盖是对 一系列测试过程的总称，这组测试过程逐渐进行越来 越完整的通路测试。测试数据执行(或叫覆盖)程序逻 辑的程度可以划分成哪些不同的等级，从覆盖源程序 语句的详尽程度分析，大致有以下一些不同的覆盖标 准。 1. 语句覆盖 为了暴露程序中的错误，至少每个语句应该执行 一次。语句覆盖的含义是，选择足够多的测试数据， 使被测程序中每个语句至少执行一次。 图5.4 被测试模块的流程图 2. 判定覆盖 判定覆盖又叫分支覆盖，它的含义是，不仅每个 语句必须至少执行一次，而且每个判定的每种可能的 结果都应该至少执行一次，也就是每个判定的每个分 支都至少执行一次。 3. 条件覆盖

15、条件覆盖的含义是，不仅每个语句至少执行一次 ，而且使判定表达式中的每个条件都取到各种可能的 结果。 4. 判定/条件覆盖 既然判定覆盖不一定包含条件覆盖，条件覆盖也 不一定包含判定覆盖，自然会提出一种能同时满足这 两种覆盖标准的逻辑覆盖，这就是判定/条件覆盖。它 的含义是，选取足够多的测试数据，使得判定表达式 中的每个条件都取到各种可能的值，而且每个判定表 达式也都取到各种可能的结果。 5. 条件组合覆盖 条件组合覆盖是更强的逻辑覆盖标准，它要求选 取足够多的测试数据，使得每个判定表达式中条件的 各种可能组合都至少出现一次。 5.4 控制结构测试 5.4.1 基本路径测试 基本路径测试是Tom

16、 McCabe提出的一种白盒测试 技术。使用这种技术设计测试用例时，首先计算过程 设计结果的逻辑复杂度，并以该复杂度为指南定义执 行路径的基本集合，从该基本集合导出的测试用例可 以保证程序中的每条语句至少执行一次，而且每个条 件在执行时都将分别取true(真)和false(假)值。 使用基本路径测试技术设计测试用例的步骤如下 。 1. 根据过程设计结果画出相应的流图 图5.5 求平均值过程的流图 PROCEDURE average; /*这个过程计算不超过100个在规定值域内的有效数字的 平均值； 同时计算有效数字的总和及个数。*/ INTERFACE RETURNS average,totalinput,total