Blockchains - en QA-utmaning

Blockchain är kanske en av de mest hypade teknikerna just nu och om man som QA-specialist ibland känner sig överöst av olika verktyg så är utbudet av befintliga verktyg för att testa blockchain-lösningar inte imponerande. Eftersom det är en väldigt hypad teknik kommer man säkert att börja se andra implementeringar utöver kryptovalutor så som Bitcoin och NFTer inom en snar framtid.

Men vad är då blockchain?

Tänk dig en databas där du bara har möjlighet att lägga till saker men inte kan ta bort eller ändra data som lagrats i databasen. För att andra ska kunna använda lösningen behöver databasen vara öppen och tillgänglig för vem som helst för att både läsa och lägga till ny data. Utöver det behöver man också säkerställa att det bara är ägaren av en tillgång som kan använda tillgången och överföra den till någon annan, trots att det är en öppen databas.

För många låter kanske det här som en komplex lösning som man borde undvika. För en devopsare låter det som en utmaning. En blockchain-lösning är komplex och att testa den är minst lika komplext eftersom det:

1. 1. Saknas testramverk

2. 2. Kunskapsnivån om blockchain är begränsad

3. 3. Testdata är komplext när varje transaktion har ett nyckelpar att hålla reda på
4. 4. Lösningen behöver verifieras i ett nätverk av noder
5.  

Här beskriver vi ett par exempel på hur man kan tänka för att skapa de förutsättningar som krävs att testa lösningen. Blockchain är som sagt komplext och det är inte standardiserat så olika implementeringar fungerar på lite olika sätt. Som QA-specialist behöver man därför ha en mycket större förståelse för hela den komplexa lösningen än vad man kanske behöver för en ”vanlig” lösning. Att förstå nätverket och komponenterna som man normalt talar om i en blockchain-lösning är ett måste för att man ska lyckas i testningen.

De huvudsakliga komponenterna i en blockchain-lösning är:

• Kedjan
• Block
• Konton över tillgångar
• Transaktionerna
• Kryptografiska signaturer
• Smarta kontrakt/lösningens script implementation
• Noderna
• API:erna (de meddelanden som skickas mellan noderna i P2P nätverket)

Vill man lyckas och uppnå en så nära felfri lösning som möjligt måste man ha en hög grad av testautomatisering och en CI/CD pipeline som säkerställer att man alltid testar av alla testfall. Att bygga en CI/CD pipeline kan man göra med befintliga verktyg som t.ex. Azure Devops, Bitbucket och Jenkins.

Därefter är det mera skralt med befintliga verktyg. En orsak till det beror kanske på att blockchain-lösningarna skiljer sig åt och verktygen behöver därför många specialanpassningar, vilket gör att det blir nischat mot en specifik blockchain-lösning. BitcoinJ är ett ramverk som till exempel kan användas för att testa delar av Bitcoins blockchain-lösning. Man behöver dock koda själv en hel del eftersom det inte är ett specifikt testramverk. Ethereum-tester och Truffel är två testramverk för Ethereum-typer av blockchain-lösningar och med dessa kan man testa vissa delar av lösningen som till exempel smarta kontrakt.

Att testa helhet blir mycket svårare eftersom det är många delar som ett testramverk behöver klara av och eftersom det inte finns bra heltäckande ramverk behöver man ha en djup kunskap om hur lösningen är uppbyggd så man kan skapa de ramverk som den egna testningen kräver.

Skapa initiala kedjor

Initialt behöver man sätta upp en längre kedja med block och transaktioner. I Bitcoin-implementationen läggs ett nytt block till i medeltal var 10:e minut. Att skapa denna initiala kedja skulle alltså ta dagar, månader eller år. Men genom att manipulera svårighetsgraden och tidstämpeln då man skapar de initiala blocken kan man snabba upp den här processen. Svårighetsgraden används för att det ska vara jobbigt då ett block minas. När man skapar testdata kan man ju tumma på den regeln.

Begränsa testdata

Ett annat exempel är att kryptografiska signaturer används i transaktionerna för att säkerställa att framtida transaktioner bara kan utföras av den som äger tillgången. Det skulle bli mer eller mindre omöjligt att hålla kolla på miljontals privata/publika nyckelpar som testdata. Inom testning behöver man dock inte alltid använda unika nyckelpar. Istället kan man exempelvis använda beloppet i transaktionen som ett index för att hitta rätt nyckelpar i sin testapplikation. Så att alla transaktioner på 1 Bitcoin använder sig av ett visst nyckelpar och så vidare.

Skapa fördröjningar i nätverket

Det mest komplicerade är att testa hela nätverket för att hitta problem som uppstår på grund av fördröjningar, det vill säga att en nod inte har blivit uppdaterad med en transaktion eller ett meddelande. Med en fördröjande stubbproxy som läggs mellan två noder kan man enkelt lägga till fördröjningar i kommunikationen mellan två noder. Den här typen av fördröjningar uppstår normalt i ett globalt distribuerat nätverk, men i en labbmiljö behöver man skapa dem själv.

Ett annat alternativ är att implementera sitt nätverk i en molnlösning som Azure Devops eller AWS och allokera Noderna i olika datacenter utspridda över världen. Då får man en viss fördröjning, dock är den ganska liten och man kommer ändå för eller senare behöva en stubbproxy.

Vi skulle dock rekommendera att man allokerar sina noder i en molnlösning för då är man mer eller mindre obegränsad av antalet noder som man kan spinna upp.

Sammanfattning

Det här är bara ett par exempel på olika testlösningar som används vid testning av blockchains.

Eftersom det ännu inte finns bra heltäckande testramverk för blockchain så behöver man som QA-specialist skapa sina egna testramverk, och därför behöver man också en mycket djupare förståelse för blockchain-lösningen. När man testar blockchains får vi som jobbar med QA verkligen tänka utanför lådan och hitta på nya lösningar eftersom det just nu saknas bra testverktyg.