软件测试的常见分类是一个多角度、层次化的体系，这些分类并不是相互分开的，而是根据测试活动的不同重点、阶段和目的相互交织，共同保证软件质量。

一、 按测试阶段和对象

这是最经典的分类方向，反映了软件从构建到交付过程中，测试关注点的逐级上升。

1. 单元测试

这是最微观的测试级别，聚焦于软件中最小的可测试单元，一般是函数、方法或类。主要目的是验证每个独立单元的内部逻辑正确性，隔离外部依赖（常使用测试替身如Mock、Stub）。由开发者本人在编码阶段同步完成，是缺陷反馈最快、修复成本最低的步骤。适用场景包括：驱动开发（如TDD）、保证主要算法正确性、重构代码时的安全网。

2. 集成测试

在单元测试之后，关注点转移到单元之间的接口和交互。目的是暴露在模块相互调用、数据传递、以及和环境（如数据库、外部服务）集成时产生的缺陷，例如接口协议不一致、数据格式错误、资源竞争或异常处理缺失。适用场景包括：验证子系统间的协作、接口契约测试、在持续集成环境中快速发现集成问题。

3. 系统测试

这是将已集成的软件作为一个完整的系统进行测试。站在用户和业务需求的角度，在尽可能模拟真实生产环境（或预发布环境）中进行。系统测试全面验证功能性需求和非功能性需求（如性能、安全、可靠性）。一般由独立的测试团队执行，是交付前验证产品整体行为是否符合规格说明书的决定性步骤。所有上线的软件都必须经过严格且完整的系统测试。

4. 验收测试

这是最高层级的测试，为了从最终用户或产品所有者的视角确认软件是否已准备好交付和部署。基于用户需求而非技术规格，一般使用真实的业务场景和工作流。验收测试又可分为：用户验收测试，由最终客户或领域专家执行；运营验收测试，验证系统的可维护性、备份恢复等运维需求；合同/法规验收测试，保证符合合同条款或行业法规。这是产品上线前的最后一道质量关卡。

二、 按测试方法和可见性划分

此方向关注测试用例的设计依据和执行方式。

1. 黑盒测试

测试者将软件视为一个不透明的“黑盒”，无需了解内部结构和代码，仅依据需求规格说明书，针对输入和输出关系进行测试。主要是验证功能是否实现，行为是否符合预期。等价类划分、边界值分析、决策表、状态转换等是经典设计技术。绝大多数系统测试和验收测试都属于黑盒范畴。

2. 白盒测试

和黑盒相对，测试者需要深入软件内部逻辑，基于代码结构（如控制流、数据流）来设计测试用例。目的是实现一定的覆盖率指标（如语句覆盖、分支覆盖、路径覆盖），以发现逻辑错误、循环错误或条件判断缺陷。主要由开发人员进行，是单元测试和部分集成测试的主要方法。

3. 灰盒测试

一种实用主义的混合方法。测试者具备有限的内部知识（如数据库架构、算法概要），但测试设计和执行仍主要从外部接口层面进行。这种方法能设计出比纯黑盒更高效、更深层的测试用例，尤适用于集成测试、安全性测试和性能调优场景。

三、 按测试目的\质量属性

此方向定义了测试的具体质量特性。

1. 功能测试

验证软件是否实现了规定的功能，这是所有测试活动的基础。涵盖正面功能验证、错误处理、数据完整性等。

2. 非功能测试

评估软件在特定条件下的表现和行为，关乎产品的“品质”而不仅仅是“功能”。包含一系列关键子类：

性能测试：评估系统的响应时间、吞吐量、资源利用率和可伸缩性。具体包括压力测试（超负荷下）、负载测试（预期负荷下）、耐力测试（长时间运行）、尖峰冲击测试。

安全测试：主动发现系统的安全漏洞，如注入、跨站脚本、权限提升、敏感数据泄露等，涉及漏洞扫描、渗透测试、代码审计。

兼容性测试：保证软件在不同目的环境（如浏览器、操作系统、移动设备、不同硬件配置）中正常工作。

可用性测试：从用户界面和交互体验角度，评估软件是否易学、高效、令人满意且符合人机工程学。

可靠性测试：验证软件在长时间或高负荷下无故障运行的能力，以及故障发生后能否正确恢复。

3. 专项测试

回归测试：在任何代码修改后执行，为了保证原有功能未被意外破坏。是持续集成和敏捷开发中的主要安全网。

探索性测试：在无预设脚本的情况下，结合学习、设计和执行，依赖于测试者的经验、直觉和创造力，为了发现计划外、意料之外的缺陷。

四、 综合应用

在实际项目中，这些分类是纵横交错的。一个完整的测试策略，需要根据项目特点（如技术架构、风险分布、业务关键性）来选择和组合。

例如，对一个金融主要系统，策略可能是：单元测试（白盒）保证算法绝对正确；接口自动化测试（灰盒）保障每日构建的集成质量；全面的系统测试（黑盒）覆盖所有功能路径；严格的非功能测试包括性能压测、安全渗透测试和合规性测试；最后，由业务专家进行用户验收测试。

理解每种分类的“为何”（目的）和“何时”（场景），远比记忆名称更重要。这使得测试团队能够为特定项目裁剪出最有效、最经济的测试活动集合，从而系统性地管理风险，交付高质量产品。