一个完整、高效的测试框架对于区块链系统意味着什么？

区块链测试是确保整个区块链系统中缺陷被消除的关键环节。

 

在大数据时代，测试用例量非常庞大，仅仅只依靠人工测试，无法不能保证测试效率和质量，所以必须要借助于非人工手段来实现。自动化测试将自动化工具和技术应用于软件测试，旨在减少测试工作，更快，更经济地验证软件质量。有助于以更少的工作量构建质量更好的软件。

 

在CPChain系统开发过程中，通过Jenkins部署自动化测试服务器，并使用Jepsen作为模拟测试用例框架实现自动化测试，这也是CPChain持续集成工作流的基础。

 

本文将从在以几个下部分介绍CPChain测试框架，具体详情可查看CPChain文档（https://docs.cpchain.io/test/test-overview.html）。

 

 

测试类型

 

白盒测试

白盒测试主要用于检查区块链的内部功能和结构，白盒测试包含三个级别：单元，集成和回归测试。

 

单元测试

单元测试由Go语言编写并附带区块链代码，所有单元测试文件均以-test.go结尾。每个单元测试文件都包含数个测试函数，用于给定输入的情况下，与预定输出对比，检查其功能。此外，单元测试还包括对Fusion API和RPC API功能测试。

 

集成测试

在CPChain中，一部分Go文件引用并集成了多个文件，用于实现更高层的功能，对于这部分文件有必要通过相应的测试文件进行集成测试。

 

回归测试

当远端代码仓库某个分支更新时，Jenkins将激活所有测试文件进行回归测试。重新执行单元和集成测试，以确保现有代码不出错。

 

黑盒测试

黑盒测试指的是在不了解内部实现的情况下检查区块链系统的功能。在黑盒测试中，会列出测试用例列表以检查系统是否正常工作。每个测试用例包含三个部分：

场景：简要描述用例；

步骤：如何重现用例；

预期结果：一个正常的链，在执行完上述步骤后的预期结果是什么。

 

异常共识测试用例

共识是区块链的核心。当验证者和出块者面临拜占庭错误时，需要确保链的安全性和一致性。因此，CPChain设计了大量关于LBFT 2.0共识的测试用例（包括异常和正常测试用例）以测试链的功能。对于每个可能的异常情景，如面对非法行为的应对，均设计一种输入及其预期输出来模拟该情况。该测试用例采用Jepsen框架实现。

 

稳定性测试用例

稳定性测试内容包括启动、重新启动和终止引导节点、出块者、验证者、普通节点和智能合约管理员等，提供了CPChain主网在停电，连接错误等极端情况下的稳定性证明。

 

挖矿测试用例

该测试用例主要用于检测节点出块并广播这一过程。主要分为以下几种类型：

出块节点：包含策划的测试用例，其中出块者执行不同的行为。

竞选：检查竞选日志、api、候选人列表和智能合约。

RNode：确保在不同条件下参与的RNode是没有问题的。

奖励：保证正确计算和分配基本和维护奖励。

准入控制：确保为最小CPU容量设置的阈值按预期工作。

验证者：测试验证者合约和域的有效性。

启动和停止：通过多次中止和重新启动链进行稳健性测试。

 

Nemesis测试用例

Nemesis项目是为了开发一个UNIX/Linux系统是基于命令行，方便人们使用的IP栈，它可以自定义数据包、插入数据包、进行协议攻击等，是一个很好的测试防火墙、路由器和其他网络设备的工具。目前主要利用Jepsen Nemesis来模拟一些系统异常情况，如：网络包延迟、网络断连、节点崩坏、时间漂移（错误的本地时间）。

 

兼容性测试用例

兼容性是所有去中心化系统都必须面对的重大挑战，并非所有节点都会随时保持系统更新。类似于比特币系统的软分叉与硬分叉，CPChain也有软更新与硬更新。在软更新中，仍处于旧版本的节点依旧能参与出块节点竞选。硬更新中，处于旧版本的节点将不能参与出块节点竞选，甚至不能同步整条链的出块记录。

保证了区块链与所有最新版本的节点不会受到旧版本节点的影响。

 

压力测试用例

压力测试通过提高交易量，测试CPChain主网所能达到的吞吐上限。压力测试主要分成不同类型：

• 以接近主网tps上限的速率发送交易数据，持续测试CPChain主网在该压力状态下交易处理的稳定性；

• 以超过主网tps上限的速率发送交易数据，持续测试CPChain主链是否会发生崩溃，以及超过上限的交易是否会顺延到未来的区块。

 

DDoS攻击防护

DDoS攻击，即分布式拒绝服务（Distributed Denial of Service）攻击，是所有分布式系统都会遇到的问题。近十年来，DDoS攻击规模迅速飙升。2016年，美国域名服务提供商Dyn公司遭受大规模的DDoS攻击，导致大半个美国的网络服务瘫痪，多个知名公司服务受到影响。DDoS的攻击形式往往是通过操纵多台服务器，联合对一个或多个重要目标进行大量的服务请求，完全占据目标的计算资源或者带宽，最终使目标原有功能完全瘫痪，最终停止提供服务。

 

在CPChain上，验证节点可能成为DDoS攻击潜在目标，面对DDoS攻击，我们采取如下对策：

• 设立多台默认出块节点，作为备选方案；

• 验证节点设立一个白名单，其中包含了所有默认出块节点；

• 每台验证节点上设立一个检测器。一旦发现CPU长时间超负荷运转，就会默认自己遭受DDoS攻击，启动白名单，在防火墙的层级上拒绝除默认出块节点以外所有节点；

• 当满足以下任一条件时，移除白名单：

  a.一段时间内不再检测到DDoS攻击；

  b.连续长时间开启白名单；

  c.手动进行解除。

 

形式化验证

当前，形式化验证（formal specification）已经应用于金融、军事、航空航天等高新技术领域，例如 NASA 的 Mars Rover 项目等。与人工审计不同，形式化验证可以大规模检查整个代码逻辑，并在数学层面确保程序运行符合设计规范。通过对代码进行严格而完整的数学推理验证，软件验证并不能证明一段代码是否存在缺陷，数学上是否完备。形式验证通过一定的形式或者规范，在更高的层次上描述一个程序，从而判断数学上是否正确。形式验证在高度并行的程序上尤为重要，死锁与竞争危害都是并行程序上必须考虑的重要问题。

 

为了进一步确保CPChain代码的正确性与完整性，CPChain技术团队对DPoR共识机制及LBFT2.0共识算法进行了形式化验证，其中采用TLA+形式验证语言，确保算法正确性。

 

 

测试环境

 

不同环境下，CPChain主网有着不同性能，主要有两个性能值得尤为关注，分别是公共环境与受控环境。

 

公共环境

公共环境是指在实际公开网络环境下运行。它具有以下的特点：

• 节点分布在世界各地；

• 每个节点都有着截然不同的硬件与网络配置；

• 每个节点都由不同的用户操作，其中绝大部分用户对链的实现并不熟悉；

• 不是所有的节点都更新到最新版本。

 

其中，验证节点为CPChain布置，且配置相同：

虚拟服务器类型：亚马逊云计算服务（AWS）t2.large模组；

网络：1 Gps（预估值）；

地点：新加坡；

处理器：3.0GHz英特尔可扩展处理器，两个虚拟处理器；

内存：8GB；

数量：共计7台服务器；

 

在该配置下，CPChain团队在2019年5月1日-6月5日进行了一次Beta测试。遍布全球795个普通节点，70个荣誉节点以及分布在新加坡的7个验证节点参与本次测试。

 

最终，Beta主链产生70万个区块（其中包括Beta测试期间生成的近30万个块），440万笔交易，交易峰值可达每秒1000笔交易。

 

受控环境

受控环境指的是一个受控的网络仿真运行环境。它具有以下特点：

• 所有的节点分布在多台内网服务器，或者是由一台服务器发起的多个线程；

• 各个节点之间的带宽可认为是无穷大，或者逼近网线极限；

• 所有节点均更新至最新版本；

• 所有节点拥有完全一致的本地时间。

 

在该条件下，CPChain主链在1000-10000TPS情形下均能稳定运行。

 

 

结语

 

主网的安全性与稳定性，对于每一个参与到CPChain生态的节点用户而言至关重要，每一个微不足道的系统漏洞都有可能对节点用户造成重大的链上财产损失，对整个CPChain生态造成不可逆转的伤害。

 

一直以来，CPChain团队对主网测试都格外重视。本期我们列举了CPChain主网测试的测试类型以及在不同测试环境下的测试表现，希望大家对于CPChain系统的安全性和稳定性有一个更加直观的了解和认识。除了完善自身的测试案例之外，在主网上线之初，我们还联系了专业代码审计机构，对主网代码进行审计，以提高整个主网的安全度。