【中级软件设计师】上午题12-软件工程(2):单元测试、黑盒测试、白盒测试、软件运行与维护

【中级软件设计师】上午题12-软件工程(2)

  • [1 系统测试](#1 系统测试)
    • [1.1 单元测试](#1.1 单元测试)
    • [1.2 集成测试](#1.2 集成测试)
      • [1.2.1 自顶向下](#1.2.1 自顶向下)
      • [1.2.2 自顶向上](#1.2.2 自顶向上)
      • [1.2.3 回归测试](#1.2.3 回归测试)
  • [2 测试方法](#2 测试方法)
    • [2.1 黑盒测试](#2.1 黑盒测试)
      • [2.1.1 McCabe度量法](#2.1.1 McCabe度量法)
    • [2.2 白盒测试](#2.2 白盒测试)
      • [2.2.1 语句覆盖-"每个流程"执行一次](#2.2.1 语句覆盖-“每个流程”执行一次)
      • [2.2.2 判定覆盖](#2.2.2 判定覆盖)
      • [2.2.3 条件覆盖-A=True B=True C=True和A=False B=False C=False](#2.2.3 条件覆盖-A=True B=True C=True和A=False B=False C=False)
      • [2.2.4 判定/条件覆盖](#2.2.4 判定/条件覆盖)
      • [2.2.5 条件组合覆盖-"菱形"中的排列组合](#2.2.5 条件组合覆盖-“菱形”中的排列组合)
      • [2.2.6 路径覆盖-流程中的YN覆盖](#2.2.6 路径覆盖-流程中的YN覆盖)
    • [2.3 伪代码+白盒测试+McCabe度量法](#2.3 伪代码+白盒测试+McCabe度量法)
  • [3 运行和维护知识](#3 运行和维护知识)
    • [3.1 可维护性评价指标](#3.1 可维护性评价指标)
    • [3.2 软件维护](#3.2 软件维护)
    • [3.3 软件文档](#3.3 软件文档)
    • [3.4 软件维护内容](#3.4 软件维护内容)
  • [4 软件可靠性、可用性、可维护性](#4 软件可靠性、可用性、可维护性)
  • [5 沟通路径](#5 沟通路径)

1 系统测试

1.意义:系统测试是为了发现错误而执行程序的过程,成功的测试是发现了至今尚未发现的错误的测试

2.目的:测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。

根据测试的概念和目的,在进行信息系统测试时应遵循以下基本原则。

(1)应尽早并不断地进行测试。

(2)测试工作应该避免由原开发软件的人或小组承担,

(3)在设计测试方案时,不仅要确定输入数据,而且要根据系统功能确定预期输出结果。

(4)在设计测试用例时,不仅要设计有效、合理的输入条件,也要包含不合理、失效的输入条件。

(5)在测试程序时,不仅要检验程序是否做了该做的事,还要检验程序是否做了不该做的事。

(6)严格按照测试计划来进行,避免测试的随意性。

(7)妥善保存测试计划、测试用例,作为软件文档的组成部分,为维护提供方便。

(8)测试例子都是精心设计出来的,可以为重新测试或追加测试提供方便。

(9)系统测试阶段的测试目标来自于需求分析阶段。

1.3.4.5.8.9比较常考 6.7没怎么考过

1.1 单元测试

单元测试也称为模块测试,在模块编写完成且无编译错误后就可以进行。单元测试侧重于模块中的内部处理逻辑和数据结构。如果选用机器测试,一般用白盒测试法。这类测试可以对多个模块同时进行。

1.2 集成测试

1.2.1 自顶向下

不需要编写驱动模块

1.2.2 自顶向上

需要编写驱动模块,不需要编写桩模块

1.2.3 回归测试

每当加入一个新模块作为集成测试的一部分时,软件发生变更,建立了新的数据流路径,可能出现新的IO,以及调用新的控制逻辑。

这些变更可能会使原来可以正常工作的功能产生问题。

在集成测试策略的环境下,回归测试是重新执行已测试过的某些子集,以确保变更没有传播不期望的副作用。

在改正当前故障的同时可能会引入新的故障, 这时需要回归测试。

2 测试方法

在软件测试过程中,应该为定义软件测试模板,即将特定的测试方法和测试用例设计放在一系列的测试步骤中。

动态测试。动态测试是指通过运行程序发现错误。在对软件产品进行动态测试时可以采用黑盒测试法和白盒测试法。

2.1 黑盒测试

黑盒测试也称为功能测试,在完全不考虑软件的内部结构和特性的情况下,测试软件的外部特性。进行黑盒测试主要是为了发现以下几类错误。

常见的黑盒测试技术有:等价类划分、边界值分析、错误推测和因果图。(首字母缩写:bcyd饱餐一顿)

等价类划分测试方法中,一个测试用例的不合理的输入越多就说明该用例不是一个好的测试用例。

2.1.1 McCabe度量法

McCabe 度量法是通过定义环路复杂度,建立程序复杂性的度量,它基于一个程序模块的程序图中环路的个数。计算有向图G的环路复杂性的公式为:V(G)=m-n+2,其中V(G)是有向图 G 中的环路个数,m 是 G 中的有向弧数,n是 G中的节点数。

m是边的个数/箭头数,n是节点数
V(G) = 边数-节点数+2

例子:

v(g)=10-7+2=5

2.2 白盒测试

使用白盒测试方法时,应根据 程序的内部逻辑 和 指定的覆盖标准 确定测试数据。

2.2.1 语句覆盖-"每个流程"执行一次

语句覆盖是指选择足够的测试数据,使被测试程序中的每条语句至少执行一次。(每个"菱形或长方形"执行一次)

语句覆盖对程序执行逻辑的覆盖很低,因此一般认为它是很弱的逻辑覆盖。

因为N(否定)语句上没有执行条件,所以只需要满足YY即可将"每个菱形"执行一次。

2.2.2 判定覆盖

判定覆盖也叫分支覆盖

至少满足每个流程的真和假各一次,YY和NN即可

2.2.3 条件覆盖-A=True B=True C=True和A=False B=False C=False

满足每个逻辑条件各种可能的值

A=True,False

B=True,False

C=True,False

A=True B=True C=True

A=False B=False C=False

可以一次性把ABC的值都满足为真值或假值

2.2.4 判定/条件覆盖

判定覆盖∪条件覆盖

2.2.5 条件组合覆盖-"菱形"中的排列组合

2.2.6 路径覆盖-流程中的YN覆盖

YY NN YN NY

最强的覆盖

2.3 伪代码+白盒测试+McCabe度量法


选B D

3 运行和维护知识

3.1 可维护性评价指标

1.可理解性

2.可测试性

3.可修改性

3.2 软件维护

软件维护:在软件工程的每一个阶段都应考虑并提高软件的可维护性;

软件维护通常比软件开发投入的时间、人力、精力更大。

3.3 软件文档

编写高质量文档可以提高软件开发的质量

文档也是软件产品的一部分,没有文档的软件就不能称之为软件。

软件文档的编制在软件开发工作中占有突出的地位和相当大的工作量

高质量文档对于软件产品的效益有着重要的意义

总的来说,软件文档只好不坏,选项中说软件文档不好的大概率就是不正确的。

3.4 软件维护内容

软件维护

1.正确性维护:正确性维护是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。

2.适应性维护:适应性维护是指使应用软件适应信息技术变化和管理需求变化而进行的修改。

3.完善性维护:这是为了扩充功能和改善性能而进行的修改,主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。占比很多50%~60%

4.预防性维护:为了改进应用软件的可靠性和可维护性,为了适应未来的软/硬件环境的变化,应主动增加预防性的新的功能,以使应用系统适应各类变化而不被淘汰。

题目中的一些话术:

2.适应性维护 这需要对数据类型/数据格式稍微进行一些改变

3.完善性维护 修改其排序算法使其更高效;系统交付用户使用后,为了改进系统

4 软件可靠性、可用性、可维护性

可靠性、可用性和可维护性是软件的质量属性,软件工程中,用0-1之间的数来度量。

可靠性是指一个系统对于给定的时间间隔内、在给定条件下无失效运作的概率。可以用 M T T F / ( 1 + M T T F ) MTTF/(1+MTTF) MTTF/(1+MTTF)来度量,其中 MTTF 为平均无故障时间。

可用性是在给定的时间点上,一个系统能够按照规格说明正确运作的概率。可以用 M T B F / ( 1 + M T B F ) MTBF/(1+MTBF) MTBF/(1+MTBF)来度量,其中MTBF为平均失效间隔时间。

可维护性是在给定的使用条件下,在规定的时间间隔内,使用规定的过程和资源完成维护活动的概率。可以用 1 / ( 1 + M T T R ) 1/(1+MTTR) 1/(1+MTTR)来度量,其中 MTTR为平均修复时间。

MTTF, MTBF, MTTR 的含义分别是

mean time to failure 平均无故障时间

mean time between failures 平均失效间隔时间

mean time to repair 平均修复时间

这几个都是时间单位,在国外的网站可以搜到都是拿小时什么作为单位的,不是占比。

ttf可靠,tb可用

5 沟通路径

一般情况来说n个人员的开发小组(也就是无主程序员)有n * (n -- 1) 条沟通路径;

主程序员的开发小组:有 n-1条沟通路径

相关推荐
Devil枫7 小时前
Vue 3 单元测试与E2E测试
前端·vue.js·单元测试
小袁在上班13 小时前
Python 单元测试中的 Mocking 与 Stubbing:提高测试效率的关键技术
python·单元测试·log4j
测试199814 小时前
外包干了2年,快要废了。。。
自动化测试·软件测试·python·面试·职场和发展·单元测试·压力测试
安冬的码畜日常17 小时前
【The Art of Unit Testing 3_自学笔记06】3.4 + 3.5 单元测试核心技能之:函数式注入与模块化注入的解决方案简介
笔记·学习·单元测试·jest
王解18 小时前
Jest项目实战(2): 项目开发与测试
前端·javascript·react.js·arcgis·typescript·单元测试
rolt1 天前
长得像用例图的类图-《软件方法》8.2.3.4
软件工程·uml·面向对象
阿萨姆.3571 天前
结对编程 --- 软件工程
java·软件工程·结对编程
写代码的橘子n1 天前
软件工程笔记一
笔记·软件工程
程序员小雷1 天前
软件测试基础:单元测试与集成测试
python·功能测试·selenium·测试工具·单元测试·集成测试·压力测试
思茂信息1 天前
CST汽车天线仿真(双向混合求解)
javascript·人工智能·5g·汽车·ar·软件工程