PoS_EVM
/
woop
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
The core protocol of WoopChain
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
5493 Commits
46 Branches
191 Tags
64 MiB
 
 
 
Tag: Branch: Tree: bf96109f04
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'bf96109f04'
${ noResults }
woop/specifications/test/testplan.md

7.3 KiB
Raw Blame History

Harmony blockchain test plan

We list the major testing area and the test cases. For each test case, it should have a description of the test case, expected behavior and passing criteria.

test case template

template

  • test case # :
  • description :
  • test procedure :
  • passing criteria
  • dependency
  • note
  • automated?

functional test

Functional test is used to validate the function of each component in the blockchain. It should cover the basic function to pass, to fail, and error conditions.

peer discovery

  • test case # : PD1
  • description : find peers using rendezvous string
  • test procedure : a new node connected to bootnode and call FindPeers function to return a list of peers using different rendezvous strings
  • passing criteria : new node can get a list of peers using the same rendezvous string
  • dependency
  • note
  • automated? N
  • test case # : PD2
  • description : boot node recovery
  • test procedure : start a bootnode, start a few new node to connect to bootnode, restart the bootnode, start a few new node to discover peers
  • passing criteria : bootnode should be able to store previously connected peers
  • dependency
  • note
  • automated? N
  • test case # : PD3
  • description : multiple boot nodes
  • test procedure : start 3-5 bootnode, start a few new node to connect to all the bootnodes for peer discovery
  • passing criteria : new node can get a list of peers using the same rendezvous string
  • dependency : redundant peers maybe returned and we should handle the reduanancy (or not)
  • note
  • automated? N
  • test case # : PD4
  • description : number of peers supported in bootnode
  • test procedure : start a bootnode, connect up to 5000 new node using the same rendezvous string
  • passing criteria : each new node should get a list of peers, not sure how many though
  • dependency
  • note
  • automated? N

state syncing

  • test case # : SS1
  • description : node state sync basic
  • test procedure : node joins network and is able to sync to latest block
  • passing criteria : blockheight of node is equal to that of the shards blockchain and node has joined consensus.
  • dependency
  • note
  • automated? N
  • test case # : SS2
  • description : network connectivity issues
  • test procedure : node experiences network connectivity issues or is down and then regains connectivity
  • passing criteria : the node is able to sync back to current state of blockchain from the point where it dropped off
  • dependency
  • note
  • automated? N
  • test case # : SS1
  • description : beacon chain node ss
  • test procedure : one new beacon node join in the beacon chain after beacon chain reach a few consensuses
  • passing criteria : the new node can join in the consensus after state syncing
  • dependency
  • note
  • automated? N

consensus

  • test case # : CS1
  • description : beacon chain reach consensus
  • test procedure : start beacon chain with 50, 100, 150, 200, 250, 300 nodes, check leader log on number of consensuses
  • passing criteria
  • dependency
  • note
  • automated?

drand

  • test case # : DR1
  • description : drand generate random number
  • test procedure : start beacon chain with 50, 150, 300 nodes, check leader log on the success of generating random number
  • passing criteria : random number genreated
  • dependency
  • note
  • automated?
  • test case # : DR2
  • description :
  • test procedure :
  • passing criteria
  • dependency
  • note
  • automated?

smartcontract

  • test case # : SC1
  • description : deploy ERC20 smart contract in 1 shard
  • test procedure : smart contract is deployed in a automated fashion e.g. erc20 (utility) token contract
  • passing criteria: ability to interact with smart contract e.g. transfer erc20 tokens from one address to another
  • dependency
  • note
  • automated?
  • test case # : SC2
  • description : deploy ERC721 (non-fungible tokens) smart contract in 1 shard
  • test procedure : smart contract is deployed in a automated fashion e.g. smart contract like Cryptokitties
  • passing criteria: ability to succesfully transfer the non-fungible token from one address to another via transaction
  • dependency
  • note
  • automated?

staking

  • test case # : SK1
  • description :
  • test procedure :
  • passing criteria
  • dependency
  • note
  • automated?
  • test case # : SK2
  • description :
  • test procedure :
  • passing criteria
  • dependency
  • note
  • automated?

resharding

  • test case # : RS1
  • description : reshard with 1 shard only
  • test procedure : start beacon chain with 50 nodes, wait for resharding after 5 blocks
  • passing criteria : a new leader should be selected
  • dependency
  • note
  • automated?
  • test case # : RS2
  • description : reshard with 2 shards
  • test procedure : 0 new nodes join the network for the new epoch
  • passing criteria : a new leader should be selected
  • dependency
  • note
  • automated?
  • test case # : RS3
  • description : reshard with 2 shards with 250 nodes each
  • test procedure : 50 to 250 new nodes join the network for the new epoch
  • passing criteria : a new leader should be selected
  • dependency
  • note
  • automated?

transaction

  • test case # : TX1
  • description : wallet send transaction to blockchain
  • test procedure : start beacon chain with 50 nodes, send one transaction from wallet
  • passing criteria : transaction is recorded in blockchain
  • dependency
  • note
  • automated?

view change

  • test case # : VC1
  • description : change leader after resharding
  • test procedure : after resharding, new leader was selected and changed
  • passing criteria : consensus keeps going
  • dependency : resharding
  • note
  • automated?
  • test case # : VC2
  • description : change malicious leader
  • test procedure : started beacon chain with 50 nodes, leader started consensus and offline, after sometime, a new leader is selected
  • passing criteria : new leader keeps the consensus going
  • dependency : resharding
  • note
  • automated?

stress test

protocol level stress

  • test case # : STP1
  • description :
  • test procedure : increase number of txns in block from 1000 to 10,000, stepwise
  • evaluation: change in block latency per shard/change in transactions per sec, per shard.
  • dependency
  • note
  • automated?
  • test case # : STP2
  • description : increasing number of nodes in a shard
  • test procedure : increase number of nodes in a shard from 100 to 1000
  • evaluation: change in latency per shard/change in transactions per sec, per shard.
  • dependency
  • note
  • automated?
  • test case # : STP3
  • description : epoch change with increasing number of nodes in shard
  • test procedure : initiate epoch change with increasing number of nodes in a shard from 100 to 1000
  • evaluation: latency in leader election
  • dependency
  • note
  • automated?

epoch change stress

  • test case # : EC1
  • description : hight waiting nodes
  • test procedure : for 5 shards having 200 nodes each initiate epoch change with 10,000 nodes waiting
  • evaluation: latency in leader election/resharding
  • dependency
  • note
  • automated?

networking level stress

  • test case # : NT1
  • description :
  • test procedure : start consensus with a peer-p2p network of 50 peers, increase it to 1000 peers, send 1 ping message every 100 ms.
  • evaluation: change in latency per shard/change in transactions per sec, per shard.
  • dependency
  • note
  • automated?

long running stress

storage

security test

malicious node

DoS attack

stability test