Innovatie & Strategie

Software-ontwikkeling
software testen

Automatisch testen op GUI-niveau

Alternatieven voor script-based tools

16 juli 2019

Alternatieven voor script-based tools

Voor GUI-testautomatisering wordt nu veel gebruikgemaakt van script-based tools. Scripts zijn echter complex en dus tijdrovend om te maken en te onderhouden. Tanja Vos en Machiel van der Bijl zien hiervoor een oplossing in tools die scriptless GUI testing mogelijk maken en tools die automatisch scripts genereren en uitvoeren.

Testen op het niveau van de grafische user interface, of de GUI, is een belangrijke testfase, omdat getest wordt vanuit het perspectief van de eindgebruiker. Testgevallen via de GUI bestaan uit testsequenties die aangeven welke acties (klik, type, drag, drop, etc.) je achtereenvolgens wilt uitvoeren op de GUI.

Een voorbeeld is de GUI van een simpel koffieapparaat. Bij voldoende saldo kunnen we kiezen uit koffie of thee voor 50 cent. Dit resulteert in een boodschap op het scherm met de gekozen drank en vervolgens het gekozen drankje zelf. Het bedrag wordt van het saldo afgetrokken en je kunt een volgend drankje pakken.

Als we de aankoop van thee willen testen:

1. Zorg voor voldoende saldo

2. Klik op thee

3. Wacht op je drankje

Orakel

Nadat deze acties zijn uitgevoerd in deze sequentie, moet er met behulp van een zogenaamd orakel gecheckt worden of de test geslaagd is (in dit geval: of er thee is gemaakt en of het juiste bedrag van ons saldo is afgehaald). Een orakel[1] is een mechanisme dat correct en incorrect gedrag van een softwaresysteem van elkaar kan onderscheiden.

Er zijn heel veel tools beschikbaar die het testen van applicaties op het GUI-niveau ondersteunen en test executie helpen te automatiseren door middel van scripts. Stel dat een tester een testgeval heeft ontwikkeld zoals in het voorbeeld hierboven: een sequentie van acties en invoerwaarden, zoals klikken, typen, slepen, enz. Dit willen we omzetten in een script dat we automatisch kunnen afspelen.

Dat kan bijvoorbeeld met een capture/replay tool zoals Ranorex en Squish. Terwijl de tester dit handmatig uitvoert, neemt de tool deze sequentie op in een script dat achteraf opnieuw automatisch kan worden afgespeeld. Maar we kunnen ook het script meteen schrijven met tools als bijvoorbeeld Robot Framework, Selenium, SikuliX of eyeAutomate. Denk bijvoorbeeld aan het volgende testscript:

 

set_focus_to_window("$main");

enter("$saldo", 200);

click_field("thee");

verify(get_field("drink"), thee);

verify(get_field(“$saldo”),150);

Figuur 1: voorbeeld testscript

 

Het doel van deze tools is het automatiseren van het uitvoeren van de tests die handmatig door een tester zijn gemaakt. Dit is een trend bij de meeste testautomatiseringstools: ze bieden functionaliteiten aan voor testmanagement en automatische testexecutie. Er zijn veel minder tools die assisteren bij het automatisch genereren van testcases, dat wil zeggen testontwerp. Dit wordt vooral nog handmatig gedaan. Dat is niet verwonderlijk, want dit is een van de meest uitdagende onderdelen van alle testactiviteiten: we moeten de beste testgevallen kiezen en we moeten precies weten wanneer zo’n testgeval een fout heeft ontdekt. Dit laatste staat bekend als het orakelprobleem.

Een andere trend is dat deze GUI-scripts use cases of functionaliteiten testen waaraan de software moet voldoen. Vaak zijn dit echter de sunny, happy use cases waar we van uitgaan. Doordat tijd en geld gelimiteerd zijn, komen we er vaak niet aan toe om nog meer testgevallen toe te voegen die ook de niet-use cases testen.

TESTOMAT

In het TESTOMAT-project (www.testomatproject.eu) worden tools onderzocht voor de "next level of test automation". Het project gaat op zoek naar een delicaat evenwicht tussen twee tegengestelde krachten: streven naar betrouwbaarheid en streven naar agiliteit. In deze context kijken we naar scriptless testen van non-use cases en automatische testcasegeneratie.

 

Om scriptless non-use cases te testen, hebben we de TESTAR-tool ontwikkeld (www.testar.org). Zonder dat je vooraf testgevallen specificeert, kan TESTAR automatisch testreeksen genereren op basis van de acties die mogelijk zijn in elke toestand waarin de GUI komt. Deze scriptless en geautomatiseerde testen van de non-use cases vullen de bestaande test mooi aan.

 

https://lh5.googleusercontent.com/0OshqUR1dgVN6uttfmrDF-XoFaVEod1y2QJAFzGQJ29oJYC4Hdu1bqcV9rwCFnrlRA7at3JU7GJgrgDAVnRpKSWHdMnN1MEuymdEyaEc1WZEMbOheMvIv5PCaXsWOoTbdA

 

TESTAR (testar.org) is een opensourcetool die als volgt werkt:

1. Start de software die je wilt testen (Software Under Test (SUT)).

2. Scan de GUI en verkrijg de toestand waarin deze GUI van de SUT zich bevindt.

Deze toestand bestaat uit alle widgets die in die bepaalde toestand van de GUI te zien zijn (dat wil zeggen: alle knoppen, menu's, tekstvelden,  enz.) en al hun bijbehorende eigenschappen, zoals: positie, grootte, kleur, titel, enz. 

In de onderstaande figuur zie je voorbeelden van toestanden. De groene bolletjes zijn voorbeelden van widgets.

https://lh4.googleusercontent.com/-fNm-l_CN4etgxlUhBN0dWBkXTfgKN7PpPmE4YleOSnmB7D4n8zuC4NfwO_q3fXjSX1cIJBhuGsP2fLqoczUMm5uALJoCfEECdFImtvh_Wt5jls7foR8nSI9FjS5RlVIaw

 

3.  Leid een verzameling van mogelijke acties af die een gebruiker zou kunnen uitvoeren in deze specifieke toestand.

4. Selecteer een van deze acties uit de verzameling.

5. Voer de geselecteerde actie uit (bijvoorbeeld klik, typ, schuif).

6. Pas de beschikbare orakels toe om de correctheid van de nieuwe toestand waarin de gebruikersinterface zich bevindt te controleren. Als er een fout is gevonden, stop dan de SUT en sla de testreeks op die de fout heeft gevonden. Zo niet, ga naar stap (2).

 

TESTAR

Om de toestand waarin de GUI van de SUT zich bevindt te verkrijgen, gebruikt TESTAR de toegankelijkheids-API van een besturingssysteem of de Selenium WebDriver voor webapplicaties. Zonder iets te specificeren, kan TESTAR fouten detecteren in algemene systeemvereisten, i.e. situaties die bijna altijd slecht zijn voor de meeste applicaties. Denk aan:

- de SUT mag niet crashen;

- de SUT mag zich niet bevinden in een niet-responsieve toestand ('bevroren' zijn);

- de GUI-toestand mag geen verdachte woorden bevatten, zoals error, problem, exception enz.

In de praktijk vinden we op deze manier al heel wat fouten in de verschillende casussen die we hebben bestudeerd bij bedrijven.

De kracht van TESTAR ligt in de implementatie van stap 4: actieselectie. In de standaardmodus van TESTAR wordt deze uit te voeren actie willekeurig gekozen uit de verzameling. In de meer geavanceerde modus kunnen we slimmer selecteren. Actieselectie, of what to do next, is het probleem dat vele artificieel intelligente systemen proberen op te lossen. In TESTAR worden verschillende implementaties van reinforcement learning gebruikt om de optimale strategie te leren. Op deze manier kan de testtool zelf leren hoe te testen.

De tool kan ook gebruikt worden om automatisch testreeksen te genereren voor use cases. Wel moet de tool dan meer informatie krijgen. De tester moet dan een model maken waarin de use cases zijn geformaliseerd. Wij gebruiken daar de state-modellen voor van TESTOMAT-partner Axini (www.axini.com).

Deze tools beschrijven het ontwerp in een model. Het voordeel van een model is dat het zowel dient als ontwerp als als documentatie. Op basis van het model worden testgevallen gegenereerd en uitgevoerd en wordt de testuitkomst gecontroleerd.

Een voorbeeld van een state-model voor een klein deel van een koffieautomaat:

 

https://lh3.googleusercontent.com/QD1tqQlANP50-1KWlqWfjEz8uJGUztNcHDkpaGdQ_XLJrcOtUwd6FJEFVsXovsdCdjFSdk961AxDNTFpopVo7IWXjayBWD5K8Q31p6owlUMf5epOUtErsvKvUpb4JOB5-A

 

Testgevallen worden automatisch gegenereerd door de paden van het model te volgen en slimme datawaarden te kiezen. Bijvoorbeeld voor de hoofdpaden in bovenstaand model:

  1. Te weinig saldo. De boodschap ‘niet genoeg saldo’.
  2. Keuze voor koffie. Een saldo van 500 cent, keuze voor item ‘koffie’, observatie van de boodschap ‘koffie wordt gemaakt’, observatie van de drank koffie en observatie dat er nu 450 cent saldo over is.
  3. Keuze voor thee. Een kaart met 1000 cent, keuze voor item ‘thee’, observatie van de boodschap ‘thee wordt gemaakt’, observatie van de drank thee en observatie dat er nu 950 cent saldo over is.

Deze afgeleide testgevallen zet de Axini-toolset automatisch om naar executeerbare testscripts, zoals in figuur 1.

Resumerend is het gebruik van script-based tools de huidige state of the art in GUI-testautomatisering. Het probleem hierbij is dat het maken en onderhouden van scripts moeilijk en tijdrovend is. TESTAR is een tool die scriptless GUI testing mogelijk maakt. Ook bij de Axini-toolset hoef je geen scripts te onderhouden, omdat deze de scripts automatisch genereert en uitvoert. Beide tools worden verder ontwikkeld en toegepast in het ITEA3 TESTOMAT-project: op weg naar de next level van testautomatisering.

 

 

[1] Deze terminologie werd in 1978 geïntroduceerd door Williams Howden.

Magazine AG Connect

Dit artikel is ook gepubliceerd in het magazine van AG Connect (juni-julinummer 2019). Wil je alle artikelen uit dit nummer lezen, klik dan hier voor de inhoudsopgave.

Lees meer over
Lees meer over Innovatie & Strategie OP AG Intelligence
Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.