通常，我们可以从以下几个核心视角来对这些测试进行分类和理解：
📊 按测试级别划分 (由小到大)
这种分类方式关注测试在开发流程中的阶段和范围。
-
单元测试 (Unit Testing)
- 是什么：对软件中最小的可测试单元（如一个函数、一个类或一个模块）进行验证。
- 谁来做：通常由开发人员自己完成。
- 目的：确保每个独立的“零件”在组装前本身就是正确的。
-
集成测试 (Integration Testing)
- 是什么：将已经通过单元测试的模块组装起来，测试它们之间的接口和交互是否正常。
- 目的：发现模块间接口不匹配、数据传递错误等问题，确保“零件”能正确地拼装成“子系统”。
-
系统测试 (System Testing)
- 是什么：将整个软件系统作为一个整体进行测试，包括软件、硬件、网络等所有元素。
- 目的：验证完整的系统是否满足了需求规格说明书中的所有要求，模拟真实用户环境进行端到端的测试。
-
验收测试 (Acceptance Testing)
- 是什么：软件交付前的最后一道测试，通常由最终用户或客户来执行。
- 目的：确认软件是否满足了用户的业务需求和预期，决定是否接受这个产品。常见的形式有 Alpha 测试（内部模拟用户）和 Beta 测试（向部分真实用户发布）。
🎯 按测试目的划分 (功能与非功能)
这种分类方式关注测试是为了验证软件的哪个方面。
功能性测试 (Functional Testing)
关注软件“做什么”，即功能是否正确。
- 冒烟测试 (Smoke Testing) ：在正式测试前，对软件的核心功能进行快速检查，确保版本基本稳定，可以进行后续测试。
- 探索性测试 (Exploratory Testing) ：不依赖预设的测试用例，测试人员凭借经验和直觉自由探索软件，以发现一些难以预测的缺陷。
- API 测试 (API Testing) ：直接对应用程序编程接口（API）进行测试，验证不同软件组件之间的数据交互是否正确可靠。
非功能性测试 (Non-functional Testing)
关注软件“做得怎么样”，即性能和用户体验。
-
性能测试 (Performance Testing) ：评估软件在不同负载下的响应速度、稳定性和资源消耗情况。它通常包括：
- 负载测试 (Load Testing) ：模拟预期的用户并发量，测试系统性能。
- 压力测试 (Stress Testing) ：施加超出预期的压力，测试系统在极限情况下的表现和崩溃点。
-
安全测试 (Security Testing) ：验证软件抵御恶意攻击的能力，发现潜在的安全漏洞，如SQL注入、跨站脚本等。
-
兼容性测试 (Compatibility Testing) ：检查软件是否能在不同的操作系统、浏览器、硬件设备或网络环境下正常运行。
-
可用性测试 (Usability Testing) ：从用户角度出发，评估软件界面是否直观、易用，用户体验是否良好。
🛠️ 按测试方法划分 (是否看代码)
这种分类方式关注测试时是否需要了解软件的内部实现。
- 黑盒测试 (Black-box Testing) ：测试人员完全不关心软件内部代码如何实现，只关注输入和输出是否符合预期。
- 白盒测试 (White-box Testing) ：测试人员需要深入了解软件的内部逻辑和代码结构，并据此设计测试用例，以确保代码路径、分支等被充分覆盖。
- 灰盒测试 (Gray-box Testing) ：介于黑盒和白盒之间，测试人员对软件内部结构有部分了解，结合两者特点进行测试。
⚙️ 按执行方式划分 (手动与自动)
- 手动测试 (Manual Testing) ：由测试人员模拟用户操作，手动执行测试用例。适合探索性测试、可用性测试等需要人类主观判断的场景。
- 自动化测试 (Automated Testing) ：使用脚本和工具自动执行测试。适合回归测试、性能测试等需要重复、大量执行的场景，能极大提高效率。
总而言之，一个高质量的软件产品，通常是综合运用了以上多种测试方法的结果。不同的测试类型相互补充，共同构成了完整的软件质量保障体系。
⚙️ 回归测试
核心目标：防止“顾此失彼”
现代软件系统的各个模块高度耦合，牵一发而动全身。回归测试就是为了防止以下情况发生：
- 修复了一个Bug，却引入了两个新Bug。
- 添加了一个新功能，却导致一个老功能失效。
- 优化了某处性能，却降低了另一处的响应速度。
