软件工程复习（四）

栩xx

已于 2022-07-04 16:32:42 修改

阅读量572

点赞数

文章标签：软件工程

于 2022-07-04 10:26:11 首次发布

本文链接：https://blog.csdn.net/qq_45767764/article/details/125575404

版权

第15章质量概念

15.1 什么是质量

质量的定义很多，这里主要是设计质量
什么是设计质量

设计质量是指设计师赋予产品的特性
原料等级和性能等规格说明决定了设计质量
产品是按照规格说明书制造的，那么如果使用了较高等级的原料、达到更高级别的性能，产品的设计质量就能提高

设计质量包括设计满足需求模型规定的功能和特性的程度

用户满意度=合格的产品+好的质量+按预算和进度安排交付

15.2 软件质量

软件质量定义：

在一定程度上应用有效的软件过程
创造有用的产品
为生产者和使用者提供明显的价值

1.有效的软件过程为生产高质量的软件产品奠定了基础
2.有用的产品是指交付最终用户要求的内容、功能和特征，但最重要的是，以可靠、无误的方式交付这些东西
3.高质量软件为软件组织和最终用户群体带来了收益

软件质量（质量维度）

性能质量
特性质量
可靠性
符合性
耐久性
适用性
审美
感知

McCall的质量因素
侧重于三个重要方面：

操作特性（产品运行）
承受变更的能力（产品修改）
对新环境的适应能力（产品转移）

质量因素具体描述：
产品运行
正确性
可靠性
效率
完整性
易用性
产品修改
维护性
灵活性
易测试性
产品转移
可移植性
可复用性
互操作性

ISO 9126质量因素

功能性
可靠性
易用性
效率
维护性
可移植性

定向质量因素

直觉
效率
健壮性
丰富性

过渡到量化的观点
在这里插入图片描述

15.3 软件质量困境

在这里插入图片描述
质量成本
包括追求质量过程中或在履行质量有关的活动中引起的费用以及质量不佳引起的费用等。
质量成本：

预防成本
评估成本
失效成本

软件质量管理决策
估算决策
进度安排决策
面向风险决策

15.4 实现软件质量

四大管理和实践活动

软件工程方法
项目管理技术
质量控制活动
软件质量保证

第16章软件质量保证

在这里插入图片描述
软件质量保证：就是为了保证软件高质量而必需的“有计划的、系统化的行动模式”

16.1 背景问题

在这里插入图片描述

16.2 软件质量保证的因素

标准
SQA的任务是要确保遵循所采用的标准，并保证所有的工作产品符合标准
评审和审核
技术评审是由软件工程师执行的质量控制活动
审核是由SQA人员执行的评审
测试
SQA的任务是要确保测试计划合适和实施有效，以便最有可能实现软件测试的基本目标
错误/缺陷的收集和分析
变更管理
变更是对所有软件项目最具破坏性的一个方面
教育
软件质量保证组织牵头软件过程改进，同时还是教育计划的关键支持者和发起者
供应商管理（外包）
软件质量保证组的任务是将质量要求作为与任何外部供应商签订合同的一部分，确保高质量的软件成果
安全防卫
软件质量确保应用适当的过程和技术来实现软件安全
安全
软件质量保证负责评估软件失效的影响，并负责启动那些减少风险所必需的步骤
风险管理
软件质量保证组应确保风险管理活动适当进行，且已经建立风险相关的应急计划

16.3 软件质量保证的过程和产品特性

16.4 软件质量保证的任务、目标和度量

软件质量保证任务

编制项目质量保证计划
参与编写项目的软件过程描述
评审软件工程活动（以验证其是否符合规定的软件工程）
评审指定的软件工作产品（以验证是否遵守作为软件过程一部分的那些规定）
确保根据文档化的规程记录和处理软件工作和工作产品中的偏差
记录各种不符合项并报告给高层管理人员

SQA目标、属性、度量
在这里插入图片描述

16.5 软件质量保证的形式化方法

在这里插入图片描述

16.6 统计软件质量保证

统计软件质量反映了一种在产业界不断增长的趋势：质量的量化
在这里插入图片描述

统计软件质量保证的应用可以用一句话来概括：
将时间用于真正需要的地方，但是首先你必须知道什么是真正重要的！

软件工程中的六西格玛
在这里插入图片描述

16.7 软件可靠性

软件可靠性可以通过历史数据和开发数据直接测量和估算出来。按统计术语所定义的软件可靠性是：
“在特定环境和特定时间内，计算机程序正常运行的概率”

失效——意味着与软件需求的不符
所有的软件失效都可以追溯到设计或实现问题上
MTBF就是可靠性的简单测量
在这里插入图片描述

软件安全
主要用来识别和评估可能对软件产生负面影响并促使整个系统失效的潜在灾难

在这里插入图片描述

16.8 ISO 9000质量标准

在这里插入图片描述

16.9 SQA计划

SQA计划为软件质量保证提供了一张路线图。该计划由SQA小组制定，作为各个软件项目中SQA活动的模板
SQA计划包括：

计划的目的和范围
SQA覆盖的所有软件工程工作产品的描述
软件过程中的所有适用的标准和习惯做法
SQA活动和任务（包括评审和审核）以及它们在整个软件过程中的位置（哪些阶段需要SQA活动）
支持SQA活动和任务的工具和方法
软件配置管理的规程
收集、保护和维护所有SQA相关记录的方法
与产品质量相关的组织（人员）角色和责任

16.10 产品度量框架

五个活动描述测量过程

公式化
收集
分析
解释
反馈

功能的度量（补）

在这里插入图片描述

第17章软件测试策略

在这里插入图片描述
软件测试策略包含：

测试计划
测试用例设计
测试执行
测试结果数据的收集与评估

17.1 软件测试的策略性方法

测试开始于构件层，然后向外“延伸”到整个计算机系统的集成
软件测试策略必须提供必要的低级测试
测试的进度必须是可测量的
软件错误的来源：

错误的需求
缺少需求
不能实现的需求
设计错误
编码错误
软件错误类型
算法错误
精度错误
文档错误
压力错误
吞吐量错误
恢复错误
计时错误
硬件和系统软件错误

在这里插入图片描述

软件测试的组织

开发人员：熟悉系统，态度温和，提交驱动
测试人员：不熟系统，破坏系统，质量驱动

软件测试策略的一般特征

应进行有效的、正式的技术评审，将明显的错误消于无形
采用螺旋模型

软件测试原则
Pareto原则（80/20原则）
80%的错误出现在20%的代码中，80%的时间执行20%的代码
木桶理论
全面质量管理
程序中存在错误的概率与已发现错误数成比例
软件缺陷的免疫力

17.2 策略问题

早在开始测试之前，就要以量化的方式规定产品需求
明确地陈述测试目标
了解软件的用户并为每类用户建立用户描述
制定强调“快速周期测试”的测试计划
建立能够测试自身的“健壮”软件
测试之前，利用有效的正式技术评审作为过滤器
实施正式技术评审以评估测试策略和测试用例本身
为测试过程建立一种持续的改进方法

17.3 传统软件的测试策略

单元测试
在这里插入图片描述
测试用例
是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径是否满足某个特定需求

单元测试

接口
目的：检查进出程序单元的数据流是否正确。模块接口测试必须在任何其他测试之前进行
局部数据结构
目的：保证模块内部的数据在程序执行过程中完整与正确
独立路径
错误处理路径
边界条件

单元测试通常在编码完成后进行，一般由白盒测试工程师、开发人员完成

单元测试步骤

编译运行：对程序进行语法正确性验证
静态测试：检查代码是否符合规范，参看“编码规范”
动态测试：深入检查代码的正确性、容错性和边界值等。主要用于白盒测试

在这里插入图片描述

集成测试
单元测试的下一个阶段，指将通过测试的单元模块组装成系统或子系统，再进行测试
测试的内容：

单元组装后的功能正确性：是否实现预期功能
单元之间的接口：调用关系、数据传递是否正确
集成后的系统性能：集成后系统资源使用情况

一步到位集成

增量式集成
自顶向下测试
广度优先（横向）深度优先（纵向）
自底向上测试
组合方法（三明治）

回归测试
程序修改的情况下

每次对软件做重要变更时（包括：新构件的集成、删除、修改），要进行回归测试

重新执行已测试过的某些子集，以确保变更没有传播不期望的副作用
在这里插入图片描述
冒烟测试（烟幕测试）

好处：

降低了集成风险

冒烟测试是每天进行的

提高最终产品的质量
简化错误诊断和修正
易于评估进展状况

在这里插入图片描述

17.4 面向对象软件的测试策略

不再孤立地对单个操作进行测试（传统的单元测试观点），而是将操作作为类的一部分

面向对象软件的类测试等同于传统软件的单元测试

面向对象系统的集成策略

基于线程的测试
对响应系统的一个输入或事件所需的一组类进行集成
每个线程单独地集成和测试
基于使用的测试

17.5 确认测试

确认测试始于集成测试的结束，那时已测试完单个构件，软件已组装成完整的软件包，且接口错误已被发现和改正
软件确认是通过一系列表明与软件需求相符合的测试而获得的
在这里插入图片描述
确认过程的一个重要的成分是配置评审。
评审的目的是确保所有的软件配置元素已正确开发、编目，且具有改善支持活动的必要细节。

	Alpha Test	Beta Test
测试场所不同	Alpha测试是指把用户请到开发方的场所来测试	Beta测试是指在一个或多个用户的产所进行的测试
环境的不同	Alpha测试的环境受开发方控制	Beta测试环境不受开发方控制，开发商无法知道用户如何折磨软件
测试时间不同	Alpha测试时间比较集中，一般情况下比Beta测试先进行	Beta测试时间不集中

在这里插入图片描述

17.6 系统测试

系统测试实际上是对整个基于计算机的系统进行一系列不同考验的测试。虽然每个测试都有不同的目的，但所有测试都是为了验证系统成分已正确地集成在一起且完成了指派的功能
系统测试包括

恢复测试
安全测试
压力测试
目的是在性能可以接受的前提下，测试系统可以支持的最大负载
压力测试要求以非正常的数量、频率或容量的方式执行系统
压力测试的一个变体称为敏感性测试
性能测试
在不同负载下（负载一定）时，通过一些系统参数（如反应时间等）验证系统性能指标
部署测试

17.7 调试技巧

在这里插入图片描述

第18章测试传统的应用软件

18.1 软件测试基础

软件可测试性：计算机程序能够被测试的容易程度。受以下方面影响：

可操作性
可观察性
可控制性
可分解性
简单性
稳定性
易理解性

在这里插入图片描述

18.2 测试的内部视角和外部视角

两种测试方法

白盒测试：这种方法需要内部观察，了解产品的内部工作情况，可以执行测试以确保内部操作依据规格说明执行，而且对所有的内部构件已进行了充分测试
黑盒测试：这种方法采用外部观察，了解产品要完成的指定功能，可以执行测试以显示每个功能是可操作的，同时，查找在每个功能中的错误

软件测试技术如何区分

黑盒测试/白盒测试
从要不要看代码部分来区分
动态测试/静态测试
从要不要运行软件来区分

18.3 白盒测试

在测试早期进行
主要对程序模块进行如下的检查：

对模块的所有独立的执行路径至少测试一次
对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次
在上下边界和可操作的范围内执行所有的循环
测试内部数据结构的有效性

18.4 基本路径测试

它是在程序控制流图的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合
设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次
在这里插入图片描述

从流图来看，一条独立路径是至少包含有一条在其它独立路径中从未有过的边的路径

环形复杂度计算的三种方法：

流图的区域数量应该对应环路复杂度V(G)
给定流图G的环路复杂度V(G)定义为：V(G)=E-N+2
- 其中：E为流图中的边数量，N为流图中的节点数量
给定流图G的环路复杂度V(G)也可以定义为：
- V(G)=P+1，其中P为流图中的判断节点数量

导出测试用例步骤
在这里插入图片描述

18.5 控制结构测试

控制结构测试包括：

条件测试
- 基于模块中包含的逻辑条件，设计测试用例
- 使得程序中每个判断的每个条件的可能取值至少执行一次
数据流测试
- 根据变量的定义和使用位置来选择测试路径
循环测试
- 侧重于循环的有效性

条件测试（每个条件都取到）
在这里插入图片描述
语句测试（保证每条语句至少执行一次）

分支测试（保证每个分支至少执行一次）

数据流测试
数据定义点：数据被赋值的点
数据使用点：数据被使用的点
数据使用：计算性使用（C-USE）和判定性使用（P-USE）
在这里插入图片描述
定义使用关联

求某个变量i的定义使用对
步骤：