以登录功能理解单元测试、集成测试、系统测试和用户测试

在学习测试阶段时，我发现最容易混淆的一点是：测试阶段、测试方法、测试手段 其实不是同一个维度。

简单来说：

所以，单元测试不等于白盒测试，集成测试也不代表一定不能使用 Mock 或 Stub。关键要看本次测试目标是什么。

登录功能链路

以一个登录功能为例，它背后可能包含这些步骤：

latex 复制代码

用户输入账号密码
-> 调用登录接口
-> 查询用户信息
-> 校验密码
-> 查询角色权限
-> 生成 Token / Session
-> 返回登录结果并跳转页面

单元测试：验证小零件本身是否正确

单元测试关注的是最小代码单元，比如一个函数、一个方法、一个类的行为是否正确。

以登录功能为例：

单元测试通常偏白盒，因为开发更了解内部代码结构，但它并不只能用白盒方法。像等价类、边界值这些黑盒设计方法，也完全可以用于单元测试。

集成测试：验证模块之间能否正确协作

集成测试关注的是多个模块连接起来之后是否能正常工作。

以登录功能为例：

登录接口调用用户服务
常用手段：接口测试
例如用 Apifox、Postman 或自动化脚本调用 /login，验证返回状态码、Token、用户信息是否正确。
登录模块与权限模块联调
常用方法：接口联调、判定表、权限矩阵
例如不同角色登录后，是否返回对应的菜单和操作权限。
用户服务查询数据库
常用方法：数据驱动、异常数据验证
例如用户存在、用户不存在、账号被禁用、数据库中存在脏数据时，登录结果是否符合预期。
登录成功后写入 Session / Token
常用方法：链路验证、异常测试
例如登录成功后是否生成 Token，Token 是否有效，Session 写入失败时系统是否能正确处理。

这里容易产生疑问的是：集成测试不是应该调用真实对象吗？为什么还会用 Mock 或 Stub？

我的理解是：集成测试中，本次重点验证的模块应该是真实的；但非重点、不可控、还没开发完、或者很难制造异常的外部依赖，可以用 Mock 或 Stub 辅助。

latex 复制代码

Stub：固定返回结果的替身。
Mock：模拟依赖对象，并且可以检查是否按预期被调用。
异常注入：故意制造异常，验证系统能否正确处理。

例如，登录模块和用户服务已经开发完成，但权限服务还没完成。此时可以用 Stub 固定返回"医生权限"，先验证登录主流程是否正常。

再比如想测试"权限服务超时后，登录接口如何处理"。真实权限服务不一定容易制造超时，这时就可以用 Mock 或异常注入来模拟超时、500、字段缺失等情况。

所以集成测试不是"所有东西必须都真实"，而是"本次要验证的集成关系必须真实"。

系统测试：验证完整系统是否符合需求

系统测试关注的是从完整系统角度验证功能是否正确。它不再只看某个函数或某几个模块，而是看用户完整使用时，系统表现是否符合需求。

以登录功能为例：

系统测试中的"系统"不是只指硬件环境，而是指整个软件系统。硬件、浏览器、分辨率、操作系统等环境验证，只是系统测试中的一部分。

用户测试：验证业务人员是否认可这个功能

用户测试通常也叫用户验收测试，也就是 UAT。它关注的不是代码实现，而是真实业务人员是否认为这个功能可用、好用、符合业务流程。

以医院系统登录为例：

用户测试常用的是业务场景法、验收用例、可用性测试。它更接近真实工作场景，也更关注业务目标是否达成。

总结

可以用一句话区分这几个阶段：

latex 复制代码

单元测试：零件本身对不对。
集成测试：零件接起来对不对。
系统测试：整套系统对不对。
用户测试：真实用户觉得能不能用。

再补充一个容易混淆但很重要的点：

latex 复制代码

单元、集成、系统、用户测试，是测试级别。
白盒、黑盒、灰盒，是测试视角。
等价类、边界值、判定表、状态迁移、场景法，是用例设计方法。
Mock、Stub、异常注入，是控制依赖和制造测试场景的手段。

理解这些概念时，不能只背定义，最好结合一个具体功能去拆。比如登录功能，从账号格式校验到权限返回，再到用户真实登录体验，刚好能把不同测试阶段串起来，也更容易理解每个阶段到底在测什么。