企业级Web项目中应该如何做单元测试、集成测试和功能测试？

先自我介绍下：

本人有过10年测试经验，也参与过公安部网络安全产品测试交付、华为4G

网络设备测试交付、腾讯QQ空间APP产品测试交付。

关于“企业级Web项目中应该如何做单元测试、集成测试和功能测试”这个问题，我想给大家唠唠，我所知道的这方面知识。

一、首先简单说说这三种测试有什么区别

【单元测试】、【集成测试】和【功能测试】三种测试的是什么，三者有什么区别和联系，如果想更清晰的了解

通过上方文章我们可以知道，

1、 单元测试是针对程序的源代码

进行测试；
2、集成测试是将单元测试的源代码/模块进行组装测试，一般我们也叫它接口测试；
3、这里的功能测试，也叫系统测试。该类测试就是对整个系统进行UI层面的测试，内容包括功能测试、兼容性测试、易用性测试、可靠性测试等。由于功能是最核心的部分，所以大家也把系统测试，习惯性叫功能测试。

二、企业级Web项目中是怎么做这三类测试的？

早期的项目中，由于受测试人员技术水平的限制，外加系统测试（也可称为功能测试）往往能起到立竿见影的效果，所以基本都是以系统测试（也叫功能测试）为主导，集成测试（也叫接口测试）为辅。

而单元测试交给开发来做，测试人员对这块的工作涉及较少。

这种测试现象被称为冰淇淋理论（如下图）。

如果说早起是冰淇淋理论，接下来我们看看当前企业三类测试是怎么弄的：

1、当前企业项目是如何做系统测试（也叫功能测试）的：

系统测试（也叫功能测试）是从⽤户的⾓度出发，验证系统是否满⾜需求规格说明书中的功能要求，以保证UI界⾯功能性、⾮功能性正常使⽤。

一开始，系统测试（也叫功能测试）大部分都是手工的测试工作。

再后来，慢慢有了各种自动化测试工具的辅助，进行端到端的自动化测试，来提升回归测试的效率，如：早期的QTP工具、后面的Selenium、Appium，RobotFramework等框架。

到现在，各种小程序端、游戏端等自动化测试框架层出不穷。框架越来越丰富，但本质都是一样的，就是通过UI界面上各种元素的定位，再加上框架提供的一些操作类API（例如：点击、输入、拖拽等），模拟人工对UI界面进行操作，以达到自动化执行的效果。这种操作方法在测试领域有个高大上的叫法“小程序持续集成与持续部署

2、当前企业项目是如何做集成测试（也叫接口测试）的

随着前后端分离架构的普及，前后端集成测试（也叫接口测试）基本已经被所有项目组广泛接受。

相比系统测试（也叫功能测试）而言，集成测试（也叫接口测试）可以更早介入，更早发现问题，确实有一定的提效作用。

如果想用手工来做接口测试，当前可以使用Postman、Jmeter、或者Swagger等工具或者组件，模拟客户端-的请求，直接验证服务器的返回结果是否正确。

如果想用自动化来做接口测试，当前可以使用Jmeter工具，或者Requests库来实现。

对于项目而已，接口的变化几率比UI界面元素的变化要小得多，所以自动化脚本更好维护，所以接口自动化的范围越来越广，这几年在自动化比例上已经远超UI自动化。

再加上CI/CD等持续集成平台的辅助，自动化构造执行能力大大提升。

不过随着这几年微服务架构的兴起，部分使用微服务的团队，还可以做基于RPC（微服务）接口的自动化，例如常见的Dubbo接口，现在也有一些现成的框架，可以提供现成的API来进行Dubbo接口的调用和结果校验。但其原理和前后端的HTTP接口调用没有本质区别，就是模拟客户端发送请求，然后接收结果进行校验即可。