本文发布已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
聚焦 SIG 测试
欢迎来到SIG 聚焦博客系列的另一期，我们将在此重点介绍 Kubernetes 项目中各个特别兴趣小组（SIG）所做的出色工作。在本期中，我们将关注 SIG 测试，该小组对 Kubernetes 的有效测试和自动化项目中的繁琐工作感兴趣。SIG 测试专注于创建和运行工具及基础设施，使社区更容易编写和运行测试，并贡献、分析和处理测试结果。
为了深入了解 SIG 测试，Sandipan Panda 与 Michelle Shepardson 进行了交谈，她是 Google 的高级软件工程师，也是 SIG 测试的主席；以及 Patrick Ohly，他是 Intel 的软件工程师和架构师，也是 SIG 测试的技术主管。
与贡献者见面
Sandipan： 您能简单介绍一下自己、您的角色以及您如何参与 Kubernetes 项目和 SIG 测试的吗？
Michelle： 嗨！我是 Michelle，是 Google 的高级软件工程师。我最初通过为 SIG 测试开发工具（例如 TestGrid 的外部实例）参与到 Kubernetes 中。我负责 TestGrid 和 Prow 的值班，现在是 SIG 的主席。
Patrick： 你好！我在 Intel 的一个团队中担任软件工程师和架构师，该团队专注于开源云原生项目。当我开始了解 Kubernetes 以开发存储驱动程序时，我的第一个问题是“如何在集群中对其进行测试以及如何记录信息？” 这种兴趣促成了各种增强提案，直到我（重新）编写了足够的代码，并且还接管了 SIG 测试技术主管（针对 E2E 框架）和结构化日志 WG 主管的官方角色。
测试实践和工具
Sandipan： 测试是一个存在多种方法和工具的领域；您是如何得出当前实践的？
Patrick： 我不能谈论早期的情况，因为我当时还没有加入 😆，但是回顾一些提交历史，很明显开发人员只是使用了可用的东西并开始使用它。对于 E2E 测试，那就是 Ginkgo+Gomega。一些技巧是必要的，例如在测试运行后进行清理和对测试进行分类。最终，这促成了 Ginkgo v2 和 修订后的 E2E 测试最佳实践。关于单元测试的观点差异很大：一些维护人员更喜欢只使用带有手写检查的 Go 标准库。其他人则使用像 stretchr/testify 这样的辅助包。这种多样性是可以接受的，因为单元测试是独立的 - 贡献者在处理许多不同领域时只需灵活一些。集成测试介于两者之间。它基于 Go 单元测试，但需要复杂的辅助包来启动 apiserver 和其他组件，然后运行更像 E2E 测试的测试。
SIG 测试拥有的子项目
Sandipan： SIG 测试非常多样化。您能简要概述一下 SIG 测试拥有的各个子项目吗？
Michelle： 广义上讲，我们有与测试框架和基础设施相关的子项目，尽管它们肯定会重叠。因此，对于前者，有 e2e-framework（外部使用）、test/e2e/framework（用于 Kubernetes 本身）和用于端到端测试的 kubetest2，以及 boskos（用于 e2e 测试的资源租赁）、KIND（Docker 中的 Kubernetes，用于本地测试和开发）以及 KIND 的云提供商。对于后者，有 Prow（基于 K8s 的 CI/CD 和聊天机器人），以及大量其他用于分类、分析、覆盖率、Prow/TestGrid 配置生成等工具和实用程序，这些都位于 test-infra 存储库中。
如果您愿意了解更多信息并参与 SIG 测试的任何子项目，请查看 SIG 测试 README。
主要挑战和成就
Sandipan： 您面临的主要挑战有哪些？
Michelle： Kubernetes 在各个方面都是一个庞大的项目，从贡献者到代码，再到用户等等。测试和基础设施必须满足这种规模，跟上 Kubernetes 下每个存储库的每一次更改，同时尽可能地促进项目的开发、改进和发布，当然，我们不是唯一参与其中的 SIG。我认为另一个挑战是为子项目配备人员。SIG 测试有许多子项目已经存在多年，但是许多最初的维护人员已经转移到其他领域，或者不再有时间维护它们。我们需要在这些子项目中培养长期的专业知识和所有者。
Patrick： 正如 Michelle 所说，庞大的规模可能是一个挑战。不仅仅是基础设施，我们的流程也必须随着贡献者的数量而扩展。记录最佳实践是好的，但还不够：我们有很多新的贡献者，这很好，但是让审阅者解释最佳实践是不可扩展的 - 假设审阅者甚至知道这些实践！现有代码不能立即更新也没有帮助，因为代码太多了，尤其是对于 E2E 测试。在接受现有代码未通过相同 linter 检查的情况下，对新代码或修改后的代码应用更严格的 linting 的举措有所帮助。
Sandipan： 您对 SIG 的哪些成就感到自豪并希望重点介绍？
Patrick： 我有偏见，因为我一直在推动这项工作，但我认为 E2E 框架和 linting 现在比以前好得多。我们可能很快就能够启用竞争检测来运行集成测试，这很重要，因为我们目前只对单元测试进行竞争检测，而单元测试往往不那么复杂。
Sandipan： 测试始终很重要，但是就 Kubernetes 发布过程而言，您的工作有什么特别之处吗？
Patrick： 测试不稳定... 如果我们有太多这种问题，开发速度就会下降，因为如果没有干净的测试运行，PR 就无法合并，而干净的测试运行变得不太可能。开发人员也会对测试失去信任，只是“重新测试”，直到他们获得干净的运行，而没有检查失败是否确实与他们当前更改中的回归有关。
人员和范围
Sandipan： 您最喜欢这个 SIG 的哪些方面？
Michelle： 当然是人员 🙂。除此之外，我喜欢 SIG 测试的广泛范围。我觉得即使是很小的更改也可以为其他贡献者带来很大的不同，而且即使我的兴趣随着时间的推移而改变，我也永远不会用完可以从事的项目。
Patrick： 我可以从事一些工作，使我和其他开发人员的生活变得更好，例如我们每天在其他地方开发新功能时必须使用的工具。
Sandipan： 您能告诉我们一些有趣/酷/今天我才知道的轶事吗？
Patrick： 我在五年前开始从事 E2E 框架增强工作，然后在那里活跃了一段时间。当我回来并想测试一些新的增强功能时，我问了如何为新代码编写单元测试，并且被指向了一些看起来有点熟悉的现有测试，就好像我以前见过它们一样。我查看了提交历史，发现我编写了它们！我让你决定这是否说明我长期记忆力衰退，或者仅仅是正常的……无论如何，伙计们，记住要写好的提交消息和注释；有人会在某个时候需要它们 - 甚至可能是你自己！
展望未来
Sandipan： 您的 SIG 需要哪些领域和/或子项目的帮助？
Michelle： 目前一些子项目没有配备人员，并且可以使用愿意更多了解它们的人。boskos 和 kubetest2 特别突出，因为两者对于测试都很重要，但缺乏专门的所有者。
Sandipan： SIG 测试的新贡献者可以带来哪些有用的技能？如果他们来自与编程没有直接联系的背景，他们可以做些什么来帮助这个 SIG？
Michelle： 我认为用户同理心、编写清晰的反馈和识别模式非常有用。可以使用测试框架或工具并且可以概述具有明确示例的痛点的人，或者可以识别项目中的更广泛问题并提取数据以告知解决方案的人。
Sandipan： SIG 测试的下一步是什么？
Patrick： 更严格的 linting 将很快成为新代码的强制要求。如果有人想承担这项工作，则可以对一些 E2E 框架子包进行现代化改造。我还看到了统一我们用于 E2E 和集成测试的一些辅助代码的机会，但这需要更多的思考和讨论。
Michelle： 我期待着为我们的一些工具和基础设施进行一些可用性改进，并支持更多的长期贡献以及贡献者在 SIG 内成长为长期角色。如果您有兴趣，请与我们联系！
展望未来，SIG 测试小组有着令人兴奋的计划。您可以通过他们的 Slack 频道 联系 SIG 测试小组的成员，或者参加他们每周二举行的 例会。如果您有兴趣让社区更容易运行测试并贡献测试结果，以确保 Kubernetes 在各种集群配置和云提供商中保持稳定，请立即加入 SIG 测试社区！