再聊这个问题之前，我们先了解一下公司技术架构的演变过程，这样我们才能真正体会到我们为什么要使用 Mock功能。

单体应用

在早期， 大部分公司的应用技术栈主要可以分为两大类：LAMP（Linux + Apache + MySQL + PHP）和 MVC（Spring MVC+ Hibernate/MyBatis + Tomcat）。这两种技术栈都是为单体应用架构设计的，具有易学易懂、开发上手快以及测试、部署、运维方便等优点。因此，单人甚至可以完成一个网站的完整开发和部署过程。以MVC架构为例，通常我们只需将一个 war 包部署到Tomcat中，启动Tomcat并监听特定端口，就可以向外部提供服务。在业务规模和开发团队人数较小的初期，这种单体应用架构可以有效控制团队的开发和运维成本。

但是随着业务规模的不断扩大，团队开发人员的不断扩张，单体应用架构就会开始出现问题。只有经历过公司业务量从 0 到百万级流量的人员对此深有感触，别说现在的千万甚至亿级流量。从我的角度来看，会有如下几个明显的问题：

• 部署效率低、时间长：在我们测试过的项目里面，最久的编译、打包到部署完成达到 1 个小时，如果提测的版本存在阻碍问题，再次进行部署，我们想想就可以知道这种效率。

• 团队协作效率低、成本高：团队规模达到一定规模之后，这种模式就会存在这种团队协作效率低下的问题，例如一个人的代码修改了要打包，就需要通知所有人，是否提交了代码，提交的有没有影响。

• 系统高可用降低：由于团队里面每个人的技术水平不一，就会导致代码里面存在不稳定的因素，又因为单体应用所有功能都打在一个 war 包里面，就会影响程序的运行。例如编写的代码存在内存泄露、耗资源等情况，很容易是整个应用挂掉。

• 线上发布太慢：部署过环境的都清楚，我们把安装包上传到服务器后，就是启动应用，但是有些启动的时候很长，特别是 Java 应用，我见过就一个小业务的应用，启动就差不多用了 15 分钟，如果是再大一些，启动时间就更长了。

微服务

具体微服务可以去参考对应的微服务的技术文章进行了解，下面是个人的理解。

微服务是一种应用构建方式，该应用由多个小型服务组成，这些服务各自运行在独立的进程中。这些服务通过轻量级通讯机制相互交互，同时，它们可以通过自动化部署机制独立地进行部署。由于在微服务架构中，各个服务都是相互独立的，因此它们可以根据业务需求使用不同的技术进行实现。

个人看来，微服务具有如下优点：

• 更快的开发速度：微服务架构支持团队对服务进行独立的开发与部署，从而提升了开发的效率。同时，每个服务的独立性也允许开发者采用各种不同的技术栈和工具进行服务开发，使得技术选择更加灵活多样。

• 更好的灵活性：微服务架构支持团队对服务进行独立的开发与部署，这使得系统更加灵活。此外，由于每个服务都是独立的，因此可以更容易地添加新功能或修改现有功能。

• 更好的扩展性：微服务架构支持将应用程序划分为多个独立的服务，每个服务都能进行独立的部署和扩展。这种架构方式增强了系统的可扩展性，便于根据业务需求动态地添加或删除服务。

• 更好的可靠性：微服务架构提供了将应用程序分割为多个单独服务的能力，这些服务都可以独立部署和运行。这种架构方式进一步提升了系统的健壮性，能更有效地应对故障和错误处理。

• 更高的维护性：微服务架构将应用程序划分为众多独立的服务，每个服务都拥有自己的代码库和专属团队。这样的划分方式使得代码更具模块性，从而更便于进行维护和更新。

当然微服务也具体一定的缺点，如下：

• 分布式系统的复杂性：微服务架构由于涉及到多个服务的协同工作，因此增加了系统的复杂度。在这种架构中，必须对服务间的性能、通讯、数据一致性以及故障定位、恢复等问题进行深入考虑。

• 部署和运维的复杂性：在微服务架构中，由于涉及到多个服务的部署，因此部署的复杂性得到了提高，其中需要深入考虑服务间的依赖关系和版本控制等问题。同时，微服务架构也增加了运维的复杂性，因为需要部署和管理多个服务，这就需要我们关注服务的监控、故障恢复以及容量规划等问题。

• 测试的复杂性：在微服务架构中，服务数量众多，每个服务都是独立的业务单元，服务主要通过接口进行交互，如何保证依赖的正常，是测试面临的主要挑战。

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：691998057【暗号：csdn999】

测试分析

我们通过前面说的单体应用、微服务可以知道，现在大部分公司都是微服务化，我们看下下面一个图。

上述的服务之间的关系看起来比较简单，但是也是互相之间调用、依赖，但是实际的公司应用情况更加复杂，微服务数量少则几十上百个，多的上千个，它们之间的关系像蜘蛛网一样复杂。

如上图所示，当我们在测试微服务A 的功能时，微服务 B 、 E 经常不稳定，第三方服务也是一样非常不稳定，这个时候非常影响我们测试的进度、效率。这导致了尽管待测系统已经开发完毕，测试脚本、测试用例也准备充分，但测试工作却无法进行，这是一个令人沮丧的结果。面对这种情况，我们感到非常不适，因为尽管我付出了大量努力，但工作进度却因一个不是我们负责的服务而受阻。这种感觉就好像是全力出击，却只是打在了棉花上，无论自己有多大的力量也无法施展。

在团队有一定规模的公司里面，日常工作中大家应该碰见到前后端项目、跨团队项目、和第三方公司合作的测试任务。下面情况很常见：

• 前端进入开发了，后端还在开发中，无法进行联调

• 跨团队项目，存在一些关联团队的功能开发进度拖慢

• 第三方合作项目，内部基本上开发完成，第三方公司的一直没完成

• 自动化用例运行总是出现部分失败，由于其他服务不稳定

那作为QA工程师，面对这样的情形，我们该怎么办呢？ 难道一直等着吗？有什么办法解决么？

我们能否这样做的，我的被测服务就是服务 A，那么我不用管其他服务是不是好用，我只要保障服务 A 能够走完流程，就可以完成服务A测试任务了。这个思路，我们只需要找一个工具模拟其他服务的工作就好了了，也不用再关心其他服务到底调用了多少服务。

Mock 应用

我们知道我们需要模拟其他服务的处理，不同的是，它不需要实现原有服务的处理逻辑，只要能按服务的处理逻辑给出对应返回就可以了，就是目前我们常说的 Mock 服务、挡板服务/系统。

那么，到底应该怎么选择 Mock 服务呢？

我们要基于自己和团队的技术栈来做选择，这决定了你进行模拟服务的效率。你要知道，无论Mock服务做得多么完美，它只是一个 Mock，它存在的意义就是帮助你快速完成被测服务的测试工作，因此，选择一个学习成本低、上手快并且完全适合你自己技术栈的 Mock 框架，能让你的测试工作事半功倍。我们主要需要下面几个参考点：

• 使用简单、容易上手

• 处理速度快

• 非常轻量级

• 投入成本低

选择 Mock 技术栈与选择测试框架的技术栈有所区别。在挑选 Mock 技术栈时，你需要重点考虑学习成本，并努力将其降至最低，这是选择 Mock 框架的首要因素。此外，你需要关注的不仅是自己的学习成本，也要考虑团队的学习成本，因为现在每个项目可能都需要 Mock 服务。这就要求每个项目的测试工程师都有能力独立构建 Mock 服务。在 Mock 服务的技术选型上，应以团队的整体技术栈为基础，并参考自己的技术进行选型。

下面是配套资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！

最后： 可以在公众号：自动化测试老司机！ 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！