Het testen van nieuwe of gewijzigde software is een belangrijke, maar ook een tijdrovende klus. In deze bijdrage laten we zien hoe de testsoftware Selenium het uitschrijven van testgevallen overbodig maakt, zodat ontwikkelaars en eindgebruikers hun energie kunnen besteden aan de kwaliteit van de testgevallen. Deze bijdrage is bedoeld voor ontwikkelaars en – wat betreft de minder technische secties – eindgebruikers van webtoepassingen.
Aanleiding
Een grote uitdaging bij het ontwikkelen van software is het effectief en efficient testen van die software. Eindgebruikers waarderen foutloze software enorm. Maar testen is ook kostbaar. Tijdens een test dien je voor alle mogelijke voorkomende situaties na te gaan of de software zich juist gedraagt.
Dat “alle mogelijke voorkomende situaties” is de bottleneck tijdens het testen. Want stel dat 2 personen een jaar lang 24 uur per dag, 7 dagen mogen testen, en stel dat een test 5 minuten duurt. Dan kunnen max 2 * 12 * 24 * 365 = 210.240 testgevallen uitgevoerd worden.
Dat lijkt veel. Voor software-producten, die met de hand getest worden, zal het uitvoeren van 210.240 testen in de praktijk onhaalbaar zijn. Maar dat is het niet. Om een eenvoudig webformulier met 10 velden, waarbij ieder veld 6 keuze-mogelijkheden heeft, volledig te testen, zijn 1.000.000 (10*10*10*10*10*10) testgevallen nodig. Bovendien moet na iedere wijziging in de software het hele pakket opnieuw getest worden.
Omdat volledig testen geen optie is, proberen wij met geautomatiseerd testen en het opbouwen van een vaste verzameling met testsituaties de kwaliteit van de test en daarmee van onze producten te verbeteren.
Automatiseren testen
Het automatiseren van testen is niet nieuw: er bestaan verschillende software-pakketten die het automatisch testen van software ondersteunen. Commerciele pakketten zoals Tmap en Testrunner. Maar ook OpenSource varianten. Wij hebben zelf een hele tijd gebruik gemaakt van HttpUnit, een extensie van het veel-gebruikte jUnit.
Hoe werkt dat, een automatische testtool? Voor onze webtoepassingen maken wij scripts waarmee wij de mogelijke acties van eindgebruikers simuleren. Een script om in te loggen bijvoorbeeld, dat bestaat uit de volgende stappen:
1. open de login pagina
2. vul de gebruikersnaam in in het veld voor de gebruikersnaam
3. vul het wachtwoord in in het veld voor het wachtwoord
4. druk op de knop met het woord login
5. controleer dat je op de pagina Afspraken Overzicht bent gekomen
of, als voor het testen van de reactie op een verkeerd wachtwoord:
1. open de login pagina
2. vul de gebruikersnaam in in het veld voor de gebruikersnaam
3. vul het wachtwoord in in het veld voor het wachtwoord
4. druk op de knop met het woord login
5. controleer dat er een foutmelding verschijnt met de mededeling dat er een verkeerd wachtwoord is ingevuld
Het maken van dit soort testen is tijdrovend, maar als ze er eenmaal zijn, dan leveren ze veel tijdbesparing op. De zgn ReturnOnInvestment is enorm.
Vaste verzameling representatieve testgevallen
Omdat het niet haalbaar is alle testgevallen uit te voeren, is het zinvol om te bepalen welke testgevallen in ieder geval wel uitgevoerd moeten worden. Bijvoorbeeld testgevallen die de beveiliging testen, testgevallen die de meest voorkomende handelingen van eindgebruikers testen en testgevallen voor situaties die na analyse van de programma-code tot problemen kunnen leiden.
In de loop van tijd kan de verzameling representatieve testgevallen uitgebreid worden. Bijvoorbeeld wanneer de eindgebruiker een fout meldt, dan kan na het oplossen van de fout een testgeval worden gemaakt die test die de gemelde fout niet meer voorkomt. Dit is erg belangrijk voor de klantbeleving.
Waarom een alternatief voor HttpUnit
Wij hadden goede successen met HttpUnit voor onze online agenda en het internet-adresboek, maar het lukte ons niet onze nieuwste roostertoepassing met automatisch volledig te testen. Hier zijn 2 redenen voor. Ten eerste is rooster-software veel complexer dan agenda en adresboek-software. Ten tweede maken wij gebruik van Javascript om de toepassing gebruikersvriendelijker te maken. Het lukte ons niet de JavaScript met HttpUnit te simuleren. Dus zijn wij op zoek gegaan naar een nieuwe, automatische testtool voor webtoepassingen, en wij hebben een oplossing gevonden in Selenium van www.thinkworks.com. Selenium downloaden kan van de website http://www.openqa.org/selenium.
Het product Selenium – de Core
Het product Selenium bestaat uit verschillende onderdelen, waarvan wij nu de onderdelen Selenium Core gebruiken en Selenium IDE. De kern van de Selenium testsoftware is de Selenium Core. Deze core bestaat uit een verzameling voorbeeld-testgevallen. deze voorbeeld-testgevallen zijn de basis voor de eigen testgevallen.
<tr>
<td>open</td>
<td>http://192.168.0.10:8080/login.jsp</td>
<td></td>
</tr>
Deze testcase opent een loginpagina. De derde parameter is leeg.
<tr>
<td>type</td>
<td>USERID</td>
<td>s.fischer@mijnbedrijf.nl</td>
</tr>
Met deze testcase wordt ingelogd.
In het algemeen geldt dat de eerste kolom de actie bevat, de tweede kolom de locatie en de derde kolom de waarde. Een actie kan een actie van een eindgebruiker zijn, zoals open pagina, tik een waarde in of klik op een link. Maar een actie kan ook een verifieer-actie zijn, zeer belangrijk als je wilt verifieren dat een bepaalde foutmelding wordt getoond. De tweede kolom kan bijvoorbeeld een URL zijn, zoals http://192.168.0.10:8080/login.jsp, een invoer-veld, zoals USERID of een DOM-referentie. De derde kolom mag leeg zijn. Dus een algemene testcase is
<tr>
<td>action</td>
<td>location</td>
<td>value</td>
</tr>
De tweede kolom mag overigens ook leeg zijn, zoals in het voorbeeld:
<tr>
<td>goBackAndWait</td>
<td></td>
<td></td>
</tr>
waarmee het klikken op de Vorige-toets in een browser-window wordt gesimuleerd.
Erg krachtig is het aanroepen van test-bestanden in een soort super-test-bestand. Daarmee is het mogelijk uitgebreidere testen te splitsen en op te slaan in handzame delen. Bovendien is het mogelijk een conditie toe te voegen aan het <tr> element van de testcase zodat testen afhankelijk van het browser-type worden uitgevoerd. Bijvoorbeeld: <tr unless=”browserVersion.isKonquerer”> voert een test uit tenzij er met de Konquerer browser gewerkt wordt.
Het valideren van het testresultaat
Een testgeval behoort naast de acties ook een beschrijving te hebben van het verwachte resultaat. Selenium kan het controleren van de verwachte resultaten automatisch uitvoeren. Hiervoor bestaan bijvoorbeeld de commando’s verifyTextPresent en verifyText. De verifyTextPresent controleert of een tekst, bijvoorbeeld een foutmelding of een toegevoegd item, op het scherm voorkomt. De verifyText controleert of een bepaald element (link, button) op het scherm voorkomt. De controle-stappen voor het valideren van de testresultaten moeten handmatig in de test worden geplaatst.
Het product Selenium – IDE
Selenium – IDE is een plugin en om deze te gebruiken is Firefox 1.5.8 of hoger nodig. Na installatie van deze versie kan de Selenium – IDE automatisch geinstalleerd worden vanaf de website. De plugin is vervolgens beschikbaar onder Tools.
Voordeel: Met Selenium – IDE hoef je geen testgevallen meer in de omgeving van de applicatie-server te plaatsen.
De Selenium – IDE biedt een opname mogelijkheid voor het uitvoeren van testen op dezelfde manier waarop je vroeger muziek op een casette opnam, en je nu macro’s in Excel kunt opnemen.
Hiermee wordt het mogelijk om gebruikers-gedrag te simuleren. Want gebruikers voeren niet de velden op een scherm in de juiste volgorde en met de goede waarden in. Ze openen een scherm, komen er achter dat ze niet over de juiste informatie beschikken, gaan terug naar eerdere pagina’s met de browser-vorige-knop en vergeten vervolgens een veld. Dit gedrag kan nu opgenomen worden en later weer worden afgespeeld.
Wij zijn bij het opnemen van de testen de volgende zaken tegengekomen:
- Wanneer wij een link op een ander frame aanklikken, dan wordt er een actie click in het testbestand gezet. Dit zou naar onze mening clickAndWait moeten zijn, net zoals dat gebeurt bij links op hetzelfde frame. Wij adviseren het testbestand door te lopen en click te vervangen door clickAndWait.
- De browser-backtoets wordt niet gesimuleerd. Deze teststap goBackAndWait zal apart moeten worden toegevoegd.
Troubleshooting en documentatie
Een nadeel van testen met Selenium is dat het niet snel duidelijk is welk object, zij het een window, formulier, frame, enz, centraal staat. Zo zijn wij nogal wat tijd kwijt geraakt omdat we 2 frames dezelfde naam hadden gegeven. Het eerste frame met de naam bevatte geen links, het tweede frame bevatte wel links. Tot vervelends toe meldde de test dat een link niet bestond, en wij hadden geen mogelijkheid om te zien waar de tool aan het zoeken was.
Een tweede reden waardoor een link niet gevonden kan worden is bij het zoeken niet gewacht wordt totdat de pagina volledig geladen is. Zelf maken de Selenium testcases veelvuldig gebruik van het commando clickAndWait en selectAndWait. Dat betekent dat het script op een link klikt en wacht totdat de resulterende pagina geladen is. Bij de commando’s click en select gaat het script meteen door, en zal links niet kunnen vinden als die nog niet opgehaald zijn.
De documentatie is niet goed, niet duidelijk en onvolledig. Maar er zijn zoveel testvoorbeelden met aansprekende titels, en er is een goed forum met een goede zoekfunctie. Een avondje puzzelen en je kunt ermee aan de gang.
Tot slot
Welke methoden gebruikt u om te controleren of software aan uw wensen voldoet? Maakt u gebruik van handmatige of automatische testen? Kende u Selenium al? Zo ja, wat is uw ervaring met Selenium RC? Zo nee, denkt u dan dat u Selenium gaat gebruiken in de nabije toekomst?
Sophie Fischer
www.sponiza.nl
www.etikettenprinten.nl
