🔥个人主页：中草药

🔥专栏：【Java】登神长阶史诗般的Java成神之路

测试分类

了解各种各样的测试方法分类，不是为了墨守成规按照既定方法区测试，而是已了解思维为核心，并了解一些专业名词

根据测试方法分类

白盒测试

白盒测试（又称结构测试、透明盒测试）是一种基于对系统内部结构、代码逻辑和实现细节充分了解的测试方法。测试人员需要查看代码、算法或架构设计，针对性地设计测试用例，验证内部逻辑的正确性。白盒测试主要分为两类

静态测试

通过人工或工具分析代码的结构、规范、逻辑，不实际执行程序，发现潜在问题。包括：

桌面检查：人工阅读代码 / 文档，初步检查逻辑错误、代码规范等（最基础的静态自查）。
代码审查：团队（如评审会议）对代码进行正式检查，从逻辑、性能、安全等多维度发现缺陷。
代码走查：模拟代码执行流程（但不运行），“走读” 代码逻辑，检查每一步的合理性。
代码扫描工具：借助自动化工具（如 SonarQube、PMD 等），批量检测语法错误、安全漏洞、代码异味（如重复代码、冗余逻辑）。

动态测试

动态测试通过执行测试用例，观察代码运行时的行为，验证内部逻辑是否正确。主要包含以下六种，我们以代码块为例

if(A && B){func1();
}
if(C && D){func2();
}

语句覆盖

每个语句至少执行一次。

针对A and B:A为T且B为T

针对C or D:C为T或者D为T

得出用例:

用例1: A为T，B为T，C为T，D为F

判定覆盖

A and B 为 T -> A=T B=T (1)

A and B 为 F -> A=T B=F 或 A=F B=T 或 A=F B=F (2)

C or D 为 T -> C=T D=T 或 C=T D=F 或 C=F D=T (3)

C or D 为 F -> C=F D=F (4)

得出用例:

用例1:A=T B=T C=T D=F 满足(1)(3)

用例2:A=T B=F C=F D=F 满足(2)(4)

条件覆盖

A T F

B T F

C T F

D T F

（5）（6）

得出用例:

用例1:A=T B=T C=T D=T

用例2:A=F B=F C=F D=F

判定条件覆盖

结合判定覆盖和条件覆盖

得出用例:

用例1:A=T B=T C=T D=T 满足(1) (3) (5)

用例2:A=F B=F C=F D=F 满足(2) (4) (6)

条件组合覆盖

A B C D

T T T T

T F T T

F T T T

F F T T

每一行都可以作为一个用例

路径覆盖

以冒泡排序为例

public static void sort(int[] array) {for (int i = 0; i < array.length - 1; i++) {for (int j = 0; j < array.length - 1 - i; j++) {if (array[j] > array[j + 1]) {int temp = array[j];array[j] = array[j + 1];array[j + 1] = temp;}}}
}

需要覆盖的测试路径:

1) 3,12

2) 3,4,3,12

3) 3,4,5,4,3,12

4) 3,4,5,678,4,3,12

黑盒测试

黑盒测试是一种不关注系统内部结构和实现细节的测试方法。

测试人员将系统视为一个 “黑盒子”，只通过输入数据和观察输出结果来验证系统是否符合需求规格说明书的要求。因此黑盒测试又称为数据驱动测试，只注重软件功能

优点：不需要了解程序内部的代码以及实现，不关注软件内部的实现。从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维

缺点：不可能覆盖所有代码

灰盒测试

灰盒测试是介于黑盒测试和白盒测试之间的一种测试方法。测试人员不需要完全了解系统内部的所有细节，但会基于部分内部结构信息（如接口设计、数据库结构、模块交互逻辑）来设计测试用例，兼顾功能验证和内部逻辑检查。

灰盒测试多用于集成测试阶段，不仅关注输入输出的正确性，也关注程序内部的情况

根据测试阶段分类

单元测试

与编码同步进行，针对软件的最小组成单元（通常是函数、方法、类或模块）进行测试，主要采用白盒测试方法，从被测对象的内部结构出发设计测试用例。它是测试金字塔（单元测试→集成测试→系统测试）的基石，也是敏捷开发、持续集成（CI）等流程的核心支撑。

核心目标

验证单元功能正确性：确保单个函数 / 方法在各种输入下返回预期结果，符合设计逻辑。
早期发现缺陷：在开发初期（编码阶段）暴露问题，避免缺陷流入后续集成或系统测试阶段，降低修复成本。
支持快速迭代：为代码重构、优化或需求变更提供 “安全网”，确保修改后原有功能不受影响。

java中提供很多单元测试框架，如Junit提供很多注解与断言函数，有效提升开发单元测试脚本效率

测试阶段：编码后或者编码前(TDD)

测试对象：最小模块

测试人员：白盒测试工程师或开发工程师

测试依据：代码和注释+详细设计文档

测试方法：白盒测试

测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

集成测试

集成测试（也称 “组装测试”）是在单元测试通过后，将多个已测试的模块（或组件）按照设计要求组合起来，验证模块之间的接口、交互逻辑是否正确的测试过程。

核心目标

发现模块间交互的问题：例如模块 A 传递给模块 B 的数据格式错误、接口参数不匹配、依赖关系冲突（如模块 A 未完成时模块 B 提前调用）等。
验证 “模块组合” 是否符合设计预期：单个模块功能正确≠组合后功能正确，集成测试确保模块协作时整体逻辑无误。

测试阶段：一般单元测试之后进行

测试对象：模块间的接口

测试人员：白盒测试工程师或开发工程师

测试依据：单元测试的模块+概要设计文档

测试方法：黑盒测试与白盒测试相结合

测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

系统测试

系统测试是在集成测试通过后，将整个软件系统作为一个完整的实体，在接近真实的环境中，验证系统是否满足需求规格说明书（用户需求）的测试过程。

测试阶段：集成测试通过之后

测试对象：整个系统(软、硬件)

测试人员：吴黑盒测试工程师

测试依据：旁需求规格说明文档

测试方法：黑盒测试

测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

冒烟测试

冒烟测试起源于硬件测试：如果电路板通电后 “冒烟”（无法正常启动），就无需进行后续复杂测试。在软件中，它是对软件最核心、最基础功能的快速验证。

通常在软件开发早期阶段进行，目的是判断软件是否 “可测”—— 即是否稳定到足以支持后续更详细的测试（如集成测试、系统测试）

核心目标

快速排查阻断性缺陷：验证软件的核心流程是否能跑通，是否存在导致测试无法进行的严重问题（如无法启动、登录失败、核心功能崩溃等）。
过滤 “无效版本”：避免将时间浪费在明显不稳定的版本上（例如开发刚提交的版本连基本功能都用不了，就无需进行耗时的系统测试）。

回归测试

回归测试是指在软件发生修改（如修复 bug、新增功能、优化代码）后，重新验证原有功能是否依然正常的测试过程。其核心逻辑是：“修改可能引入新问题，需要确认历史功能未受影响”。

在软件开发的后期，通常在每次代码修改或新增功能后执行

核心目标

发现 “修改后遗症”：防止因代码变更（即使是微小修改）导致原有正常功能出现异常（例如修复了支付 bug，却导致订单状态更新失败）。
保障软件稳定性：确保软件在迭代过程中，历史功能的正确性不被破坏，维持整体质量。

根据实施组织分类

α 测试（Alpha Testing）

α 测试是软件开发接近完成时，由开发团队内部或指定的内部用户（如公司员工、QA 团队）在模拟的用户环境中进行的测试。

核心特点：

测试人员：以内部人员为主，不对外开放。
测试环境：通常是开发方搭建的 “模拟用户环境”（尽量接近真实使用场景，但仍受开发方控制）。
测试阶段：在软件功能基本完成、但可能仍有较多缺陷时进行（早于 β 测试）。
主要目的：发现软件的功能性缺陷、逻辑错误、界面问题等，验证核心功能是否可用，排除明显的 “硬伤”。
结果处理：测试中发现的问题会直接反馈给开发团队，快速修复后再进入下一阶段。

β 测试（Beta Testing）

β 测试是软件基本完成开发、经过 α 测试修复主要问题后，由真实用户在实际使用环境中进行的测试，相当于 “公开试用”。

核心特点：

测试人员：外部用户（可能是特定用户群体，也可能是公开招募的试用者）。
测试环境：用户自己的真实环境（如个人电脑、手机等），不受开发方控制。
测试阶段：晚于 α 测试，是发布前的最后一轮大规模测试。
主要目的：收集用户实际使用中的反馈，发现 α 测试中未暴露的问题（如兼容性问题、性能瓶颈、用户体验缺陷等），验证软件在真实场景下的稳定性。
结果处理：用户反馈的问题会被整理后交给开发团队，作为最终优化的依据，修复后即可正式发布。

自动化测试

自动化测试是指通过工具、脚本或代码自动执行测试用例，替代或辅助人工测试的过程。其核心是将重复、机械的测试操作（如点击按钮、输入数据、验证结果等）转化为可自动运行的程序，从而提高测试效率、降低人为误差，并支持软件在快速迭代中持续验证质量。

Web自动化测试

Web 自动化测试是指通过自动化工具或脚本模拟用户在 Web 浏览器中的操作（如点击按钮、输入文本、跳转页面等），对 Web 应用的功能、兼容性、性能等进行自动化验证的测试手段。

要实现Web的自动化测试我们需要 Web+驱动+Selenium

这三者的交互关系如下所示

1. 通过selenium编写的自动化脚本代码中在ChromeDriverService中创建一个服务

2.通过创建好的服务打开webdriver，安装在本地的驱动服务IP为localhost，PORT为ChromeDriverService中创建的端口号，该服务地址为selenium向webdriver发送请求的服务地址。

3.向浏览器驱动程序发送HTTP请求，浏览器驱动程序解析请求，打开浏览器，并获得sessionid，如果再次对浏览器操作需携带此id

4.打开浏览器后，所有的selenium的操作(访问地址，查找元素等)均通过创建好的服务链接到webdriver，然后使用execute发送请求

5.驱动收到请求并对请求进行解析，转成浏览器能够解析的脚本并发送给浏览器，浏览器通过请求内容执行对应动作

6.浏览器再把执行的动作结果通过浏览器驱动程序返回给测试脚本

<dependencies><dependency><groupId>io.github.bonigarcia</groupId><artifactId>webdrivermanager</artifactId><version>5.8.0</version><scope>test</scope></dependency><dependency><groupId>org.seleniumhq.selenium</groupId><artifactId>selenium-java</artifactId><version>4.0.0</version></dependency>
</dependencies>

WebDriverManager是一个开源Java库，以完全自动化的方式对Selenium WebDriver所需的驱动程序(如chromedriver、geckodriver、msedgedriver等)进行管理(即下载、设置和维护)，自版本5起，WebDriverManager还提供了其他相关功能，如发现本地系统中安装的浏览器的能力，构建WebDriver对象(如ChromeDriver、FirefoxDriver、EdgeDriver等)

Selenium 是目前最流行的开源 Web 自动化测试框架，由一系列工具组成，支持跨浏览器、跨平台、多编程语言，广泛用于 Web 应用的功能测试和回归测试。

用一个demo来验证它的功能

import io.github.bonigarcia.wdm.WebDriverManager;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;public class AutoTest {public void test01(){WebDriverManager.chromedriver().setup();ChromeOptions options = new ChromeOptions();//允许访问所有连接options.addArguments("--remote-allow-origins=*");WebDriver driver = new ChromeDriver(options);//请求地址driver.get("https://www.baidu.com/");driver.findElement(By.xpath("//*[@id=\"chat-textarea\"]")).sendKeys("Java");driver.findElement(By.xpath("//*[@id=\"chat-submit-button\"]")).click();driver.quit();}
}