几年前，我面试过一个开发微服务的无服务器团队的候选人。在我面前的是一位非常能干的无服务器工程师。当我们的谈话进入了最后一个环节 —— 团队合作。
我：你能解释一下你与质量保证工程师的合作方式吗？
候选人：（一脸茫然……几秒钟后）。呃……，对不起，我不能回答这个问题，因为我们团队里没有质量保证工程师。
我：（控制住自己的惊讶）啊，我明白了。没关系。那么，谁来履行质量保证职责？
候选人：我们的团队由五名工程师组成，每个人都分担质量保证责任！
虽然我们的谈话结束了，但我还是继续探究分析了无服务器团队中质量保证工程师的角色和需求，该团队专注于后端服务开发。
质量保证的众多化身
质量保证（QA）是一个过程，它根据产品规格确保产品的特性，使每一次、每一件产品都能达到预期的质量。质量保证不是一次性、单点的活动，而是持续性的。以制造业为例，产品的质量取决于生产流水线每个阶段的质量 —— 从原材料到零部件，从工艺到包装等等。
软件质量保证（SQA）
质量保证并非软件工程的原生内容。软件质量保证 (SQA) 是软件行业对质量保证流程的调整，专门针对软件开发中的质量活动。与制造业一样，SQA 可确保软件开发的每个阶段都符合标准，满足质量标准，并在整个软件开发生命周期中并行运行。软件测试是 SQA 的一个子集，而不是全部。
保证与工程
如果说 SQA 是关于原则、程序和协议，那么软件质量工程 (SQE) 就是负责执行 SQA 流程。通常很难区分计算机程序员（程序员）、软件开发人员（开发人员）和软件工程师。同样，质量保证的角色和职责也很难界定。
工程与测试
过去，瀑布模型的顺序软件（系统）开发生命周期（SDLC）有需求、分析、设计、编码、测试、发布和维护等不同阶段，需要数月或数年才能完成。专门的质量保证团队建立了质量流程、审核程序、合规性和软件测试。测试是质量保证的一部分，从事测试工作的人被称为软件测试员或测试人员，有时也被称为测试工程师！随着软件行业将 SQA 作为一项主要活动，QA 这一缩写词在其范围内成为通用语言。
左翼大转移运动
几十年来，技术的发展催生了更新的开发和运营模式，带来了灵活性、自主性和加速度。快速流动、速度和价值已成为企业赢得现代消费者的口号。这就需要从传统的各自为政转变为团结协作的团队。
质量门—速度的突破口
瀑布模型在每个阶段结束时进行质量检查，称为 “质量门 “或 “QA 门”。例如，软件发布需要质量保证团队在测试阶段结束时批准，这被称为质量保证签收流程。虽然质量保证签核的目的是好的，但在快节奏的开发环境中，它拖慢了工作进度。
成功拆除筒仓
从过去各自为政的团队转变为团队合作和业务成果带来了明显的好处。不过，该行业的其他一些因素也为成功做出了贡献。
- 增量和迭代开发的灵活性。
- 领域驱动设计对确定业务领域和边界背景的影响。
- 自主双比萨饼团队的效率。
- DevOps 运动的力量
- 服务所有权文化—你来建设，你来运营。
- 微服务的优势
- 接受事件驱动架构和分布式系统。
- 云运营模式的普及。
- 多技能团队 “能做 “的态度。
责任的转移
云技术的采用改变了许多人的心态。云计算运营模式的责任分担使团队能够将某些事情转移到右侧，将其他事情转移到左侧。
- 云提供商对其管理的平台和服务的责任。
- 在云中，消费者对其部署和运行的应用程序负责。
多技能自主团队看到了建立部署管道、实施安全措施、应用可持续发展原则的责任，也看到了他们的工作量在向左转移（向软件工程师转移）。
质量保证和测试如何？
除单元测试外，质量保证工程师或测试人员负责其他形式的测试。在瀑布式开发模式中，测试人员的职责是发现错误。随着敏捷和现代实践的发展，方法已经转变为预防错误。无服务器将改变更多事物！如果说传统的质量保证方法是发现错误，那么现代的方法就是防止错误。
无服务器与平衡广场
无服务器给软件开发带来了一些变化。作为一个技术生态系统，它需要转变思想，将产品视为事件驱动的管理服务协调，与基础设施代码编织在一起，从而带来最佳价值。
《AWS 上的无服务器开发》（O’Reilly，2024 年）建议企业组建多学科无服务器团队。多学科无服务器工程师能够理解利益相关者的需求，提出架构建议，实现单用途功能，组成微服务，纳入安全措施，采用可观察性，部署到生产中，并拥有自己的服务。
无服务器中的常见软件测试
作为标准，无服务器工程师会编写单元测试和必要的集成测试。那么其他类型的测试 —— 负载测试、性能测试、合同测试、验收测试、端到端测试等，如何呢？
负载测试很少见，但在特殊情况下存在。使用云和无服务器时，您需要使用专为高可用性和自动扩展而构建的服务。性能测试很重要，但在哪里进行测试以及如何进行测试取决于你的应用环境。
随着现代架构的发展，端到端测试的概念也发生了变化。在讨论无服务器测试时，AWS 上的无服务器开发提出了以下问题：分布式事件驱动系统是否有两个不同的目的？
无服务器平衡广场
将无服务器应用程序构建为多个独立的微服务是有正当理由的。但是，在构建事件驱动和分布式应用时，您不能指望不断测试所有内容。在《AWS 上的无服务器开发》中介绍的无服务器平衡方概念说明了四种关键活动：
- 测试
- 交货
- 观察
- 恢复
在无服务器开发中，充足而非过量的测试与可观察性机制和错误恢复相结合，对于增量开发和自信的快速周期发布至关重要。传统的方法是增加过多的测试，并采用精心设计的测试套件和框架来实现 100% 的测试覆盖率，这会对团队的工作速度造成不必要的延误。
无服务器团队中质量保证专家的作用
具备软件测试专业知识的质量保证工程师会编写测试策略、设计测试用例，并使用 Selenium 和 Cypress 等测试框架实施测试。但是，如果您的应用程序中没有需要专家和自动脚本检查的用户体验组件，您就不太可能使用重型测试框架。那么，你的无服务器团队需要测试框架技能吗？
无服务器团队应具备的测试技能
快速发展的无服务器后端团队中的工程师需要了解云、云上的大量服务、IaC 工具和相关主题。随着越来越多的团队使用真正的云服务进行测试，QA 工程师和无服务器工程师一样，需要很好地了解无服务器知识。但如果无服务器工程师和质量保证工程师原型之间的技能差距缩小了，这种分离是否有益？
并非所有业务逻辑都在功能代码中
在无服务器应用程序中，业务逻辑并非仅以函数的形式实现。服务编排、集成和基础架构也是其中的一部分。无服务器工程师负责功能代码的单元测试，而其他形式的测试则需要大量的云服务和基础设施知识。传统的质量保证专家往往缺乏这方面的知识。
API 测试如何？
并非所有无服务器团队都拥有 API。不过，API 测试是质量保证工程师经常关注的一个领域。API 测试并不需要由 QA 负责。无服务器团队中的每个人都应该能够执行这项任务。
此外，大多数团队都会在资源库中维护他们的 Postman（Katalon、HHTPie 或其他）集合，供每位工程师进行手动和自动测试。
从 QA 门到 PR 门
虽然现代团队都在实践持续交付（CD），但许多团队在工作方法上都陷入了 “公关门 “政策。无服务器工程师提出 PR（拉取请求）后，会等待 QA 工程师将更改部署到测试环境中并执行测试（大部分是手动测试），然后再批准，这样就会造成延迟。以上是在流行的精益工作价值流映射中，等待时间与增值时间的对比。
模糊的质量保证过程和责任
随着技术的进步和用户需求的提高，自主团队的工作方式也发生了变化。对速度的需求催生了自动化，这使得每天都能发布多次修复和功能。持续可观察性是自主团队运行工作负载的一部分。为了实现无服务器方阵的平衡，工程师们充当其应用程序的站点可靠性工程师（SRE）。
谁倡导无服务器测试实践？
关于无服务器应用程序的测试，众说纷纭：这样或那样、简单或复杂、本地或云、模拟或真实、金字塔或六边形。但是，您听说过或读过质量保证工程师或专家倡导的无服务器测试实践吗？为什么？
是因为测试无服务器应用程序更像是一项工程任务而非质量保证任务吗？还是因为无服务器尚未深入质量保证领域，尚未引起足够的重视？
目前还不清楚，但可以确定的是，后端无服务器团队（无论是否有常驻的质量保证工程师）的测试方法发生了变化。为什么我们没有听说过质量保证专家提倡的无服务器测试实践？
那么，你的无服务器团队需要 QA 吗？
选项如下：
A) 是的！
B) 没有！
C) 这要看情况！
D) 也许吧？
答案是 —— 以上皆是！
评估您的需求
- 你的无服务器团队是否拥有网络应用程序和用户界面或体验组件？如果是，你就需要测试专家专注于这些领域。
- 你的无服务器团队是否使用大型共享代码库？如果是，聘请专门的质量保证工程师是个好主意。
- 你的无服务器团队是否在共享云账户中运行工作负载？如果是，那么在测试方面获得额外帮助可能会很有用。
- 你的无服务器团队是否在边界不清晰的业务领域开展业务？如果是，就有必要通过额外的测试和质量措施来保护合同。
- 你的无服务器团队是否在高度受监管的环境中工作？如果是，你可能需要一位专家来确保合规性。
以上并非完整清单。由于不同团队和组织的用例、领域和技能各不相同，因此更多的是根据具体情况而定。
要有超前意识，成为变革的催化剂
本文的目的并不是提倡从所有无服务器团队中移除质量保证活动和专家。本文旨在探讨技术和开发的变化如何使我们能够重新评估现有实践。
一个尺寸并不适合所有人。如果你的团队是一个界限分明的 “两张披萨 “团队，团队中充满了充满激情、多才多艺、务实的无服务器工程师，他们可以操作自己的工作负载，了解无服务器的平衡方略，那么你就应该大胆地进行尝试。毕竟，想法和实验以及技术演变对于确定未来适当的发展实践和团队动力至关重要！
