专注测试技术的课程订阅站点

逃离微服务?为什么现在大家又在讨论微服务

最近比较热门的圈内话题,出了下云就是对微服务的讨论。

微服务今年又一次的引起了广泛讨论可能是源自今年年初亚马逊内部的一次架构迁移。

起因

在这个案例中,Prime Video 团队将一个监控系统从微服务架构迁移到单体架构,并避免使用昂贵的服务(如 AWS Step Functions 和 Lambda 无服务器函数),并对此举所带来的降本效果进行了评估。简单来说就是该团队通过将服务从微服务变成单体应用取得了明显的降本增效的效果。

这个例子引发了广泛的关注和讨论,一时间人们似乎不知道该如何去评价这件事情。反倒是一直鼓吹下云和反对微服务化的 dhh(可以理解为著名网络喷子)一针见血,他指出:即使是亚马逊也无法理解无服务器或微服务

讨论

事件逐渐发酵,目前关于逃离微服务的讨论可以频繁的见诸报端,比如前几天有人就这样的评价微服务

“microservices conflate logical boundaries (how code is written) with physical boundaries (how code is deployed).” “we propose a different programming methodology” “Our implementation reduces application latency by up to 15x and cost by up to 9x”

  • “微服务将逻辑边界(代码编写方式)与物理边界(代码部署方式)混为一谈。”
  • “我们提出了一种不同的编程方法论。”
  • “我们的实现可以将应用程序的延迟降低多达 15 倍,成本降低多达 9 倍。”

这里有一个非常有意思的点,那就是有没有一种可能单体服务比微服务其实要节省资源?

还有人认为微服务其实是一种权衡,并给出了下列的忠告。

  1. 谨慎地拥抱复杂性 投身于微服务不仅仅是一个技术决策,而是对复杂性的一种承诺。有时候,为了追随潮流,我们似乎在破坏一个系统。并非每个应用程序都需要一个相互连接的服务网络。正如 Sam Newman 在《构建微服务》一书中提到的那样,架构需要满足一定的前提条件,否则就可能过度设计。

  2. 灵活性是有代价的 是的,微服务承诺了灵活性,但也伴随着沉重的代价,不仅仅是基础设施方面的代价,还包括认知负荷。每个服务都变成了自己的领域,需要专门的关注。

  3. 没有一种大小适合所有 如果我从中获得了什么,那就是架构决策不能孤立地脱离业务需求而做出。一个灵活的初创公司的需求与传统的企业应用程序截然不同。虽然像 Netflix 那样的案例研究对我们启发很大,但我们必须认识到,适用于某个公司的解决方案未必适用于所有公司。

推荐:Docker备忘录

项目源地址:https://github.com/wsargent/docker-cheat-sheet

docker 的安装

略,windows 上可以用 docker desktop,具体可以参考官方文档。https://hub.docker.com/editions/community/docker-ce-desktop-windows

安装之后用 admin 身份打开 powershell,输入

#Display the version of docker installed:
docker version

##Pull, create, and run 'hello-world' all in one command:
docker run hello-world

容器相关

容器的生命周期

  • [docker create](https://docs.docker.com/engine/reference/commandline/create)  创建但未启动
  • [docker rename](https://docs.docker.com/engine/reference/commandline/rename/)  重命名容器
  • [docker run](https://docs.docker.com/engine/reference/commandline/run)  一个命令创建并启动容器
  • [docker rm](https://docs.docker.com/engine/reference/commandline/rm)  删除容器
  • [docker update](https://docs.docker.com/engine/reference/commandline/update/)  更新容器的资源限制

几个有用的点

  • 一般启动容器我们用 docker run -td container_id, -t 表示分配 TTY session,-d 表示后台运行并打印容器 id
  • docker run –rm 用来运行容器后自动删除
  • docker run -v $HOSTDIR:$DOCKERDIR 用来做 volume 的映射

容器的启动和停止

  • [docker start](https://docs.docker.com/engine/reference/commandline/start)  运行容器
  • [docker stop](https://docs.docker.com/engine/reference/commandline/stop)  停止一个运行中的容器
  • [docker restart](https://docs.docker.com/engine/reference/commandline/restart)  重启容器
  • [docker pause](https://docs.docker.com/engine/reference/commandline/pause/)  暂停容器
  • [docker unpause](https://docs.docker.com/engine/reference/commandline/unpause/)  继续运行一个暂停了的容器
  • [docker wait](https://docs.docker.com/engine/reference/commandline/wait)  等待直到容器停止
  • [docker kill](https://docs.docker.com/engine/reference/commandline/kill)  发送 SIGKILL 信号给容器
  • [docker attach](https://docs.docker.com/engine/reference/commandline/attach)  连接运行中的容器

限制 cpu 和内存

docker run -it -c 512 agileek/cpuset-test

上面的命令限制了 cpu 使用率为 50%,看起来很奇怪对不对?因为 100%使用率用的参数是-c 1024,所以 50%就是 512

给测试开发工程师的5条建议

近些年可以看出测试开发工程师是热度比较高的测试职位,除了涵盖了之前自动化测试工程师的职能外,测开同学的开发能力进一步提升,可以做到开发一些测试平台和测试框架的工作,并在推广自动化测试方面也有一定的 kpi 要求,能力越大责任越大,正好看到了国外有同行写的给自动化测试工程师的几条建议,觉得还是有一定道理的,所以在这里简单的分享一下,希望对大家所有裨益。

质量心态

作为测试开发工程师,我们可能专注于学习测试工具和测试框架,提升代码能力,日复一日,循环往复。学习是没问题的,不管你是测试开发还是功能测试同学,持续学习应该是整个职业生涯里必不可少的一部分。话虽如此,不过对于测试同学来说,全方位的质量心态还是很有必要的。

那么质量心态是什么呢?作为测试开发同学,我们应该关注项目/产品质量的方方面面,而不是仅仅满足于将验收标准或者是手工用例转化成自动化脚本。

相反,我们应该站在质量控制的层面去从用户的角度带入思考,如果我们的脚本不能为用户带来价值,那么这些脚本其实就没有价值。

举一个例子,我们在提交一个表单的时候,比如注册用户以后,我们的 ui 自动化用例是不是需要去查数据库,看看新的用户记录已经被持久化到了用户表里?我的答案是:在开发时间有限的前提下不需要去连数据库查询,因为用户是不会连数据库直接看数据的,我们应该从用户可以感知到的方面进行断言。连数据库查询的事情可以交给其他类型的自动化用例,比如单元测试用例去实现。

获取其他测试领域的知识

相比于成为某种工具或者编程语言的专家,测试开发工程师可能更有必要成为一名通才,我们最核心的观念应该是帮助团队满足用户的需求和期望。

因此除了功能测试和自动化测试之外,我们是需要学习其他领域的知识,比如性能测试,可用性测试,可测试性,安全测试,移动端测试,可视化测试和数据测试。

技术已经发展了很多年,我们几乎每天都有许多领域和新技能需要学习。让我们探索一些可以帮助你提升自动化工程师职业生涯的领域:

探索性测试

老生常谈的话题了,探索性测试可以叫做老司机测试,但探索性测试并不是随心所以,而是需要精心计划和设计一些测试用例。我们可以通过探索性测试来开阔用例设计的思路,从而改进我们的 e2e(也就是 ui)测试用例。《Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing》阅读这本书可能是一个不错的开始,不过我好像并没找到中文版本,有点可惜了。

数据测试

机器学习和人工智能每天都在使用数据,但数据的有效性还是要验证的。我的建议是开始学习数据模型的性能,这有助于我们弄清楚一些 ML 预测错误的具体场景。

可视化测试

其实就是 ui 测试了,ui 是产品和用户打交道的最终途径,很多情况下也是唯一途径,生产环境中的视觉错误会危及我们的声誉并影响我们的品牌,所以 ui 的测试是非常必要的,也是需要我们去花精力学习的。

可访问性测试

正如您可能知道的那样,许多国家/地区的法律法规要求让每个人都可以访问应用程序,并且创建一种必须适合所有人的软件应用程序文化。比如产品对盲人用户的可访问性就是一个很好的例子。我们可以从https://www.w3.org/WAI/WCAG21/quickref/开始进行学习。

安全测试

就法律处罚和品牌声誉而言,安全漏洞往往代价高昂。我们应该在 CI 的 pipeline 中增加安全扫描的环境。我的建议是开始阅读OWASP和学习一些安全测试工具。

混沌测试

混沌测试/混沌工程测试是在影响客户之前发现漏洞和进行中断。简而言之,我们希望系统是可以在受控的环境中进行错误恢复的。如果你想学习混沌测试,那么《Chaos Engineering: System Resiliency in Practice》这本书将是一个不错的开始。

获得正确的帮助

获得他人的支持可以加速学习周期并显着改善您的职业生涯。但是,首先得找一个你信任的导师,他已经掌握了你想学习的技能,这些技能可以是技术技能或软技能。

我的建议是你问问自己:“我公司或我的人脉网中谁会注意到我的变化并为我提供诚实的反馈?”  有时候找导师可能很困难,我们希望有最好的老师来指导我们。如果你在你的社交网络中找不到导师,你可以要求你的上级提供高质量的指导。

“如果你想快点走,就一个人走。想走远一点,就一起走”

自动化不仅仅是执行测试脚本

这个很好理解,自动化的目的是什么?大家可能有自己的答案,但答案一定不会是执行用例并使其通过。

其实我总结自动化的目标是帮助团队从质量和效率的维度满足用户的预期。

质量很好理解,我们不希望用户用到全是 bug 的产品;效率也不难想象,我们希望用户可以尽快的用到产品。

分享也是学习的一种途径

正如你可能知道的那样,教导他人可以提高你自己的学习能力。记得之前看到过一个学习的方法就是先自己学一遍,然后把自己学到的东西讲给别人去听,如果别人能弄明白,那么你自己就学会了。

基于k8s的测试执行工具:TestKube

之前我们自己开发过一些基于 k8s 的执行用例执行工具,原理大致是在用例执行的时候动态去 k8s 上创建容器,执行任务,上报指标,最后销毁容器,不过这些过程基本上与测试过程耦合在一起,难以平移扩展。最近发现了一款在开发早期的通用型的基于 k8s 的用例执行工具: TestKub。

有用的链接

特性

  • 支持执行 postman collection
  • 支持执行 cypress 的 ui 测试用例
  • 支持执行基于 curl 的简单探活,比如站点,接口有没有挂的检测之类

工具希望解决的实际问题

  • 避免 vender 锁定 CI/CD 管道中的测试编排和执行
  • 在集群中轻松编排和运行任何类型的测试 - 功能、负载/性能、安全性、合规性等 - 无需将它们打包成在 docker-images 或提供网络访问
  • 使测试执行与构建过程分离成为可能; 工程师应该能够在需要时运行特定的测试
  • 以一致的格式集中所有测试结果,以实现“可操作的 QA 分析”
  • 提供模块化架构以添加新类型的测试脚本和执行器

简单来说就是提供了与 ci/cd 解耦的纯测试容器编排和执行能力,并提供了统一的报告输出。

主要模块

  • kubectl 插件
  • API Server - 调度器,执行器,收集执行结果
  • CRDs Operator - 观看 TestKube CR,处理与 API Server 通信的更改
  • Executors - 运行为特定运行程序定义的测试,目前可用于 Postman、Cypress 和 Curl
  • 结果数据库 - 用于集中测试结果管理
  • 一个简单的基于浏览器的看板,用于监控测试结果

总结

这里就不列举如何安装以及简单使用该工具进行用例执行了,目前 TestKube 的版本是 0.6,还处在早起的开发阶段,不过项目的文档较为全面,而且模块化良好,有一定的扩展性,所以后面可能吸引一些使用者,有强烈需求的同学可以直接拿来就用,拿不定主意的同学建议再观察一定时间,等到 1.0 版本再入坑。

测试同学找工作要不要刷题

最近有公司裁员火到上了热搜,今年就业形式不容乐观,相信有不少同学正在努力找工作中,另外可能有一些同学被裁员的阴影所笼罩,也许在默默的为下一份工作而努力。看到一些开发同学正在刷题刷的飞起,而与之对应的是工作机会的减少,简历字面要求的提高,以及面试周期的增加,据说现在面试题难出了天际,其实也是一种变相提高门槛的表现,那么这个时间点测试同学在面试之前是否需要刷题呢?

答应是不一定,具体情况可以具体对待。

初级测试同学

一些公司对初级测试的同学的要求不是特别高,人聪明能干活就行,所以可能不需要频繁刷题,但一些简单的编程能力还是要有,防止被一些不太复杂的代码题被动过滤,如果时间不是很充裕的话,优先级是了解测试流程,测试方法,测试工具,各种测试种类(功能性能接口等),最后才是简单的算法和数据结构题。

中高级测试同学

其实中高级在技术上的要求差不多,所以放到一起讲,技术的广度上中高级的区别不大,不过深度上高级同学可能需要有一个强点可以侧重,能讲出东西来,让人信服。这两个职级都强烈建议刷题,不过优先刷简单的题先,中等难度的适当刷一点点,有些实在是看不明白的放弃也不可惜,高难度的题的就不用刷了,如果在面试中遇到的话,那这个职位可能是为某些人高度定制化的,或者根本就没有诚心招人,做不出来也不要紧。至于算法,可以了解比较简单的排序递归等,高级一点的贪心算法和动态规划可以适当的看看,大概知道概念,做不出来也问题不大。数据结构的话推荐优先了解二叉树及各种变种,更复杂的数据结构不看也可以。

管理岗位

管理岗位的话一般来说不用刷题,因为管理者可能很多年都没写过代码了,实在是霸王硬上弓的话可能会让场面一度显得比较尴尬。不过不写不意味着就可以不知道,数据结构和算法应该有所了解,比如 merge sort 写不出来具体的实现,但是其过程和原理应该是可以表述清楚的。算法的话可以了解一些简单的,数据结构也是从二叉树开始,结束在你没有时间去了解的地方。

测试开发

岗位相对较少,所以可能会更卷一些。建议初中级难度的全部刷完,高级难度如果能熟练掌握的话就转开发吧,大部分的开发没有花时间准备的话中高级题都很难写出来,简单题翻车也不是没有可能。

其他测试相关岗位

比如 pmo,qa 等质量度量和流程管理类的角色,其核心竞争力与刷题无关,不刷是完全没问题的。

给测试人员的7条建议

理解业务

要深入理解业务领域和用户需求。这将有助于设计更好的测试场景,确保软件满足用户的需求。

成为问题解决者

在开始自动化测试之前,要充分理解问题,思考如何解决它。作为一名 SDET,您的工作不仅仅是将功能测试用例自动化,我们的工作是使测试过程更加高效,消除减慢过程并不必要消耗时间的瓶颈。

保持开放的心态并愿意学习新事物

对测试人员来说,保持开放的心态和愿意学习新事物是至关重要的,因为软件测试领域不断发展。新技术,方法和工具不断涌现,测试人员需要随时了解这些发展,才能在其角色中保持效率。 开放的心态意味着接受新想法,新观点和新方法。测试人员应该对学习新测试技术,探索新工具和采用新方法持开放态度。他们也应该愿意尝试新方法和技术,看什么对他们和他们的团队最有效。 开明也意味着愿意质疑假设和先入为主的看法。测试人员不应该假定某种方法或工具始终是最佳选择。相反,他们应该愿意评估不同的选择,选择最适合情况的选择。 此外,开明意味着愿意接受反馈和批评。测试人员应该愿意接受同事和利益相关者的反馈,并用它来改进工作。他们也应该对测试方法持开放态度,如果需要的话,愿意作出改变。 总之,对测试人员来说,开明和愿意学习新事物对于在不断发展的领域保持相关性和效率至关重要。它使他们能够适应新挑战,保持创新,不断提高技能和知识

别害怕提问或表达疑虑。

在软件测试中,提问和表达疑虑是工作的重要组成部分。测试人员负责识别软件中的缺陷和问题,他们常常需要寻求澄清或就需求,设计或功能提出疑虑。 提问是一种收集信息和澄清需求的方式。测试人员应该提出一些问题,以确保他们理解软件的预期行为,并发现需求中的任何歧义或缺口。这可以帮助确保软件能够满足用户和企业的需求。 表达疑虑对测试人员也很重要。如果测试人员发现软件中的潜在问题,他们应该向相关的利益相关者提出。这可能包括开发团队,项目经理或业务相关人员。及早表达疑虑可以帮助避免更大的问题。 测试人员不害怕提问或表达疑虑是非常重要的。测试人员应该感到自在地寻求澄清,质疑假设和识别潜在问题。这样做可以帮助确保软件满足用户和企业的需求,并按时在预算范围内交付。 总之,提问和表达疑虑是软件测试的关键部分。它有助于确保软件达到必要的标准,并根据用户和企业的需求进行开发。测试人员应该有权提出澄清和表达疑虑,以确保软件质量高。

始终测试可用性——这和功能测试同样重要。

可用性测试是软件测试的关键部分,它和功能测试同样重要。可用性测试是评估产品的用户界面(UI)和用户体验(UX)的过程,以确保它对用户友好,高效和有效。 可用性测试的目的是识别任何可能阻止用户有效使用软件的可用性问题。这些问题可能包括混乱或杂乱的 UI,响应时间慢,缺乏反馈或难以理解的错误信息。 可用性测试涉及观察用户与软件的交互,并要求他们执行特定任务。测试人员将寻找任何用户难以掌握或出错的地方,并收集有关软件可用性的反馈。 可用性测试至关重要,因为即使产品具有所有必要的功能,如果使用不便,用户很可能会感到沮丧和抛弃它。这可能导致收入损失,负面评论和对公司声誉的损害。 因此,可用性测试应该从一开始就集成到软件测试过程中。它应该与功能测试一起考虑,以确保软件满足用户需求并提供积极的用户体验。 总之,可用性测试与功能测试同样重要。测试人员应该通过测试 UI 和 UX 来确保软件对用户友好,高效和有效。这样做可以帮助确保软件满足用户需求并提供积极的用户体验。

记录下每一件事情——这将有助于你和你的团队在将来。

🤓记录是软件测试的重要部分。它涉及创建和维护有关所有测试活动的记录,包括测试计划、测试案例、测试结果和缺陷。在测试过程中记录每一件事情至关重要,因为它将帮助测试人员和他们的团队在未来。 记录可以帮助测试人员跟踪他们的进度,找出潜在的问题和缺陷,并在整个测试过程中跟踪缺陷。通过记录每一件事情,测试人员可以轻松参考以前的测试活动,确保他们正在测试软件的正确区域。 记录每一件事情也有助于测试人员和他们的团队在未来。当新成员加入项目或软件需要更新或修改时,有记录可以帮助确保团队清楚了解已经测试了什么和还需要测试什么。 此外,记录有助于知识转移。当测试人员离开团队或项目时,他们创建的记录可以被替代者用于快速了解已经测试了什么和还需要测试什么。 而且,记录有助于通过提供缺陷及其解决方案的记录来提高软件质量。此信息可用于识别缺陷的模式或趋势,从而改进软件开发过程。 总之,在软件测试中记录每一件事情至关重要。它可以帮助测试人员跟踪进度,找出潜在的问题和跟踪缺陷。它也可以帮助团队在将来确保新成员了解已经测试了什么和还需要测试什么。最后,记录可以通过提供有价值的缺陷和解决方案信息来改进软件质量。

制定测试计划并坚持执行。

制定测试计划是软件测试的基本步骤,它涉及定义测试目标、范围、方法和时间表。一个明确定义的测试计划为测试过程提供了清晰的路线图,并帮助测试人员专注于测试目标。 测试计划应概述测试目标和优先级以及要执行的具体测试任务。该计划还应确定测试环境、测试工具和技术以及预期结果。 通过制定测试计划,测试人员可以确保执行所有必要的测试任务,并且不遗漏任何关键区域。该计划也可以帮助测试人员更有效和高效地管理时间和资源。 然而,仅制定测试计划是不够的;坚持执行它同样重要。偏离测试计划可能导致测试不完整、错过缺陷和测试过程延迟。因此,测试人员应尽可能密切地遵循测试计划,仅在必要时和经过仔细考虑后进行调整。 坚持测试计划需要纪律、专注和注重细节。它涉及监控进度、识别与计划的任何偏差并在必要时采取纠正措施。 总之,制定测试计划对测试过程的成功至关重要。它为测试提供了路线图,并帮助测试人员专注于目标。但是,坚持计划同样重要,以确保测试所有关键区域,并有效和高效地完成测试过程。