今天小编来介绍下测试分类。

那么为什么要有这个测试分类呢？

软件测试是软件生命周期中的一个重要环节，具有较高的复杂性，对于软件测试，可以从不同的角度/维度加以分类，使开发者在软件开发过程中的不同层次，不同阶段对测试工作进行更好的执行和管理测试的分类方法

按照测试目标进行分类

这个是值根据测试所要验证的软件质量特性（如功能正确性、界面友好性、性能稳定性等）来划分测试类型

具体类别如下：

测试类型	对应质量属性	核心目标	典型方法/工具
1. 功能测试	功能适合性、准确性	验证系统是否按需求正确实现业务逻辑	黑盒测试、判定表、等价类
2. 界面测试（UI/UX）	易用性、美观性	验证界面是否符合设计规范，操作是否直观	人工走查、视觉回归工具（Applitools）
3. 性能测试	性能效率（响应时间、吞吐量、资源利用）	验证系统在负载下的速度、稳定性和可伸缩性	JMeter、LoadRunner、Gatling
4. 兼容性测试	兼容性	验证系统在不同环境（OS/浏览器/设备）下表现一致	云测平台（BrowserStack、Testin）
5. 易用性测试	易用性（可学习性、可操作性）	验证用户能否高效、无挫败感地完成任务	用户访谈、A/B测试、眼动追踪
6. 安全测试	安全性（保密性、完整性、抗攻击性）	验证系统能否抵御恶意攻击和数据泄露	OWASP ZAP、Burp Suite、渗透测试
7. 可靠性测试	可靠性（容错性、可用性）	验证系统在异常或长时间运行下的稳定性	故障注入、7×24 小时稳定性测试
8. 可维护性 & 可移植性测试	可维护性、可移植性	验证代码可读性、模块解耦、部署便捷性	代码扫描（SonarQube）、部署演练

注意：有些情况下，会把弱网测试纳入性能测试，安装卸载测试纳入兼容性测试

具体内容如下：

1. 功能测试（Functional Testing）

目标：验证“系统是否做了它该做的事”
内容：
- 业务流程（注册 → 登录 → 下单）
- 输入验证（边界值、非法字符）
- 数据处理（计算、存储、同步）
- 错误处理（提示、回滚）
示例：

用户输入优惠券码，系统正确抵扣金额，且不可重复使用。

2. 界面测试（UI/UX Testing）

目标：验证“界面是否好看、好用”
内容：
- 布局、字体、颜色、图标一致性
- 控件状态（禁用/启用/悬停）
- 提示文案清晰无错别字
- 响应式适配（PC/Pad/手机）
示例：

在 iPhone 14 上，“提交订单”按钮完整显示，无遮挡。

3. 性能测试（Performance Testing）

目标：验证“系统是否快、稳、省”
子类型：
- 负载测试：模拟预期用户量
- 压力测试：突破系统极限
- 稳定性测试：长时间运行是否泄漏
示例：

1000 用户并发下单，平均响应时间 ≤ 1.5s，错误率 < 0.1%。

4. 兼容性测试（Compatibility Testing）

目标：验证“系统是否在各种环境下正常工作”
维度：
- 操作系统（Windows 10/11, macOS, Android 12/13）
- 浏览器（Chrome, Firefox, Safari, Edge）
- 设备（iPhone, 华为, 小米, iPad）
- 分辨率 & 屏幕方向
示例：

在 Safari 16 上，支付页面 JavaScript 不报错。

5. 易用性测试（Usability Testing）

目标：验证“用户是否愿意用、能轻松用”
关注点：
- 学习成本（新用户能否自助完成）
- 操作效率（完成任务步骤是否最少）
- 容错能力（误操作能否撤销）
示例：

90% 的测试用户能在 2 分钟内完成首次发布内容。

6. 安全测试（Security Testing）

目标：验证“系统是否防得住攻击”
常见攻击面：
- 注入（SQL、XSS）
- 越权（普通用户访问管理员接口）
- 敏感信息泄露（日志、URL、缓存）
- 会话劫持（Token 未加密/未过期）
示例：

输入 ' OR '1'='1 到登录框，系统返回“用户名或密码错误”，而非数据库报错。

7. 可靠性测试（Reliability Testing）

目标：验证“系统是否扛得住意外”
场景：
- 网络中断后自动重连
- 服务宕机后自动恢复
- 长时间运行无内存泄漏
示例：

APP 在后台运行 72 小时，内存占用无持续增长。

8. 可维护性 & 可移植性测试（Maintainability & Portability）

目标：验证“系统是否易于修改和迁移”
内容：
- 代码模块化程度
- 配置与代码分离
- 部署脚本是否一键完成
- 是否依赖特定硬件/OS
示例：

将服务从 CentOS 迁移到 Ubuntu，仅需修改 1 个配置文件

按照执行方式分类：

核心分类：两大执行方式

分类	是否运行程序	主要目的	典型阶段
静态测试（Static Testing）	不运行代码	预防缺陷：在代码/文档编写阶段发现错误	需求、设计、编码早期
动态测试（Dynamic Testing）	运行程序	发现缺陷：通过执行程序观察行为是否符合预期	编码完成后（单元测试起

静态测试：

不执行被测软件，而是通过人工或工具对文档、代码、设计等制品进行检查，以发现潜在缺陷

主要方法：

方法	说明	责任人
1. 评审（Review）	有组织的文档检查活动	- 非正式评审：结对编程、走查（Walkthrough） - 正式评审：技术评审（Technical Review）、审计（Inspection）
2. 静态分析（Static Analysis）	用工具自动分析源代码/字节码	- 代码规范检查（缩进、命名） - 潜在缺陷检测（空指针、资源泄漏） - 安全漏洞扫描（硬编码密码）

动态测试：

通过实际运行被测程序，输入测试数据、观察输出结果、行为、性能等是否符合预期

主要方法（按技术视角）：

方法	说明	典型场景
1. 黑盒测试	不关心内部结构，只测输入-输出	功能测试、验收测试
2. 白盒测试	基于代码逻辑设计用例（如覆盖所有分支）	单元测试、集成测试
3. 灰盒测试	介于两者之间，了解部分内部结构	API 测试、数据库验证

主要方法（按自动化程度）：

类型	说明
手工测试	人工操作界面或命令行执行
自动化测试	用脚本/工具自动执行（如 Selenium、JUnit）

按照测试方法分类：

常用的测试方法有：白盒测试、灰盒测试、黑盒测试

方法概览：

方法	是否需要代码知识	测试视角	主要目标	典型阶段
白盒测试（White-box）	需要	内部结构视角（像开发一样看代码）	验证代码逻辑是否被充分执行	单元测试、集成测试
黑盒测试（Black-box）	不需要	用户视角（只关心输入→输出）	验证功能是否符合需求	系统测试、验收测试
灰盒测试（Gray-box）	部分需要	混合视角（知道部分内部结构）	结合功能与结构，提高测试效率	API测试、集成测试

白盒测试（动态）中的常见六种测试方法

覆盖类型	定义	覆盖目标	示例（代码片段）	是否覆盖所有路径？
1. 语句覆盖（Statement Coverage）	每条可执行语句至少执行一次	行覆盖率	if (a>0) print("A"); else print("B"); → 输入 a=1（只覆盖 print("A")）	否（else 分支未覆盖）
2. 判定覆盖（Decision Coverage）（又叫分支覆盖）	每个判定（if/while）的真假分支都至少执行一次	分支覆盖率	同上 → 需 a=1（真）和 a=-1（假）	否（复合条件可能漏）
3. 条件覆盖（Condition Coverage）	每个原子条件（如 a>0, b==1）的真假值都至少出现一次	条件取值覆盖率	if (a>0 && b<5) → 需 a>0为真/假，b<5为真/假	否（未覆盖组合）
4. 判定-条件覆盖（Decision/Condition Coverage）	同时满足判定覆盖 + 条件覆盖	分支 + 条件取值	同上 → 需覆盖所有条件取值 + 整个 if 的真假	仍可能漏组合
5. 条件组合覆盖（Multiple Condition Coverage）	每个判定中所有条件的真假组合都至少执行一次	条件组合覆盖率	if (a>0 && b<5) → 需4种组合： (T,T), (T,F), (F,T), (F,F)	对单个判定是，但跨判定不一定
6. 路径覆盖（Path Coverage）	程序中所有可能的执行路径都至少走一遍	全路径覆盖率	含多个 if 的嵌套 → 路径数 = 2ⁿ（n=独立判定数）	是（理论上最全）

覆盖强度关系：

语句覆盖 < 判定覆盖 ≤ 条件覆盖 < 判定-条件覆盖 < 条件组合覆盖 ≤ 路径覆盖

黑盒测试中常用方法：

方法	适用场景	说明
等价类划分	输入有范围/类型	将输入划分为有效/无效类
边界值分析	数值型输入	测试边界及邻近值（min-1, min, min+1）
判定表法	多条件组合逻辑	用表格覆盖规则组合
状态迁移测试	有状态系统（如订单状态）	验证状态转换是否合法
场景法/用例法	业务流程长	模拟用户真实操作路径
错误推测法	基于经验猜缺陷	如“空输入”“超长字符串”

灰盒测试常用方法：

场景	说明
API 测试	知道请求/响应结构，但不关心服务端 if-else 逻辑
数据库验证	知道表字段，验证增删改查后数据是否正确
集成测试	知道模块A调用模块B，验证接口契约是否满足
安全测试（部分）	知道登录流程，测试越权访问

按照测试阶段分类

通常可以分为以下这5个阶段：

阶段	英文	测试对象	主要目标	责任人
1. 单元测试	Unit Testing	单个函数/类/模块	验证最小代码单元逻辑正确性	开发人员
2. 集成测试	Integration Testing	多个模块/服务间交互	验证接口、数据流、依赖是否正常	开发 / 测试
3. 系统测试	System Testing	整个集成后的系统	验证系统是否满足需求规格（功能+非功能）	测试人员
4. 验收测试	Acceptance Testing	可交付的完整产品	验证是否满足用户/业务方真实需求	产品 / 用户 / 测试
5. 回归测试	Regression Testing	修改后的系统	验证新代码是否破坏已有功能	自动化 + 测试

各阶段详解：

1. 单元测试（Unit Testing）

目标：验证最小可测试单元（如一个函数、一个类）的行为是否正确。
特点：
- 隔离外部依赖（用 Mock/Stub）
- 执行速度快（毫秒级）
- 覆盖率高（通常要求分支覆盖 ≥ 80%）
方法：白盒测试（语句/分支覆盖）
工具：
- Java: JUnit + Mockito
- Python: pytest + unittest.mock
- JS: Jest, Mocha
示例：
Java
编辑

// 测试 calculateDiscount(100, true) → 应返回 80
@Test
public void testVipDiscount() {
    assertEquals(80, DiscountService.calculateDiscount(100, true));
}

责任人：开发人员（TDD/BDD 实践中甚至先写测试）

2. 集成测试（Integration Testing）

目标：验证多个模块或服务在集成后能否协同工作。
常见策略：
- 自底向上：先测底层模块，逐步集成
- 自顶向下：先测高层调用，用 Stub 模拟底层
- 大爆炸集成：所有模块一次性集成（风险高，不推荐）
测试重点：
- API 接口契约（请求/响应格式）
- 数据库读写一致性
- 第三方服务调用（如支付、短信）
方法：灰盒测试（知道接口，不深究内部逻辑）
工具：
- Postman（手动）
- RestAssured, Karate（自动化）
- TestContainers（集成数据库/中间件）
示例：

调用“创建订单”API → 验证订单服务是否正确调用库存服务扣减库存

责任人：开发（模块间） / 测试（服务间）

3. 系统测试（System Testing）

目标：对完整、集成后的系统进行全面验证，包括功能与非功能需求。
测试类型覆盖（即提到的“万能公式”）：
- 功能测试
- 界面测试
- 性能测试
- 兼容性测试
- 安全测试
- 易用性测试
- 弱网测试
方法：黑盒测试为主
工具：
- UI 自动化：Selenium, Cypress, Appium
- 性能：JMeter, Locust
- 安全：OWASP ZAP
示例：

用户从注册 → 登录 → 下单 → 支付 → 查看订单，全流程验证

责任人：专职测试人员

4. 验收测试（Acceptance Testing）

目标：确认系统是否满足业务方或最终用户的真实需求，决定是否可上线。
类型：
- UAT（User Acceptance Testing）：由真实用户或产品经理执行
- 合同验收测试：按合同条款验证
- Alpha 测试：内部用户试用（开发环境）
- Beta 测试：外部用户试用（生产环境灰度）
特点：
- 基于真实业务场景
- 不关注技术细节
- 通常手工执行
示例：

财务人员验证“月度报表导出”数据是否与线下账目一致

责任人：产品经理、业务方、最终用户

5. 回归测试（Regression Testing）

目标：确保新代码修改没有破坏已有功能。
触发时机：
- 修复 Bug 后
- 新增功能后
- 重构代码后
策略：
- 全量回归：成本高，适用于重大版本
- 选择性回归：基于影响分析（Impact Analysis）
- 自动化回归：核心主干流程必须自动化
工具：所有自动化测试框架（Selenium, pytest, JUnit 等）
示例：

修改了登录逻辑后，重新执行“注册、登录、找回密码”相关用例

责任人：测试 + 自动化脚本

按照是否手工测试分类

手工测试：

就是由人去一个个的输入用例，观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤

自动化测试：

就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说

自动化测试是把以为驱动的测试行为转化为机器执行的一种过程。自动化测试比如功能测试自动化、

性能测试自动化、安全测试自动化。自动化测试按照测试对象来分的话，还可以分为接口测试、UI测试等

.接口测试的ROI（产出投入比）要比UI测试高

自动化测试优点

节省成本
提高测试人员执行工作效率
保障软件的质量

自动化测试缺点

对测试人员技术要求较高
不能发散性测试

手工测试优点

对测试人员技术要求没有自动化技术要求高
可以进行发散性测试

手工测试缺点

效率低
人员，时间成本比起自动化测试都比较高

按照实施组织划分

核心分类如下：

维度	α测试（Alpha Testing）	β测试（Beta Testing）
中文名	内部测试 / 封闭测试	外部测试 / 公开测试
实施组织	公司内部人员（开发、测试、产品、非项目员工）	真实外部用户（客户、种子用户、公众）
测试环境	受控的内部环境（开发/预生产环境）	真实用户环境（用户自己的设备、网络、操作系统）
测试目标	验证核心功能稳定性，发现严重缺陷	验证真实场景下的可用性、兼容性、用户接受度
反馈机制	直接、快速、结构化（如 Jira）	间接、延迟、非结构化（如问卷、应用商店评论）
是否公开	不对外公开	可公开（Open Beta）或邀请制（Closed Beta）
典型阶段	系统测试之后，正式发布之前	α测试通过后，正式发布前（或作为灰度发布一环）

那么还有其他的一些测试分类，小编就在这里不再做过多介绍了，本次分享就到这里。