PlatON测试Case全景图：底层测试阶段

原创 ：PlatON

说PlatON测试之前，我们需要先了解下关于区块链测试和传统测试互联网测试的区别，其主要体现在系统边界模糊，对于区块链的测试不仅仅是前端API与某个区块链节点之间的测试，还涉及大量区块链节点与节点之间的测试。

现在我们可以来认识下PlatON，首先它不属于交易所类型的业务产品，而是于基于区块链的技术以及链技术产生的价值的生态基础服务，测试的重点也是不一样的。我们的测试会更加关注底层，比如共识算法、网络、存储、经济模型等。本篇内容将讲述链上功能测试中的底层测试。

3. 链上功能阶段

这个阶段也是PlatON主要的测试内容，这个阶段主要包含了对底层和业务层两个方面。

底层

• Giskard共识

正所谓「无共识，不区块」，作为区块链的核心属性，「共识机制」决定了区块链的安全性、 去中心化和可扩展性等重要性质，并且保证各共识节点对交易执行结果达成一致。

PlatON的Giskard共识协议由概率性权益证明PPoS(PlatON proof of stake)和Giskard拜占庭容错协议-Giskard BFT(Giskard Byzantine Fault Tolerance) 组成。PPoS使用质押、委托、随机选取的形式选出参与共识的验证节点，Giskard BFT使用类BFT算法实现区块的生产和验证。

针对Giskard共识我们设计了相应的验证场景来覆盖PlatON共识模块。

1. 从共识的不同阶段我们来验证每个阶段共识

• viewChange：对viewChange基本信息校验同时包含viewChange发起、收到等场景组合来验证正确性。 

• prepareBlock：对prepareBlock消息基本校验同时窗口期内viewChangeQC后发起的不同状态下的prepareBlock进行验证。 

• prepareVote：对prepareVote消息基本校验同时不同窗口期以及不同节点状态下的prepareVote进行验证。 

• VerifyQC：包含了viewChangQC和prepareQC，主要检测不同签名数量下场景验证。

2. 模拟拜占庭场景下共识模块的验证

• Giskard-非拜占庭场景：模拟参与节点在非拜占庭场景下共识模块各个阶段的验证。 

• Giskard-拜占庭场景：模拟参与节点在拜占庭场景双出、恶意等操作下共识模块各个阶段的验证。 

3. 异常场景下共识模块的验证 

• Giskard-节点启停：通过启停节点、间隔启停、节点恢复等操作来验证共识模块的完整性和连续性。 

• Giskard-消息丢失：模拟丢弃投票、prepareBlock等场景下验证共识消息传递的有效性。 

• Giskard-容错：通过构建超时、恶劣环境的运行稳定性场景来验证共识的容错性。

通过以上场景我们测试需要验证的是，这种共识机制能否按预期算法完成从交易触发到数据落块，以及在容错和容灾范围内依然正常工作。区块链平台上线前，对其使用的共识算法需要做严格的测试验证，涉及功能、安全、易用性等各方面。

• P2P网络验证

涉及到连接的地方主要有节点间P2P连接、节点与客户端的连接，以及链下机构间通过链上节点进行通信。通常在环境条件正常时，以上连接都能顺利进行，并且通过网络连接命令和日志信息能查询对应结果。而真正考验连接的健壮性是在异常环境下系统的应对能力，以及环境恢复正常之后，连接能否也恢复正常。

从而我们需要考虑从以下几个方向来验证p2p网络的安全性：

1. 节点数

不同的节点数量组合，可以验证网络通信中消息传递所需要的时间是否满足以及消息传递过程中是否出现遗漏和丢失。

2. 网络流量

监控网络流量，则是为了验证在一个链运行过程中的各种业务功能和节点操作时，链上资源消耗情况是否能达到预期的要求，避免出现运行过程中异常流量的产生导致链出现无法共识的情况。

3. 节点发现

通过配置种子节点数、静态节点数来验证节点在互联过程中静态节点连接数限制，主动链接数限制、被动链接数限制是否生效，模拟在不同级别的数量节点配置情况下链的运行是否稳定。

发送到节点的交易，应当能同步到网络中其他节点。不同的区块链平台，根据节点的类型、组网模式，会采用不同的同步逻辑。区块同步涉及场景较多，新入网节点、进程停止一段时间在重启、节点遭遇故障导致数据丢失等，都会触发区块同步逻辑，以及在没有交易处理时，节点间也会保持状态的同步，以上都涉及到很多的同步场景，在测试中需对每一个场景设计详细、全面的验证过程，包括一些场景的交叉测试。

• 区块存储验证

区块存储功能的验证主要还是稳定性和正确性，在落块成功的基础上还要保证节点之间数据都一致。

每个节点根据不同节点启动策略部署的数据存储的信息能有效且准确的保留信息，一般我们会根据启动参数以及同步模式的不同采取fast或者full模式进行验证，这时候我们需要考虑的是多交易在发送过程中记录在本地的区块信息是否有遗漏，同时在进行功能验证的时候可采用混沌模型测试，各业务场景进行组合，验证每个节点存储稳定且数据正确。