只做网站的,番禺网站制作多少钱,重庆制作网站公司简介,酒店网站解决方案再聊这个问题之前#xff0c;我们先了解一下公司技术架构的演变过程#xff0c;这样我们才能真正体会到我们为什么要使用 Mock功能。
单体应用
在早期#xff0c; 大部分公司的应用技术栈主要可以分为两大类#xff1a;LAMP#xff08;Linux Apache MySQL PHP#x…
再聊这个问题之前我们先了解一下公司技术架构的演变过程这样我们才能真正体会到我们为什么要使用 Mock功能。
单体应用
在早期 大部分公司的应用技术栈主要可以分为两大类LAMPLinux Apache MySQL PHP和 MVCSpring 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自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
如果我的博客对你有帮助、如果你喜欢我的博客内容请 “点赞” “评论” “收藏” 一键三连哦
