看到一篇非常有意思的女性测试从业者的技术分享，忍不住翻译了一下，角度非常感性，引人深思，测试的世界其实特别多元，也希望以后有机会能遇到各种有意思的观点。

原文地址: https://fishouthebox.medium.com/the-power-of-emotion-driven-testing-280a944d352b

昨晚，我在 Ministry of Testing 的 TestBash World 做了一个演讲，其中有一部分是关于情感的。其中有一部分我分享了 10 条情感路径，你可以用来指导你的测试。来源于 Gojko Adzi, David Evans 和 Tom Roden 的《改善我们测试的五十个快速想法》一书。

我把这个写在博客上是出于 Gwen Diagram 的一个建议，以文字的形式来分享这个内容会很有用。因此，我们开始吧。

• 可怕的路径–对你的利益相关者来说，什么会真正烧毁你的房子？可能是品牌效应？安全风险？
• 快乐的路径–每次都能通过的道路。
• 愤怒的路径 - 试图让应用程序做出糟糕的反应。如验证错误、不良输入和逻辑区域。
• 疏忽的路径 - 考虑需要测试的安全风险，如认证、授权、权限、数据保密性。
• 尴尬的路径–会造成巨大尴尬的事情，如主页上的拼写错误。
• 荒凉的路径–为应用程序或组件提供暗淡的东西。例如 nulls、blanks 或缺失的数据。
• 遗忘之路–填满内存和 CPU 容量，使应用程序没有地方可以存储任何东西。看看它变得多么健忘，是否开始丢失数据，要么是已经存储的东西，要么是它正在持有的东西。
• 犹豫不决的路径–打开和关闭一些东西，点击浏览器上的返回按钮等。
• 贪婪的路径–选择一切，勾选每一个方框，选择每一个选项。
• 紧张的路径–找到功能和组件的突破点。负载/性能测试的考虑。

by 乙醇：情绪相关的分类方式更加感性一些，相比于我们理性的测试用例和测试场景来说，这里没有对错之分，只要考虑的全面，用任何分类方式都是合理的。

这几天 hack news 上比较热烈的讨论是这一套 python 教程：https://github.com/dabeaz-course/python-mastery。

作者是 Dabeaz, David Beazley 的别名，他是一位计算机科学家、教育家和研究员，拥有超过 35 年的经验。Dave 在 Python 社区中非常活跃，他创建了多个软件包，参加了会议演讲和教程，并且以《Python Distilled》（Addison-Wesley）、《Python Essential Reference》（Addison-Wesley）和《Python Cookbook》（O’Reilly Media）的作者而闻名。他通过提供各种高级计算机科学和编程课程来支持这些工作。

来头很大的，毕竟是《Python Cookbook》 的作者，所以专业性上是有背书的。

简单的把项目的 readme 文件翻译了一下，这个项目的核心学习理念就是手动操作，完成课程练习，多写代码总是有收获的。

简介

这是一门高级 Python 编程的练习驱动课程，经过十多年的企业培训实战验证数百次。由 David Beazley 撰写，他是《Python Cookbook, 3rd Edition》（O’Reilly）和《Python Distilled》（Addison-Wesley）的作者。课程采用了知识共享许可协议，无广告、无追踪、无弹窗、无新闻通讯和 AI。

目标受众

这门课程适合希望进一步提高 Python 编程水平，从编写简短脚本转向编写更复杂程序的 Python 程序员。课程主要关注常用库和框架中使用的编程技巧。主要目标是更好地理解 Python 语言本身，以便理解他人的代码，并将新学到的知识应用于自己的项目中。

先决条件

你已经掌握一些 Python 知识。这不是一门面向初学者的课程。如果你需要更多入门材料，你可以考虑参加 Practical Python Programming(https://dabeaz-course.github.io/practical-python)课程。

如何参加课程

首先，你应该将 GitHub 仓库 fork 或克隆到自己的机器上。

我们假设你在本地有一个合适的 Python 开发环境。这意味着你已经正确安装了 Python，有一个编辑器/集成开发环境和其他常用于 Python 开发的工具。由于课程使用了多个文件和模块导入，不推荐使用 Notebooks。

PythonMastery.pdf 文件包含了详细的演示幻灯片。课程练习和建议的时间安排都有清楚的标示。你应该将它放在身边（我建议你下载并在本地 PDF 阅读器中查看）。从这里开始吧！

关于测试左移 shift left 的讨论已经持续了很长一段时间了，前几天刚好看到有外国友人亲身参与了这个过程，结果有点出人意料，所以翻译出来分享了一下。

在 2017 年，成为一名 QA 是一个有趣的时间。但不是搞笑哈哈，是有点点诡异了。每个人都想着测试左移（在合理范围内），但不是为了提高他们的质量，他们会以减少传统的质量保障人员的瓶颈的心态来做，那就是在迭代结束时，测试所有的东西。

我记得几年前，我是一个由 5 个开发人员组成的团队中唯一的 QA，我们没有大量的自动化测试，但左移的思维方式得到了应用，至少是部分应用。我在开发人员做需求时，尽早地帮助他们，这在迭代结束后会得到回报，测试阶段的时间是最少的。充其量，我们会在测试阶段发现一两个问题，并迅速修复它们（或假设该问题到下一个版本）。

公司内部的一个新项目已经开始了，他们想在一开始就应用左移的思维方式，但他们不需要 QA。所有的工作都可以通过自动化测试完成，开发人员将完全承担和拥有这些测试。作为一个 QA 人员，我很好奇，我想看看他们是怎么做的，他们是怎么涵盖这个用例的，或者其他用例的，我想学习并帮助他们。但是我被推到了一边，因为自动化才是王道，不需要 “手动 QA”。

当他们在几个月后找到我的时候，我遇到了 “告诉你 “的时刻，他们在生产中出现了大量的问题。那是一个混乱的局面。这时他们意识到，即使他们写了大量的测试，他们也没有考虑到他们的测试策略。解决方案是在团队中加入一个 “手动 QA”，来处理应用程序的问题，防止生产中出现更多的错误。

快到今天，我意识到他们已经非常接近了。他们拥有自动化测试策略。团队中的任何新开发人员都经历了严格的代码覆盖率、配对编程和细致的提交代码审核过程。他们唯一缺少的是一个好的测试策略，按照测试金字塔的描述进行工作（我知道你们中的一些人鄙视这个，但有时，它真的可以帮助团队分类并专注于正确的事情！），以及在用户体验上多想一点。

那么，你的 QA 团队成员可以在左移的转型或项目中扮演什么角色呢？

• 在开始 “左移 “时，文档被证明是有用的。通过确保针对现有功能和新功能中最关键的点，它可以更容易地从传统的方法过渡。通常把重点放在用户的关键功能和你的应用程序中常见的脆弱点上。
• 参加研发的启动会议。帮助提前考虑潜在的问题，用例子来引导这些会议是最好的做法。就我个人而言，我更喜欢在开发人员开始一个需求时以非正式的方式召开这些会议，但你也可以把这些会议变成一个定期会议，类似于你的 scrum 计划和复盘会议。这种做法也被称为 3 amigos（读起来不错）。
• 学会阅读代码，看看 PR 评论，学习自动化，你的 QA 团队成员越是多才多艺，开发人员就越有信心作为一个团队来交付他们的功能，而不是依赖一个 QA 警察。

如果你的团队没有一个已经在职的 QA，你的团队已经可以开始应用同样的准则。停下来，呼吸，花 15 分钟思考可能的测试用例。不要在功能上走得太深，但思考所有可能的用户行为有很大的帮助。把它们写下来 👏。这将帮助你防止很多 “我没有想到的 “情况。

虽然这不是一个完美的指南，但这是很好的第一步，我称之为 “在 3 天周末前的星期五下午 4 点部署的信心”。但这是另一个故事了。

最近看到一篇关于测试金字塔的讨论，觉得非常有道理，原文在这里: https://www.smashingmagazine.com/2023/09/long-live-test-pyramid/

顺便翻译一下，希望对大家有所帮助。

我亲爱的同事 Jan Philip Pietrczyk 曾经对开发者在编写功能代码方面的责任发表过评论：

“我们的日常工作最终会交到信任我们的人手中，他们不仅信任我们已经尽力而为，还信任我们的代码能够正常运行。” — Jan Philip Pietrczyk

他的这些话一直深深地印在了我的脑海中，因为它让我们的代码置于依赖它的人们的背景之中。在这个快节奏的世界里，用户信任我们编写最优秀的代码，并且我们的软件“简单地”可以运行。确实，要达到这种信任水平是一个挑战，这就是为什么测试是任何开发堆栈中如此重要的一部分。测试过程评估了我们工作的质量，通过对不同情况进行验证，帮助在问题变得严重之前识别问题。

测试金字塔是众多测试策略之一。尽管自 2012 年引入以来，它可能已经成为了主要的测试模型，在过去的十年中占据主导地位，但我发现现在提及它的次数并不像过去那么多。它是否仍然是测试的“首选”方法？与此同时，许多其他方法也已经涌现，因此是否可能是测试金字塔被更适合当今开发的更现代模型所淹没和遮盖？

这就是我想要探讨的问题。

测试策略的关键点

与用户建立信任需要一个强大的测试策略，以确保我们编写的代码使产品按照他们的期望工作。我们应该从哪里开始编写好的测试？我们需要多少个测试？许多人一直在思考这个问题。但是 Kent C. Dodds 发表的一个简短评论让我恍然大悟。

“最大的挑战是知道要测试什么，以及如何进行测试，以获得真正的信心，而不是测试实现细节所带来的虚假信心。”

-Kent C. Dodds 这就是起点！确定测试的目标是测试策略中最关键的任务。互联网上充斥着描绘糟糕决策的迷因，其中许多是因为根本不知道特定测试的目的以及我们需要多少测试来确保信心。在测试方面，有一个“正确的比例”，以确保代码经过适当的测试并且按照预期工作。

问题在于许多开发人员只关注一种类型的测试 - 通常是单元测试覆盖率 - 而不是对各种单元如何协同工作制定策略。例如，当测试一个水槽时，我们可以分别测试水龙头和下水道，但它们是否协同工作呢？如果下水道堵塞，而水龙头继续放水，那么事情就不正常了，即使单元测试表明水龙头正常工作。

关于测试的方法通常用不同的形状来描述，就像我们已经看到金字塔模型一样。在这篇文章中，我想分享一些我观察到的形状，以及它们在现实场景中的应用，最后总结出哪种测试策略符合我对当今开发实践中良好测试覆盖的个人标准。

回顾基础知识

在此之前，让我们回顾一些不同测试类型的常见定义，以刷新我们的记忆：

手动测试

这是由实际人员执行的测试。这意味着测试将要求真实用户按照脚本化的使用案例进行点击应用程序，以及未经脚本化的尝试在不可预见的情况下“破坏”应用程序。这通常是通过与由产品团队观察的用户进行面对面或远程面试来完成的。

单元测试

这种类型的测试是将应用程序分解为小的、隔离的、可测试的部分，或者称为“单元”，通过分别和独立地测试每个单元以确保其正常运行来提供覆盖。

集成测试

这些测试关注组件或系统之间的交互。它们一起观察单元测试，以检查它们在集成在一起作为整体工作时是否良好。

端到端（E2E）测试

在这种类型的测试中，计算机模拟实际用户的交互。将 E2E 视为验证用户故事的一种方式：用户是否可以完成需要一系列步骤的特定任务，结果是否符合预期？这是从用户体验的一端到另一端进行测试，确保输入产生正确的输出。

那么，这些测试类型应该如何互相交互呢？测试金字塔是我们传统依赖的隐喻，用来将这些不同类型的测试整合到一个完整的测试套件中，适用于任何应用程序。

伟大的测试金字塔

测试金字塔是由 Mike Cohn 在他的书《成功的敏捷》中首次引入，并由 Martin Fowler 在他的“实用测试金字塔”文章中进一步发展的，根据测试的性能和成本对测试进行了优先排序。它建议编写具有不同粒度级别的测试，包括较少的高级别测试以及更多快速、经济、可靠的单元测试。推荐的测试顺序是从快速和经济到慢和昂贵，从底部开始有很多单元测试，然后是服务，即中间的集成测试。然后是位于顶部的较少但更具体的 UI 测试，包括端到端测试。

微软今天发布了集成了 GPT-4 模型的 office 套件，从演示视频看，大概可以做这样一些事情

• 输入指令自动做表
• 输入指令写邮件
• 输入指定自动做 ppt，而且一做就是好多页，挺震撼的

稍微了解了一下原理，大概流程是

• 用户发送 prompt 到 office
• office 获得用户授权访问用户的核心数据（email，聊天记录，会议信息，日程，联系人列表等）
• office 整合用户信息修改 prompt
• office 将修改后的 prompt 发送到语言模型
• office 拿到语言模型的返回，并结合用户数据进行信息整合
• office 拿到整合后的信息和 app 的命令列表，进行自动化和信息展示

从原理可以看出 office 基本上把语言模型，目前也就是 GPT-4 当成了黑盒，这样应用软件层面其实不需要了解太多模型的细节和实现，只需要把模型当成语言理解器，内容生成器就好了。语言模型只负责理解用户的 prompt 和生成内容，office 负责整合数据，调整 prompt，以及我们今天讨论的话题，执行 ui 自动化。

未来办公软件的形态

未来办公软件有很大概率会跟 AI 结合起来，他们大概会是

• 有自己的主要形态和业务领域，比如邮件客户端，文字处理软件客户端，也就是有 UI，有交互，有一些逻辑，跟现在的办公软件差不多
• 有 AI 辅助的能力，可以接受用户的 prompt 并进行修改和吟唱，然后调用大语言模型
• 有完善的 UI 自动化能力，根据大语言模型返回的内容自动化的进行操作，并展现给用户

所以简单来说，未来的办公软件将会调用 AI，并执行自动化。

那么未来的软件都会有 ui 自动化的接口

这个结论是水到渠成了，有 ui 自动化接口，那么就需要做 ui 自动化测试。所以对于一些泛化的办公软件开发团队来说，测试人员不仅要负责传统的功能测试，还需要调用 ui 自动化接口，保证接口的正确性，甚至是 ui 自动化的测试代码都可以成为大语言模型的无监督学习物料。

更泛化的办公软件实现

也许未来会出现更加泛化办公软件或者是办公流程软件，可能包含这些部分

看到了一篇关于 whatsup 是如何做测试的文章，尽管里面有一些拍领导彩虹屁的嫌疑，不过还是可以让我们了解到 meta(whatsup 属于 meta)内部整体质量保障架构的情况。翻译了一下，供大家参考。原文地址: https://automationhacks.io/2023-10-18-how-whatsapp-tests-software

我正在思考 WhatsApp 团队如何测试其应用程序以及全球其他团队可以从他们的测试工程实践中学到什么。这也是很多人问我的一个经常性问题，所以让我们来揭开一些面纱，好吗？

测试方法

我在 2021 年底到 2023 年中期的一年半时间里，作为 WhatsApp 测试自动化团队的成员，在他们伦敦办公室工作，我有幸近距离观察了一个拥有 20 亿多用户的应用程序是如何进行测试的。

WhatsApp 测试自动化团队负责开发测试基础设施、工具和框架，以便让开发人员为 WhatsApp 客户端（尤其是 Android、iOS、Web 和桌面应用程序）编写高效的测试。这是整个组织测试策略的关键部分。

在某些方面，这些方法与其他面向消费者的移动应用程序相似，具有测试金字塔的各个典型层次。WhatsApp 团队倾向于使用许多开源工具来编写自动化测试，但也使用许多内部元工具和基础设施来加强整个测试策略。WA 的测试方法也与元应用程序有很大的不同。

在本文中，我将讨论两个关键因素，这些因素促成了自动化的强大文化。

• 框架和基础设施
• 支持这一文化的团队和角色

让我们深入探讨一下吧 🏊

测试框架

首先，让我们看看测试金字塔的不同层次，以及使用了哪些不同的工具和框架。

对于移动框架，自动化测试在测试金字塔的各个层次上进行编写，使用了大量的 Espresso 和 XCUITests，相对较少的 E2E 测试。

Android

• Unit tests: JUnit, Roboelectric
• UI tests: Espresso
• Screenshot tests: Screenshot tests for Android (read more about this here 🔗)
• E2E tests: Jest-based internal E2E testing framework

iOS