软件测试按照阶段划分，一般可以分为如下四类：
单元测试
单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：函数。常常由开发人员依据详细的设计文档进行测试，包含接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试等。总的来说，单元测试主要是测试程序员自己编写的代码逻辑的正确性，并非是端到端的集成测试，它不需要测试所依赖的外部系统的逻辑正确性。所以，如果代码中依赖了外部系统或者不可控组件，比如，需要依赖数据库、网络通信、文件系统等，那我们就需要将被测试代码与外部系统解依赖，而这种解依赖的方法就叫作"mock"。所谓的 mock 就是用一个"假"的服务替换真正的服务，mock 的服务完全在我们的控制之下，模拟输出我们想要的数据。
集成测试
将模块接口采用适当的集成策略组装起来，对模块的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查模块之间的接口是否正确。一般单元测试之后进行，主要测试模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响。
系统测试
包括对功能、性能以及软件所运行的软硬件环境进行测试。包括回归测试和冒烟测试，测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等。
验收测试
目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买者展示该软件系统满足原始需求。这个阶段主要是依据用户的需求和验收标准来测的，由用户进行测试，测试所有的功能是否符合他们的预期等等。
不同点
下面这个表格详细展示了单元测试、集成测试、系统测试和验收测试的区别：
1）【强制】好的单元测试必须遵守 AIR 原则。
说明：单元测试在线上运行时，感觉像空气（AIR）一样并不存在，但在测试质量的保障上，却是非常关键的。好的单元测试宏观上来说，具有自动化、独立性、可重复执行的特点。
A：Automatic（自动化）
I：Independent（独立性）
R：Repeatable（可重复）
2）【强制】单元测试应该是全自动执行的，并且非交互式的。测试框架通常是定期执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测试中不准使用 System.out 来进行人肉验证，必须使用 assert 来验证。
3）【强制】保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护，单元测试用例之间决不能互相调用，也不能依赖执行的先后次序。
反例：method2 需要依赖 method1 的执行，将执行结果做为 method2 的输入。
4）【强制】单元测试是可以重复执行的，不能受到外界环境的影响。
说明：单元测试通常会被放到持续集成中，每次有代码 check in 时单元测试都会被执行。如果单测对外部环境（网络、服务、中间件等）有依赖，容易导致持续集成机制的不可用。
正例：为了不受外界环境影响，要求设计代码时就把 SUT 的依赖改成注入，在测试时用spring这样的 DI 框架注入一个本地（内存）实现或者 Mock 实现。
5）【强制】对于单元测试，要保证测试粒度足够小，有助于精确定位问题。单测粒度至多是类级别，一般是方法级别。
说明：只有测试粒度小才能在出错时尽快定位到出错位置。单测不负责检查跨类或者跨系统的交互逻辑，那是集成测试的领域。
6）【强制】核心业务、核心应用、核心模块的增量代码确保单元测试通过。
说明：新增代码及时补充单元测试，如果新增代码影响了原有单元测试，请及时修正。
7）【强制】单元测试代码必须写在如下工程目录：src/test/java，不允许写在业务代码目录下。
说明：源码构建时会跳过此目录，而单元测试框架默认是扫描此目录。
8）【推荐】单元测试的基本目标：语句覆盖率达到80%。
说明：在MVC分层中的 DAO 层，可重用度高的 Service，都应该进行单元测试。
9）【推荐】编写单元测试代码遵守 BCDE 原则，以保证被测试模块的交付质量。
B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。
C：Correct，正确的输入，并得到预期的结果。
D：Design，与设计文档相结合，来编写单元测试。
E：Error，强制错误信息输入（如：非法数据、异常流程、非业务允许输入等），并得到预期的结果。
10）【推荐】针对 private 方法，不单独写单元测试，应该依赖 public 方法的单测去调用。
11）【推荐】对于不可测的代码建议做必要的重构，使代码变得可测，避免为了达到测试要求而书写不规范测试代码。
12）【推荐】在设计评审阶段，开发人员需要和测试人员一起确定单元测试范围，单元测试最好覆盖所有测试用例（UC）。
13）【推荐】单元测试作为一种质量保障手段，不建议项目发布后补充单元测试用例，建议在项目提测前完成单元测试。
14）【参考】为了更方便地进行单元测试，业务代码应避免以下情况：
构造方法中做的事情过多。
存在过多的全局变量和静态方法。
存在过多的外部依赖。
存在过多的条件语句。
使用复杂的继承关系。
说明：多层条件语句建议使用卫语句、策略模式、状态模式等方式重构。
采用 Mockito 框架，不采用其他框架，已经使用 PowerMock 等其他框架的单测代码保留不变或者自行修改。我们注意到，Mockito 框架在持续更新，PowerMock 最新的版本停在了是2020年11月份。
Mockito 推荐使用4.x版本，Mockito4要求jdk最低为jdk8，Mockito5最低要求为jdk11。
采用 JUint4 框架。
3.1、引入 Mockito和 Spring Test 依赖
在pom.xml文件中加入下列依赖：
3.2、一个简要的测试样例
下面列举简单的service写法：
对应的测试类如下：
版权声明：
本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。
本文网址：https://www.mushiming.com/mjsbk/6308.html