martin fowler的博客上新发了一篇关于 AI 和 TDD 的文章，先翻译一下，然后聊聊我的看法。

使用测试驱动开发(TDD)与 GitHub Copilot 编码助手

AI 编程助手如 GitHub Copilot 的出现意味着我们不再需要测试了吗?TDD 将过时吗?为了回答这个问题,我们来看一下 TDD 如何帮助软件开发的两点:提供良好的反馈,以及在解决问题时“分治法”。

TDD 提供良好的反馈 良好的反馈要快速和准确。在这两方面,没有什么能比一个编写良好的单元测试更好。不论是手动测试,文档,代码审查,甚至是生成式 AI,都不能取代。事实上,大型语言模型提供无关信息,甚至 hallucinate。当使用 AI 编程助手时,尤其需要 TDD。我们需要对自己编写的代码快速准确的反馈,也同样需要对 AI 编程助手编写的代码快速准确的反馈。

TDD 通过分治法解决问题 通过分治法解决问题意味着较小的问题可以比较大的问题更早解决。这实现了持续集成,基于主线的开发,最终实现持续交付。但是如果 AI 助手为我们编写了代码,我们是否真的还需要所有这些?

是的。大语言模型很少能在一次提示后就提供我们所需的确切功能。所以迭代开发还没有走到尽头。此外,大语言模型似乎在通过思路提示的增量方式解决问题时“激发了推理”(参见相关研究)。基于 LLM 的 AI 编程助手在分治法解决问题时表现最好,而 TDD 是我们在软件开发中所做的。

使用 GitHub Copilot 的 TDD 技巧

Thoughtworks 从年初开始就一直在使用带有 TDD 的 GitHub Copilot。我们的目标是实验、评估和发展一系列围绕使用该工具的有效实践。

0. 开始

从一个空白的测试文件开始并不意味着从一个空白的上下文开始。我们通常从一个带一些粗略笔记的用户故事开始。我们也会与配对伙伴讨论一个起点。

所有这些上下文都是 Copilot 在我们把它放入一个打开的文件之前(例如测试文件顶部)“看不到”的。Copilot 可以处理拼写错误、点式格式、糟糕的语法等等。但是它无法处理一个空白文件。

一些对我们有效的启动上下文示例:

• ASCII 艺术画布
• 验收标准
• 引导假设,例如:
• “不需要 GUI”
• “使用面向对象编程”(而不是函数式编程) Copilot 使用打开的文件作为上下文,所以同时保持测试文件和实现文件打开(例如并排)大大提高了 Copilot 的代码补全能力。

1. 红色

我们首先编写一个描述性的测试示例名称。名称越描述性越好,Copilot 代码补全的表现也越好。

RPC

试想这样一种场景，一个复杂系统中的两个模块之前需要互相调用，一般的做法是什么？

可能这两个模块是跑在同一个进程上，那么通信起来其实是非常方便的，也有可能这两个模块分别是跑在不同的进程之上，那么就涉及到复杂一点的跨进程通信的技术了。但这些都是模块部署在同一机器下的情景，大家想象起来也会比较容易。

更加深入一些，如果两个模块跑在不同的机器之间，那么模块之前的调用如何实现呢？这就需要使用 RPC 技术了。

RPC（Remote Procedure Call）— 远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC 协议假定某些传输协议的存在，如 TCP 或 UDP，为通信程序之间携带信息数据。在 OSI 网络通信模型中，RPC 跨越了传输层和应用层。RPC 使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC 采用客户端/服务器模式。请求程序就是一个客户端，而服务提供程序就是一个服务器。首先，客户端调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

简单来说 RPC 需要 server 端和 client 端，server 端定义一些函数，client 端通过网络请求去调用这些函数拿到返回值。server 端和 client 端跑在不同的机器上，结合微服务的概念就是 server 端就是一个独立的微服务，其他微服务需要通过启动 client 端来调用该微服务提供的服务。

gRPC

gRPC 一开始由 Google 开发，是一款语言中立、平台中立、开源的远程过程调用(RPC)系统。

在 gRPC 里客户端应用可以像调用本地对象一样直接调用另一台不同的机器上服务端应用的方法，使得您能够更容易地创建分布式应用和服务。与许多 RPC 系统类似，gRPC 也是基于以下理念：定义一个服务，指定其能够被远程调用的方法（包含参数和返回类型）。在服务端实现这个接口，并运行一个 gRPC 服务器来处理客户端调用。在客户端拥有一个存根能够像服务端一样的方法。

组成

典型的 grpc 实现有两端组成，分别是

• server
• client

gRPC 的特性

• 由于 client 和 server 需要通过网络进行消息的传递，那么网络协议成了 grpc 里重要的一环。grpc 协议是 HTTP/2，这是一种优化过的 http 协议，实现了连接多路复用、双向流、服务器推送、请求优先级、首部压缩等机制。可以节省带宽、降低 TCP 链接次数、节省 CPU，帮助移动设备延长电池寿命等。
• 服务端向外提供了一些可供调用的函数，这些函数的原型通过 ProtoBuf 协议来进行定义。ProtoBuf 是由 Google 开发的一种数据序列化协议（类似于 XML、JSON、hessian）。ProtoBuf 能够将数据进行序列化，并广泛应用在数据存储、通信协议等方面。压缩和传输效率高，语法简单，表达力强。
• 支持多种编程语言。比如支持 golang/java/c++/ruby/python/nodejs 等。

gRPC 的优点

• 使用 protobuf 进行消息的序列化，压缩率高，性能好，毕竟压缩的越小在网络上传播的速度就相对会更快一点
• 序列化反序列化直接对应程序中的数据类，不需要解析后在进行映射，其实除了可读性差之外，pb 的使用方式跟 json 基本都差不多了
• 支持向前兼容和向后兼容，升级比较简单
• 支持多语言

典型的 gRPC 实现

典型的 gRPC 实现有 3 个部分，分别是

原文地址: https://medium.com/@dstekanov.tech/qa-team-as-a-fire-department-9b5abd470e44

翻译及总结如下。

作者是一名有十多年经验的 QA 工程师，作者曾经在不同的公司和项目中工作过，从小型的创业公司到大型的跨国公司，从传统的水瀑式方法到现代的敏捷方法。在这些年里，作者观察到了 QA 团队在软件开发过程中扮演着不同的角色和职责，有时候是成功的，有时候是失败的。作者想分享一下作者对 QA 团队的看法和建议，希望能对那些想要提高 QA 团队效率和价值的人有所帮助。

作者喜欢用消防队来比喻 QA 团队。消防队是一个重要的组织，它可以在紧急情况下保护人们和财产免受火灾的危害。消防队员需要具备以下几个特点：

• 快速反应：消防队员需要能够在第一时间到达火灾现场，并迅速采取措施控制火势。
• 高效协作：消防队员需要能够和其他消防队员以及其他救援人员密切合作，共同完成救援任务。
• 专业技能：消防队员需要掌握各种消防设备和技术，以及如何应对不同类型和规模的火灾。
• 持续学习：消防队员需要不断地更新自己的知识和技能，以适应不断变化的环境和需求。

类似地，QA 团队也是一个重要的组织，它可以在软件开发过程中保证产品的质量和性能。QA 工程师也需要具备以下几个特点：

• 快速反馈：QA 工程师需要能够在第一时间发现并报告产品中存在的问题，并提供有效的解决方案。
• 高效沟通：QA 工程师需要能够和开发工程师以及其他利益相关者密切沟通，共享信息和反馈。
• 专业技能：QA 工程师需要掌握各种测试工具和技术，以及如何针对不同类型和规模的产品进行测试。
• 持续学习：QA 工程师需要不断地更新自己的知识和技能，以适应不断变化的环境和需求。

基于这个比喻，作者想给出以下几点建议，来帮助 QA 团队更好地发挥自己的作用和价值

• QA 团队应该和开发团队紧密合作，共享信息和反馈，而不是互相指责或隔离。这样可以提高沟通效率，减少误解和冲突，提升产品质量。作者举例说，他曾经在一个项目中，QA 团队和开发团队使用同一个工具来管理问题和需求，这样可以及时地交流和解决问题，避免了重复工作和延误。
• QA 团队应该使用自动化测试工具，提高测试效率和覆盖率，而不是依赖人工测试或过时的方法。这样可以节省时间和资源，发现更多的问题，提高测试质量。作者举例说，他曾经在一个项目中，QA 团队使用了自动化测试框架来执行回归测试，这样可以在短时间内完成大量的测试用例，而不需要人工干预。
• QA 团队应该关注用户的需求和体验，而不是只关注技术细节或功能。这样可以更好地满足用户的期望，增加用户的满意度，提高产品价值。作者举例说，他曾经在一个项目中，QA 团队使用了用户故事来定义测试场景，这样可以从用户的角度来验证产品的功能和性能，而不是只从技术的角度来检查。
• QA 团队应该持续地学习和改进，跟上行业的发展和变化，而不是停滞不前或满足现状。这样可以提高自身的能力和知识，适应不同的环境和需求，保持竞争力和创新力。作者举例说，他曾经在一个项目中，QA 团队使用了敏捷方法来进行测试活动，这样可以灵活地调整测试计划和策略，根据实际情况来优化测试过程。

作者最后总结说，QA 团队是一个重要的角色，它可以帮助产品成功地上市和运行，但是它也需要不断地适应和创新，才能保持竞争力和价值。

原文地址: https://medium.com/@peterdtitan/designing-for-failure-in-software-development-and-testing-9f3f2d0bbd7b

软件开发是一个复杂的过程，涉及到许多不同的技术、工具、方法和人员。在这个过程中，失败是不可避免的，甚至是必要的，因为它可以帮助我们发现错误、改进质量和提高效率。然而，并不是所有的失败都是有益的，有些失败可能会导致严重的后果，如数据丢失、系统崩溃、客户不满或法律责任。因此，我们需要在软件开发和测试中为失败而设计，即预见可能发生的失败情况，并采取相应的措施来防止、检测、恢复和学习。

为失败而设计的原则

为失败而设计并不意味着我们要故意制造失败，而是要在开发过程中考虑到失败的可能性，并采用一些原则来应对它们。以下是一些常见的为失败而设计的原则：

• 容错：容错是指让系统能够在出现错误时继续正常运行，而不是崩溃或停止工作。容错可以通过多种方式实现，如使用异常处理、重试机制、备份系统、冗余组件等。
• 隔离：隔离是指将系统分割成不同的模块或服务，使得一个模块或服务的失败不会影响其他模块或服务的正常运行。隔离可以通过多种方式实现，如使用微服务架构、消息队列、断路器模式等。
• 降级：降级是指当系统无法提供完整的功能或性能时，能够提供一些基本的或替代的功能或性能，以满足用户的最低需求。降级可以通过多种方式实现，如使用缓存、静态页面、功能开关等。
• 监控：监控是指收集和分析系统的运行状态、性能指标、错误日志等信息，以便及时发现和解决问题。监控可以通过多种方式实现，如使用日志系统、度量系统、报警系统等。
• 反馈：反馈是指向用户或开发者提供有关系统状态或问题的信息，以便他们能够做出适当的响应或改进。反馈可以通过多种方式实现，如使用用户界面、通知系统、报告系统等。

为失败而设计的好处

为失败而设计可以带来许多好处，如：

• 提高系统的可用性和可靠性：通过容错、隔离和降级等手段，可以使系统在出现错误时仍能保持运行，从而减少停机时间和损失。
• 提高系统的可扩展性和可维护性：通过隔离和监控等手段，可以使系统更容易分布式部署和管理，从而适应不同的负载和环境。
• 提高用户和开发者的满意度和信任度：通过监控和反馈等手段，可以使用户和开发者更清楚地了解系统的状态和问题，并及时得到解决方案或建议。

为失败而设计的挑战

为失败而设计也有一些挑战，比如增加系统的复杂度和成本：为了实现容错、隔离、降级等功能，需要增加额外的代码、配置、测试和部署

、

命令行应用很多时候可以提升我们的工作效率，这里给大家推荐 4 款常见好用的命令行应用，希望对大家有所帮助。

vim

大名鼎鼎的命令行编辑器，有时间的同学都可以尝试一下。

说起来比较惭愧，当初学习 vim 的原因有两个。第一个是十多年前的室友表示 vim 这种工具的学习成本底，因为学会以后键位几十年不变，学一次用终生，性价比极高，尽管入门的时候学习曲线非常的陡峭，甚至有点反直觉。第二个理由是学习 vim 可以让我比较方便的在线上环境改代码，是的，你没看错，很多年前我们用 php 的时候确实做过线上调试和改代码的极限操作。

如今随着运维的规范以及自动化发布的普及，线上改代码这种高危操作应该是被严令禁止了。不过使用 vim 仍然可以让你在任意机器 ssh 进远程服务器进行代码的编写和执行。配合上自定义的配置和第三方的插件，vim 也是日常代码编辑的一个不错选择。

另外很多编辑器都支持 vim 键位，比如 atom，vscode，这会让你在写代码的时候更有如鱼得水的感觉。

tmux

tmux 之前是运维同学的钟意之物，因为该工具可以

• 分屏，将 1 个 terminal 分成多个部分
• 独立运行 session，每个部分都是独立的会话，互不干涉
• 快照，任意时刻退出 terminal，tmux 都会保存当前会话，下一次可以无缝恢复

命令行的典型使用方式是，打开一个终端窗口（terminal window，以下简称"窗口"），在里面输入命令。用户与计算机的这种临时的交互，称为一次"会话"（session） 。 会话的一个重要特点是，窗口与其中启动的进程是连在一起的。打开窗口，会话开始；关闭窗口，会话结束，会话内部的进程也会随之终止，不管有没有运行完。 一个典型的例子就是，SSH 登录远程计算机，打开一个远程窗口执行命令。这时，网络突然断线，再次登录的时候，是找不回上一次执行的命令的。因为上一次 SSH 会话已经终止了，里面的进程也随之消失了。 为了解决这个问题，会话与窗口可以"解绑"：窗口关闭时，会话并不终止，而是继续运行，等到以后需要的时候，再让会话"绑定"其他窗口。

Tmux 就是会话与窗口的"解绑"工具，将它们彻底分离。 （1）它允许在单个窗口中，同时访问多个会话。这对于同时运行多个命令行程序很有用。 （2） 它可以让新窗口"接入"已经存在的会话。 （3）它允许每个会话有多个连接窗口，因此可以多人实时共享会话。 （4）它还支持窗口任意的垂直和水平拆分。

tmux 对于我来说的典型用法就是

• 把一个窗口分成几块，小的窗口运行 mysql，redis 之类的服务
• 用一个窗口运行主服务，比如 python 的 flask 开发服务器
• 用最大的窗口来运行 vim 编辑器，做代码的编辑

这样任意时刻我退出 ssh，上面的这些服务都会一直运行，下次我再 ssh 上去的话就可以无缝的继续工作了。

昨天 google 发布了全新的 ai 模型 gemini，在视频里 google 演示了 gemini 近乎神奇的实时反馈能力，比如测试人员画一只鸭子，ai 可以立即识别，以及后面的一些互动小游戏中，gemini 展示出了出人意料的精准度和推理能力，这是令我印象最为深刻的多模态模型的实时演示了。

珠玉在前，gpt4 的文本类型的推理能力已经到达了一个相对可用的状态，基于该能力，我们也看到了一些比较有意思的自动化类型的项目，比如通过简化 html 输入大语言模型，让大语言模型去推断用户想要进行的操作，最终调用浏览器 api 进行自动化操作的项目，以及利用 llm 的解释器能力，一步一步推理并进行浏览器操作的项目，这些项目都非常有创意，也有一定的实用性，但是缺乏完善的多模态支持总让人觉得想象空间可能没有变得非常广阔。gemini 的出现，强大的推理能力，代码生成能力以及多模态能力的结合，也许会为自动化测试领域带来翻天覆地的变化。

UI 自动化

这是难度最高的自动化测试类型，比如浏览器和 app 的自动化，尽管概念出现的非常早，而且也发展了相当长的一段时间，但是 ui 自动化的普及度却相对来说不算太高，在资源和时间有限的情况下，ui 自动化测试往往是被大家优先降本增效的不二选择。

类型 gemini 的大语言模型的出现，可能会给 ui 自动化带来革命性的变化。今后，我们可以直接向 ai 输入一些描述相对明确的测试用例，当然，是用自然语言编写的，ai 可以推断出我们的测试意图，还原测试步骤，最终将测试步骤转化成测试代码，自动运行，通过运行中提供的截图和代码报错信息自动分析结果，自动迭代和修正代码错误，直到输出最终代码，基本上 ui 自动化是可以完美闭环的。

也就是说也许不久之后我们只需要写好手工测试用例就可以完成相对完美的自动化测试工作了，以后的测试人员可能不再需要每个用例都去执行一遍，执行的工作应该可以被 ai 和机器替代绝大部分。

顺便再考虑一下测试用例，如果 ai 的推断能力足够强的话，ai 应该可以写出大部分的测试用例，这时候测试人员只需要补充一些极端场景的用例就可以了。

那测试用例是从哪里来呢？可能是从产品文档里分析出来的，同样，如果模型精通多模态和推断的话，那么产品文档和产品设计图也是可以用 ai 去生成一大部分的，人工只要负责查缺补漏和提出修改意见就好了。同理，代码的话 ai 也能写个大部分，也许今后我们的工作方式会发生巨大的转变，从单纯的跟人合作变成跟人和 ai 一起协作，通用知识和能力将变得廉价，垂类的信息和领域知识可能会越来越值钱。

接口自动化

接口自动化可能不太需要多模态，基于模型的推理和生成能力，如果模型支持海量的上下文输入的话，那么我们是完全可以为接口自动化的用例定义规则，并教会模型如何应用这些规则生成测试用例。

举个例子，如果我们 curd 的接口遵循 restful 规则的话，ai 是完全有能力生成 restful 接口的测试用例的，毕竟 restful 的规则比较清晰，而且对于具体资源来说接口和用例的数量都是可以枚举的。

因此对于一些相对简单的接口，用 ai 去编写用例从直觉上来说是可行的，不过对于复杂接口，比如一些接口有很繁杂的前置依赖和操作步骤，ai 自动根据接口文档的话可能不太好去推断各种具体场景，这种情况下我们可能需要一种接近自然语言的简化版中间语言，这种语言描述一些接口的输入输出以及构造复杂的接口测试场景，ai 根据这种 DSL 去生成代码的话可能效率和准确性都要更高一点。