[开发测试]02333软件工程要点及考点

软件工程概念的提出和发展

1.从事软件开发实践和软件工程项目管理的思想基础：正确认识软件开发

2.20 世纪 60 年代以来，随着计算机的广发应用，软件生产率、软件质量满足不了社会发展的需求，成为社会、经济发展的制约因素，人们通常把这些现象称为软件危机

3.软件工程概念的提出，其目的是倡导以工程的原理、原则和方法进行软件开发，以期解决出现的软件危机，软件工程这一术语首次出现在 1968 年的NATO（北大西洋公约组织）会议上

4.软件工程是应用计算机科学理论和技术以及工程管理的原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究对象的学科

5.20 世纪 60 年代末到 80 年代初，提出瀑布模型，开发了诸多过程式语言（如 C 语言、Pascal 语言）和开发方法（如 Jackson 方法、结构化方法）、开发了一些支持工具（调试工具、测试工具）等,前期主要研究系统实现技术，后期开始关注软件质量和软件工程管理

6.20 世纪 80 年代以来，提出《软件生存周期过程》、开展计算机辅助工程（CASE）、面向对象语言（如 Smalltalk、C++）、提出面向对象软件开发方法等,开展了一系列有关软件生产技术，特别是软件复用技术和软件生产管理的研究和实践

7.计算机软件一般是指计算机系统中的程序及其文档，程序是对计算机任务的处理对象和处理规则的描述；文档是为了理解程序所需的阐述性资料

8.软件开发的本质：不同抽象层术语之间的映射，以及不同抽象层处理逻辑之间的映射，实现这一映射的基本途径：系统建模。内容：一是如何实现这样的映射，这是技术层面的问题，而是如何管理这样的映射，以保障映射的有效性和正确性，这是管理层面的问题

9.模型，简单来说，是待建系统的任意抽象，其中包括所有的基本能力、特性或其他一些方面，而没有任何冗余的细节，进一步说，模型是在特定意图下所确定的角度和抽象层次上对物理系统的描述，通常包含对该系统边界的描述、对系统内各模型元素以及它们之间关系的语义描述

10.软件系统模型分为概念模型和软件模型，软件模型又分为设计模型、实现模型、部署模型，在软件开发领域，分层的基本动机是为了控制开发的复杂性

软件需求与软件需求规约

1.软件需求是任何软件工程项目的基础

2.一个需求描述了待开发产品/系统功能上的能力、性能参数或其他性质

3.需求的基本性质：

• 必要的：该需求是用户所要求的
• 无歧义的：该需求只能用一种方式解释
• 可测的：该需求是可进行测试的
• 可跟踪的：该需求可从一个开发阶段跟踪到另一个阶段
• 可测量的：该需求是可测量的

4.需求分为功能需求和非功能需求，非功能需求包括性能需求、外部接口需求、设计约束、质量属性，功能需求是整个需求的主体

5.需求发现技术：

• 自悟：需求人员把自己作为系统的最终用户，审视该系统并提出问题
• 交谈：为确定系统应该提供的功能，需求人员通过提出问题/用户回答这一方式，直接询问用户需要的是一个什么样的系统
• 观察：通过观察用户执行其现行的任务和过程，或通过观察他们如何操作与所期望的新系统有关的现有系统，了解系统运动的环境，特别是了解要建立的新系统与现存系统、过程以及工作方法间必须进行的交互
• 小组会：举行客户和开发人员的联席会议，与客户组织的一些代表共同开发需求
• 提炼：复审技术文档，并提取相关信息

6.需求规约是一个软件/产品/系统所有需求陈述的正式文档，它表达了一个软件/系统的概念模型

7.需求规约一般需要满足以下 4 个基本性质：

• 重要性和稳定性程度：按需求的重要性和稳定性对需求进行分级，如基本需求、可选需求和期望需求
• 可修改的：在不过多地影响其他需求的前提下，可以容易地修改一个单一需求
• 完整的：没有被遗漏的需求
• 一致的：不存在互斥的需求

8.需求规约的三种表达方式

• 非形式化的需求规约：以一种自然语言来表达需求规约，如同使用一种自然语言写了一篇文章，适用于规模比较小的、复杂程度不大高的小型软件项目，或在获取 SRS 时使用的
• 半形式化的需求规约：以半形式化符号体系（包括术语表、标准化的表达格式等）来表达需求规约；一些有能力的组织针对大型复杂项目，在开发需求文档时往往使用系统化的需求获取、分析技术和工具
• 形式化的需求规约：以一种基于良构数学概念的符号体系来编制需求规约，一般常伴有解释性注释的支持，主要针对质量（特别是安全性）要求比较高的软件产品/系统或其中某一部分

9.需求规约的作用：

• 需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现
• 对于项目的其余大多数工作，需求规约是一个管理控制点
• 对于产品/系统的设计，需求规约是一个正式的、受控的起始点
• 需求规约是创建产品验收测试计划和用户指南的基础，即基于需求规约一般还会产生另外两个文档 – 初始测试计划和用户系统操作描述

结构化需求分析

1.在进行软件系统/产品的需求工作中，通常面临三大挑战：
问题空间理解；人与人之间的通信；需求的变化性
应对三大挑战的软件开发方法：
结构化方法、面向数据结构方法、面向对象方法

2.需求分析的首要任务是建立系统的功能模型，结构化分析方法给出一种能表达功能模型的工具，即数据流图，简称DFD 图，常用在分析阶段的图形工具

3.建模过程 – ‘自顶向下，逐步求精’
NO.1 建立系统环境图，确定系统语境
NO.2 自顶向下，逐步求精，建立系统的层次数据流图
NO.3 定义数据字典（用于定义数据流图包含的所有数据流和数据存储的数据结构，直到给出构成以上数据的各数据项的基本数据类型的工具是数据字典）
NO.4 通过结构化自然语言、判定表、判定树等工具，来描述加工

定义数据结构的符号
= 定义为 -顺序
| 选择
{ } 重复
m…n 子界

4.结构化语言是介于自然语言和形式语言之间的一种半形式语言

5.把要解决问题的过程分解为多个步骤或阶段，每一步是对上一步结果的细化，以接近问题的解法，该方法称为逐步求精

6.结构化设计分为总体设计和详细设计，总体设计将系统分解成一个个黑盒子，详细设计描述其细节

7.模块：软件中具有特定标识的独立成分，是执行一个特殊任务的一个过程以及相关的数据结构

8.模块调用：模块之间的一种使用关系

9.总体设计工具：模块结构图、层次图（H 图）、HIPO（H 图 + IPO 图）

10.总体设计步骤：
系统的 DFD 图 ==> 初始的模块结构图（基于高内聚低耦合这一软件设计原理模块化） ==> 最终的、可供详细设计使用的模块结构图

软件测试目标与软件测试过程

1.软件评估：静态评估（评审、走查和形式化证明）、动态评估（软件测试）

2.软件测试目标：
首要目标 – 预防错误（几乎不可实现）
第二目标 – 发现错误

3.对软件测试目的的认识所经历的阶段：
NO.1：软件测试和软件调试无区别
NO.2：测试为表明软件能正常工作
NO.3：测试为表明软件不能正常工作
NO.4：测试仅为了将已察觉的错误风险减少到可接受的程度
NO.5：测试不仅是一种行为，而是一种理念，即测试是产生低风险软件的一种训练

4.软件测试的概念：使用人工或自动手段，运行或测定某个系统的过程，目的是检验它是否满足规定的需求，清除了解预期结果与实际结果间的差异

好的测试方案：极尽可能去发现迄今为止尚未发现的错误的测试方案
成功的测试：发现了至今为止尚未发现的错误的测试

5.软件测试与软件调试的区别

6.软件测试是一个有程序的过程，包括测试设计、测试执行、测试结果比较等

7.路径测试技术，测试策略：
路径覆盖：执行所有可能穿过程序控制流程的路径（度量最强，不可实现）
语句覆盖：至少执行程序中所有语句一次（度量最低）
分支覆盖：至少将程序中的每一分支执行一次（度量强于语句覆盖，不能查出全部错误）
条件覆盖：每个判定中为真的条件取值至少执行一次
条件组合覆盖：每个判定中所有可能的条件取值组合至少执行一次
语句覆盖 ≤ 分支覆盖 ≤ 条件组合覆盖 ≤ 路径覆盖
在路径测试技术中，路径选取是测试用例设计的基础，好的用例设计是发现程序错误的关键

8.白盒测试技术 – 结构测试技术(别称) – 程序的逻辑结构(依据) – 控制流程图(建模工具) – 路径测试技术(典型技术)

黑盒测试技术 – 功能测试技术，包括事务处理流程技术、定义域测试技术和状态测试技术

9.事务与事务流程图的概念
事务：指从系统用户角度出发所见到的一个工作单元，由一系列操作组成
事务流程图：一种表达被测软件模型的工具

10.等价类划分
等价类：把软件所有可能输入数据划分成若干部分，一个部分中各数据发现软件错误的概率一样
有效等价类：合理、有意义的输入数据集合
无效等价类：不合理、无意义的输入数据集合
等价类划分：从等价类中选取数据作为测试用例进行软件测试

11.软件测试的步骤
单元测试、集成测试、有效性测试、系统测试
① 单元测试：关注每个独立的模块，检验软件设计的最小单元 – 模块，以详细设计文档为指导，往往采用白盒测试技术
测试设备，模块不是独立程序，须为每个模块单元测试开发驱动模块和承接模块
驱动模块：模拟“主程序”接受测试用例的数据，将这些数据传送给要测试的模块并打印结果
承接模块：代替被测模块的下属模块，打印入口检查信息，并将控制返回到它的上级模块
单元测试期间，通常考虑模块的错误执行路径

② 集成测试：关注接口有关错误，发现与接口有关的错误，将经过单元测试的模块构成一个满足设计要求的软件结构
驱动模块：主控模块，设计承接模块替代直接的下属模块，按选取的测试方式（先深度/先宽度），在组合模块时进行测试

③ 有效性测试
黑盒测试技术(技术)，软件需求的可追溯性(验证)，关注检验是否符合用户的文档(任务)，发现软件实现的功能与需求规格说明书不一致的错误(目标)

④ 系统测试，关注检验系统中所有元素(包括硬件、信息等)间的协作是否合适，整个系统的性能、功能是否达到要求，验证将软件融于更大系统时整个系统的有效性

创作打卡挑战赛

赢取流量/现金/CSDN周边激励大奖