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

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

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

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

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

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

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

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

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

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

现代测试的问题

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

对技术的追求

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

技能和知识水平不足

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

技术知识

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

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

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

编程和架构

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

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

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

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

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

看到了一篇不错的关于单元测试的文章，于是就机翻加改写了一下。作者的观点是适当的，不过稍微欠缺了些数据。原文地址：https://betterprogramming.pub/why-dont-we-do-unit-testing-e0bb55a38aa2

我开始打算写一篇关于单元测试及其背后的哲学和过程的文章。 我想谈谈完成对项目的一组更改并能够部署它们所带来的满足感，因为数百个单元测试正在通过，并且在生产中出现问题的可能性很小。 然后我意识到我参与过的大多数项目（在计算行业的长期职业生涯中）都没有使用任何类型的单元测试。 因此，我认为检查未使用单元测试的各种原因以及对这些项目的影响可能会有所帮助。

没有测试工具

当我在 80 年代开始以编程为生时，这是一个很好的借口。在 pascal 中编写航空电子代码，我们确实编写了测试，但几乎不得不推出我们自己的测试框架。这里没有 fakes、mocks 或 DI。 但是，如果您今天使用 Visual Studio 在 .Net/C# 中编写代码，则没有理由不测试任何重要代码。 VS Code 有一个内置的测试运行器，其他测试运行器也可用。fake 和 mock 框架被广泛使用，另外还有非常优秀的 CI/CD 支持，可以让你在构建过程中自动化的运行单元测试。

后面作者又列举了一些例子来证明一个观点：就是测试工具实际上是持续进化的，而且现在已经很强大了，因此他的核心观点应该是在如今这个年代，单元测试工具其实不应该是匮乏的，大家应该有不少的选择。

我们没有时间做测试

客户希望我们现在发货。写一些代码就行了。先搞出来吧，没有时间学习有关单元测试的象牙塔软件工程学士学位！ 你多久听说过一次？ 这种方法通常似乎在最初几周有效。然后，当您陷入莫名其妙的错误和副作用的泥潭时，生产力就会下降。加倍努力，开夜车，让更多的人进行手动测试！ 不必如此。我会说你没有时间不做测试。

看看上面的图表。橙色线显示“没有做单元测试”项目。 起初，我们可以通过不进行任何测试来节省时间。 随着越来越多的功能被实现，（手动）回归测试的负担呈指数级增长。添加的每个新功能都会带来额外的回归测试负担。 很快，您的项目将不得不在质量、成本和实现每个新功能所需的时间之间做出妥协。 所以是的，最初编写一个好的单元测试可能比手工测试你的功能要长两到三倍。但是经过两三个循环的回归测试，你就会领先——而且只会变得更好。

我们发现写单元测试好难

编写测试很难，这是绝对正确的。 编写好的测试更难。但不写测试会让你的生活更加艰难（或者你真的喜欢手动测试你的前任 5 年前写的代码？？？） 如果您的开发人员不知道如何编写好的测试，那么他们可能还不是好的开发人员（目前）。 但是他们可以学习。 写测试用例是一个不断进度熟能生巧的过程， 你做的越多，它就会变得越快越容易。 让最好的开发人员编写“模范”测试。 这些可以被经验不足的开发人员用作模板来创建他们自己的测试。 创建测试基类。 我经常这样做是为了封装经常重用的功能并简化单个测试用例。

单元测试是白费力气！

当我花时间编写单元测试时，我从不认为这是浪费时间。 如果我编写代码并手动测试它，我认为这是浪费精力。 在一系列手动测试结束时我会得到什么？ 代码在我做手动测试时候是没问题可以正常工作的，但如果我更改代码，我将不得不重复这些测试（或者更有可能不打扰……） 如果我创建了自动化测试，那么我就有了一个测试套件，我可以随时重新运行这些测试，以验证代码是否仍然按照我编写时预期的方式工作。 更重要的是，如果我离开并且一位同事接管了这段代码，他们就会继承这个祖传的测试套件，他们可以使用这些测试来验证他们的更改没有破坏它，并且代码仍然以我预期的方式工作。 手动测试是浪费精力——手动测试的剩余价值为零（并且通常没有记录，因此不可重复）。 自动化测试可以在未来几年内使用，以证明您的软件仍然按预期工作。

**Mindset Shifts For Engineers to Achieve Higher Software Quality**

看到个开发小哥写的关于测试的文章，挺有意思的，翻译了一下，观点虽不新颖，但能从开发角度去思考软件质量，格局上面是值得称赞的。原文地址：https://medium.com/@phdmeyildiz/mindset-shifts-for-engineers-to-achieve-higher-software-quality-8ef8ee00a041

作为一个刚从大学毕业的初级工程师，没有什么是比掌握越来越多的工具、编程语言等更重要的事情了。当你刚进入工程领域时，你想捣鼓点新东西，然后你想看这些玩意可以正常工作。这是职业生涯早期最大的动力来源。我也是这样做的，并把大部分时间花在这上面。我一直不太理解我的前辈们，他们更关注工作方式，而不是下一个很酷的技术。现在，经过 12 年的时间，我不仅理解了他们，而且在这里，我写下了我的第一篇文章，讲述了一个简单的思维方式的转变对你的项目的影响会比几十种编程语言大。

这篇文章是关于转变我们作为软件工程师的心态，在交付产品时获得高的视角，最终让客户的满意提升。下面的思维转变说明没有详细解释，只是用简短的句子写出来，我们可以做更深层次的思考。

让我们来谈谈我们需要改变的思维模式。👍 表示目标思维模式，👎 表示我们需要远离的思路。

哪种工作方式？

持续交付 👍

• 软件总是处于可发布的状态。
• 我们可以随时进行发布。
• QA 尽早介入开发流程。
• 尽早测试以避免 bug 的产生，并分析产品的质量。

瀑布式的敏捷 👎

• 软件需要经过完善流程才能到可发布的状态。
• 我们需要等到发布那的那个星期才能来进行发布。
• QA 等到发布之前才能检查软件质量。
• 测试置后旨在发现已经开发的功能中的错误。

什么时候测试？

从一开始就进行测试 👍

• 从一开始就进行测试，以增加最终结果的可预测性。
• 在开发过程中做探索性测试。
• 开发和测试同时结束。

最后测试 👎

• 以部署前的例行测试作为开发流程的结束。
• 在开发过程中可能已经引入了错误，我们的作用是找到它们。
• 首先开发，最后测试。

谁为质量负责？

每个人都要对质量负责 👍

• 把质量放在前面和中心，而不是放在 pipeline 的末端。整个团队都要关注质量。
• bug 的检测是在开发过程中同步进行的，不存在 QA 资源是瓶颈的说法!
• 更少的资源可以做得更多。

只有 QA 团队对质量负责 👎

• 把质量作为最后一道防线。
• QA 成为瓶颈的可能性很大。
• 需要越来越多的资源来战胜质量问题。

何时交付？

更快、更小的交付 👍

• 尽量高频率的交付少量的代码
• 高质量来自于小的、快速的、明确的工作步骤，我们可以在创造变化的过程中进行监控。

岁月静好，我憋大招 👎

• 一次性交付大量的代码。
• 当软件很复杂的时候，要验证其质量是比较困难的。

质量保证（QA）还是质量控制？

QA 高于质量控制 👍

• 主要关注点是高效的工作方式和建立团队间的和谐。
• 在从事任何工作时，都要考虑到质量问题。
• 不断的反馈机制来改善 SDLC（软件开发生命周期）的 pipeline。

只有质量控制 👎

• 主要关注的是检查最终结果。
• 当出现问题时，质量成为关注点。
• 在最后的测试中收到反馈。

什么是 QA？

QA 是指质量协助 👍Q

• QA 团队从开发的开始到结束都处于顾问的位置。
• 重点是放在质量上，而不是寻找错误。
• 错误更容易修复，也更便宜。
• QA 不应该发现 bug。当发现一个 bug 时，它不仅应该被修复，而且应该调查其根本原因。
• 错误意味着 SDLC 过程中存在问题，这个过程需要被修正。

QA 意味着发布守门员 👎

• QA 团队是一个测试者和 bug 寻找者。
• 没有改善质量的空间。
• 修复问题的成本和风险都比较大。
• QA 应该找到 bug，然后 bug 应该被修复而不需要进一步挖掘其根本原因。
• 错误只是一个软件问题。

观点

你对上面的一些思路转变有什么样的看法呢？

首先这个标题不是我取的，是我喂了关键字让 AI 给取的，果然非常的标题党，让人印象深刻。

先简单回顾一下 web 自动化测试的一些发展阶段

QTP 时代

很多年前 QTP 横空出世的时候，没有人会怀疑这种工具将是自动化测试的未来形态。使用者理论上不需要掌握任何编程语言就可以通过录制回放的方式实现 web 端的自动化测试。后来事实证明 QTP 向人们证明了自动化测试的可行性，然而其自身的一些限制让其渐渐被主流市场所抛弃。看看 bing 是怎么说的

您好，这是 Bing。QTP 是 QuickTest Professional 的简称，是一种自动化软件测试工具，主要用于功能测试和回归测试 。QTP 的优点有：

• 支持多种编程语言和平台
• 基于关键字驱动的测试方法，易于编写和维护测试脚本
• 提供丰富的测试对象库和检查点，方便识别和验证被测系统的元素
• 可以与其他 HP 测试工具集成，实现全面的测试管理

QTP 的缺点有：

• 商业软件，价格昂贵
• 对于一些复杂的界面或控件，可能无法正确识别或操作
• 对于一些新技术或框架，可能需要安装额外的插件或补丁
• 对计算机资源的消耗较大，可能影响被测系统的性能

请注意，QTP 在官网已被改名为 UFT（Unified Functional Testing）统一功能测试 。

selenium RC 和 waitir 时代

后来的一段时间 selenium 和 watir 渐渐流行起来，这一次一切似乎是发生了倒退，相较于 qtp 提供的足够简单的录制回放模式，selenium rc 和 watir 只能自己写代码去实现自动化里的每一步操作和断言，炫酷的未来似乎渐行渐远。看看 chatgpt 对 selenium rc 的评价，先声明这些评价内容不够准确，大家仅作为参考。

Selenium RC（Remote Control）是一个自动化测试工具，以下是 Selenium RC 的优缺点：

优点：

今天在国外论坛看到了个很有意思的发帖，有人提问：线上发现了 bug 该如何处理。

我知道大家已经问过很多次类似的问题了，不过工作还是很让我失望。我在生产环境上漏掉了 1 个很明显的 bug 没测出来，我想知道你们是怎么处理这种情况的。我的项目经理发现了这个 bug。

大家的回答其实很暖心的。下面是一些高赞回答。

这就意味着你们在单元测试，集成测试和功能测试以及自动化测试的阶段就已经漏掉了这个问题，希望你们有做这些。其实开发跟你们的感受一下，我就是个开发，我一直为我写的 bug 感到抱歉，我认为责任应该由整个 team 承担。

事情都发生了，先承认错误。确定是否真的有测试遗漏，并在未来的发布中加入这个用例。

好的 devops team 需要有零责备文化（https://www.releaseteam.com/the-importance-of-a-zero-blame-culture-in-devops/），好的软件质量交付需要团队的努力。

这就是 QA 当下生存现状。如果你能忍受压力持续进步，那么你会成为一个好的 QA 的。

你并没有搞砸，是流程的锅。扔给你点资料去学习吧https://www.amazon.com/Antifragile-Things-That-Disorder-Incerto/dp/0812979680。

总的看来大家的观点还是开明的，比较包容，不过事实上大家的看法是一回事，但最后处理问题的方式又是另外一回事了。假如发生了一个很严重的线上事故，还好有别人背锅，你是安全的，这时候你心里肯定是同情和理解，觉得 qa 其实有点无辜，是流程的锅，觉得需要整个团队努力一下以便改进交付质量，但是如果你是直接或相关责任人，处罚落到了你头上，你大概率就不会这么宽容的看问题了。

我的观点是发现线上问题不可怕，能不能迅速发现问题和迅速修复问题才是关键，而这两点光靠 qa 负重前行是无法得到根本上的改善的。

一般情况下我们都会避免在周五进行发布，毕竟大家都不喜欢

• 周五留下来加班发布，周五还是早点回去比较好
• 万一发出问题来了周六周日还要想办法去修复，休息的时间无形中被占用了

不过最近看到一篇文章观点很有意思，作者认为只要做的够好，在周五发布其实也不是什么大不了的事情。原文地址在这里，https://dev-tester.com/feel-free-to-deploy-on-friday/?utm_campaign=Software%2BTesting%2BWeekly&utm_medium=email&utm_source=Software_Testing_Weekly_147。 我稍微翻译了一下大意，也许它山之石可以攻玉。

省略前面若干字。

然而，我坚信，如果你想创建一个高质量的应用程序，大多数开发和测试团队的 “看在上帝的份上，不要在星期五部署 “的态度是不可取的。

为什么避免周五部署是一种不健康的质量控制习惯？

当一个团队像躲避瘟疫一样躲避周五部署时，通常可以认为他们对自己的的产品、流程或两者缺乏信心。这种不情愿通常源于组织需要知道或信任他们的应用程序已经准备好让客户使用。任何时候有人说 “我们不会在周五部署”，他们真正说的是 “我们不相信我们的应用程序或流程会在周五部署”。

从长远来看，这种想法并不能带来高质量的系统。团队并不把这些不确定性的作为一个表明他们需要专注于改进的信号。无论缺乏信任和信心是一个现实的问题还是一个想象中的问题，大多数团队都采取简单的方法来掩盖问题，而不是花时间去寻找改进问题的方法。他们想出了一些规则，比如周五不进行部署。

与其避免在周末进行部署，不如正面解决这些问题，加强现有的流程，让团队在任何需要的时候都能自由地进行部署。 作为一个开发人员或测试人员，如果不用担心因为在下班前要更新你的应用程序而使你的周末被打断，你会有什么感觉？

任何认真推动整个团队和产品的质量的组织必须在他们的公司中建立这种信任。虽然对你的系统完全有信心需要时间，但好消息是任何人都可以做到这点，无论他们认为他们的应用程序和流程在他们的组织中是多么的混乱不堪。下面的三步计划可以让你比你想象中的更快达到目的。

第一步：实现一个稳定的自动化测试集

自动化测试用例集合是任何想要快速构建和发布而不需要经常担心他们的应用程序的软件开发团队的必备工具。如果没有自动化测试套件，你就会严重削弱你的团队工作和部署的能力。如果你还没有给自己或你的团队一个空间来增加自动化测试覆盖率，你就会让自己处于不利的位置。

提升质量的第一步是用自动化测试去覆盖所有的关键路径，所以如果你是从头开始，请关注这一步。然而，比覆盖率更重要的东西是稳定性。即使有很高的覆盖率，如果你的测试自动化不断失败，也不会有什么帮助。如果你的测试用例很不稳定，你在任何时候都不会感到舒服，更不用说在星期五部署了。在测试覆盖率方面的工作，重点是建立一个强大的、可维护的测试框架，以保持你的团队长期的高信心。

另一个重点领域是你应该做什么类型的测试。根据你的应用程序的需求，你可能需要各种自动化测试的混合。有些团队写了几个单元测试就结束了，但今天的现代应用程序有很多变化的地方，你需要检查 E2E、验证性能、确保安全性和可访问性等这些都只是冰山一角，提前计划哪些类型的自动化测试可以使你的组织受益。

知道你需要什么类型的测试和你想覆盖的领域。拥有一个稳定的自动化测试用例集和正确的测试组合将加强你的团队对你的应用程序和部署的信心。

第二步：不要忘记手动探索性测试

当团队养成了为他们的应用程序建立稳定的自动化测试的习惯，他们可能会对他们的测试套件在部署前捕捉问题的能力过于自信。通常，一种错误的安全感导致组织内的人认为他们不需要用测试自动化实践来执行额外的测试活动。这种想法与事实相差甚远。不管你的测试自动化习惯有多好，或者你的测试覆盖率有多高，你都不能忽视手动、探索性测试的重要性。

自动化测试只能做他们被告知要做的事情，在快速开发周期中很好进行功能回归。另一方面，手动和探索性测试将允许你观察自动测试的盲点，并在没有人想到的地方发现问题–所谓的 “未知的未知”。忽视测试的这一重要部分而依赖自动化，不可避免地会导致产品质量下降。

人工测试需要时间和精力来完成。一些团队，特别是没有专门的 QA 团队的小团队，往往在最后一刻才进行这些测试。与我合作的大多数初创企业只在重大部署前几天甚至几小时做探索性测试。有时这很有效，但你有可能匆忙完成这个过程，让 bug 遗漏到了线上。

理想情况下，手动探索性测试应该在整个团队的开发周期中持续进行并伴随着新的构建在 staging 环境上进行部署。让你的组织有时间做这种测试，你会发现自己在任何时候都不会担心部署的问题。

第 3 步：建立一个自动化的构建和部署流程

在构建软件的组织中，开发和发布周期的一个部分经常被遗忘，那就是构建和部署过程。在我工作过的一些地方，构建和部署一个新的版本几乎感觉像是一个神秘的过程，只有少数被选中的人才能完成。他们的部署通常由一个漫长的步骤组成，按照精确的顺序和几乎完美的时机进行。如果执行这种仪式性行为的人在途中寄掉，这个过程的脆弱性可能会在瞬间使整个应用程序崩溃。

我描述这个过程的方式可能略显夸张，但却非常接近事实。我合作过的许多公司都有不必要的复杂部署程序。当被问及原因时，一些团队试图证明为什么需要这样做，但他们回答背后的潜台词其实是 “我们一直是这样做的，所以我们从未改变过”。常见的原因是，很久以前有人创造了这个复杂的过程。既然它是有效的–不管这个过程变得多么微妙或曲折–他们从来没有费心去改善现状。

如果你的团队必须执行多个步骤来构建和部署你的应用程序的新版本，那么你就对你的组织造成了巨大的伤害。无论你的整个系统包含多少模块，你都可以将几乎所有的发布过程自动化–甚至将其浓缩为一个命令。如今，我们有大量优秀的工具，从 Jenkins 到 AWS CodePipeline 到 CircleCI 和无数其他工具，使构建和部署过程自动化变得非常简单。你的组织没有任何借口可以避免自动化部署。

部署过程中一个同样重要但被遗忘的部分是回滚失败的部署。尽管有一个经过良好测试的自动化过程，它仍然可能由于许多不同的原因而失败，从糟糕的代码被合并到你的应用程序的基础设施的故障。大多数团队发现他们没有任何回滚策略，当部署失败时，他们的应用程序就会停机。在这种情况发生之前，制定一个适合你的情况的回滚策略，并经常测试，以确保当墨菲定律发生时，你不会感到惊讶。

总结

这篇文章的目的不是让你的团队每周五进行部署，而是让他们在需要时可以毫无顾虑地进行部署。自信部署而不用担心某些幺蛾子会发生的能力，会让每个开发人员和测试人员在他们的项目周期中不用担心太多。如果我们幸运的话，也许我们会看到更少的 memes 在我们的 LinkedIn feeds 上乱窜。

总之作者的观点是如果你够强，什么时候部署都没问题。然而时间总是自己的，为了不必要的节外生枝，还是建议大家在周五下班前或者下午不要进行部署，多一事不如少一事，不在周五部署不是真理，而是生活。