长文详解PlatON测试Case全景图

原创 PlatON 

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

同时还要注意PlatON链本身包含公有链、私有链，不同类型在管理、用户身份、最大节点数等平台自身特征方面均有不同，测试需要考虑所有的模式，导致测试方案和场景也比常规的传统测试更加复杂。

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

| PlatON测试范围总览

从Case全景图可以看出，我们对PlatON的Case过程进行分类，主要是通过5个方面去验证系统保证安全可靠。

1. 初始化阶段

主要是通过在链初始化时，搭建私链或者链接主网时对经济模型中的合约账号、信息以及参数进行合理性的验证。

隐式初始化-不指定网络时链接PlatON主网络，这时候需要验证网络节点搭建成功之后链上信息和内置的信息保持一致。

显式初始化-搭建私链则是通过创世文件初始化的方式加入到特定的私有网络，成功加入链之后验证链上信息和配置的信息保持一致初始化参数。

共识参数-经济模型参数、治理参数、惩罚参数、奖励参数、增发参数。

初始化参数是通用的系统参数，参数分主网参数和自定义参数两类：

主网参数-通过在启动节点时增加命令参数来实现链接PlatON主网络，需要验证的就是链上共识参数、经济模型参数、治理参数等和主网参数保持一致。

自定义参数-在启动节点时，通过调整初始化创世文件里的初始化参数来实现自定义参数，然后通过链初始化启动节点，这时候链上的参数应该和创世文件中的参数保持一致。

但是这里需要注意的是自定义参数时，创世文件中数值阈值的调整需要合理，不同的参数组合最终会导致链启动成功与否以及链上运行的规则发生变化，我们的测试过程正是验证这些参数变动带来的各种边界值，以及参数是否给链的运行提供合理的标准。

2. 启动阶段

启动阶段测试我们分为两种模式进行验证，分别是单节点和集群，因为不同的节点数量链运行方式也会有所不同，我们从简单的结构出发，然后慢慢扩展数量，从而达到模拟真实环境。

| 单节点

• 启动节点 

• 查看节点信息 

• 查看版本信息 

• 链上功能

| 集群

• 快速参数集群 

• 主网集群 

• 链上功能

作为区块链运转的载体，所有的事情几乎都要节点参与，网络通信、逻辑运算、交易、数据验证等，而区块链一般是由多个节点组成协同工作，因此节点属性及对节点的管理至关重要。在实际管理中，节点能由管理者操作加入或者退出区块链网络，而不影响业务的正常运行，以及扩容新增节点。

在节点相关验证，主要包含了链部署时不同节点数量的情况下节点的运行情况检查，创世文件启动时不同的参数组合对链影响，如共识节点数量、治理参数配置、同步方式等，我们会根据不同的组合去验证配置参数的合理性，同时节点本身具备了不同的启动参数，在整个链运行的过程中需要对启动参数的调整来验证这些启动命令的有效性以及对链的影响。

同时还需要分别在单节点和集群模式下进行链上功能的验证，确保在不同模式下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模式进行验证，这时候我们需要考虑的是多交易在发送过程中记录在本地的区块信息是否有遗漏，同时在进行功能验证的时候可采用混沌模型测试，各业务场景进行组合，验证每个节点存储稳定且数据正确。

业务层

• 经济模型验证

PlatON的经济模型就是在链上进行各种会产生经济活动的场景组合，所有参与到经济活动的主体在互动时，都将伴随着Token的变化，针对不同的经济活动我们可以运用测试理论中的测试手段，如边界值、等价类、因果法、场景构建等方法进行验证，主要是活动主体的Token的数量进行校验。

01 锁仓

• 锁仓创建 

• 锁仓质押委托 

• 锁仓回退 

• 锁仓结算 

• 处罚通知….

02 Staking

• createStaking (质押) 

• editCandidate (修改候选人信息) 

• increaseStaking (增持质押) 

• withdrewStaking (撤销质押) 

• delegate (委托) 

• withdrewDelegate (撤销委托) 

• withdrawDelegateReward (领取奖励)

• getVerifierList (查询当前结算周期的验证人列表) 

• ElectNextVerifierList (选举下一个结算周期的验证人列表)激励 ……

03 激励

• 发放质押奖励 

• 发放出块奖励 

• 是否到达年末……

04 处罚

• 举报双签 

• 举报双出 

• 查询举报信息 

• 处罚规则……

在这个过程中，我们也会对节点排名、状态、节点的收益进行验证，针对不同的经济活动场景进行有效的组合，其中包括了节点的状态以及链的结算周期和共识周期的变化，根据不同的组合我们可以通过自动化的方式检查活动主体的Token数量和状态变化情况是否满足设计要求，从而验证了经济模型的合理性和正确性。

• 治理模型验证

PlatON治理模型主要是验证PlatON进行链上治理时，链上节点参与投票的进行更新或者修复的一个过程，在这个过程中节点的选择行为会影响到链上发展方向和链的一个状态，如果节点对治理的内容有分歧则会出现不同的结果，治理升级的验证主要是验证治理前后链上数据的一致性和区块的连续性。

01 提交提案

• 提交升级提案 

• 提交文本提案 

• 提交参数提案 

• 提交取消提案 ……

02 投票

• 有效提案投票 

• 无效提案投票 

• 放弃投票 

• 投票统计……

03 版本声明

• 有效的提案声明 

• 无效提案声明……

04 提案全流程

• 提交文本提案统计 

• 提交升级提案 

• 提交取消提案……

通过不同的结算周期、共识周期、投票节点状态的变化来验证治理机制的正确性。同时为了满足实际场景中的复杂运行环境，需要增加经济活动的场景来丰富可能出现的异常情况，从而验证整个治理模型的可靠性。

4. 稳定性

对于区块链底层的测试，不仅仅是前端API与某个区块链节点之间的测试，还涉及大量区块链节点与节点之间的测试。所以，如果只是单一地去做某个特性的测试，比如连接或者同步，同样条件，这次成功，下次可能就会失败，因为区块链是个分布式的系统软件，一个节点的正常不代表整个系统正常。

测试过程也需要融入分布式思想，而不能停留在中心化软件上。某个节点在同步，其他节点可能在共识，包括节点所在机器环境也可能随时发生变化，在场景模拟的过程，需要将软件、硬件以及区块链自身操作进行各种组合验证，区块链的边界比较模糊，而各种组合测试正好通过模拟现实运行的场景，让系统尽可能运行在边界处，就比如共识算法，多节点的网络，让其中部分正常运行，剩下的部分节点在正常的阈值内进程启停，进行场景模拟会更容易发现一些边界问题。所有场景模拟过程，持续运行测试，观察资源的消耗情况，从而找到系统的盲点。

5. 性能

作为一个底层平台，性能是一个很关键的指标，它决定了上层应用在高峰期能跑多少的业务量。一个系统中每个接口，每个功能特性都会涉及到性能，但并非都需要压出其性能。对于区块链来说，重点关注的是它处理交易的性能，从客户端发起交易、签名，到节点打包、共识，最后数据落盘，这一完整过程系统的性能。

任何一个性能数据背后都对应着软件和硬件配置组合的结果，包括CPU、内存、磁盘、带宽等硬件条件，以及压测的合约类型、交易大小，节点组网模式等因素都会影响性能结果。理论上，代码自己没有逻辑错误，只要配置跟上，性能是可以无限的。但实际生产条件肯定有个上限，因此压测的性能数据可以提供两份，生产常用的硬件及软件配置条件下的，和实验室里高配的硬件和软件时的性能数据。后续会再出一篇专门的性能文章，来讲解PlatON性能是如何提升上去的。

6. 扩展

• 合约编译及支持

合约的使用和管理对区块链是一个重要的评测标准。包括合约的部署方式是否简便，即能提供哪些语言支持的客户端或者中间件工具部署合约，以及发送交易。合约是否支持升级，升级后如何管理版本。除了合约本身的升级，区块链节点升级后，已经部署的老合约也应当能继续调用，兼容性都没问题。

PlatON提供对应的编译工具，为此我们也要对合约编译工具及本身合约版本进行验证，确保链上支持不同版本的合约语法。拿solidity语言来说，需要验证提供的各种变量类型、语法表达式、控制接口等合约结构，在链上是否都能跑通，包括能否跨合约调用链上的内置合约功能。

• 安全

区块链系统涉及的安全包括很多方面，从连接到共识、从算法到隐私保护，都和安全息息相关，安全措施覆盖得越全面，系统被攻击的概率越低，运行越稳健。区块链是由节点组成，而对于非法节点的加入，平台是否提供了证书网络准入机制或者黑白名单特性，解决非法连接和入网问题。链上大量的数据或者各种类型的表，需要提供权限管理机制给不同用户授予不同操作权限，包括部署合约及发送交易。