理解业务

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

成为问题解决者

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

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

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

别害怕提问或表达疑虑。

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

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

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

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

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

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

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

前几天看到一篇 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 负重前行是无法得到根本上的改善的。