测试分类介绍

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

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

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

按照测试目标进行分类

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

具体类别如下：

测试类型	对应质量属性	核心目标	典型方法/工具
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）
典型阶段	系统测试之后，正式发布之前	α测试通过后，正式发布前（或作为灰度发布一环）

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