脚踏实地

访问量 ... 次
访客数 ... 人
总文章数 185 篇
博客已运行 1921 天

软考高级架构师-软件工程（重点）

2025.01.16

考试重点之一，综合分值接近20分，在案例分析或论文写作也可能涉及软件工程主题。

软件过程模型

也称软件开发模型，指在软件开发过程中遵循的一些开发规范、思想、流程。

瀑布模型

瀑布模型严格区分阶段，每个阶段因果关系紧密相连。在实际开发中软件需求完整性、正确性很难确定所以失败率很高，只适合需求明确的项目。 瀑布模型严格串行化，很长时间才能看到结果。瀑布模型要求每个阶段一次完全解决该阶段工作，这不现实。

软考-020

原型模型

原型模型是一种获取需求的模型，适合需求不明确的项目。分为2个阶段，原型开发阶段、目标软件开发阶段。主要分为2种，抛弃型原型、演化型原型。

软考-021

V模型

V模型【瀑布变种】与瀑布模型不同的是，V模型强调测试贯穿于始终。测试分阶段，测试计划提前。

软考-022

W模型

V模型改进，强调测试和开发并行进行。

软考-023

迭代与增量

很多模型都用到了迭代与增量。增量强调一轮一轮有增加，迭代强调一轮一轮再变好。在软件开发中迭代与增量总是一起出现，很少单独出现。

软考-024

螺旋模型

螺旋模型以快速原型为基础，叠加瀑布模型形成，它考虑了风险问题。图中中间为原型模型，每一圈都是瀑布模型。

软考-025

构件组装模型

主要思想，先将组件根据标准构件出来，然后设计组装成系统。以乐高积木为例。

  • 优点：易扩展、易重用、降低成本、安排任务更灵活。
  • 缺点：构件设计要求经验丰富的架构师、设计不好的构件难重用、强调重用可能牺牲其他指标(如性能)、第三方构件质量难控制。

软考-026

快速应用开发RAD

基于构件的软件工程（CBSE）：是利用已有的东西，开发构造新的东西。CBSE体现了购买而不是重新构造的哲学。 CBSE的构件应该具备的特征：

  1. 可组装性:所有外部交互必须通过公开定义的接口进行。
  2. 可部署性:构件总是二进制形式的，能作为一个独立实体在平台上运行。
  3. 文档化:用户根据文档来判断构件是否满足需求。
  4. 独立性:可以在无其他特殊构件的情况下进行组装和部署。
  5. 标准化:符合某种标准化的构件模型。

构件模型要素：

  1. 接口构件通过构件接口来定义，构件模型规定应如何定义构件接口以及在接口定义中应该包含的要素，如操作名、参数以及异常等。
  2. 为使构件远程分布和访问，必须给构件一个特定的、全局唯一的名字或句柄。构件元数据是构件本身相关的数据，比如构件的接口和属性信息。 用户可以通过元数据找到构件提供的服务。构件模型的实现通常包括访问构件的元数据的特定方法。构件是通用实体，在部署的时候，必须对构件进行配置来适应应用系统。
  3. 部署构件模型包括一个规格说明，指出应该如何打包构件使其部署成为一个独立的可执行实体。部署信息中包含有关包中内容的信息和它的二进制构成的信息。

构件的组装(一般都要借助胶水代码)：

  1. 顺序组装:按顺序调用已经存在的构件，可以用两个已经存在的构件来创造一个新的构件。
  2. 层次组装:被调用构件的“提供”接口必须和调用构件的“请求”接口兼容。
  3. 叠加组装:多个构件合并形成新构件，新构件整合原构件的功能，对外提供新的。

软考-027

快速应用开发模型（RAD）是由SDLC（瀑布）、CBSD（基于构件）组成，主流程用瀑布模型，通过引入大量的构件模块来提速，这也是快速开发的原因。

软考-028

统一过程

统一过程方法（UP）基本特性：用例驱动、以架构为中心、迭代和增量。四个阶段：初始、细化、构造、移交。

  • 初始：定义最终产品视图和业务模型、确定系统范围；
  • 细化：设计及确定系统架构、制定工作计划及资源要求；
  • 构造：开发剩余构件和应用程序功能，把这些构件集成为产品，并进行详细测试；
  • 移交：确保软件对最终用户是可用的，进行β测试，制作产品发布版本；

软考-029

9个核心工作流：

  • 过程：业务建模、需求、分析与设计、实现、测试、部署；
  • 支持：配置与管理、项目管理、环境；

软考-030

敏捷开发方法

敏捷方法特点：

  1. 适应性的
  2. 以人为本
  3. 增量迭代，小步快跑
  4. 适合小型项目

敏捷宣言：

  1. 个体和交互胜过过程和工具
  2. 可工作的软件胜过大量的文档
  3. 客户合作胜过合同谈判
  4. 响应变化胜过遵循计划

常见敏捷方法：

  • 极限编程(XP)：价值观【交流、朴素、反馈、勇气】、近螺旋式的开发方法。 软考-031
  • 水晶方法：提倡“机动性”的方法，拥有对不同类型项目非常有效的敏捷过程。
  • SCRUM：侧重于项目管理。 软考-032
  • 特征驱动开发方法(FDD)：认为有效的软件开发需要3要素【人、过程、技术】。定义了6种关键的项目角色:项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。开放式源码:程序开发人员在地域上分布很广【其他方法强调集中办公】。
  • ASD方法：其核心是三个非线性的、重的开发阶段:猜测、合作与学习。
  • 动态系统开发方法(DSDM)：倡导以业务为核心。

逆向工程

逆向工程分为四个层级：

  • 实现级：包括程序的抽象语法树、符号表、过程的设计表示；
  • 结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构；
  • 功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型；
  • 领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如实体关系模型；

与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。

  1. 重构/重组(Restructuring)：重构是指在【同一抽象级别】上【转换系统描述形式】。
  2. 设计恢复(Design recovery)：设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。
  3. 逆向工程(Reverse engineering)：逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。
  4. 正向工程(Forward engineering)：正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。
  5. 再工程/重构工程(Re-engineering)：再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。

软件开发环境

软件开发环境（Software Development Environment，SDE）是指支持软件的工程化开发和维护而使用的一组软件，由软件工具集和环境集成机制构成。

软件开发环境应支持多种集成机制，根据功能的不同，集成机制可以划分为环境信息库、过程控制与消息服务器、环境用户界面三个部分。

  1. 环境信息库。环境信息库是软件开发环境的核心，用以存储与系统开发有关的信息，并支持信息的交流与共享。环境信息库中主要存储两类信息，一类是开发过程中产生的有关被开发系统的信息，例如分析文档、设计文档和测试报告等；另一类是环境提供的支持信息，如文档模板、系统配置、过程模型和可复用构件等。
  2. 过程控制与消息服务器。过程控制与消息服务器是实现过程集成和控制集成的基础。过程集成时按照具体软件开发过程的要求进行工具的选择与组合，控制集成使各工具之间进行并行通信和协同工作。
  3. 环境用户界面。环境用户界面包括环境总界面和由它实行统一控制的各环境部件及工具的界面。统一的、具有一致性的用户界面是软件开发环境的重要特征，是充分发挥环境的优越性、高效地使用工具并减轻用户的学习负担的保证。

净室软件工程

净室软件工程强调以合理的成本开发出高质量的软件，理论基础主要是函数理论和抽样理论。 它提倡开发者不需要进行单元测试(但还是需要传统的模块测试)，而是进行正确性验证和统计质量控制。因为高质量改进管理，降低风险及成本，满足用户需求，提供竞争优势。

净室软件工程技术手段：

  1. 统计过程控制下的增量式开发：控制迭代。
  2. 基于函数的规范和设计：盒子结构。定义3种抽象层次：行为视图(黑盒)->有限状态机视图(状态盒)->过程视图(明盒)。
  3. 正确性验证:净室工程的核心，它使软件质量有了极大提高。
  4. 统计测试和软件认证：使用统计学原理，总体太大时必须采用抽样方法。

净室软件工程缺点：

  1. 太理论化，正确性验证的步骤比较困难且耗时。
  2. 开发小组不进行传统的模块测试，这是不现实的。
  3. 脱胎于传统软件工程，不可避免带有传统软件工程的一些弊端。

需求工程

软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。需求工程主要活动阶段划分：

  1. 需求获取
  2. 需求分析
  3. 形成需求规格(形成SRS)
  4. 需求确认与验证，形成需求基线（经过评审的SRS）
  5. 需求管理，分为变更控制、版本控制、需求跟踪、需求状态跟踪。需求管理是对【需求基线】进行管理。

需求获取

软考-034

需求获取分层：

  1. 业务需求：整体全局视角；
  2. 用户需求：用户视角；
  3. 功能需求（系统需求）：计算机化，分为功能需求、性能需求、设计约束；

按项目管理纬度划分：

  1. 基本需求：用户明示的需求，常规需求；
  2. 期望需求：隐含的需求，用户期望做的需求；
  3. 兴奋需求：多余的需求，镀金；

需求获取方法：

  • 用户面谈：1对1-3，有代表性的用户，了解主观想法，交互好。成本高，要有领域知识支撑。
  • 联合需求计划(JRP)：高度组织的群体会议，各方参与，了解想法，消除分歧，交互好成本高。
  • 问卷调查：用户多，无法–访谈，成本低。
  • 现场观察：针对较为复杂的流程和操作。
  • 原型化方法：通过简易系统方式解决早期需求不确定问题。
  • 头脑风暴法：群人围绕新业务，发散思维，不断产生新的观点。

需求分析

结构化开发在需求分析阶段会建立3中模型： 软考-035

  1. 功能模型：较为重要，数据流图（DFD）；
  2. 行为模型：状态转换图，状态-事件；
  3. 数据模型：重要，E（实体）-R（联系）图；

UML图

UML是统一建模语言，与平台无关，语言无关具有通用性。主要由以下3个部分组成：

  1. 构造块：重点
    • 图主要分为静态图（结构图）和动态图（行为图） 软考-036
    • 关系
    • 事物
      1. 结构事物：最静态的部分，包括：类、接口、协作、用例、活动类、构件和节点。
      2. 行为事物：代表时间和空间上的动作。包括：消息、动作次序、连接。
      3. 分组事物：看成是个盒子，如：包、构件。
      4. 注释事物：UML模型的解释部分。描述、说明和标注模型的元素。
  2. 规则
    • 命名：为构造块命名
    • 范围：给一个名字以特定含义的语境
    • 可见性：怎样使用或看见名字
    • 完整性：事物如何正确、一致地相互联系
    • 执行：运行或模拟动态模型的含义是什么
  3. 公共机制：所有的元素要达成的共识。
    • 规格说明：事物语义的细节描述，它是模型真正的核心
    • 修饰：通过修饰来表达更多的信息
    • 公共分类：类与对象、接口与实现
    • 扩展机制：允许添加新的规则
用例图

用例图描述一组用例、参与者及它们之间的关系。 软考-037

  • 用户角度描述系统功能；
  • 参与者是外部触发因素；
  • 用例是功能单元；

用例模型建立流程：

  1. 识别参与者【参与者：用户、组织、外部系统、时间】；
  2. 合并需求获得用例；
  3. 细化用例描述（用例规约）；
    软考-039
  4. 调整用例模型（可选步骤）【关系包括：包含关系、扩展关系、泛化关系】；
    软考-038
类图和对象图
  • 类图：类图描述一组类、接口、协作和它们之间的关系。
  • 对象图：对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。

软考-040

  • 类名，方法名，属性名，要能看懂；
  • 多重度：表示图中的对应关系，一对一，一对多，多对多；
    1. 1：表示一个集合中的一个对象对应另一个集合中的一个对象。
    2. 0..：表示一个集合中的一个对象对应另一个集合中的0个或多个对象。(可以不对应)
    3. 1..*：表示一个集合中的一个对象对应另一个集合中的一个或多个对象。(至少对应一个)
    4. 表示一个集合中的一个对象对应另一个集合中的多个的对象。
  • 关系：重点，类间关系的语义强度，由弱到强如下：
    1. 依赖关系：一个事物发生变化影响另一个事物；
    2. 关联关系：描述了一组链，链是对象之间的连接关系；
      1. 聚合关系：整体与部分生命周期不同
      2. 组合关系：整体与部分生命周期相同；
    3. 实现关系：接口与类之间的关系；
    4. 泛化（继承）关系：特殊/一般关系； 软考-041
顺序图

顺序图（序列图）是一种交互图，它强调对象之间消息发送的顺序，同时显示对象之间的交互。 顺序图通过消息来传递信息，分为四种类型：同步消息、异步消息、简单消息、返回消息。

软考-042

顺序图的组合片段：

  • Loop【循环】：如果满足“循环条件”，则重复执行本框中的内容。
  • Alt【条件分支】：满足条件1，则执行条件1对应的内容，满足条件2则执行条件2对应的内容。
  • Opt【可选分支】：如果条件满足，则执行框中内容，否则跳过不执行。

软考-043

通信图

通信图（协作图），也是一种交互图，强调对象之间存在的消息收发关系，而不专门突出这些消息发送的时间顺序。

软考-044

状态图

状态图是对类描述的补充，用于展现此类对象所具有的可能状态，以及某些事情发生时其状态转移情况。

软考-045

活动图

活动图是一种特殊的状态图，活动图描述一个操作中要进行的各项活动的执行流程。同时，也常被用来描述一个用例的处理流程或某种交互流程。 活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流，它强调对象间的控制流程。

软考-046

软考-047

定时图

定时图也叫计时图，也是一种交互图，用于展示交互过程中的真实时间信息，具体描述对象状态变化的时间点以及维持特定状态的时间段。

软考-048

构件图与包图

构件图描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。 构件图用于表示系统的静态设计实现视图。对于由小的部件构件大的系统来说，构件图是很重要的。构件图是类图的变体。

包图，包的图标像是一个带标签的文件夹，包的基本思想是把共同工作的元素放到一个文件夹中。 例：多个类或构件组成了一个子系统，就可以将它们放到一个包中。

构件图聚焦于某一个功能，把相关的类、接口放在一起，需对外提供接口；而包图是将共同工作的元素放在一起。

软考-049

部署图

部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。

软考-050

SysML

MBSE（ModelBasedSystemsEngineering，基于模型的系统工程），系统工程包括软件工程，MBSE的三大支柱：

  1. 【建模语言】沟通标准化，MBSE的核心。典型代表：SysML，OPM。对标【软件工程】中UML
  2. 【建模思路】类似于路线图，如：INCONSE面向对象系统工程法。对标【软件工程】中面向对象开发
  3. 【建模工具】如：Agilian，Modelio。对标【软件工程】中Visio、Rose

SysML是类似UML（统一建模语言）的一种系统建模语言。SysML主要包括行为图、需求图、结构图。

软考-051

需求图

软考-052

SysML中的需求关系：包含、跟踪、继承需求、改善、满足、验证和复制。

  • 包含(Include)：需求可以且只能包含其他需求。
  • 跟踪(Trace)：对提供方元素（位于箭头端）的修改可能会导致对客户端元素(位于尾端)修改的需要。
  • 继承(deriveReqt)：一个需求可以继承另一个需求的属性。
  • 改善(refine)：表示一个需求改进了另一个需求的满足程度。
  • 满足(satisfy）：一般是模块满足某种需求。
  • 验证(verify)：表示一个需求验证了另一个需求的正确性。
  • 复制(Copy)：表示一个需求复制了另一个需求的特性。

形成需求规格

有两种形成需求规格的方法（需求定义）：

  1. 严格定义法：
    • 所有需求都能够被预先定义
    • 开发人员与用户之间能够准确而清晰地交流
    • 采用图形文字可以充分体现最终系统
  2. 原型法：
    • 并非所有的需求都能在开发前被准确的说明
    • 项目参加者之间通常都存在交流上的困难
    • 需要实际的、可供用户参与的系统模型
    • 有合适的系统开发环境
    • 反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法

需求确认与验证

在完成需求说明书后，召集甲方的人来验证需求，确定需求是否正确，包括需求评审、需求测试。 软考-053

需求管理

需求跟踪

实际应用中简单有效的跟踪需求，将需求与功能用表格一一对应，能清晰的显示出哪些需求已经实现，哪些需求尚未实现。 软考-054

需求变更管理

简单分为3个步骤： 软考-055

  1. 问题分析和变更描述
  2. 变更分析和成本计算
  3. 变更实现

详细划分为10个步骤：

  1. 明确问题：明确变更原因
  2. 书面申请：防止扯皮不认账
  3. 判断变更需求类别：性能类别、功能类别
  4. 评估变更影响：性能影响、功能影响、成本控制
  5. 判断变更紧急级别：紧急、重要、一般
  6. 沟通确认：与变更方内部主要人员确认
  7. 明确解决方案
  8. 审批管理
  9. 执行变更
  10. 版本控制

系统分析与设计

软件系统建模

论文考点 软考-056

常见的建模方法：

  1. 结构化建模方法：结构化建模方法是以过程为中心的技术，可用于分析一个现有的系统以及定义新系统的业务需求。结构化建模方法所绘制的模型称为数据流图(DFD)。对于流程较为稳定的系统可考虑结构化建模方法。
  2. 信息工程建模方法（或数据库建模方法）：信息工程建模方法是一种以数据为中心，但过程敏感的技术，它强调在分析和研究过程需求之前，首先研究和分析数据需求。 信息工程建模方法所创建的模型被称为实体联系图(ERD)。主要用于数据建模。
  3. 面向对象建模方法：面向对象建模方法将“数据”和“过程”集成到被称为“对象”的结构中，消除了数据和过程的人为分离现象。 面向对象建模方法所创建的模型被称为对象模型。随着面向对象技术的不断发展和应用，形成了面向对象的建模标准，即UML(统一建模语言)。 UML定义了几种不同类型的模型图，这些模型图以对象的形式共建一个信息系统或应用系统，是目前比较常用的建模方法。

人机界面设计

黄金3法则：

  1. ★置于用户控制之下：
    • 以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
    • 提供灵活的交互
    • 允许用户交互可以被中断和撒销
    • 当技能级别增加时可以使交互流水化并允许定制交互
    • 使用户隔离内部技术细节
    • 设计应允许用户和出现在屏幕上的对象直接交互
  2. ★减少用户的记忆负担
    • 减少对短期记忆的要求
    • 建立有意义的缺省
    • 定义直觉性的捷径
    • 界面的视觉布局应该基于真实世界的修喻
    • 以不断进展的方式褐示信息
  3. ★保持界面的一致性
    • 允许用户将当前任务放入有意义的语境
    • 在应用系列内保持一致性
    • 如过去的交互模型已建立起了用户期望，除非有迫不得已的理由，不要改变它

结构化设计

  • 概要设计【外部设计】：功能需求分配给软件模块，确定每个模块的功能和调用关系，形成模块结构图。
  • 详细设计【内部设计】：为每个具体任务选择适当的技术手段和处理方法。

结构化设计原则：

  1. 模块独立性原则（高内聚、低耦合）
  2. 保持模块的大小适中
  3. 多扇入，少扇出（被人调用称为扇入，调用别人称为扇出）
  4. 深度和宽度均不宜过高

内聚类型分为（由高到低）：

  • 功能内聚：完成一个单一功能，各个部分协同工作，缺一不可
  • 顺序内聚：处理元素相关，而且必须顺序执行
  • 通信内聚：所有处理元素集中在一个数据结构的区域上
  • 过程内聚：处理元素相关，而且必须按特定的次序执行
  • 时问内聚(瞬时内聚)：所包含的任务必须在同一时间间隔内执行
  • 逻辑内聚：完成逻辑上相关的一组任务
  • 偶然内聚(巧合内聚)：完成一组没有关系或松散关系的任务

耦合类型分为（由低到高）： 非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的 数据耦合：组模块借助参数表传递简单数据 标记耦合：组模块通过参数表传递记录信息(数据结构) 控制耦合：模块之间传递的信息中包含用于控制模块内部逻辑的信息 外部耦合：组模块都访问同一全局简单变量，而且不是通过参数表传递该全局变量的信息 公共耦合：多个模块都访问同一个公共数据环境 内容耦合：一个模块直接访问另一个模块的内部数据；一个模块不通过正常入口转到另一个模块的内部；两个模块有一部分程序代码重叠；一个模块有多个入口

模块的四个要素：

  1. 输入和输出：模块的输入来源和输出去向都是同一个调用者，即一个模块从调用者那儿取得输入，进行加工后再把输出返回调用者。
  2. 处理功能：指模块把输入转换成输出所做的工作。
  3. 内部数据：指仅供该模块本身引用的数据。
  4. 程序代码：指用来实现模块功能的程序。

面向对象设计

软考-057

类的分类：

  • 边界类：API接口、用户界面
  • 控制类：应用逻辑、业务逻辑、数据访问逻辑
  • 实体类：数据

面向对象设计原则：

  1. 单一职责原则：设计目的单一的类
  2. 开放-封闭原则：对扩展开放，对修改封闭
  3. 李氏(Liskov)替换原则：子类可以替换父类
  4. 依赖倒置原则：要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程
  5. 接口隔离原则：使用多个专门的接口比使用单一的总接口要好
  6. 组合重用原则：要尽量使用组合，而不是继承关系达到重用目的（继承耦合较高）
  7. 迪米特(Demeter)原则（最少知识原则）：一个对象应当对其他对象有尽可能少的了解

软件测试

软件测试类型分为：

  1. 静态测试：桌前检查、代码审查、代码走查。主要做静态分析：
    • 控制流分析：是否存在没有使用的语句/无法达到的语句/调用并不存在的子程序。
    • 数据流分析：引用未定义的变量、对以前未使用的变量再次赋值。
    • 接口分析：模块之间接口的一致性、子程序和函数之间的接口一致性、函数形参与实参的数量、顺序、类型的一致性。
    • 表达式分析：括号不配对、数组引用越界、除数为零。
  2. 动态测试：白盒测试（关注内部结构逻辑）、灰盒测试（介于两者之间）、黑盒测试（关注输入输出以及功能）、自动化测试（先写脚本后自动化执行）。

白盒测试与黑盒测试

  • 白盒测试【结构测试】：主要用于单元测试阶段。

    1. 控制流测试【逻辑覆盖测试（语句覆盖最弱，路径测试覆盖最强）】
    2. 数据流测试（不常考）
    3. 程序变异测试【错误驱动测试】（不常考）

    软考-058

  • 黑盒测试【功能测试】：主要用于集成测试、确认测试盒系统测试阶段。

    1. 等价类划分：不同等价类，揭示不同问题；有效等价类/无效等价类。
    2. 边界值分析：1<=x<=10，可取x的值为0、1、10和11作为测试数据。
    3. 错误推测：依靠测试人员的经验和直觉。
    4. 判定表：最适合描述在多个逻辑条件取值的组合所构成的复杂情况下，分别要执行哪些不同的动作。
    5. 因果图：根据输入条件与输出结果之间的因果关系来设计测试用例。

    软考-059

软件测试阶段

软件测试阶段，是局部到整体的过程：

  • 单元测试：依据【详细文档】，模块测试、模块功能、性能、接口等；
  • 集成测试：依据【概要设计】，模块间的接口；
  • 系统测试：依据【需求文档】，包括功能测试、性能测试、验收测试、压力测试等。其中验收测试是依据【需求文档】，验证软件与需求的一致性。经过内部确认测试、Alpha测试、Beta测试、验收测试；

其他测试：

  • AB测试：多版本同时使用，利于收集各版本的用户反馈，评估出最好版本。故也算是一种【网页优化方法】。
  • Web测试：Web系统测试与其他系统测试测试内容基本相同，只是测试重点不同。Web代码测试包括：源代码规则分析、链接测试、框架测试、表格测试、图形测试等方面。
  • 链接测试，链接测试可分为3个方面：
    1. 测试所有链接是否按指示的那样确实链接到了该链接的页面。
    2. 测试所链接的页面是否存在。
    3. 保证Web应用系统上没有孤立的页面。
  • 表单测试：验证服务器是否能正确保存这些数据，后台运行的程序能否正确解释和使用这些信息。测表单测试提交操作的完整性。
  • 回归测试：测试软件变更之后，变更部分的正确性和对变更需求的符合性。

集成测试策略

集成测试一般在单元测试之后，单个模块测试好后，就需要考虑将他们整合在一块进行测试，常见策略：

  1. 一次性组装【因测试不全面故风险高】；
  2. 增量式组装【测试全面但效率低】
    • 自顶向下【需要桩模块】
    • 自底向上【需要驱动模块】
    • 混合式【需要驱动模块和桩模块】

软考-060

性能测试

  • 负载测试：各种工作负载下系统的性能；
  • 压力测试【测上限】：系统的瓶颈或不能接受的性能点；
  • 强度测试【测下限】：系统资源特别低的情况下运行；
  • 容量测试【并发测试】：同时在线的最大用户数；
  • 可靠性测试：MTTF之类的参数；

系统运行与维护

遗留系统演化策略： 软考-061

新旧系统转换策略：（新系统上线后，要将老系统下线）

  • 直接转换策略：老系统停，新系统上线，同一时间只运行一个系统，但成本低风险高；
  • 并行转换策略：老系统不停，新系统上线，成本增加风险大大降低；
  • 分段转换策略：不一次性将新系统一次上线，分批将子系统上线，总之不是一次性完成系统的切换；

数据转换与迁移：

  1. 抽取：抽取旧数据库中的数据；
  2. 转换：系统切换前通过工具转移、系统切换前采用手工录入、系统切换后通过新系统生成；
  3. 装载：将数据装载到新数据库；

影响软件可维护性的因素：

  • 【可理解性】是指通过阅读源代码和相关文档，了解软件的功能和如何运行的容易程度。
  • 【可修改性】是指修改软件的难易程度。
  • 【可测试性】是指验证软件程序正确的难易程度。可测试性好的软件，通常意味着软件设计简单、复杂性低。因为软件的复杂性越大，测试的难度也就越大。
  • 【可靠性】一个软件的可靠性越高，需要维护的概率就会越低。
  • 【可移植性】是指将软件从一个环境移植到新的环境下正确运行的难易程度。软件运行环境的变化是软件维护的一种常见情形，可移植性好的软件会降低维护的概率。

软件维护类型：

  • ★正确性维护（改正性维护）【修BUG】：识别和纠正软件错误/缺陷，测试不可能发现所有错误。
  • ★适应性维护【应变】：指使应用软件适应环境变化【外部环境、数据环境】而进行的修改。
  • ★完善性维护【新需求】：扩充功能和改善性能而进行的修改。
  • ★预防性维护【针对未来】：为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使系统适应各类变化而不被淘汰。经典实例：【专用】报表改【通用】报表。
考试