覆盖标准(白盒、黑盒和灰盒)

覆盖标准Coverage Criteria
覆盖标准采用软件的抽象表示并将其划分为可测试的功能。
每个功能构成了测试需求的基础——需要由软件的测试套件进行测试的东西。
当测试套件的一个测试用例满足测试要求时，我们说测试要求被覆盖。测试套件覆盖的测试需求的百分比称为覆盖级别（或更简单地称为“覆盖率”）。
覆盖标准是一种分而治之的测试方法。

“抽象表示”指的是被测软件的高级概念模型或描述。它是一种捕获软件功能的基本方面而不深入研究具体实现细节的表示。抽象表示侧重于与测试目的相关的软件特性和行为，而不是特定的代码或设计。
使用抽象表示的目的是简化软件的复杂性，并为定义测试需求和识别可测试特性提供结构化框架。它帮助测试人员和开发人员清楚地了解软件的功能并定义测试范围。

“可测试特性”是可以单独测试的软件的特定方面或功能。这些特性源自软件的抽象表示。它们代表需要通过测试验证的不同组件、行为或场景。
可测试的特性应该是明确定义和可测量的，这样它们才能被有效地测试。它们可以是功能、模块、类、方法、输入、输出、用户交互或软件需要测试的任何其他方面。
通过识别抽象表示并将其划分为可测试的特性，覆盖标准提供了一种接近测试的系统方法。测试需求源自这些特性，测试套件旨在满足这些需求。测试套件的覆盖级别表示已覆盖的测试需求的百分比，提供对测试过程的彻底性的评估。

报表覆盖率Statement Coverage
一种非常简单的表示是程序语句组成一个软件。
每个功能都是一个程序语句。
每个测试要求都涉及执行（“覆盖”）每一行。
语句覆盖率是测试套件执行的代码行的百分比。

覆盖水平Coverage Level
JaCoCo 测量指令而不是语句，因为它计算 Java 字节码级别的覆盖率
覆盖率水平（或简称“覆盖率”）是测试的百分比
测试套件满足的要求。
例如执行了78%的语句，那么语句覆盖率为78%。

JaCoCo 类覆盖率报告JaCoCo Class Coverage Report
共有三种颜色：
绿色 = 由测试执行
黄色 = 测试执行的 if 或 for/while 语句的一个分支（真或假）
红色 = 测试未执行

批评和其他覆盖标准Criticisms and Other Coverage Criteria
语句是表示软件并将其划分（然后“征服”）以进行测试的一种非常简单的方法。
语句覆盖并不是一种“决定要测试什么”的有用方法，而是一种发现测试套件未涵盖的内容并决定是否需要更多测试用例的方法。
我们将在整个模块中满足不同的（并且可能更有用的）覆盖标准。

获得 100% 的覆盖率是否确保我们的程序没有错误？
不！ – 覆盖标准，例如语句覆盖，只是一个以系统的方式生成测试需求的方法。
例如，100% 的语句覆盖率可能会执行大部分缺陷，但是：
• 不保证缺陷会影响程序的状态
• 不保证感染会作为失败传播到程序的输出
• 不保证失败会被测试套件的断言捕获
更多细节: java 区分缺陷Defects/感染Infections/失败Failure

不可行的测试要求Infeasible Test Requirements
此外，一些测试要求可能是不可行的。
这意味着它们不可能被覆盖。
例如，一行无法执行的代码——即死代码。

该程序语句永远无法执行！它对语句覆盖形成了不可行的覆盖要求

回顾：重要术语Terminology
覆盖标准Coverage Criterion：一种将软件划分为一组测试要求以进行测试的方法。
测试要求Test Requirement:：测试套件必须按覆盖标准满足的软件功能。请注意，测试需求与软件需求不同，也与测试用例不同。一个测试用例可以满足多个测试需求。
不可行的测试要求Infeasible Test Requirement:：不可能满足的测试要求。
覆盖率Coverage Level：执行的测试需求的百分比（覆盖）由测试套件。

白盒、黑盒和灰盒覆盖标准
对覆盖率标准进行分类的一种方法是区分测试需求是从代码中派生出来的，还是它没有参考它的编程方式。

白盒White Box：
全面了解内部代码结构。因此通常称为“代码覆盖率”标准。
黑盒子Black Box:
不了解内部代码结构。覆盖标准基于软件的需求、设计或抽象模型。
灰盒Grey Box:
内部代码结构的一些知识。覆盖标准基于被认为是“白盒”和“黑盒”的人工制品的混合

不同的标准，不同的缺陷
黑盒覆盖标准
由于不了解软件的内部工作原理，不太适合检测调试缺陷(defects of commission)。
最适合检测基于需求的遗漏缺陷(defects of omission)，软件的抽象模型。
白盒覆盖标准
最适合检测可以“看到”代码的调试缺陷(defects of commission)。
由于不了解软件需求，不太适合检测遗漏缺陷(defects of omission)。

在软件测试中，调试缺陷和遗漏缺陷是测试过程中可能遇到的两类问题：

调试缺陷：当软件表现出不应该具有的行为或功能时，就会出现调试缺陷。换句话说，它指的是软件包含不应该存在的东西或行为不正确的情况。这些缺陷通常被认为是“错误”或“错误”，并可能导致意外结果或失败。调试缺陷的示例包括逻辑错误、计算错误、崩溃或不正确的输出。
遗漏缺陷：另一方面，当软件缺少或未能包含其应具有的功能或行为时，就会出现遗漏缺陷。它指的是缺少某些东西或未正确执行的情况。这些缺陷涉及缺少所需的特性、要求或预期的行为。遗漏缺陷可能是由于不完整或不准确的规范、不充分的实施或开发过程中的疏忽造成的。遗漏缺陷的示例包括功能缺失、错误处理不完整、安全漏洞或不符合要求。

这两种类型的缺陷、错误和遗漏都是不受欢迎的，它们会影响软件的质量和可靠性。测试的目标是识别和报告这些缺陷，以便在将软件发布给最终用户之前解决和解决这些缺陷。

覆盖标准(白盒、黑盒和灰盒)相关推荐

软件测试有白和黑盒和灰盒,白盒测试、灰盒测试和黑盒测试的区别
1黑盒测试黑盒,顾名思义,就是把所有东西装到一个盒子里,看不到内部逻辑,只能通过外部的可见的功能模块,对软件进行测试.比如说一个网站的登陆功能,你不知道它的内部逻辑是怎样的,只能通过网页的注册输入文本 ...
深入到系统组件是否白盒测试_南京豪之诺软件测试：白盒、黑盒、灰盒优缺点（知识普及）...
该楼层疑似违规已被系统折叠隐藏此楼查看此楼白盒测试概念白盒测试也称结构测试或逻辑驱动测试,重点关注软件内部的实现细节,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规 ...
iOS APP黑盒/灰盒审计checklist
本篇文章介绍如何对一款iOS应用进行基本的安全审计,主要方式为黑盒或灰盒的手动审计.注意红色字体部分为做安全审计时的checklist. 一.IPA安装包分析(静态分析) 1. Mach-O可执行文件 ...
黑盒、白盒、灰盒验证
黑盒验证: 所有的代码只局限于与rtl的外部信号进行连接,验证环境对于rtl的细节是不知道的黑盒验证的关键在于能否根据输入预测出输出. 优点为验证环境较易维护缺点是缺乏内部信号的控制和观测点白盒 ...
软件测试-白盒灰盒篇
这篇博客接着来介绍白盒测试,在没有具体接触白盒测试前,总觉他很神秘,很复杂.相信大家都会有这样的感觉, 今天就来把这个盒子打开,剖析一下白盒测试. 白盒测试白盒测试也称结构测试或逻辑驱动测试,它是知 ...
白盒/黑盒/灰盒测试的区别
单元测试属于白盒测试范畴:集成测试属于灰盒测试范畴:系统测试属于黑盒测试范畴. 一. 软件测试方法 1. 软件测试方法:白盒测试.黑盒测试.灰盒测试.静态测试.动态测试 2. ...
论文阅读3：Smart Greybox Fuzzing 智能灰盒模糊测试
原文链接: Smart Greybox Fuzzing | IEEE Journals & Magazine | IEEE Xplore Abstract 基于覆盖的灰盒模糊(CGF)是一种最 ...
FIRM-AFL: 通过增强进程仿真实现物联网固件的高吞吐量灰盒模糊测试
[题目]FIRM-AFL: 通过增强进程仿真实现物联网固件的高吞吐量灰盒模糊测试 [来源]2019 USENIX Security [笔记建立时间]2023-3-30 注:题目中的"增强进程 ...
选择灰盒安全测试工具，看准以下几点
渗透测试是模拟黑客攻击站在第三方的角度上来测试系统的安全性,通过渗透测试发掘企业系统潜在的安全漏洞.通过对网站及APP应用等,进行非破坏性质的入侵攻击,获取系统权限,并将入侵过程和漏洞细节编写成测试报 ...

覆盖标准(白盒、黑盒和灰盒)

覆盖标准(白盒、黑盒和灰盒)

覆盖标准(白盒、黑盒和灰盒)相关推荐

最新文章

热门文章