项目源地址：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

近些年可以看出测试开发工程师是热度比较高的测试职位，除了涵盖了之前自动化测试工程师的职能外，测开同学的开发能力进一步提升，可以做到开发一些测试平台和测试框架的工作，并在推广自动化测试方面也有一定的 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 的执行用例执行工具，原理大致是在用例执行的时候动态去 k8s 上创建容器，执行任务，上报指标，最后销毁容器，不过这些过程基本上与测试过程耦合在一起，难以平移扩展。最近发现了一款在开发早期的通用型的基于 k8s 的用例执行工具: TestKub。

有用的链接

• 项目主页：TestKube (kubeshop.github.io)
• 代码库：GitHub - kubeshop/testkube: Kubernetes-native framework for test definition and execution

特性

• 支持执行 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 等质量度量和流程管理类的角色，其核心竞争力与刷题无关，不刷是完全没问题的。

理解业务

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

成为问题解决者

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

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

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

别害怕提问或表达疑虑。

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

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

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

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

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

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

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

前几天看到一篇 blog 讨论现代测试行业中存在的一些问题，我愿称之为测试行业的劝学篇。有些观点还是非常中肯的，翻译了一下，希望对大家有所帮助，下面是正文。

在这篇博文中，我想强调我在测试行业看到的问题，以及我们都可以如何解决它。(你可能有不同的经历–所以让我们在评论中分享吧！）。这是我在 2022 年初在阿布扎比 MoT 会议上发表的演讲的文字版。

10 年来行业发生了什么变化

在过去的十年里，我们见证了技术的大幅提升–无人驾驶汽车、人工智能、AR / VR、区块链、无人机和机器人。许多测试和测试自动化从桌面转移到网络和移动设备上。

从瀑布模型，许多企业走向了敏捷和 Scrum。

从编写自动化测试的大型和昂贵的工具，我们已经转移到小型，灵活，最重要的是 - 免费的库和工具。现在我们有智能报告系统和 Docker 容器中的测试。现在在云端并行运行成千上万的测试用例并其实不那么昂贵。

但与此同时，许多事情和声明仍然没有改变。

以下是一些在测试人员中不断肆虐的无尽话题

“手工测试已死！” “让我们把一切都自动化吧! 通过 UI–这才是最好的！”*。 “SDET 是测试工程师进化的高峰! 我想成为像谷歌一样的人！” “我在开发领域找不到工作，所以我将做一年左右的测试，然后再尝试转行。” “测试人员的工资都在底部！” “测试工程是一份低技能专业人士的工作！”

但为什么行业中会出现这样的情况？问题会不会是别的原因呢？我看到了哪些问题？

现代测试的问题

我将把问题分为两个大组。

对技术的追求

• **寻找银弹。**一些工程师为一个项目（和一个背景）创建了一个成功的框架，然后开始把它拉到所有其他的项目中作为一个 “完美的解决方案”。这不是可重用性，它只是将一把锤子怼所有的钉子和螺栓。
• **面向框架的自动化。**在一些项目中，工程师们急于编写完美的框架，而忘记了测试本身。结果是，我们有 3-6 个月的开发时间没有测试！。但是对于客户来说，没有测试是自动化应用不充分的的直接指标。
• **专注于流水线通过的崇拜者。**在这种情况下，已经成功地将测试纳入 CICD 管道的测试工程师开始迷恋于使测试一直保持绿色。这种痴迷往往导致忽略甚至删除不稳定的测试（这导致忽略了被忽略的测试背后的问题）。
• **简历驱动的开发。**许多测试人员只考虑工作和项目，作为在简历中获得一个花哨的新行的方式。没有任何关于深化技能和用测试和自动化解决业务问题的内容。
• **只专注于短期目标。**许多工程师只喜欢快速的解决方案。这种对自动化测试的态度是很普遍的。工程师们很快就写出了 “东西”，而没有考虑到可维护性，就跑去做新项目了。

技能和知识水平不足

知识的缺乏可以有多种形式。

技术知识

在面试中，资深候选人往往能迅速回答任何关于测试的问题。他们可以为你画一个 “测试金字塔或任何你想要的数字”，告诉你世界上所有的测试设计技术，并写出完美的测试报告。但是，当你问及基本技术方面的问题（如 HTTP 或网络如何工作），候选人很快就会失去信心。

你可以告诉我，不是每个项目都需要特定的知识。这倒是真的。但测试工程师应该知道（或至少知道）基本的技术知识。理想情况下，比谷歌搜索中的第一个链接更深入一点。

90%的现代系统以这种或那种方式与网络一起工作，发送消息或请求，并使用数据库或分布式存储。多层的抽象可以覆盖它–但总的来说–它的工作原理都是类似的。

编程和架构

一些测试工程师仍然认为，学习编程是复杂和不必要的。让程序员来写代码吧!

另一部分是那些已经学会了一点代码，但只集中精力于 UI 测试的人。这些测试之外的世界似乎并不存在。

在测试工程师中，关于系统结构和它们如何工作的知识是一种稀缺的技能。所有这些都被认为是有经验的 “大胡子 “架构师的工作，或者只有有十几年经验的高级开发人员才能做。

但是，如果不知道系统的内部和相互之间是如何工作的，就很容易错过很多关键的错误。另一方面，缺乏技术知识将使我们很难在测试报告中描述这些问题。

我并不是说，如果不了解系统的组成部分，就不可能指出系统糟糕的不可测试性。结果是，我们继续编写脆弱的 XPath 定位器，因为没有人给元素添加 ID。