Centraliseren testactiviteiten levert grootste besparing op
Automatisering Gids week 16 2003
(Deelname lijnmanagement aan testprocesverbetering essentieel)

Overzicht            In een nieuw window?
Wel houden wij ons aanbevolen voor op- of aanmerkingen alsmede suggesties.

Correct schrijven van HTML      Software om HTML-code te checken
CSE HTML Validator  > >  Freeware lite-versie
Tidy
HTML-kit (freeware)

Links controleren      Software om HTML-code te checken
Checkweb
Alert LinkRunner
Voor u gelezen: Itil-methodiek ook waardevol in Internetomgeving

Uitwisselbaarheid       Controle op werking bij gebruik van verschillende browsers
Anybrowser
Browserola
Web Standards Project
Voor u gelezen: Itil-methodiek ook waardevol in Internetomgeving

Beveiliging      Houd uw systeem schoon
Microsoft
Hideaway
SEI, tips incl. een lijst van beveiligingstools
Web Informatie over internetbeveiliging

Monitoring      Services en tools
De tool Topaz meet de performance3 vanuit het perspectief van de eindgebruiker
Service die bewaakt of een website beschikbaar is en hoe de performance zich ontwikkelt
Bijhouden bezoekersaantallen

Code checkers            In een nieuw window?
Code van HTML-pagina's wordt gecontroleerd op correctheid. Dit is te vergelijken met een compiler. Voor Perl en Java zijn hier ook programma's voor. De code checkers testen ten opzichte van de standaard syntax. Verschillende leveranciers van browsers ondersteunen echter ook een uitgebreidere syntax. Hierdoor worden er foutmeldingen gegeven die niet per definitie fout hoeven te zijn. Wel duiden deze meldingen erop dat wellicht niet alle browsers de pagina's correct zullen weergeven. Wil men een groot publiek bereiken, dan zal niet al te ver afgeweken mogen worden van de algemeen geldende standaard. Een controle-middel daarvoor is het gebruik van de Opera-browser.


Link checkers            In een nieuw window?
Deze tools controleren of de links die gebruikt worden wel werken. Vooral bij links naar externe pagina's is de kans aanwezig dat de naam van de pagina veranderd is of de pagina helemaal niet meer bestaat. Het gevaar bij deze tests is dat een pagina tijdelijk uit de lucht kan zijn, de server is dan bijvoorbeeld down of aan een pagina wordt "gesleuteld".

Server load            In een nieuw window?
Kan de server de hoeveelheid transacties wel aan? Dit type tool lijkt sterk op de normale "load" testtools. Als er van een provider gebruik gemaakt wordt heeft men er weinig invloedop. Als er eigen servers op het Internet aangesloten worden heeft men het zelf in de hand. In beide gevallen is dit een belangrijk aspect om de surfers die uw site gevonden hebben niet weg te jagen.


Valkuilen bij load testing door Marjan Vanuytsel

Websites met een user-interface naar back-end applicaties -hierna webapplicaties genoemd- spelen een steeds grotere rol in de bedrijfswereld. Ze zijn als het ware de kritieke levensader van een onderneming geworden. Daarom is een goede performance van een webapplicatie enorm belangrijk. Load testing verifieert die performance onder een gesimuleerde multi-user workload. Maar er zijn heel wat misverstanden en valkuilen bij deze manier van testen.

Veel bedrijven kunnen moeilijk voorspellen hoe hun webapplicaties zullen reageren op grote workloads. Ondanks het feit dat het web een duidelijke toename in functionaliteit en flexibiliteit mogelijk maakt, worden performance, de hoeveelheid ontvangen gegevens binnen een kort tijdsbestek en een aanvaardbare respons time steeds belangrijker voor de gebruikers.

Daarom is load testing, dat zich specifiek richt op deze criteria, ook noodzakelijk. Load testing wordt wel eens in één adem genoemd met functioneel testen. Maar er zijn toch een aantal duidelijke verschillen.

Zo start load testing vanuit een multi-user perspectief waarbij end-to-end respons time naar de back-end applicatie duidelijk anders zal zijn dan bij een single-user omgeving. Als je tijdens het testen fouten detecteert, moeten de testen onmiddellijk gestopt worden. Niet alleen omdat respons time meting dan niet relevant is, maar ook omdat de oorzaken zich op verschillende niveaus van het systeem (bijv. in web, applicatie of database server) kunnen situeren. Daarom neemt het localiseren en oplossen van problemen heel wat tijd in beslag. Dit principe geldt niet voor functioneel testen, waar het dikwijls nuttig is om te blijven testen nadat je de eerste bug hebt gevonden. Waar een applicatie volledig klaar moet zijn om functioneel te kunnen testen, is dit niet het geval bij load testing. De performance kan al getest worden lang voor er gebruiksvriendelijke en mooi ogende user-interfaces zijn.

Enkele valkuilen

Load testing verschilt niet alleen van het functioneel testen qua invalshoek maar heeft ook zijn specifieke valkuilen.

Testen van de webserver i.p.v. de webapplicatie: het gaat hier om het testen van de webapplicatie en niet van de webserver. De webserver ontvangt http verzoeken en zet deze om in andere verzoeken aan de onderliggende applicaties. De hoeveelheid tijd die in de server wordt doorgebracht, is verwaarloosbaar. Alle tijd gaat naar de onderliggende applicatie. Dit wil natuurlijk niet zeggen dat je de webserver tijdens het testen over het hoofd mag zien. Ook dit moet gebeuren, maar dan wel los van het load testen. Eigenlijk test je de applicatie achter het gordijn en niet het gordijn zelf.

Verkeerde toolkeuze: bij Load Testing kan je verschillende testtools gebruiken om de performance te testen. Wil je een goede toolkeuze maken, dan is het noodzakelijk om je vereisten voor load testing op te stellen in functie van 2 dimensies: complexiteit van de applicatie en het aantal requests binnen een tijdspanne. Zo kan je bijvoorbeeld "URL Player" tools gebruiken voor applicaties -zoals een zoekmachine- die niet complex zijn maar zeer veel worden geraadpleegd. Terwijl voor online aankoopsystemen, die complex zijn maar minder frequent worden bezocht, tools bestaan uit scripts die de workflows coveren.

Workload in termen van hits en gebruikers: mensen praten graag over websites in termen van hits en gebruikers omdat dit meetbaar is. Maar dit betekent niet dat ze een indicatie zijn om een load te bepalen. Wat betekent het om 1 miljoen gebruikers te hebben? Betekent dit 1 miljoen gebruikers die gelijktijdig inloggen? Zijn het nieuwe gebruikers? Wat betekent het om 1 miljoen hits per dag te hebben? Het bepalen van het workload niveau kan op verschillende manieren. Het Marketing Requirements Document waarin de specificaties van de applicatie staan beschreven, kan een hulp zijn. Maar meestal zal het een gok zijn omdat er geen andere informatie aanwezig is. Tenzij er gegevens en statistieken beschikbaar zijn op basis van vroegere releases.

Onrealistisch hoge loads: websites gaan niet plotseling van 0 bezoekers naar een heel hoog aantal bezoekers. Je moet er rekening mee houden dat operating systems en webservers tijd nodig hebben om een bepaalde load te bereiken. Eigenlijk is het belangrijkste dat het systeem een normale, realistische load aankan. Om dit aan te pakken is het best eerst een milde load test te doen en een warm-up te voorzien. Daarna start dan de eigenlijke load test.

Opstopping in de load driver: een van de belangrijkste valkuilen bij load testing is het probleem van opstopping in de load driver. Dit kan verschillende oorzaken hebben:

Het geeft een vals gevoel van vertrouwen in het aankunnen van load door je systeem, omdat je eigenlijk niet de load aan het produceren bent die je denkt te produceren.

Gestructureerd testen als oplossing

Bovengenoemde valkuilen lijken misschien onoverkomelijk. Maar gestructureerd testen kan op verschillende vlakken bijdragen tot een geslaagd toepassen van load testing.

Organisatie: hoe verleidelijk het ook mag zijn, load testing betekent niet dat je willekeurige loads op de webapplicatie los laat en kijkt wat er gebeurt. Er moet heel gestructureerd worden gewerkt: wees duidelijk in je doel, start klein en houd gegevens bij! Een goede testplanning is onmisbaar.

Start op tijd: bij het ontwikkelen van web applicaties wordt load testing vaak uitgesteld tot de laatste minuut of zelfs afgeweerd totdat er zich problemen voordoen. Verklaring hiervoor is de overtuiging dat eerst de applicatie moet werken vooraleer naar de performance kan worden gekeken. Maar load testing kan en moet gebeuren vóór een systeem een stabiele of complete user interface heeft. Bovendien staan de gebruikers heel kritisch t.a.v. de performance en is het daarom belangrijk dat problemen zo snel mogelijk worden opgespoord en opgelost.

Een testomgeving die productie benadert: om load tests te kunnen uitvoeren, is een testomgeving nodig. Deze omgeving moet stabiel, beheersbaar en representatief zijn. Volgende eisen stellen zich: een geïsoleerd netwerk; hardware die identiek of bijna identiek is aan de productie hardware; geen andere gebruikers op het systeem; een database met een realistisch aantal data liefst gekopieerd van de productie database.

Voldoende resources en infrastructuur: een testproces wordt uitgevoerd door mensen en heeft daarom organisatie nodig. Het is dan ook heel belangrijk dat de testers de nodige kennis en vaardigheden hebben om de testen voor te bereiden en uit te voeren. Verder heb je commitment van de ontwikkelaar nodig; enkel hij kan debuggen en een oplossing bieden. De organisatie moet ook instaan voor de beschikbare tijd, apparatuur en hardware.

Goed is goed genoeg: er zullen altijd wel fouten in het systeem blijven optreden, maar die moeten enkel geïdentificeerd worden totdat de performance acceptabel is. Verlies niet uit het oog dat er nog ander testwerk is naast load testing. Een snelle site kan nog altijd onaanvaardbaar zijn. En dus is een mix tussen load testing en functionele testen een vereiste.

Besluit

Het testen van loads bij Web Applicaties is belangrijk met het oog op performance, respons time en throughput naar gebruikers toe. Hoewel load testing soms vergeleken wordt met functioneel testen, zijn er toch belangrijke verschilllen. Niet alleen in de aanpak van de testen maar ook in mogelijke valkuilen die kunnen voorkomen, zoals: een foute toolkeuze of de workload in termen van hits en gebruikers definiëren.

Deze aspecten moeten dus voldoende aandacht krijgen. Hiervoor kan gestructureerd testen op verschillende manieren (bijv. op tijd starten, een goede testomgeving opstellen) een oplossing bieden.

Bron ANDERSON, M.D., "Stakes in Load Testing Applications", Software Testing & Quality Engineering, 1999, September/October, p. 31-41.

Beveiliging
Bij Internet speelt beveiliging een grote rol, beveiligings-tools monitoren bijvoorbeeld het aantal pogingen om servers te benaderen. Men kan nagaan hoe effectief een firewall is.
Binnendringen of berichtonderschepping door hackers. Falende beveiliging vormt voor veel organisaties het nachtmerriescenario. De verbinding met het internet maakt de organisatie kwetsbaar voor ongewenste indringers van buiten. Wat te doen als een hacker het systeem binnendringt en valse bestellingen doet? Hoeveel zekerheid heeft de klant dat zijn creditcard betaling niet wordt onderschept en misbruikt?
Mogelijk het grootste obstakel voor de opmars van e-business is de problematiek rondom het beveiligen van transacties en informatie. Cyberterreur is aan de orde van de dag en ondermijnt het vertrouwen van gebruikers. Regelmatig wordt aangetoond dat de beveiliging van prominente bedrijven met relatief eenvoudige middelen kan worden doorbroken. Recentelijk komen bedrijven op deze wijze in het nieuws, dit zal de negatieve publiciteit het consumentenvertrouwen zeker niet bevorderen. Zogenaamde ‘denial of service’ aanvallen op sites van CNN, Yahoo en anderen hebben in het verleden al aangetoond dat een aanwezigheid op het internet inherent een beveiligingsrisico met zich meebrengt. Derhalve is het verwonderlijk dat veel organisaties hun internetbeveiliging nimmer doorlichten.

Wij bieden u deze informatie zonder de software getest te hebben en kunnen geen verantwoordelijkheid aanvaarden bij problemen. Wel houden wij ons aanbevolen voor op- of aanmerkingen alsmede suggesties.

Functioneel testen
Deze tools zijn vergelijkbaar met die voor het functioneel testen van gewone applicaties. Zeker met de toepassing van Java en andere meer op de traditionele programmeertalen lijkende talen neemt het belang van het testen van de functies toe. Met Internettechnologie worden steeds meer applicaties gebouwd. Hier passen de capture/playback testtools, maar dan wel in een versie die de Internettechnologie ondersteunt.

Wij bieden u deze informatie zonder de software getest te hebben en kunnen geen verantwoordelijkheid aanvaarden bij problemen. Wel houden wij ons aanbevolen voor op- of aanmerkingen alsmede suggesties.


Sitemanagement In feite is dit type tool een verzameling van bovengenoemde functionaliteiten. Het voordeel voor de klant is dat er 1 tool is voor verschillende functionliteiten en diverse verschillende tools

Wij bieden u deze informatie zonder de software getest te hebben en kunnen geen verantwoordelijkheid aanvaarden bij problemen.
Wel houden wij ons aanbevolen voor op- of aanmerkingen alsmede suggesties.

Geen knoppenbalk links? Home R.I.M.      ©Copyright 2005       Disclaimer