Filecoin官方发布：Testgroundv0.5

测试点对点（p2p）系统非常困难。可靠且可重复地这样做更加困难。今天，我们向世界发布了 Testground v0.5。对于我们以及更广泛的p2p生态系统而言，这是一个巨大的里程碑。

在这篇文章中，我们将带您了解 Testground 是什么，如何入门，接下来要做什么以及 Testground 本身的背景知识。

如果您遵循 IPFS v0.5.0 发行公告，则将听说有关 Testground 的信息。这是我们工程工作的重要组成部分，并实现了质量，速度和可靠性方面的重大改进。没有 Testground，我们将无法大规模测量，迭代和验证 v0.5.0 中 DHT 和 Bitswap 的巨大改进。

在评估我们最新的 libp2p gossipsub 1.1 安全扩展中， Testground 也是必不可少的。它使我们能够模拟一系列攻击，超过 1 万个实例集群，塞满了 sybil 和诚实节点，用 pubsub 消息重击网络，记录每个事件以便以后进行分析和比较（很快会收到报告）。

建立防弹，不可阻挡的网络和系统的雄心勃勃的使命需要坚如磐石的测试平台。

作为 Testground 从 IPFS 项目的孵化舒适的窝毕业生，我们已经做跑腿的大量包装 Testground，使其对分布式系统和 P2P 社区简单旗开得胜。我们希望它为我们（作为一个社区）为分散的未来设计 p2p 和分布式系统的方式带来巨大的飞跃。

什么是 Testground？

Testground 是用于大规模测试，基准测试和模拟分布式和 p2p 系统的平台。它被设计为多语言且与运行时无关，可根据需要从 2 个实例优雅扩展到 10k 个实例。

Testground 旨在支持各种测试工作流程，例如实验/迭代开发，A/B 测试，向后/向前兼容性测试，互操作性测试和 CI 工作流程。

在 Testground 之前，分布式测试曾经暗示着部署守护进程。您将通过 API 公开每个单独的内部组件，方法和配置参数，并通过充当伪装者的外部脚本来命令和控制它们。但是在 Testground 中，编写测试计划就像编写单元测试一样。

我们听说，Testground 方法对开发人员而言非常自然。为什么？因为测试计划直接调用您的内部 API，并且它们利用分布式同步 API 与参与测试运行的其他实例进行协调。因此，测试用例变成遵循精确编排的分布式状态机。

目前，您可以在 Go 中编写测试计划。但是为另一种语言/运行时实现 Testground SDK 实在是太简单了！实际上，该社区正在利用针对节点和浏览器的 TypeScript SDK。

由于真正的分散式系统受网络状况的影响，因此 Testground 可以通过翻转连接，在运行时更改 IP 地址或设置延迟，抖动，带宽等来影响网络流量。

而且，由于并非所有测试方案都需要数千个实例，因此您可以在本地将测试计划作为可执行文件或 Docker 容器运行，从而在需要扩展到约 300 个以上实例时节省了诉诸集群部署的开销，时间和成本。对于较大的情况，Testground 开箱即用地支持 Kubernetes。

为了说明上述内容，请考虑一个 200 实例的测试运行。使用 Kubernetes，可能需要 1-2 分钟才能将 Docker 映像运送到远程注册表，安排 Kubernetes 作业并等待工作负载开始。使用本地 Docker 运行程序，该开销为零，并且运行是立即的。听起来似乎并不多，但是开发人员知道由于一千次削减（或上下文切换）而导致的死亡，这种延迟对一个人的生产力和工作流程造成了影响。

最重要的是观察管道（实验性的）。测试计划可以记录有关被测系统的原始数据点或汇总指标（直方图，EWMA，计数器等），并发出任意输出资产。Testground 平台将收获它们并将其用于一站式收集。

架构图，侧重于测试计划的输入和输出，突出了可观察性管道的电路

入门指南

想跑步吗？请尝试以下操作：

转至我们文档的入门部分。

通读 Testground 背后的概念和体系结构。

确保检查 GitHub 上的 testground/testground 回购。

看看一些示例测试计划。

探索 Testground SDK 的参考 godocs，该库将用于编写 Testground 测试计划。

接下来会发生什么？

Testground 团队每两周进行一次灵活的冲刺。

在接下来的几周中，我们计划通过扩大整个代码库的测试覆盖率来巩固 Testground 的基础。我们亲切地称此阶段为“测试试验场”

在该 sprint 的尾端，我们将生成 v0.7 的 Testground Core，它将用作我们计划开发的下一个

功能的管道：

分时群集部署。

与 GitHub 紧密集成（以便开发人员可以@mention Testground 并自动测试其 PR）。

更好的基于矩阵的形式以可视化测试运行结果。

不用说，欢迎您随时介入！继续阅读以了解操作方法。

加入进来

Testground 是一个开放的社区，我们所做的所有工作都是公开的。要了解团队正在做什么，您可以查看 ZenHub 董事会，并检查各个里程碑的范围和进度。

如果您喜欢冒险，并愿意帮忙编写一些代码，请查看标有“good first issue”标签的问题，以开始使用！

如果遇到问题，请检查问题是否已经提出，或者通过GitHub问题跟踪器随意提出。

团队很想听听您在项目中如何使用 Testground。通过 Twitter 在@run_testground 上伸出手！

背景：Testground 如何打造

几个月以来，我们（IPFS和libp2p核心团队）一直在设计和讨论想法，以提高 DHT 的性能，保护我们的 pubsub 协议并加快内容传输。

多数讨论导致了实质性的重新设计提案，最终又回到了百万美元的问题：

我们如何在不影响实时网络的情况下进行测试？

libp2p 和 IPFS 项目的工程师倾向于采用科学方法。这是我们的 DNA。我们阐明假设，收集证据，提出假设，对设计进行推测，并通过基准测试和量化其对系统的影响来对建议的更改进行迭代。

提出和合并影响核心子系统的请求请求并不是一件容易的事。我们努力采取坚实的步骤。不幸的是，我们缺乏能够做到这一点的工具，这正在减缓我们的进展。我们知道，它燃烧了。

合并看似健全的补丁并引起副作用或退化的风险正在恶化。微观级别的单元测试和基准测试不足以预测或预测宏观级别的分散式结构化或非结构化网络（在复杂的网络拓扑中有成千上万个节点）的突发行为的变化。

我们需要具备以下能力：

在数千个节点的专用网络上启动测试工作负载。

行使任意的提交或分支以获取有关其行为的指标。

对变更集 A 和 B 进行迭代，启动相同的测试计划，以将结果与基准进行比较。

衡量网络对客户流失和连接问题等情况的反应。

测量节点升级对整体网络运行状况的影响。

验证旧节点和升级后的节点可以有效地互操作（避免分区）。

模拟变化的网络状况，例如 IP 地址更改，延迟，带宽等。

以一致，可复制的方式进行所有这些操作。

我们寻找现有的工具来释放我们的进度，但是找不到能够使我们做到这一点的平台。因此，我们建立了 Testground。但是我们不是从零开始。Testground 站在 Kubernetes，Docker 和 Redis 等 OSS 巨头的肩膀上。我们之前也曾进行过实验，例如 InterPlanetary TestLab（IPTB）可以学习并进行迭代。

从零日开始，我们意识到 Testground 对于更大的分布式系统和 p2p 社区的价值。因此，我们从一开始就使其与项目无关。

尽管是从 IPFS 和 libp2p 项目中诞生的，但 Testground 中的任何内容都不取决于 libp2p 或 IPFS：总的零导入量。您不必使用 IPFS 或 libp2p 即可从Testground中受益，以测试您的 p2p 网络（无论是 dapp，区块链还是其他 p2p 协议）！

我们希望 Testground 能够像对我们一样为您加速开发和试验，并帮助您获得信心和放心，您仅在改进系统，提交后提交，PR 后 PR，发布后释放。

End

非常感谢您对 IPFS&Filecoin 项目的持续支持。我们很高兴继续与您一起，为人类信息建立一个强大的，去中心化和高效的基础。

FilCloud 帮你迅速了解 IPFS 领域的热点技术和应用

公众号：filcloud

—-

编译者/作者：FilCloud

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。