IPFS官方|顶尖测试平台Testground（试验场）正式启动

测试点对点（P2P）系统是非常困难的，如何可靠而且重复的测试就更加困难了。今天，我们向世界正式宣布启动Testground v0.5（试验场v0.5版本）。对于我们和整个p2p生态系统来说，这都是一个巨大的里程碑。本文将为你解释试验场是什么？还有如何使用，接下来要做什么以及试验场的背景情况。

如果你看了IPFS v0.5.0版本公告（IPFS官方 | 迄今为止最大的升级，0.5版本更新发布！），那么你肯定知道了Testground试验场这个项目。是我们工程工作的重要组成部分，在质量，速度和可靠性方面均有很大的改进。没有试验场，我们将无法进行大规模测试来验证v0.5.0中DHT和Bitswap的改动。

试验场在评估我们最新的libp2p gossipsub 1.1安全扩展时也是必不可少的。它允许我们模拟一系列的攻击，超过10k的实例集群，包含sybils和诚实节点，用pubsub消息攻击网络，记录每一个事件以供以后分析和比较(预计很快会有报告)。

建立有顶尖安全性的网络和系统，所需要的坚如磐石的测试平台。

当试验场从IPFS项目中完成时，我们就已经做了大量的准备工作来打包试验场，这样分布式系统和p2p社区就可以便捷的运行了。我们希望它能给我们带来一个巨大的飞跃，对于面向分布式未来的社区工程师、p2p和分布式系统来说。

什么是Testground试验场？

试验场是一个进行大规模测试、基准测试和模拟分布式和p2p系统的平台。它被设计成多语言和运行时不可知的，可以根据需要轻松的从2个实例扩展到10000个实例。

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

在试验场之前，分布式测试通常意味着部署大量守护进程。可以通过API公开每个内部组件、方法和配置参数，并通过外部脚本像操纵木偶一样对它们进行命令和控制。但是在试验场中，编写测试计划就像编写单元测试一样。

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

现在，可以在Go中编写测试计划。但是为另一种语言/运行时实现一个Testground SDK是非常简单的!事实上，社区正在为node和浏览器开发TypeScript SDK。

由于真正的去中心化系统受网络条件的支配，试验场可以通过翻转连通性、在运行时更改IP地址或设置延迟、抖动、带宽等来塑造网络流量。

由于不是所有的测试场景都需要数千个实例，所以可以将测试计划作为可执行文件或Docker容器在本地运行，从而节省开销、时间和成本，以便在需要扩展超过300个实例时使用集群部署。对于那些较大的情况，试验场支持开箱即用的Kubernetes。

为了说明上述问题，如果一个200个实例的测试试验。使用Kubernetes，将Docker映像发送到远程注册表、安排Kubernetes作业并等待工作负载启动可能需要1-2分钟。对于本地Docker运行程序，该开销为零，并且运行是即时的。这听起来并不多，但是开发人员知道这种延迟会极大地影响工作效率和工作流程。

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

开始运行

想要开始运行吗?试试以下步骤：

1.前往我们的文档入门部分。（https://docs.testground.ai/getting-started）

2.通读试验场背后的概念和架构。（https://docs.testground.ai/concepts-and-architecture）

3.确保在GitHub上查看testground/testground repo。（https://github.com/testground/testground）

4.查看一些示例测试。（https://github.com/testground/testground/tree/master/plans）

5.探索Testground SDK的参考godocs，将使用这个库来编写Testground测试计划。（https://pkg.go.dev/github.com/testground/sdk-go?tab=overview）

接下来会发生了什么?

试验场团队以灵活的双周冲刺为自己制定进度。

在接下来的几周里，我们计划通过增加代码库的测试覆盖率来巩固试验场的基础。我们称这一阶段测试试验场

在冲刺的最后，我们将推出试验场核心版本v0.7，它将作为我们计划开发的下一个特性的基础:

共享集群部署。

与GitHub紧密的持续集成

更好的基于矩阵的表单来可视化测试运行结果。

参与进来

试验场是一个开放的社区，我们所做的所有工作都是公开的。要了解团队在做什么，可以查看ZenHub面板，并检查各个里程碑的范围和进度。

ZenHub面板

如果你胆子比较大，并且愿意帮助编写一些代码，请查看标有“good first issue”的问题，以便开始编写!

如果遇到问题，请检查是否已经提出问题，或者在GitHub问题跟踪器上提出问题。

团队会很乐意听到大家如何在项目中使用试验场。通过Twitter @run_testground联系我们!

试验场是如何诞生的

几个月来，我们——IPFS和libp2p核心团队——一直在设计和讨论改进DHT性能的想法，保护我们的pubsub协议，并加速内容传输。

大多数讨论导致了实质性的重新设计建议，最终回到了这个百万美元的问题:

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

libp2p和IPFS项目的工程师倾向于采用科学的方法。我们阐明假设、收集证据、制定假设、推测设计，并通过基准测试和量化它们对系统的影响来重复提出的更改。

提出和合并影响核心子系统的请求并不是一件轻松的事情。我们努力采取坚实的步骤，不幸的是，我们缺乏这样做的工具，这减慢了我们的进程。

合并一个看似正常的补丁并导致副作用的风险是致命的。在微观层面上的单元测试和基准测试不足以在宏观层面(在复杂的网络拓扑结构中有数十万个节点)上预测或预测分散的结构化或非结构化网络的紧急行为的变化。

我们需要具备以下能力：

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

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

迭代变更集A和B，启动相同的测试计划来比较基线的结果。

测量网络对诸如用户流失和连接问题等情况的反应。

度量节点升级对整个网络健康状况的影响。

验证旧节点和升级节点有效地互操作(避免分区)。

模拟不同的网络条件，如IP地址变化、延迟、带宽等。

以一致的、可重复的方式完成所有这些工作。

我们寻找现有的工具来开启我们的进程，但却找不到一个能够让我们做到这一点的平台。所以我们建造了试验场。但我们不是从零开始，试验场站在开源巨人如Kubernetes、Docker和Redis的肩膀上建立的。我们以前也做过类似的实验，比如星际测试实验室(IPTB)。

从第一天开始，我们就认识到了试验场对于未来更大规模的分布式系统和p2p社区的价值。

尽管诞生于IPFS和libp2p项目，但试验场中没有任何东西依赖于libp2p或IPFS。不需要为了从试验场中获益而使用IPFS或libp2p来测试你的p2p网络(无论是分布式应用程序、区块链或其他p2p协议)!

我们希望试验场能够加速大家的开发和试验，就像它为我们所做的那样，并帮助你获得信心和保证，即便只是在不断地改进系统。

—-

编译者/作者：四块科技

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