【测试】白盒测试

今天写了两个小时的软件测试实验报告,原谅我上课没有好好听冯老师讲课,下课把老师课件系统的过了一遍才开始做实验报告。

再来说说我们的冯老师,带过去我离散数学、软件工程,现在带我软件测试,hahahh~~,我猜想冯老师会不会大四的毕业论文设计也带我叭。

好啦,言归正传,今天就来说说什么是白盒测试,以及白盒测试用例设计方法。

1. 什么是白盒测试

白盒测试也称结构测试或逻辑驱动测试,是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例,主要用于软件或程序验证。

1.1 遵循原则

  1. 保证一个模块中的所有独立路径至少被测试一次;
  2. 所有逻辑值均需测试真 (true) 和假 (false) 两种情况;
  3. 检查程序的内部数据结构,保证其结构的有效性;
  4. 在上下边界及可操作范围内运行所有循环。

1.2 设计方法
白盒测试主要是检查程序的内部结构、逻辑、循环和路径。

常用测试用例设计方法有:
逻辑覆盖:以程序的内部逻辑结构为基础,分为语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖等。

基本路径测试:在程序控制流程的基础上,分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。

2. 逻辑覆盖

2.1 语句覆盖
基本思想是设计若干测试用例,运行被测程序,使程序中的每个可执行语句至少被执行一次。
在这里插入图片描述

a=2,b=1,c=6 

2.2 判定覆盖
基本思想是设计若干用例,运行被测程序,使得程序中每个判断的取真分支和取假分支至少经历一次,即判断真假值均曾被满足。
在这里插入图片描述

a=2,b=1,c=6 可覆盖判断M的Y分支和判断N的Y分支; 
a=-2,b=-1,c=-3 可覆盖判断M的N分支和判断N的N分支。
或
a=1,b=1,c=-3 可覆盖判断M的Y分支和判断N的N分支; 
a=1,b=-2,c=3 可覆盖判断M的N分支和判断N的Y分支; 

2.3 条件覆盖
基本思想是设计若干测试用例,执行被测程序以后,要使每个判断中每个条件的可能取值至少满足一次。
在这里插入图片描述

判断M表达式:                     
设条件a>0 取真记为T1、取假记为F1
  条件b>0 取真记为T2、取假记为F2

判断N表达式:
设条件a>1 取真记为T3、取假记为F3
  条件c>1 取真记为T4、取假记为F4

在这里插入图片描述

  • 条件覆盖设计的思想就是让测试用例能覆盖T1、T2、T3、T4、F1、F2、F3、F4;
  • 它覆盖了判定M的N分支和判断N的Y分支。

2.4 判定-条件覆盖
判定-条件覆盖是判定和条件覆盖设计方法的交集,即设计足够的测试用例,使得判断条件中的所有条件可能取值至少执行一次,同时,所有判断的可能结果至少执行一次。
在这里插入图片描述
测试用例要满足如下条件:

  1. 所有条件可能至少执行一次取值;
  2. 所有判断的可能结果至少执行一次。

在这里插入图片描述

  • 要满足T1、T2、 T3 、T4、F1、 F2 、F3、F4

2.5 条件组合覆盖
基本思想是设计足够的测试用例,使得程序中每个判断的所有可能的条件取值组合都至少出现一次。

与条件覆盖的差别是它不是简单地要求每个条件都出现“真”与“假”两种结果,而是要求让这些结果的所有可能组合都至少出现一次。
在这里插入图片描述
在这里插入图片描述

2.6 路径覆盖
路径覆盖就是设计所有的测试用例,来覆盖程序中的所有可能的执行路径。
在这里插入图片描述
在这里插入图片描述

  • 覆盖组合为条件组合覆盖的组合编号。
3. 基本路径测试

设计出的测试用例要保证每一个基本独立路径至少要执行一次。

测试步骤:

  1. 依据代码绘制流程图;
  2. 确定流程图的圈复杂度(cyclomatic complexity );
  3. 确定线性独立路径的基本集合( basis set );
  4. 设计测试用例覆盖每条基本路径。

圈复杂度(Cyclomatic complexity): 代码逻辑复杂度的 度量,提供了被测代码的路径数量。复杂度越高,出错的概率越大。
V(G) = 区域数量(由节点、连线包围的区域,包括图形外部区域)
V(G) = 连线数量 - 节点数量 + 2
V(G) = 简单可预测节点数量 + 1

独立路径: 至少引入一系列新的处理语句或条件的任何路径;
基本集: 由独立路径构成的集合;
由基本集导出的测试用例,保证每行代码语句至少被执行一次,基本集合不一定唯一。

【例题】
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
【附录:白盒测试知识】
1. 白盒测试知识
2. 白盒测试理论

以上不足之处,请友友们指出,博主会及时改正。💪💪😊😊

<think>好的,用户让我介绍黑盒测试白盒测试,我需要先回忆这两个概念的基本定义和区别。首先,黑盒测试,应该是不考虑内部结构,只关注输入输是否符合预期。而白盒测试则是需要了解内部代码结构,检查内部逻辑是否正确。接下来需要详细说明两者的特点、方法、优缺点以及适用场景。 然后,用户可能还希望了解两者的对比,所以需要整理一个对比表格,包括测试对象、关注点、测试方法、优点、缺点和适用阶段。另外,用户提到系统级指令,要求数学表达式用$...$和$$...$$,但这个问题可能不涉及数学公式,不过如果有例子可能需要留意格式,比如边界值分析的例子可能用到数值范围,但可能不需要数学符号。但用户给的例子中有积分符号,所以如果有用到类似的地方,要正确使用LaTeX。 需要确保回答结构清晰,分步骤或分点阐述。可能用户是软件测试的学习者,或者正在准备考试,需要明确的概念和对比。要确保信息准确,比如黑盒测试的常用方法有等价类划分、边界值分析等,而白盒测试包括路径测试、循环测试等。还要提到各自的优缺点,比如黑盒测试容易实施但覆盖率低,白盒测试覆盖率高但成本高。 另外,适用场景部分,黑盒测试常用于系统测试、验收测试,而白盒测试在单元测试、集成测试阶段。可能还需要举一些例子帮助理解,比如黑盒测试就像用户使用软件,不关心内部如何实现,只看功能是否正常;白盒测试则像开发人员检查代码逻辑是否正确。 需要检查是否满足用户的格式要求,比如分点列表、结构清晰,使用中文,没有使用markdown,所以用数字和项目符号可能用中文的“1.”、“2.”等。同时注意LaTeX语法是否正确,但这个问题可能用不上,除非有例子需要数学符号,比如边界值的例子如$0 \leq x \leq 100$,这时候需要用$...$包裹。 最后,总结两者的对比和在实际中的应用,强调互补性,通常结合使用以确保软件质量。确保回答真实可靠,如果有不确定的地方需要确认,比如测试方法的具体例子是否正确,优缺点是否准确。可能需要查阅资料确认,但根据已有知识,黑盒和白盒的基本点是对的。</think>以下是对黑盒测试白盒测试的详细介绍: --- ### 一、黑盒测试(Black Box Testing) #### 1. **定义** 黑盒测试是一种**不关注程序内部结构和实现细节**的测试方法,仅通过输入和输来验证系统是否满足需求。测试者将程序视为一个“黑盒”,只检查功能是否符合预期。 #### 2. **核心关注点** - 功能正确性 - 输入与输的对应关系 - 用户需求是否被满足 #### 3. **常用方法** - **等价类划分**:将输入数据划分为有效和无效等价类,从每类中选取代表值测试。 - **边界值分析**:测试输入范围的边界值(例如:若输入范围是$0 \leq x \leq 100$,则测试$x=0,1,99,100$)。 - **决策表测试**:针对不同输入组合设计测试用例。 - **场景法**:模拟用户实际操作流程进行测试。 #### 4. **优点** - 无需了解代码实现,适合非技术人员参与。 - 贴近用户视角,易发现功能性问题。 #### 5. **缺点** - 无法覆盖代码内部逻辑的潜在缺陷。 - 测试用例可能冗余或遗漏。 #### 6. **适用场景** - 系统测试 - 验收测试 - 第三方测试 --- ### 二、白盒测试(White Box Testing) #### 1. **定义** 白盒测试是一种**基于程序内部结构和代码逻辑**的测试方法,通过检查代码路径、分支、循环等验证程序的正确性。测试者需要理解代码实现细节。 #### 2. **核心关注点** - 代码逻辑覆盖 - 路径执行正确性 - 异常处理能力 #### 3. **常用方法** - **语句覆盖**:确保每行代码至少执行一次。 - **分支覆盖**:验证每个条件分支的真假情况均被测试。 - **路径覆盖**:覆盖所有可能的执行路径(复杂度较高)。 - **循环测试**:检查循环的边界条件(例如:0次循环、1次循环、多次循环)。 #### 4. **优点** - 能发现深层次代码缺陷(如内存泄漏、逻辑错误)。 - 提高代码覆盖率,增强可靠性。 #### 5. **缺点** - 需要熟悉代码,测试成本高。 - 可能忽略用户实际需求。 #### 6. **适用场景** - 单元测试 - 集成测试 - 代码审查 --- ### 三、黑盒测试白盒测试对比 | **对比维度** | **黑盒测试** | **白盒测试** | |----------------|--------------------------------------|--------------------------------------| | **测试对象** | 系统外部行为 | 代码内部逻辑 | | **关注点** | 功能需求 | 代码结构、路径覆盖 | | **测试人员** | 测试工程师、用户 | 开发工程师、测试工程师 | | **优点** | 易操作、贴近用户需求 | 覆盖率高、发现隐藏缺陷 | | **缺点** | 无法覆盖内部逻辑 | 成本高、需代码知识 | | **适用阶段** | 系统测试、验收测试 | 单元测试、集成测试 | --- ### 四、实际应用建议 1. **互补使用**:黑盒测试验证功能,白盒测试确保代码质量,二者结合可提升整体测试效果。 2. **阶段配合**:早期使用白盒测试(单元测试),后期结合黑盒测试(系统测试)。 3. **工具支持**:黑盒测试常用工具如Selenium、Postman;白盒测试工具如JUnit、Coverity。 通过合理运用这两种方法,可以更全面地保障软件质量。
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值