【中级软件设计师】上午题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条沟通路径

相关推荐
surfirst10 小时前
举例说明 .Net Core 单元测试中 xUnit 的 [Theory] 属性的用法
单元测试·.netcore·xunit
回眸&啤酒鸭1 天前
【回眸】Tessy 单元测试软件使用指南(四)常见报错及解决方案与批量初始化的经验
单元测试·tessy
Iam傅红雪2 天前
mock数据,不使用springboot的单元测试
spring boot·后端·单元测试
holeer2 天前
《软件工程概论》作业一:新冠疫情下软件产品设计
软件工程·axure·敏捷开发·原型设计
黄焖鸡能干四碗2 天前
【系统方案】智慧城市大数据平台建设方案(Word)
大数据·运维·需求分析·软件需求·设计规范
月光code2 天前
SLF4J报错log4j又报错
单元测试·log4j
Wlq04152 天前
系统架构设计师-英文翻译题(2022年下半年)
软件工程
Wlq04153 天前
软件工程-数据流图
软件工程
编程经验分享3 天前
Spring Boot 基于 Mockito 单元测试
spring boot·后端·单元测试
陈俊杰13 天前
软件工程的详细学习要点和学习方向
学习·软件工程