第六章 结构化开发

6. 1 结构化开发

1. 概述

  1. 指导思想是自顶向下、逐层分解
  2. 基本原则是功能的分解与抽象
  3. 适合于数据处理领域的问题,但是不适合解决大规模、特别复杂的项目,难以适应需求的变化

2.系统设计的基本原理

1. 抽象
2. 模块化
3. 信息屏蔽
4. 模块独立 : 衡量模块独立程度的标准:耦合性和内聚性
  1. 耦合

    模块间相对独立性的度量

    1. 无直接耦合:没有任何关系
    2. 数据耦合:两模块间传递简单的数据值 / 值传递
    3. 标记耦合:传递数据结构
    4. 控制耦合:一个模块调用另一个时传递变量,被调模块通过变量值不同来决定执行那个功能。被调模块通常有多个功能
    5. 外部耦合:通过软件之外的环境联结,如通过IO设备耦合到特定设备、格式、通信协议
    6. 公共耦合:通过一个公共数据环境相互作用,如全局的变量或数据结构
    7. 内容耦合:一个模块直接使用另一个模块的内部数据,或通过非正常入口进入另一个模块
  2. 内聚

    一个模块内部各个元素结合的繁密程度

    1. 偶然/巧合内聚:一个模块内各元素都没有任何联系
    2. 逻辑内聚:模块内执行若干逻辑上相似的功能,通过参数确定该模块完成哪一个功能
    3. 时间内聚:同时执行的动作组合在一起,如系统初始化
    4. 过程内聚:一个模块完成多个任务,这些任务必须按照指定的顺序进行
    5. 通信内聚:模块内的所有处理元素都在一个数据结构上操作,或者处理使用相同的输入数据或者产生相同的输出数据,如向某个数据结构读/写数据
    6. 顺序内聚:模块中的任务必须顺序执行,且前一个的输出就是下一个的输入
    7. 功能内聚:模块内的所有元素共同完成一个功能,缺一不可

    Tip:顺序内聚强调数据间的传递,然而过程内聚不强调

3. 扇入系数与扇出系数

一个模块直接调用其他模块的个数称为模块的扇出系数,反之,被调用的次数被称为扇入系数。

一般扇入和扇出系数为3,4,不会超过7

6.2 数据流图

数据流图也称为数据流程图(Data Flow Diagram DFD)

基本元素:

  • 数据流image-20201019194428595
  • 加工image-20201019194349384
  • 数据存储image-20201019194404865
  • 外部实体image-20201019194327089

6.3 集成测试策略

1. 基本概念

  1. 驱动模块:根据测试用例的设计去调用被测试模块
  2. 桩模块:用于模拟某下级模块“代替/假”模块,并可以模拟各种返回值

简单的说,被测模块上层为驱动模块,是调用被测模块的,被测模块下层为桩模块,是被被测模块调用的。

2. 各类测试分类

1. 自顶向下

​ 采用了和设计一样的顺序对系统进行测试,它在第一时间内对系统的控制接口进行验证;采用自顶向下的集成测试首先集中于顶层的组件,然后逐步测试处于底层的组件;可采用深度优先和广度优先策略。

  • 优点:

    • 在测试过程中较早的验证了主要的控制和判断点
    • 在过程的早期阶段测试,有助于最大限度地减少对驱动程序的需求
  • 缺点:

    • 桩的开发和维护时本策略的最大成本
    • 底层组件行为的验证被推迟了
    • 不能很好地支持有限功能的早期发布

2. 自顶向上

​ 由下而上的方法要求首先测试和集成最低级别的单元。这些单元常被称为实用工具模块。

  • 优点:
    • 实用工具模块在开发过程的早期阶段测试,最大限度地减少了对桩的需求
    • 最初的工作可以并行
    • 支持故障隔离
  • 缺点:
    • 驱动的开发工作量大
    • 高层的验证被推迟
    • 设计上的错误不容易发现

3. 三明治

​ 把系统划分成三层,中间一层为目标层;测试的时候,对目标层上面的一层使用由顶向下的集成策略,对目标层下面的一层使用自底向上的集成策略,最后测试在目标层会合。

  • 优点:
    • 可以较早的验证主要的控制和判断点和底层模块(集合了自顶向下和自底向上的优点)
  • 缺点:
    • 中间层的在被集成前测试不充分

4. 一次性/大爆炸

首先对每个模块分别进行单元测试,然后再把所有单元组装在一起进行测试,最终得到要求的软件系统

  • 缺点:

    • 由于程序中不可避免地存在模块间接口、全局数据结构等方面的问题,所以一次试运行成功的可能性并不很大
    • 在发现错误的时候,其问题定位和修改都比较困难;
    • 即使被测系统能够被一次性集成,但还是会有许多接口错误很容易的躲过测试而进入到系统测试范围内。
  • 适用范围

    • 维护型或增强型项目,之前的项目已经足够稳定
    • 系统较小