应用测试

1.2节点管理

节点能由管理者操作加入或者退出区块链网络，而不影响业务的正常运行，以及扩容新增节点。长期使用的软件，一般都会迭代更新，区块链节点也应能够进行升级，包括灰度升级能力，升级后业务正常运行。

1.2连接

通常在环境条件正常时，以上连接都能顺利进行，并且通过网络连接命令和日志信息能查询对应结果。

而真正考验连接的健壮性是在异常环境下系统的应对能力，以及环境恢复正常之后，连接能否也恢复正常，而不用去重启进程。

影响连接的因素包括区块链系统本身和外部环境对连接的影响：

区块链系统本身：节点（SDK）证书合法性、黑白名单等

外部环境对连接的影响：节点所在的服务器断连、网络的闪断或者带宽偏低、端口及网卡故障，以及CPU、内存的使用过高，甚至是机器重启导致进程重启。 

1.3共识

我们需要验证的是，这种共识机制能否按预期算法完成从交易触发到数据落盘，以及在容错和容灾范围内依然正常工作。实际上就是在共识的某个阶段遇到问题，它的应对机制是否可行，而不是卡在那或者直接系统崩溃。区块链平台上线前，对其使用的共识算法需要做严格的测试验证，涉及功能、安全、易用性等各方面。

功能方面，在系统正常运行，无故障、无欺诈节点时，能正确共识，各节点数据能一致。 

在测试共识算法前，需要清楚共识内部主要流程，才能对每一步骤构造场景进行相应测试。

安全方面，平台也要有相应处理机制，比如：共识过程某节点把交易篡改了，网络中其他节点能识别该欺诈节点信息并做相应处理。共识算法在应对这类故障时，应具备容错能力，保证故障节点数少于理论值区块链系统还能正常共识。

在复杂的多群组架构中，一个记账节点可能会同时属于多个群组，系统需要保证节点在不同群组能独立共识独立存储。

1.4智能合约

平台支持的合约语言丰富：通用的solidity合约、预编译合约

合约的使用和管理：

包括合约的部署方式是否简便，即能提供哪些语言支持的客户端或者中间件工具部署合约，以及发送交易。 合约是否支持升级，升级后如何管理版本。

除了合约本身的升级，区块链节点升级后，已经部署的老合约也应当能继续调用，兼容性都没问题，正常发送交易。

合约的功能点验证（solidity语言）：

需要验证提供的各种变量类型、语法表达式、控制接口等合约结构，在区块链平台是否都能跑通。

某些安全场景下，能否冻结或者销毁合约，使之不能再被调用执行，在需要使用时，又能解冻

1.5同步

交易同步：连接正常时，客户端发送到节点的交易，应当能同步到网络中其他节点。

状态同步：在没有交易处理时，节点间也会保持状态的同步。

区块同步：区块同步涉及场景较多，新入网节点、进程停止一段时间在重启、节点遭遇故障导致数据丢失等，都会触发区块同步逻辑。

1.6存储

可以从账户状态和存储介质对区块链的存储进行功能正确性和稳定性测试。可以将账户状态模型和存储介质引擎进行组合测试。

账户状态对应着合约局部变量的状态存储形式，根据平台提供的选择，配置成默克尔树结构或者分布式存储的世界状态模型，来进行相应的测试验证。

而对于存储介质的选择，主要看区块链平台提供了哪些存储驱动，常见的leveldb、rocksdb、mysql。 可采用混沌模型测试，各场景进行组合，验证每个节点存储稳定且数据正确，在落盘成功的基础上还要保证节点间数据都一致。

1.7兼容

在区块链系统中，兼容性主要考虑两大块，自身兼容和周边兼容。

自身兼容：在完成一次区块链版本升级后，链上历史数据是否还能正常使用，包括各种业务操作以及历史功能特性都能正常运行；

周边兼容：需要考虑周边组件和工具等配套，甚至一些版本的对应关系。

还需考虑灰度升级的情况，即节点有新老版本共存这种模式下需要测试验证的场景会较多，所有的功能特性在新老节点上都应操作验证一遍。

1.8接口

接口的测试重点在输入稳定输出正确，多关注边界，外部对节点的访问能持续不断连。

接口测试采用自动化是比较简单的，同时模拟接口在一定压力访问下，客户端对节点发送交易，链上共识能否保持正常。

1.9数据治理

常见的治理方式有数据导出、数据导入、数据裁剪等。

数据导出：整个过程主要关注导出数据的正确性，是否和链上的数据一致，以及数据缺失、重复和覆盖等现象

数据导入：对数据导入特性的验证，重点是数据被导入后新节点功能的完整性，也就是网络中老节点具有的特性，新节点也完全一致，打包、执行交易、同步等功能都正常。

数据裁剪：数据裁剪后所有上层业务需保证继续正常运行，包括已部署的合约业务和新部署的合约，都能正常调用，同时节点自身的退网、入网、同步、兼容性等各种特性都不受影响。

被裁剪的数据虽然不在链上，但链上业务运行过程还是可能会用到，因此涉及到这部分数据的测试场景也需要全覆盖验证。

对于区块链来说，重点关注的是它处理交易的性能，从客户端发起交易，签名，到节点打包、共识，最后数据落盘，这一完整过程系统的性能。

性能压测可以达到两个目的，一是压出系统的性能，还一个是通过压测发现代码的一些bug，比如cpu、内存等硬件没有发现瓶颈，但是性能确一直上不去，这可能就是代码实现的逻辑有问题了。在性能数据基础上，继续加大交易并发量，就能对系统做进行压力测试，验证其他指标。在性能数据基础上，适当减少交易并发量，也能对系统进行稳定性测试。

对于不同的性能指标，几点思考：

延迟：P2P系统中都是虚拟链接，实际路由可能每次都不一样。

共识率：系统中设定一些节点，故意篡改释放假数据，看是否成功。

吞吐率：检查矿工的效率，即整个系统每秒的有效交易数。

目前性能评测中，常见的是脱离网络规模和区块大小谈每秒交易数（TPS）： 实际中，网络规模越大，需要达成共识的节点越多，达成共识的进度，越慢，吞吐量（TPS）就越低。

区块越大，可扩展性越大，吞吐量可能发生抖动，大概率是变低。

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

而对于加密算法，需要考虑能否支持国密算法，以及在隐私保护中，同态加密和群环签名是都具备。落盘数据能否进行加密，而不影响系统的正常运行，包括在多群组中，数据是否隔离等，以上都是作为一个区块链底层平台需要覆盖到的安全措施。

在区块链质量体系的构建过程中，可靠性是最重要的内容之一，需要投入大量的资源去模拟各种可能的场景，完成可靠性验证。

因为区块链是个分布式的系统软件，一个节点的正常不代表整个系统正常。​ 既然是一个分布式的软件，测试过程也需要融入分布式思想，而不能停留在中心化软件上。某个节点在同步，其他节点可能在共识，包括节点所在机器环境也可能随时发生变化，在场景模拟的过程，需要将软件、硬件以及区块链自身操作进行各种组合验证，称为混沌测试。

常用的混沌测试工具有操作系统自带的iptables、tc、 wondershaper 等，可用于模拟机器间连接、端口是否可用、丢包、带宽控制，或者使用开源工具ChaosBlade也能完成以上模拟，包括cpu、内存等使用率。在结合前面章节讨论的节点连接、共识、同步等特性测试方法，进行各种混合测试。区块链的边界比较模糊，而混沌测试法正是通过模拟的方式，让系统尽可能运行在边界处，就比如PBFT共识算法，四节点的网络，让其中三个正常运行，剩下的一个节点进程停止，比同时让四个节点都正常跑着，进行场景模拟会更容易发现一些边界问题。所有场景模拟过程，可同时进行一些压力测试，保证时刻有交易在链上处理。