pbft_LIB_upgrade_test_case

ID	升级合约阶段	场景描述	测试功能	具体测试操作	预期结果
1	升级前	节点都升级到；docker-version: >= eosiosg/pbft: bos-v0.11.0, commit: >= 52208ea3	节点都升级到成功以后，开启压力和频繁投票；	投票，让BP持续轮换出块, 加压200 TPS, 持续半小时	1.节点正常运行2. 节点RAM、CPU正常3. LIB正常
2			测试snapshot	1. 生成一个snapshot 2. 用这个snapshot恢复nodeos	snapshot恢复节点成功
3			replay blockchain		replay节点成功
4			使用hard-replay-blockchain操作重新同步数据		节点能够正常同步，lib也正常
5			使用--delete-all-blocks并且重新同步数据		节点能够正常同步，lib也正常
6			正常重新启动		节点能够正常同步，lib也正常
7			随机数功能测试	升级随机数合约actiondemo	随机数正常
8			升级前的容灾恢复, 测试f个bp down和恢复	可用BP从大于2/3 * n + 1减小到小于2/3 * n + 1再恢复到大于2/3 * n + 1	LIB正常-->停止-->恢复正常
9			网络分片测试	网络原因，导致bp各自组成网络，从大于2/3 * n + 1减小到小于2/3 * n + 1再恢复到大于2/3 * n + 1 调整集群域名导致一些不能通信	LIB正常-->停止-->恢复正常
10			备选节点，如果未升级，待整个网络升级后，可以用升级版本进行同步	升级剩余节点	1.节点正常运行,同步到最新高度
11	升级中	部署合约，并设置一个目标高度, block_num > head + 100	节点都升级到成功以后，开启压力和频繁投票；	投票，让BP持续轮换出块, 压力200 TPS, 持续15分钟	1.节点正常运行2. 节点RAM、CPU正常3. LIB正常
12			升级前的容灾恢复, 测试f+1个bp down和恢复	可用BP从大于2/3 * n + 1减小到小于2/3 * n + 1再恢复到大于2/3 * n + 1	LIB正常-->停止-->恢复正常
13			网络分片测试	网络原因，导致bp各自组成网络，从大于2/3 * n + 1减小到小于2/3 * n + 1再恢复到大于2/3 * n + 1 调整集群域名导致一些不能通信	LIB正常-->停止-->恢复正常
14			测试snapshot	1. 生成一个snapshot 2. 用最新版本用这个snapshot恢复	snapshot恢复节点成功
15			replay blockchain		replay节点成功
16			随机数功能测试	升级随机数合约actiondemo	随机数功能正常
17			多次更新升级目标高度	重复set target blcok number	到达最高设置的target_block_number, 升级成功
18	准备完成升级	抵达目标高度附近，准备完成升级	21个BP可用，LIB正常	保证active BP alive，完成升级	1. 共识切换成功2. 21个bp可以正常出块3. 节点RAM\CPU指标正常
19			至少2/3 *n + 1个bp可用	down掉 f 个bp节点	1. 共识切换成功2. bp可以正常出块3. 节点RAM\CPU指标正常
20			小于2/3 *n + 1个BP可用，head超过目标高度，然后恢复2/3 *n + 1个BP可用，可以完成升级；	1. 举例目标高度还有3min时，将active BP数量小于2/3 *n + 1 2. 等待head超过目标高度180块 3. 恢复BP数量 >= 2/3 * n + 1, 能够达成共识 4. 重新设置新的target_block_number	1. 共识切换成功2. bp可以正常出块3. 节点RAM\CPU指标正常
21			网络分片测试	网络原因，导致bp各自组成网络，从大于2/3 * n + 1减小到小于2/3 * n + 1再恢复到大于2/3 * n + 1 调整集群域名导致一些不能通信	LIB正常-->停止-->恢复正常
22			测试snapshot	1. 生成一个snapshot 2. 用最新版本用这个snapshot恢复	snapshot恢复节点成功
23			replay blockchain		replay节点成功
24			随机数功能测试	升级随机数合约actiondemo	随机数功能正常
25	升级完成后	完成升级	升级后的稳定性测试	投票，让BP持续轮换出块, 加压200 TPS, 持续三天	1.节点正常运行2. 节点RAM、CPU正常3. LIB正常""
26			测试snapshot	1. 生成一个snapshot 2. 用最新版本用这个snapshot恢复	snapshot恢复节点成功
27			replay blockchain		replay节点成功
28			随机数功能和x01的checkpoint信息正常	1. 升级随机数合约actiondemo 2. 持续进行随机数压测	x01 对应block随机数和checkpoint数据正确
29			使用hard-replay-blockchain、replay-blockchain操作重新同步数据		恢复节点成功
30			使用--delete-all-blocks并且重新同步数据		恢复节点成功
31			正常重新启动		恢复节点成功
32			共识可以达成, 网络消息观察测试	开启logging.json, ,active bp不低于2/3 * n + 1,	lib可以稳定提升, lscb同步正常, 观察各个节点的收发prepare, commit, checkpoint消息是否正常
33			view change过程网络消息传递是否正常	开启logging.json, ,active bp down掉f + 1个	target_view提升, new_view可以apply, 观察各个节点的收发view change, new view, checkpoint消息是否正常
34			长时间不能达成共识, 整个网络的恢复	down掉f + 1 个 active bp, 持续加压, 投票, 网络不能达成共识, target view一直在增加, 半小时后重启1个down掉的active bp	apply new view成功, lib前进, view change结束, lscb和lib重新前进
35			压力测试	持续加压1000 TPS, 投票, 频繁发生switch fork, 持续一周的时间	观测issue 10是否有修复成功
36			CPU profiling	分别加压100, 200 TPS, 对debug版本进行CPU profiling, 生成flamechart.	压力加大, CPU使用升高, 各个function维持在固定的比例
37	部分节点升级测试	2/3 * n + 1的bp节点升级，剩下的bp节点没有升级	2/3 *n + 1个节点lib升级测试	1.仅仅升级2/3 * n+1bp节点和fullnode， 2.升级合约后 3.设置参数后 4.升级剩余节点 5.压力200 TPS 6. 投票，让BP持续轮换出块 7. 持续至少3天	1.仅仅升级2/3 * n + 1bp节点和fullnode，不影响全网达成共识2.升级合约后，没有升级的节点断开链接，当前块高度和lib前进3.升级剩余bp的两个节点，这两个节点能够追上当前的块高度4.设置参数后，正常同步数据，未升级的没有同步5.升级剩余节点，所有节点能够升级成功，网络正常运行, 后升级的bp节点可以正常出块和先升级的节点达成共识
38			测试snapshot	1. 生成一个snapshot 2. 用最新版本用这个snapshot恢复	snapshot恢复节点成功
39			replay blockchain		replay节点成功
40			使用hard-replay-blockchain、replay-blockchain操作重新同步数据		恢复节点成功
41			使用--delete-all-blocks并且重新同步数据		恢复节点成功
42			正常重新启动		恢复节点成功
43		2/3 * n + 1的bp节点升级，其中有升级的bp down掉, 其余的bp节点没有升级	2/3 *n + 1个节点node升级, 但升级过程中有node已经升级的bp down, 恢复bp后, 测试是否可以完成lib升级	1.仅仅升级21*2/3+1bp节点和fullnode， 2.升级合约后 3.其中有bp挂了，lib不前进，重启动这些bp，升级剩余节点中的部分 4.设置参数后，网络升级成功 5.升级剩余节点	1. 共识切换成功2. bp可以正常出块3. 节点RAM\CPU指标正常
44			测试snapshot	1. 生成一个snapshot 2. 用最新版本用这个snapshot恢复	snapshot恢复节点成功
45			replay blockchain		replay节点成功
46			使用hard-replay-blockchain、replay-blockchain操作重新同步数据		恢复节点成功
47			使用--delete-all-blocks并且重新同步数据		恢复节点成功
48			正常重新启动		恢复节点成功
49		2/3 * n + 1 的bp节点升级，网络升级 放在升级节点后	2/3 *n + 1个节点node升级, 合约升级顺序不同的测试	1.仅仅node升级2/3*n+1bp节点和fullnode， 2.升级合约后 3.升级剩余节点 4.设置参数后， 5.其中有bp挂了，lib不前进，重启动这些bp 6.压力200 TPS 7. 投票，让BP持续轮换出块 8. 持续至少3天	1. 共识切换成功2. bp可以正常出块3. 节点RAM\CPU指标正常
50			测试snapshot	1. 生成一个snapshot 2. 用最新版本用这个snapshot恢复	snapshot恢复节点成功
51			replay blockchain		replay节点成功
52			使用hard-replay-blockchain、replay-blockchain操作重新同步数据		恢复节点成功
53			使用--delete-all-blocks并且重新同步数据		恢复节点成功
54			正常重新启动		恢复节点成功

f: 最大的允许容错faulty的节点数量, 在n = 21的情况下, f = ⌊(21 - 1) / 3⌋ = 6