软考架构师|软件工程 (12–19 分) 核心考点④ 测试、维护、用例/对象关系、设计模式

2.4测试

2.4.1测试类型

动态测试：白盒测试，黑盒测试，灰盒测试

静态测试：桌前检查，代码审查，代码走查、静态分析方法

2.4.2测试方法

2.4.2.1静态分析方法

    控制流分析：是否存在没有使用的语句、无法达到的语句、调用不存在的子程序，解决“逻辑路径是否完整、合理” 的问题；

    数据流分析：括初始化、赋值、或引用数据等序列的异常，引用未定义的变量、对以前未使用的变量再次赋值，解决“变量使用是否正确、安全” 的问题

    接口分析：模块之间接口的一致性、子程序和函数之间的接口一致性、函数形参与实参的数量、顺序、类型的一致性

    表达式分析：括号不配对，数组引用越界，除数为零。

2.4.2.2白盒测试【结构测试】

主要用于单元测试阶段。

控制流测试

【逻辑覆盖测试（语句覆盖最弱，路径测试覆盖最强）】

主要关注程序的控制结构，确保所有可能的执行路径都经过测试。

语句覆盖最弱：每条语句至少执行一次。

判定覆盖：每个判断（如if、while、for 等的条件表达式）的真假分支至少执行一次，满足判定覆盖一定满足语句覆盖。注重结果

条件覆盖：每个判断中的每个条件（如复合条件a > b && c > d中的 a > b 和 c > d）的真假情况至少执行一次。注重过程条件

满足条件覆盖不一定满足判定覆盖，满足判定覆盖也不一定满足条件覆盖。

比如：复合条件a > b && c > d中，

条件覆盖的用例为2组：（a>b 为真，c>d为假）,（a>b 为假，c>d为真），这两组用例即可满足条件覆盖，但是不满足判定覆盖，因为结果都为false

条件覆盖> 判定覆盖 > 语句覆盖（通常情况下）。

判定覆盖和条件覆盖，侧重点不同，互不包含,比如：复合条件a > b && c > d中，条件组合覆盖的用例为4组，需要考虑所有情况。

条件组合覆盖：包含判定覆盖和条件覆盖。局限于单个判定内部，随条件数量呈2ⁿ增长，相对可控，如n个判定各含k个条件，则总组合数为2^k₁ + 2^k₂ + … + 2^kₙ。条件组合覆盖还不能保证程序中所有可能的路径都至少经过一次。

路径覆盖：选取足够多的测试用例，使得每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求每条环路路径至少经过一次）

数据流测试

旨在验证程序数据的正确性和合理性

错误驱动测试

一种测试策略，基于程序可能发生的错误的地方进行测试。

2.4.2.3黑盒测试【功能测试】

主要用于集成测试，确认测试和系统测试阶段基于软件需求规格说明书

2.4.3测试阶段

    自顶向下调用被测模块需要编写桩模块，不需要编写额外的驱动模块

    自底向上被被测模块所调用，需要编写驱动模块

    混合式桩模块和驱动模块都需要编写

2.4.4自动化测试工具

    线性脚本，纯录制，录啥播啥一步不落。是录制手工执行的测试用例得到的脚本，这种脚本包含所有的击键、移动、输入数据等，所有录制的测试用例都可以得到完整的回放。

    结构化脚本，有逻辑，像编程，类似于结构化程序设计，具有各种逻辑结构、函数调用功能。

    共享脚本，有逻辑，像编程共享脚本是指可以被多个测试用例使用的脚本，也允许其他脚本调用。共享脚本可以在不同主机、不同系统之间共享，也可以在同一主机、同一系统之间共享。

    数据驱动脚本，数据和脚本分开，换数据就换用例。将测试输入存储在独立的(数据)文件中，而不是存储在脚本中。可以针对不同数据输入实现多个 测试用例。

    关键字驱动脚本，关键字描述任务，更像自然语言。关键字驱动脚本是数据驱动脚本的逻辑扩展。它将数据文件变成测试用例的描述，采用一些关键字指定要执行的任务

2.4.5性能测试

    负载测试：各种工作负载下系统性能，各种负载下系统的表现

    压力测试：测上限，系统的瓶颈或不能接受的性能点

    强度测试（持久性测试）：测下限，资源特别低的情况下运行（限定条件下的极限也属于强度）

    容量测试：并发测试同时在线最大用户数

    可靠性测试：MTTF之类的参数 (5.1章节)

10万人请求会怎么样。

未超过拐点，则是压力测试

超过拐点，则属于负载测试

2.4.6其他测试

2.4.7测试和调试

在软件开发流程中，测试是为了发现软件中的缺陷，而调试是在测试发现缺陷之后，对缺陷进行定位、分析并解决的过程。测试在前，调试在后，调试后还得继续测试。

2.4.8Alpha测试和Beta测试，系统测试，集成测试

        Alpha测试：在软件开发环境下由用户进行的测试，或者在模拟实际操作环境中进行的测试，主要评鉴软件产品的功能，局域化，界面，可使用性，性能

        Beta测试：测试实在实际环境中有多个用户进行测试，并将测试过程中发现的错误问题反馈给开发者

    系统测试：在集成测试之后，主要采用黑盒测试方法检查系统是否符合软件需求。

    集成测试：在单元测试之后进行的，主要测试模块间的接口和集成功能，也不属于验收测试阶段。

2.4.9单元测试：方法层测试，类层次的测试，类树层次的测试

    方法层次（最底层）：测试对象，类里面的单个方法，相当于传统测试里的单个函数/过程测试，只关心输入输出对不对，不关心它属于哪个类，和其他方法有没有关系

例子：等价类划分，组合功能测试，递归函数测试，多态消息测试

    类层次的测试（中间层）：测试对象，整个类。不再只测一个方法，而是测一个类内部多个方法之间的协作。

例子：不变式边界测试，模态类模拟，非模态类测试

    类树层次的测试：测试对象，继承关系形成的类树

例子：多态服务测试，展平水平

2.5维护

2.5.1遗留系统处置

高水平低价值：针对“信息孤岛”—集成（公司刚开发的各个高水平的系统，集成）

高水平高价值：改造包括系统功能的增强和数据模型的改造两个方面—改造，包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变；数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。

低水平低价值：淘汰，完全淘汰是一种极端性策略，一般是企业的业务产生了根本变化，遗留系统已经基本上不再适应企业运作的需要；或者是遗留系统的维护人员、维护文档资料都丢失了。经过评价，发现将遗留系统完全淘汰，开发全新的系统比改造旧系统从成本上更合算。

低水平高价值：业务价值，开发新系统时，需要完全兼容遗留系统的功能模型和数据模型—继承（开发较早的系统，水平较低），新老系统必须并行运行一段时间，再逐渐切换到新系统上运行

2.5.2维护类型

影响可维护性的因素

维护类型

    正确性维护：【修BUG】，识别和纠正软件错误/缺陷，测试不可能发现所有错误

    适应性维护：【应变】指使应用软件适应环境变化，外部/数据环境而进行的修改

    完善性维护：【新需求】扩充功能和改善性能而进行的修改

    预防性维护：【针对未来】适应未来的软硬件环境变化，主动增加预防性的新功能，以使用系统适应各类变化而不被淘汰。经典实例：专用改为通用

2.6 补充

2.6.1 面向对象开发方法

面向对象开发方法主要包括需求分析、系统分析、系统设计和系统实现四个阶段

2.6.2 面向对象的分析和设计模型

面向对象的分析模型（输入）主要由顶层架构图、用例与用例图和领域模型（或类图的雏形）构成；

设计模型（输出）则包含以

包图（或组件图、部署图，根据具体设计层面，包图为常见核心）表示的软件体系结构图、用交互图表示的用例实现图、

完整精确的类图、

用于描述复杂对象的状态图

用于描述流程化处理过程的活动图等。

2.6.3 用例之间的关系继承

    取代继承（子对象在继承父对象特性后取代其位置）、

    包含继承（子对象在完全继承父对象特性后，再继承其他对象的特性，使其能力不少于父对象）、

    受限继承（子类继承父类功能进行限制，而不是扩展功能）、

    特化继承（特化继承是指子类是父类的一个特殊版本，子类在父类的基础上进行更具体的定义和细化，但一般不会通过继承多个父类来扩展功能超出原单一父类范围）

2.6.4 用例之间的关系

用例图：描述一组用例，参与者与他们（用例）之间的关系，即参与者对应的功能。

    细化：用例名称，用例ID，角色，用例说明，前置条件，基本事件流，其他事件流，异常事件流，后置条件

    用例是功能单位

用例关系：

包含关系（一个用例必须包含另一个用例的功能），

扩展关系（一个用例可以在特定条件下扩展到另一个用例功能）

泛化（继承）关系：多个用例共同拥有一种类似的结构和行为的时候，抽象父用例。

参与者的关系：继承。表示一个参与者是另一个参与者的的“特殊化”

2.6.5 类之间的关系

依赖：一个事务发生变化影响另一个事务

聚合：整体与部分可独立存在

组合：整体与部分不可独立存在

泛化:特殊元素的对象可替代一般元素的对象，子类代替父类

2.6.6 COM / Component Object Model（组件对象模型）

COM不支持任何形式的实现继承。

COM支持两种形式的对象组装:包含(Containment)和聚集(Aggregation)。

（1）包含。包含是一个对象拥有指向另一个对象的唯一引用。外部对象只是把请求转发给内部对象，所谓转发就是调用内部对象的方法。包含能够重用内含于其他构件中的实现，是完全透明的。

（2）聚集。如果包含层次较深，或者被转发的方法本身相对简单，那么包含会存在性能问题。因此，COM 定义了第二种重用形式—聚集。聚集是直接把内部对象的接口引用传给外部对象的用户,而不再转发请求。保持透明性是很重要的，因为外部对象的用户无法辨别哪个特定接口是从内部对象聚集而来的。

2.6.7 UML2

UML2.0基础结构的设计目标是定义一个元语言的核心，通过对此核心的复用，除了可以定义一个自展的UML元模型，还可以定义其他模型，包括MOF,CWM。由共用核心库，所以UML和MOF，CWM在体质结构上更加一致。上层结构定义了面向建模用户的各种UML模型的语法，语义和表示

2.6.8 UML中事务

UML中有4种事物:

1、结构事物是UML模型中的名词。它们通常是模型的静态部分,描述概念或物理元素；

2、行为事物是UML模型的动态部分。它们是模型中的动词,描述了跨越时间和空间的行为；

3、分组事物是UML模型的组仅部分。它们是—些由模型分解成的盒子；

4、注释事物是UML模型的解释部分。这些注释事物用来描述、说明和标注模型的任何元素。

2.6.9 UML中的关系

UML中有4种关系：

1、依赖是两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义；

2、关联是一种结构关系，描述了一组链，链式对象之间的连接，聚合是一种特殊类型的关联，描述整体与部分间的结构关系；

3、泛化是一种特殊一般关系，特殊元素的对象可替代一般元素的对象；

4、实现是类元之间的语义关系，其中一个类元指定了由另一个类元保证执行的契约。

2.6.10 模块化设计

模块是指执行某一特定任务的数据结构和程序代码

模块的接口是模块与其他模块自身的内部特性，与外部模块也具有相关性

每个模块完成相对独立的特定子功能，与其他模块之间的关系最简单

模块设计的重要原则：高内聚，低耦合

2.6.11 设计模式

创建型模式通过采用抽象类所定义的接口，封装了系统中对象如何创建、组合等信息，其代表有工厂方法模式（Factory Method Pattern）、抽象工厂模式（Abstract Factory Pattern）、建造者模式（Builder Pattern）、原型模式（Prototype Pattern）、单例模式（Singleton Pattern）等。结构型模式主要用于如何组合己有的类和对象以获得更大的结构，其代表有适配器模式（Adapter Pattern）、代理模式（Proxy Pattern）、桥接模式（Bridge Pattern）、外观模式（Facade Pattern）、装饰者模式（Decorator Pattern）、享元模式（Flyweight Pattern）、组合模式（Composite Pattern）等。适代（四代）桥，外观装饰 享元组合行为型模式主要用于对象之间的职责及其提供服务的分配方式，其代表有责任链模式（Chain of Responsibility Pattern）、命令模式（Command Pattern）、解释器模式（Interpreter Pattern）、迭代器模式（Iterator Pattern）、中介者模式（Mediator Pattern）、备忘录模式 （Memento Pattern）、观察者模式（Observer Pattern）、状态模式（State Pattern）、策略模式（Strategy Pattern）、模板方法模式（Template Method Pattern）、访问者模式（Visitor Pattern）等。

工厂模式：定义一个用于创建对象的接口，让子类决定将哪一个类实例化，使一个类的实例化延迟到其子类。

抽象工厂模式：为创建一系列相关或相互依赖的对象提供了一个接口。

建造者模式：将复杂对象的构建与其表示相分离，这样相同的构造过程可以创建不同的对象。

原型模式：允许对象在不了解要创建对象的确切类以及如何创建等细节的情况下创建自定义对象。

Bridge(桥接)模式，它将抽象部分与现实部分分离，使得它们两部分可以独立地变化。

中介者模式：使用各对象不需要显式的相互调用，从而使其耦合松散。

命令模式：将一个请求封装成一个对象，从而使得用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。

访问者（Visitor）模式：是一种对象的行为模式，用于表示一个作用于某对象结构中的各元素的操作，它使得用户可以在不改变各元素的类的前提下，定义作用于这些元素的新操作

装饰模式:动态地给一个对象添加一些额外的职责.它提供了用子类扩展功能的一个灵活的替代,比派生一个子类更加灵活