Navigatie

Toelichting black-box testtechnieken Afdrukken
Voor de uitvoering van de Blackbox Testen binnen systeemontwikkeling projecten wordt afhankelijk van de situatie door Flexity gebruik gemaakt van de volgende testtechnieken: *Algoritme Test (AT), *Beslissingstabellen Test (BT), *Beoordeling aan de hand van een checklist (CL), *Dataflow Test (DFT), *Elementaire vergelijkingstest (EVT), *Error Guessing (EG), *Gegevenscyclus Test (GT), *Procescyclus Test (PCT), *Real life Test (RLT), *Semantische Test (SEM), *Beoordeling op basis van statistische gegevens (STAT) en *de Syntactische Test (SYN).

Zoals is aangegeven, zijn voor de black-box benadering een aantal testtechnieken beschikbaar. In de teststrategiebepaling worden de te gebruiken technieken bepaald op grond van de gedefinieerde kwaliteitsattributen. Later wordt in de fase voorbereiding de testbasis beoordeeld om de bruikbaarheid van de technieken vast te stellen, zodat later aan de onderverdeling van het systeem in testeenheden één of meerdere testtechnieken kan worden toegewezen. De meest gangbare technieken worden in het kort navolgend toegelicht met vermelding van: het doel, de kwalificatie (het geschikte toepassingsgebied), een korte uitleg van het principe en de coverage (de te meten kwaliteitsattributen met het soort fouten waar specifiek op gezocht kan worden).


Klik het plaatje "Blackbox Test" voor een grotere weergave »

Dataflowtest (DFT)

Doel: Uitgangspunt van de dataflowtest (DFT) wordt gevormd door de gegevensstromen en de verwerking daarvan. Het is een test waarbij de verwerking door en de relaties tussen functies wordt getest.

Kwalificatie: De dataflowtest is een informele testspecificatie techniek die zowel geschikt is voor on-line als batch-processen. Hoewel er duidelijke richtlijnen zijn hoe testgevallen geselecteerd worden, is de basis voor het selecteren van de testgevallen de intuïtie van de tester en zijn begrip van het testobject. Dit heeft als voordeel dat: gebruikers vanuit hun begrip van het informatiesysteem gemakkelijk een goede test kunnen samenstellen; de kwaliteit van de testbasis minder van belang is; er met relatief weinig inspanning goede testspecificaties kunnen worden gemaakt. Nadeel is echter de relatieve onvolledigheid van de test. Voor een meer volledige test is de elementaire vergelijkingentest beschikbaar.
Principe: Voor het maken van testgevallen wordt bij de dataflowtest gestart met een inventarisatie van de relevante begrippen. Per begrip wordt vervolgens bepaald welke waarden de procesgang beïnvloeden. Op basis hiervan wordt een aantal testgegevens samengesteld. Hiermee is de basis voor de test gelegd. Door de  testgevallen in een uitvoerbare volgorde te zetten en eventuele voorbereidende acties eraan toe te voegen wordt het testscript verkregen.
Coverage: De dataflowtest geeft een goede dekking voor wat betreft het gebruik van de functionaliteit zoals die in de praktijk verwacht wordt door direct expliciet te meten. Daarbij kan impliciet de controleerbaarheid gemeten worden door de opzet de in het kader van de controleerbaarheid genomen maatregelen, met behulp van de aanwezige functionele specificaties vast te stellen.
Fouten die met de dataflowtest worden gevonden zijn met name fouten in de verwerking: worden de gegevens goed gemanipuleerd, worden berekeningen goed uitgevoerd en sluiten de verschillende functies goed op elkaar.

Elementaire Vergelijkingentest (EVT)

Doel: De elementaire vergelijkingentest (EVT) is een specificatietechniek waarbij de verwerking gedetailleerd wordt getest. De test verifieert alle functionele paden van een functie.
Kwalificatie: De elementaire vergelijkingentest is een formele specificatietechniek die een goede mate van volledigheid garandeert maar daardoor juist zeer tijdsintensief is. Daarom moet de techniek vooral worden gebruikt bij het testen van functies en/of complexe berekeningen waaraan een groot belang is toegekend. De methode kan zowel in een batch als in een on-line omgeving worden toegepast.
Principe: De elementaire vergelijkingentest stelt hoge eisen aan de gedetailleerdheid van de uitgangsdocumentatie. De specificaties worden namelijk opgesteld door eerst alle functionele condities te inventariseren en te ontleden tot vergelijkingen in pseudo code. Indien de te ontleden documentatie ‘wollige' teksten bevatten of erg versnipperd is, is dit bepaald geen sinecure. Vervolgens kunnen voor de verschillende functionele paden, die worden onderscheiden binnen de vergelijkingen, testgevallen gedefinieerd worden.
Coverage: De functionaliteit zoals die in de documentatie verwoord is wordt direct expliciet gemeten. Net als bij de dataflowtest geldt dat de controleerbaarheid impliciet gemeten kan worden door de juistheid en volledigheid van de opzet te beoordelen op grond van de gemaakte testspecificaties. Het soort fouten die met de elementaire vergelijkingentest kunnen worden gevonden zijn met name fouten in de verwerking, de gegevens manipulatie en in (complexe) berekeningen.

Procescyclustest (PCT)

Doel: De procescyclustest (PCT) heeft tot doel de inpasbaarheid van het geautomatiseerde deel van het informatiesysteem binnen de AO-procedures te controleren.
Kwalificatie: De procescyclustest kijkt met name naar de raakvlakken ("interfaces") tussen de geautomatiseerde processen en de handmatige procedures. De aanname hierbij is dat de geautomatiseerde processen op zich conform de specificaties werken. De PCT is een formele structuurtest: de testgevallen komen voort uit de structuur van de "procedure flow" (net zoals in een programmatest de testgevallen voortkomen uit de structuur van het algoritme) en niet uit de (bewerkingen binnen de ) specificaties en kan zowel voor on-line als batch-processen worden gehanteerd.
Principe: Doordat tijdens de PCT geverifieerd wordt of de geautomatiseerde processen aansluiten op de handmatige procedures en vice versa, wordt antwoord verkregen op de volgende vragen: Geven de geautomatiseerde processen voldoende informatie om alle handmatige procedures te kunnen uitvoeren?
Levert de uitvoer van de handmatige procedures voldoende gegevens op om alle geautomatiseerde processen te kunnen starten? Beschikken de uitvoerenden over voldoende autorisatie om de procedures te kunnen uitvoeren?
Ieder testgeval bestaat derhalve uit een groep opeenvolgende acties die tezamen precies een "pad" door de procedure flow bepalen. Bij deze acties horen, in tegenstelling tot de testgevallen die met behulp van andere testspecificatie technieken worden vervaardigd, geen (expliciete) controles. De (impliciete) controle van een bepaalde actie is namelijk dat de volgende actie uitvoerbaar is. Het is dus voldoende om te controleren dat de rij acties inderdaad achtereenvolgens uitvoerbaar is.
Nog een verschil met de overige testspecificatie technieken is dat er bij de testuitvoering meer nodig is dan alleen de technische infrastructuur waar het geautomatiseerde deel van het informatiesysteem op draait. De handmatige procedures  worden namelijk uitgevoerd door mensen, hetgeen betekent dat er bij de testuitvoering meerdere testers nodig zijn die ieder een bepaalde rol spelen. Tenslotte zitten de benodigde gegevens slechts voor een deel in de database van het geautomatiseerde deel van het informatiesysteem maar voor de rest daarbuiten in de vorm van ingevulde formulieren. Ook dat is  een verschil  met de overige testspecificatie technieken.
Coverage: De mate waarin het informatiesysteem past in de organisatie (incl. de reeds aanwezige systemen) wordt direct expliciet gemeten. Ofwel de inpasbaarheid van het geautomatiseerde deel  van het informatiesysteem op de handmatige procedures en de overige informatiesystemen alsmede de tijdigheid van de informatieverstrekking. Ook wordt de werking van de autorisaties op de uit te voeren procedures (beveiliging) expliciet getest. Over het gemak waarmee de eindgebruiker kan leren omgaan met het informatiesysteem en het bedieningsgemak van het informatiesysteem voor ervaren gebruikers, ofwel de gebruikersvriendelijkheid, wordt tijdens de uitvoering meer duidelijkheid verkregen zodat er sprake is van een direct impliciete meting.

Real Life Test (RLT)

Doel: De real life test (RLT) is niet een specifieke testmethode zoals de dataflowtest of de syntactische test maar is een verzamelnaam van allerlei soorten tests om het gedrag van het systeem te kunnen voorspellen. Daarbij wordt ‘real life' gesimuleerd. De bekendste testsoort is de performancetest. Deze wordt uitgevoerd om de verwerkingssnelheid van het systeem, desgewenst onder verschillende belastingen, te meten. Tests van dit soort treft men vaak aan als acceptatietest voor het rekencentrum.
Kwalificatie: De real life test kan gebruikt worden voor het testen van batch en on-line systemen. Een performancetest wordt uitgevoerd onder de aanname dat het systeem technisch en functioneel correct is. De wijze van specificeren is informeel en hangt bij de performancetest af van de kennis die bekend is over het toekomstig gebruik van het systeem om een zo representatief testdraaiboek op te stellen met een zo getrouw mogelijke database.
Principe: Voor de performancetest wordt eerst een profielschets van het systeemgebruik bestaande uit een aantal scenario's gemaakt. De scenario's beschrijven de achtergrondbelasting (ruis) die aanwezig moet zijn tijdens de metingen. Achtergrondbelasting is de vooreen dagdeel representatieve belasting van het systeem, bijvoorbeeld in termen van de frequentie van aanroepen van bepaalde systeemfuncties. Een scenario kan op twee manieren worden uitgevoerd: met behulp van een ‘testtool' (test is reproduceerbaar); met behulp van een (grote) groep gebruikers.
Na het samenstellen van de draaiboeken worden de meetgevallen gespecificeerd en direct fysiek gemaakt. Een meetgeval is een uit te voeren test waarvoor prestatie-eisen zijn gesteld. Alle meetgevallen bij elkaar vormen het meetscript. Per scenario (dus bij verschillende achtergrondbelastingen) wordt het meetscript uitgevoerd. Tijdens de uitvoering meten ‘meelopende' instrumenten (‘monitoring-tools') het systeem. Deze meetinstrumenten registreren allerlei voor de performance interessante gegevens (o.a. Elapse-tijden, CPU-tijden, aantallen I/O's, ‘memory'-gebruik). Uit de analyse van deze gegevens kan na afloop informatie worden samengesteld over de behaalde performance-eisen van het systeem tijdens de verschillende scenario's.
Coverage: De performancetest meet direct expliciet de snelheid waarmee het informatiesysteem interactieve en batch-transacties  afhandelt ofwel de tijd die verloopt tussen het moment waarop men het informatiesysteem een bewerking opdraagt en het moment waarop het resultaat ter beschikking komt. Impliciet worden meetgegevens verzameld om de zuinigheid (communicatiebeslag, intern geheugenbeslag, extern geheugenbeslag en/of processorbeslag) te beoordelen.
Als de performancetest door een groep gebruikers wordt uitgevoerd in een ‘als het ware' productie omgeving wordt expliciet ook de mate van beveiliging gemeten.

Syntactische Test (SYN)

Doel: De syntactische test (SYN) heeft tot doel fouten te ontdekken in de lay-out van schermen en overzichten alsmede in de primaire invoercontroles met betrekking tot de schermrubrieken.
Kwalificatie: Dit testtype wordt met name gebruikt bij het testen van on-line systemen. Echter ook bij batch-systemen kan een syntactische test worden toegepast voor een lay-out-controle op de geproduceerde overzichten. Als toetscriteria worden de geldende standaards gebruikt, alsmede de specifieke beschrijvingen van schermen en overzichten in de functionele specificaties. Afhankelijk van de wijze waarop deze test wordt uitgevoerd (bijvoorbeeld aan de hand van een checklist) is de testspecificatie techniek meer of minder formeel.
Principe: Het grootste deel van de primaire invoercontroles kan worden bepaald door schermrubrieken te relateren aan de attributen uit het gegevensmodel en van deze attributen vervolgens bijvoorbeeld de toegestane veldlengte en het domein te bepalen. Ook worden de beschikbare opties geïnventariseerd en gerelateerd aan de schermen c.q. schermrubrieken. De controle op de presentatie van gegevens beperkt zich overigens niet alleen tot de schermen. Ook de uitvoer op papier wordt qua lay-out gecontroleerd. Als resultaat kunnen er twee toetslijsten (één voor schermen en één voor de overzichten) worden opgesteld. De testuitvoering is vervolgens relatief rechtlijnig.
Coverage: Het soort fouten dat met deze techniek kan worden gevonden op schermen en overzichten zijn ontbrekende of verkeerde velden, foutieve veldlengte, foutieve domeinwaarde of controle en velden op een foutieve plaats. Op deze wijze wordt de functionaliteit van de schermen en overzichten direct expliciet gemeten. Daarbij komt dat de gebruikersvriendelijkheid van de schermen en overzichten impliciet wordt gemeten.

Semantische Test (SEM)

Doel: De sematische test (SEM) heeft tot doel de relaties tussen gegevens bij het invoeren (de zogenaamde relatiecontroles) te verifiëren. Deze relaties kunnen aanwezig zijn tussen de gegevens binnen één scherm, tussen gegevens op verschillende schermen en tussen (invoer) gegevens en reeds in de database aanwezige gegevens.
Kwalificatie: Het is een formele testspecificatie techniek die met name wordt gebruikt bij het testen van on-line systemen. Syntactische tests kunnen parallel met de semantische tests worden uitgevoerd. Het verdient aanbeveling ook de testscripts van beide testtechnieken te combineren.
Principe: Semantisch testen start met het inventariseren van de relatiecontroles. Deze relatiecontroles worden ontleed in condities en paden: onder welke omstandigheden gebeurt wat. Deze condities worden middels testacties één voor één (per scherm) uitgetest.
Coverage: De semantische test kan worden gebruikt als een direct expliciete testtechniek in het kader van functionaliteit maar ook bij het testen van de beveiliging. De controle op de logische toegangsbeveiliging kan worden gezien als een relatiecontrole op de in het systeem aanwezige beveiligingsdefinities (o.a. autorisaties) en de invoer van bijvoorbeeld user-id en wachtwoord. Tevens wordt de gebruikersvriendelijkheid van de schermcontroles met de bijbehorende foutmeldingen en het autorisatie mechanisme impliciet gemeten.

Error Guessing (EG)

Doel: Error guessing (EG) is in wezen ongestructureerd testen. De waarde ervan ligt in het onverwachte: er worden tests uitgevoerd die anders met gestructureerd testen niet aan bod komen.
Kwalificatie: De tests zullen voornamelijk worden uitgevoerd op de systeemdelen, batch en/of on-line, die kwetsbaar of onduidelijk in kwaliteit zijn. Hiervoor worden geen formele en te beheren testspecificaties opgesteld. Wel moet achteraf gerapporteerd worden dat een EG is uitgevoerd met aanduiding van de geteste situaties.
Principe: Error guessing gaat uit van de "neus" van de tester en deze heeft dan ook de volledige vrijheid ter plekke testgevallen te verzinnen en uit te proberen. De tester moet dan ook op basis van een combinatie van testervaring, materiedeskundigheid en intuïtie de test uitvoeren.
Coverage: Het soort fouten dat door error guessing gevonden kan worden is zeer verschillend. Op bijna alle kwaliteitsattributen, uitgezonderd continuïteit, flexibiliteit, onderhoudbaarheid en testbaarheid kan gemeten worden. Bedacht moet worden dat deze techniek niets anders is dan met kennis van zaken ongestructureerd testen. Het is daarom slechts bedoeld als aanvulling op de geselecteerde gestructureerde testtechnieken.

Gegevens Cycli Test (GCT)

Doel: Met de gegevens cycli test (GCT) wordt de volledigheid en de logica van de gegevens getest. Gegevens ontstaan, worden gelezen, worden gewijzigd en verdwijnen uiteindelijk weer, in het Engels: create, retrieve, update, delete (crud).
Kwalificatie: De gegevens cycli test is een informele techniek die geschikt is voor batch als on-line functies. Door de crud-matrix uit te breiden van functie niveau naar systeembreed kan de integratie tussen de verschillende functies getest worden.
Principe: Door per proces te inventariseren welke gegevens op wat voor manier worden gebruikt en vervolgens per gegeven te sorteren kan eenvoudig inzicht worden verkregen in de levensloop van de gegevens. Op basis hiervan kunnen testgevallen worden gecreëerd om te verifiëren dat de verschillende processen de gegevens correct gebruiken.
Coverage: Het soort fouten dat wordt gevonden zijn voornamelijk de ontbrekende stappen in de crud-matrix en fouten in de referentiële integriteit. Direct expliciet wordt de functionaliteit van de levensloop van gegevens gemeten.

 
blackbox.jpgblackbox_small.jpg

 

Flexity Test Approach

Organizing
Modelling
Engineering
Executing
Consulting & Delivering