计算机科班知识整理专栏系列文章：

第五章设计（Design）

5.1 软件工程中的设计

需求模型注重描述所需要的数据、功能和行为。
设计模型提供了软件体系结构、数据结构、接口和构件的细节。
设计创建的模型是实现系统所必须的。
设计模型的质量可以被评估和改建。
设计是确立软件质量的关键步骤。
软件设计包括一系列原理、概念和实践，用以指导高质量的系统和产品开发。
软件设计的目标是创作坚固（稳定）、适用和令人愉悦的模型或表示（这里借鉴了建筑上的观念）
- 坚固是指程序应该不含任何妨碍其功能的缺陷。适用是要程序符合开发的目标。赏心悦目是要求使用程序的体验应是愉快的。
设计中设计师的做法：
- 先是实现多样化、再进行聚合。
- 多样化是指要获取多种方案和设计的原始资料，包括目录、教科书和头脑中的构件、构件方案和知识。
- 聚合是把各种信息汇聚在一起，从其中挑选能够满足需求工程和分析模型所定义的需求的元素。进行经取舍。
- 多样化和聚合需要直觉和判断力，其质量取决于设计师的水平、设计方式、评价标准、迭代过程等
分析模型——>设计模型

数据或类设计：将类模型转化为设计类的实现及软件实现所要求的数据结构。
体系结构设计：定义了软件的主要结构化元素之间的关系、用于达到系统需求的体系结构风格和模式以及影响体系结构实现方式的约束。
接口设计：描述了软件和协作系统之间、软件和使用者之间是如何通信的。
构件级设计：将软件体系结构的结构化元素变换为对软件构件的过程性描述。

5.2 设计过程

5.1.1 软件质量

5.1.1.1 软件设计质量8条指导原则

设计应展示出这样一种结构；
a. 已经使用可识别的体系结构风格或模式创建；
b. 由展示出良好设计特征的构件构成；
c. 能够以演化的方式实现，从而便于实现和测试。
设计应该模块化；即软件应按照逻辑划分为元素或子系统。
设计应该包含数据、体系结构、接口和构件的清楚表示。
设计应导出数据结构，这些数据结构适用于要实现的类，并由可识别的数据模式提取。
设计应导出显示独立功能特征的构件。
设计应导出接口，这些接口降低了构件之间以及与外部环境连接的复杂性。
设计的导出应根据软件需求分析过程中获取的信息采用可重复使用的方法进行。
应使用能够有效传达其意义的表示法来表达设计。

5.1.1.2 软件的质量属性（FURPS）及从属属性

一种软件质量属性称为FURPS，FURPS质量属性体现了所有软件设计的目标：

功能性（Functionality） ：评估程序的特征集和能力、所提交功能的普遍性以及整个系统的安全性。
- 适合性、准确性、互操作性、安全保密性。
易用性（Usability） ：通过考虑人为因素、整体美感、一致性和文档来评估。
- 易理解性、易学性、易操作性、吸引性。
可靠性（Reliablity） ：通过测量故障的频率和严重性、输出结果的精确性、故障平均时间、故障恢复能力和程序的可预见性来评估。
- 成熟性、容错性、易恢复性。
性能（Performance） ：度量处理速度、响应时间、资源消耗、吞吐量和效率。
- 时间特性、资源利用性。
可支持性（Supportability） ：可扩展性、可适应性和可用性。还包括可测试性、兼容性、可配置性、系统安装的简易性和问题定位的简易性。
- 适应性、易安装性、共存性、易替换性。

注意：

软件设计时，并不是每个软件质量属性都具有相同的权重。有的系统看重功能，有的系统要求高性能。
但是，必须在软件设计开始时就要考虑这些质量属性，否则会导致低质量的软件产品。

插入一道题目，记得即可：

以下哪一个是功能要求（functional requirement）？

a）可维护性（Maintainability ） b）可携性（Portability）c）健壮性（Robustness）d）以上都没有

5.1.2 软件设计的历史发展

软件设计历史有60多年了
早期（70年代），注重模块化程序开发和自顶向下的”结构化“方式
后来（90年代），面向对象的设计方法
再后来，提出设计模式，面向方面的设计方法，模型驱动开发，测试驱动开发等
每一种软件设计方法都引入了独特的设计过程和表示法，同时也引入了标定的质量特征观点。
这些方法共同特征：
1）都是将需求模型转化为设计表示的方法
2）都有表示功能性构件及它们之间接口的表示方法
3）细化和分割的启发式方法
4）质量评估的指导原则
无论哪种设计方法，都要进行数据设计、体系结构设计、接口设计和构件设计，都具有一套基本概念。

5.1.3 耦合性

（stamp coupling 标记耦合）

5.3 设计概念

这些概念包括：抽象，体系结构，模式，关注点分离，模块化，信息隐藏，功能独立，求精，重构，面向对象，类设计，依赖倒置，测试设计等。
抽象（abstract） ：
- 抽象是人类处理复杂问题的基本方法之一
- 抽象层次有高低，越高越概括，越低越具体
- 同义词：概括，总结，泛化
- 数据抽象，产生数据类型
- 过程抽象，产生函数和方法
- 面向对象中，类就是个对数据和过程的抽象，接口是能力的抽象等等。
体系结构（ architecture ）：
- 软件体系结构意指”软件的整体结构和这种结构为系统提供概念上完整性的方式“。
- 简单说，体系结构是程序构件（模块）的结构或组织、这些构件交互的方式以及这些构件所用的数据结构。
- 软件设计的目标之一是导出系统的体系结构透视图，该透视图作为一个框架指导更详细的设计活动。
- 一系列的体系结构模式使得软件工程师能够复用设计级的概念。
模式( pattern) ：
- 设计模式描述了解决某个特定环境中的特定设计问题的设计结构。
- 每个设计模式的目的都是提供一个描述，以使得设计人员能够确定：
  - 模式是否适合当前的工作；
  - 模式是否能够复用；
  - 模式是否能够用于指导开发一个类似但是功能或结构不同的模式。
- 设计模式参考书《设计模式：可复用面向对象软件的基础》
关注点分离(Separation of concerns)：
- 关注点分离是一个设计概念，它表明任何复杂问题如果被分解为可以独立解决或优化的若干块，该复杂问题能够更容易地被处理。
- 一个关注点是一个特征或行为。通过将关注点分割为更小的关注点，使得解决一个问题需要付出更少的工作量和时间。
- 关注点分离在其他相关设计概念中也有体现：模块化、方面、功能独立、求精。
模块化(modularization)：
- 模块化是关注点分离最常见的表现。
- 软件被划分为独立命名的、可处理的模块（或构件），把这些构件集成到一起可以满足问题的需求。
- 对于一个给定的系统，合适的模块是多少呢？
- 答：过少过多都会使得成本增加
- 模块化基本问题：如何分解获得最好的模块集合？
信息隐蔽(Information concealment)：
- 信息隐蔽的目的是将数据结构和处理过程的细节隐藏在模块接口之后，用户不需要了解模块内部的具体细节。
- 信息隐蔽原则建议：每个模块对其他所有模块都隐蔽自己的设计决策。
- 联系一下面向对象的三大特点之一：封装
功能独立：
- 功能独立是希望软件设计时要使每个模块仅涉及需求的某个特定子功能，并且当从程序结构的其他部分观察时，每个模块只有一个简单的接口。
- 独立模块更容易维护
- 独立性的评估标准：内聚性和耦合性
  - 内聚是模块内的相关强度，耦合性是模块间的相互依赖。
求精：
- 逐步求精是一种自顶向下的设计策略。
- 求精实际上就是一个细化的过程。
- 细化过程是渐进的，逐步的，细化过快容易导致错误，而且使得难于评审。
- 抽象和细化是互补的概念。
重构(refactor)：
- 重构是一种重新组织的技术，可以简化构建的设计而无需改变其功能或行为。
- 重构定义：“重构是使用这样一种方式改变软件系统的过程：不改变代码的外部行为而是改进其内部结构。”
- 一种观点：好系统（代码）是重构出来的
- Eclipse中有refactor功能
面向对象的设计概念：
- 类
- 对象
- 继承
- 封装
- 多态
- 消息
类设计：
- 分析模型定义的分析类的抽象级相对较高
- 设计中，定义设计类可以：
  - 1）通过提供设计细节精化分析类，这些设计细节将促成类的实现；
  - 2）创建一组新的设计类，该设计类实现了软件的基础设施以支持业务解决方案。下面建议了五种不同类型的设计类。
- 设计类，五种不同类型的设计类：
  - 用户接口类：定义人机交互（HCI）所必须的所有抽象。在很多情况下，HCI出现在隐喻的环境，而接口的设计类可能是这种隐喻元素的形象表示。
  - 业务域类：通常是早期定义的分析类的精化。这些类识别实现某些业务域所必须的属性和服务。
  - 过程类：实现完整管理业务域类所必须的低层业务抽象。
  - 持久类：代表将在软件执行之外持续存在的数据存储。
  - 系统类：实现软件管理和控制功能，使得系统能够运行并在其计算环境内与外界通信。
- 在设计模型演化时，软件团队必须为每个设计类开发一组完整的属性和操作。
- 随着每个分析类转化为设计表示，抽象级就降低。
- 分析类使用业务域的专门用语描述对象；设计类更多地表现技术细节，将作为实现的指导。
- 良好的设计类一般有四个特征：
  - 完整性与充分性：设计类应该完整地封装所有的，可以合理预见会存在于类中的属性和方法。
  - 原始性：和某个设计类相关的方法应该关注于实现类的某个服务。一旦服务已经被某个方法实现，类就不应该再提供另外一种完成同一事情的方法。
  - 高内聚性
  - 低偶合
依赖倒置(Dependency inversion)：
- 高层模块不应该依赖低层模块，两者都应该依赖抽象
- 抽象不应该依赖细节，细节应该依赖抽象
- 依赖倒置原则在java语言中，表现是：
  - 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
  - 接口或抽象类不依赖实现类
  - 实现类依赖接口或抽象类
- 有一种说法“面向接口编程”

测试设计：
- 到底是先开始软件设计还是测试用例设计，这是个争论。
- 测试驱动开发提倡在编写任何其他代码之前先编写测试代码。

5.4 设计模式

5.4.1 设计模式的三大分类

创建型：创建对象时，不再由我们直接实例化对象；而是根据特定场景，由程序来确定创建对象的方式，从而保证更大的性能、更好的架构优势。创建型模式主要有简单工厂模式（并不是23种设计模式之一）、工厂方法、抽象工厂模式、单例模式、生成器模式和原型模式。

结构型：用于帮助将多个对象组织成更大的结构。结构型模式主要有适配器模式、桥接模式、组合器模式、装饰器模式、门面模式、享元模式和代理模式。

行为型：用于帮助系统间各对象的通信，以及如何控制复杂系统中流程。行为型模式主要有命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板模式和访问者模式。

5.4.2 设计模式的六大原则

总原则：开闭原则（Open Close Principle，OCP）

开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类等，后面的具体设计中我们会提到这点。

1、单一职责原则

不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。

2、里氏替换原则（Liskov Substitution Principle，LSP）

里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现，即子类可以替换父类。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

里氏替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。

3、依赖倒转原则（Dependence Inversion Principle，DIP）

这个是开闭原则的基础，具体内容：面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。

4、接口隔离原则（Interface Segregation Principle，ISP）

这个原则的意思是：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。

5、迪米特法则（最少知道原则）（Demeter Principle，DP）

就是说：一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。

最少知道原则的另一个表达方式是：只与直接的朋友通信。类之间只要有耦合关系，就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。

6、合成复用原则（Composite Reuse Principle，CRP）

原则是尽量首先使用合成/聚合的方式，而不是使用继承。

5.5 设计模型

设计模型可从过程和抽象两个维度观察，如图：

5.5.1 数据设计

数据设计也称数据体系结构
数据设计创建在高抽象级上（以客户或用户的数据观点）表示的数据模型和信息模型。然后不断求精细化直到实现。
数据结构通常是软件设计的重要部分。
- 在程序构建级，数据结构设计关注实现局部数据对象的数据结构和数据相关的算法。
- 在体系结构级，数据设计关注文件和数据库等等。
- 在业务级，重新组织数据形成“数据仓库”

5.5.2 体系结构设计

软件的体系结构类似于房屋的平面图。平面图描绘了房间的整体布局，包括各房间的尺寸、形状、相互之间的联系，能够进出房间的门窗。体系结构设计元素为我们提供了软件的整体视图。
体系结构模型从以下三个来源获得：
- 关于将要构建的软件的应用域信息；
- 特定的分析模型元素，如数据流图或分析类、现有问题中它们的关系和协作；
- 体系结构模式和风格的可获得性。

5.5.3 接口设计

软件的接口设计相当于一组房屋的门、窗和外部设施的详细绘图。
这些绘图描绘了门窗的尺寸和形状、门窗的工作方式、设施连接入室的方式和在平面上的室内布置。
门、窗、外部设施的详细图纸（以及规格说明）大体上告诉我们事件和信息如何流入和流出住宅以及如何在平面图的房间内流动。
类似地，软件接口设计元素告诉我们信息如何流入和流出系统以及被定义为体系结构一部分的构件之间是如何通信的。
接口设计有三个重要的元素：
- 用户界面（UI）；
- 和其他系统、设备、网络或其他的信息生产者或使用者的外部接口；
- 各种设计构件之间的内部接口。

接口设计元素允许软件和外部通信，
接口设计元素使得在软件体系结构内的构件之间能够通信和协作。

用户界面设计（interface design）

黄金原则

用户操作控制
减少用户的记忆和负担
保持界面的一致性

用户界面设计模型

用户模型所有终端用户的画像
设计模型用户模型的设计实现
感知模型界面给用户的印象
实施模型界面的外观和给用户的感觉与描述的支持文档相符合

用户界面设计过程（界面设计的步骤）

界面分析和建模
界面设计
界面构建
界面确认

界面分析和建模（界面分析的任务）

用户分析
任务分析
展出内容分析
工作环境分析

界面设计

使用接口分析期间获得的信息定义接口对象和操作
定义将导致用户界面改变的事件,对这种行为进行建模
将每个接口状态描述为它将实际呈现给终端用户的样子
指示用户通过界面提供的信息理解系统的状态

插入一道题目：

以下哪些界面设计原则不允许用户继续控制与计算机的交互？

a)允许交互可中断（allow interaction to interruptible）

b)允许交互是不可执行的（allow interaction to be undoable）

c)向普通用户隐藏技术内部内容（hide technical internals from casual users）

d)只提供一个已定义的完成任务的方法（only provide one defined method for accomplishing a task）

5.5.4 构件级设计

软件的构件级设计完整地描述了每个软件构件的内部细节。
构件是模块化的、可部署的和可替换的部件，该部件封装了操作实现和接口
构件级设计需要为所有本地数据对象定义数据结构。
为所有在构件内发生的处理定义算法细节，并定义允许访问构件操作（行为）的接口。
类似于某个房屋中的一组详细绘图（以及规格说明）。这些绘图描绘了每个房间内的布线和管道、电器插座和开关、水龙头、水池、浴池、浴盆、下水道、壁橱和储藏室的位置，还说明了所使用的地板、装饰以及和房间相关的任何细节。
部件设计原则，详细见5.4.2 设计模式的六大原则
- 开闭原则（open-close principle, OCP）
- 替换原则 (the liskov substitution, LSP)
- 依赖倒置原则(dependency inversion principle, DIP)
- 接口分离原则(the interface segregation principle, ISP)

5.5.5 部署级设计

部署级设计元素指明软件功能和子系统将如何在支持软件的物理计算环境内分布。
例如SafeHome产品元素被配置在三个主要的计算环境内运行
- 基于住宅的PC
- SafeHome控制面板
- 提供Internet访问的服务器

在设计过程中，开发的UML部署图以及随后的精化。
部署图显示了计算环境但并没有明确地说明配置细节。
在后面的阶段或构件开始时，应该用实例形式重新为部署图提供这些细节，明确每个实例的部署（专用的如硬件配置）。

第六章测试（Test）

6.1 测试是什么

测试是为了在将软件交付给用户之前发现软件设计和实现过程中因疏忽所造成的错误。

6.2 测试策略

为了执行有效的测试,应该进行有效的技术审查.这样可以在测试开始之前消除许多错误
测试是从部件级开始并且向外朝着整个基于计算机的系统的集成测试
不同的测试方法适用于不同时间点的不同软件工程方法
测试是由软件开发者和一个独立的测试组执行的
测试和调试是不同的活动,但任何测试策略都应该适应调试

6.3 测试方法

单元测试：单元测试是指对软件中最小可测单元进行检查和验证。
- 模块接口测试
- 局部数据结构测试
- 路径测试
- 错误处理测试
- 边界测试
集成测试（cluster testing）：集成测试是在单元测试的基础上，将所有模块按照概要设计要求(如根据结构图)组装成为子系统或系统，进行集成测试。
- 自顶向下
- 自底向上
- 三明治测试
验证测试（Verification test）
- 软件的验证是通过一系列证明符合要求的测试来实现的.设计测试计划和测试用例都是为了确保所有的功能需求得到满足,所有的行为体征和属性得到实现,所有的内容都是准确的,并且正确的呈现,所有的性能需求都得到了满足,文档是正确的,并且可用性和其他需求都得到了满足
- 配置检查
- 验收测试(alpha/beta testinng)
  - α测试即为非正式验收测试。
  - β测试是给用户进行测试

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可用性、可靠性、性能和支持)。尤其注重产品的界面和特色。

α测试可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。

β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，即发放一部分给用户进行测试，并要求用户报告异常情况、提出批评意见，然后软件开发公司再对β版本进行改错和完善。β测试也是黑盒测试。黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。

两者的区别：

测试时间不同：

Beta测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段。

alpha测试简称“α测试”，可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。

测试的目的不同：

α测试的目的是评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能和支持）。尤其注重产品的界面和特色。α测试即为非正式验收测试。

Beta测试是一种验收测试，通过了验收测试，产品就会进入发布阶段。

测试人员及场所不同：

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，α测试不能由程序员或测试员完成。α测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。

Beta测试由软件的最终用户们在一个或多个客户场所进行。开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。

系统测试
- 恢复测试
- 安全性测试
- 压力测试
- 性能测试
- 部署测试
- 配置测试
黑盒测试与白盒测试
- 黑盒测试：就是功能测试，从外部执行测试用例，用以验证待测功能的正确性，而不考虑软件内部处理逻辑，外部测试将程序看做一个黑盒子，只知道输入输出，不知道内部代码，由此设计出测试用例，分为下面几类：
  - 等价类划分：把所有的数据按照某种特性进行归类，而后在每类的数据里选取一个即可。等价类测试用例的设计原则：设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
  - 边界值划分：将每类的边界值作为测试用例，边界值一般为范围的两端值以及在此范围之外的与此范围间隔最小的两个值，如年龄范围为0-150，边界值为0,150，-1,151四个。
  - 错误推测：没有固定的方法，凭经验而言，来推测有可能产生问题的地方，作为测试用例进行测试。
  - 因果图：由一个结果来反推原因的方法，具体结果具体分析，没有固定方法。
  黑盒测试补充博客：blog.csdn.net/weixin_4619…
- 白盒测试：也叫玻璃盒测试,是一种测试用例设计方法.它利用作为构件层设计的一部分所描述的控制结构来生成测试用例.白盒测试是基于过程细节的封闭测试.测试构建内部的数据结构,算法流程与接口,内部测试.（结构测试，Structural testing）.知道程序的代码逻辑，按照程序的代码语句，来设计覆盖代码分支的测试用例，覆盖级别从低至高分为下面几种：
  - 语句覆盖SC： 逻辑代码中的所有语句都要被执行一遍，覆盖层级最低，因为执行了所有的语句，不代表执行了所有的条件判断。
  - 判定覆盖DC： 逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次。
  - 条件覆盖cc： 针对每一个判断条件内的每一个独立条件都要执行一遍真和假。
  - 条件判定组合覆盖 CDC： 同时满足判定覆盖和条件覆盖。
  - 路径覆盖： 逻辑代码中的所有可行路径都覆盖了，覆盖层级最高。
  白盒测试补充博客：blog.csdn.net/xiadanying/…
6. 其他测试
- 回归测试（Regression Testing）：是指对旧的代码修改后（换句话说就是“发布新的版本时”），重新进行的测试，进而验证缺陷得到了正确的修复，同时判断系统的变更是否影响以前的功能。
- 冒烟测试（smoke testing）：冒烟测试是指对提交测试的软件在进行详细深入的测试之前而进行的预测试，这种预测试的主要目的是暴露导致软件需重新发布的基本功能失效等严重问题。
- 调试|调试方法

6.4 面向对象的测试

面向对象的单元测试

单元的概念改变,最小的可测试单元是封装的类,单个操作不能再单独测试,而是作为类的一部分
面向对象的集成测试

集群测试是OO软件集成测试的一个步骤,定义一个协作类集群(通过检查CRC和对象关系模型确定),是通过测试用例来实现的,这些测试用例试图发现协作中的错误.
两种集成方法：
- 基于线程的测试集成了响应系统使用的一个输入或事件所需的一组类.
- 基于使用的测试通过测试那些很少使用服务类在独立的类测试后,下一层的类称为从属类

6.5 环复杂度(cyclomatic complexity)

V(G) = E(edge) - N(Node) + 2（边数，节点数）
V(G) = P(选择节点数) + 1（ 流图中判定结点的数目 ）

例题：如下所示代码(用缩进表示程序块)，要实现语句覆盖，至少需要(1)个测试用例。采用McCabe度量法计算该代码对应的程序流程图的环路复杂性为(3)。

    input A,n
    for i=2 to n
        key=A[i]
        j=i-1
        while j>0 and A[j]>key
            A[j+1]=A[j]
            j=j-1
        A[j+1]=key

解：针对于伪代码而言，我们具体能够根据其关系判断，做得应该是将一组数据，按照从小到大的顺序进行排序的过程，实质是属于插入排序的算法。

首先对于第一个问题，要实现语句覆盖，至少需要多少个测试用例，我们只需要一组数据就能够得到不断重复排序后的输出结果。

对于第二个问题，计算环路复杂度，我们需要做个相关简图，如下图所示，可以根据环路公式V（G）=m-n+2也可以直接数闭环+1，得出其结果为3（13-12+2）

附录：一些可能出现的单词

Deterioration 退化

Wear out 磨损

Longevity 寿命

Convoluted 复杂的；盘旋的 Convoluted Code 复杂的代码（贬义）

pivotal 关键的；核心的

evolutionary 进化的；演化的

incremental 增量

pervasive 普遍的

scenario 设想

specification 规格

inception 开始；开端

collaborative 协作的

accommodate 容纳；接收；适应

manufacture 制造

umbrella activities 普适活动

phase 阶段

compress 压紧；压缩

priority 优先级

delivery 交付；交出

is nothing more than 无非是；不过是

stakeholder 利益相关者

Coupling class 耦合类

depict 描述；描绘

strategy 策略

interaction 交互

capture 捕获

程序员不得不会的计算机科班知识——软件工程篇(下)

第五章 设计（Design）