DAG 3 Testtechnieken deel 1 Algemene informatie Syntactisch testen

Presentatie over: "DAG 3 Testtechnieken deel 1 Algemene informatie Syntactisch testen"— Transcript van de presentatie:

1 DAG 3 Testtechnieken deel 1 Algemene informatie Syntactisch testen
Semantisch testen Rechterkant van V-model: daadwerkelijke testen, hiervoor heb je de software nodig 1

2 Elementaire vergelijkingstest
Testtechnieken Testtechniek Beslistabeltest Exploratory testing Real life test Datacombinatietest Gegevenscyclustest Semantische test Elementaire vergelijkingstest Grenswaardenanalyse Syntactische test Error guessing Procescyclustest Use case test Overzicht te gebruiken testtechnieken volgens Tmap-Next Rechterkant van V-model: daadwerkelijke testen, hiervoor heb je de software nodig 2

3 SysteemIntegratieTest
Testtechnieken (1) White box Black box Formeel Informeel ProgrammaTest IntegratieTest SysteemIntegratieTest SysteemTest GebruikersAcceptatieTest KetenTest ProductieAcceptatieTest Programmabeschrijving Technisch Ontwerp Logisch Data Model Fucntioneel Ontwerp CRUD-matrix Gebruikers eisen & wensen AO-procedures Beheerders eisen & Beheerdershandleiding Productiehandleiding Beveiliging Bruikbaarheid Continuïteit Controleerbaarheid Fucntionaliteit Gebruikersvriendelijkheid Inpasbaarheid Performance Zuinigheid Must Should Could Would ALG X BTT DFT EVT GCT PCT PIT RLT SEM SYN ERR Testsoort Prioritering productrisico’s < algemene kennis van het systeem > Testbasis Dynamische kwaliteitsattributen Overzicht sheet. Rechterkant van V-model: daadwerkelijke testen, hiervoor heb je de software nodig 3

4 Doel: afleiden testgevallen
Invoer Uitgangssituatie Testacties Veranderingsproces Verwacht resultaat Benodigd: relevante documentatie, testdoelstelling (waarom is de specificatie gemaakt) 4

5 Testsituaties Definitie:
Testsituatie is een geïsoleerde omstandigheid waaronder het testobject een specifiek gedrag vertoont en die getest dient te worden. Een bestelling van meer dan 1 boek Gerelateerd hieraan: een bestelling van precies 1 boek Evt korting die gegeven wordt bij een grens Orderbedrag boven de drempelwaarde Orderbedrag beneden de drempelwaarde Testgevallen: Met een testgeval wordt onderzocht of het systeem onder bepaalde omstandigheden het gewenste gedrag vertoont. Input---processing---resultaatvoorspelling(output) 5

6 Logische testgevallen
Beschrijft in logische termen de omstandigheden waarin het systeemgedrag onderzocht wordt, door aan te geven welke testsituaties door het testgeval gedekt worden Bestelling van meer dan 1 boek waarbij het orderbedrag beneden de drempelwaarde blijft Bestelling van 1 boek met een bedrag dat boven de drempelwaarde ligt. Wat de testsituaties zijn Dat alle gedefinieerde testsituaties afgedekt zijn met testgevallen 6

7 Fysieke testgevallen Is de concrete uitwerking van een logisch testgeval, waarbij keuzes gemaakt zijn voor de waarden van alle benodigde invoer en instellingen van de omgevingsfactoren. Initiële situatie (geldig voor beide testgevallen) Drempelbedrag €50 Korting = 10% Prijs boek = €18,50 = €25,50 = €65,00 TG-1: Actie: bestel boek-01 en boek -02 Resultaatvoorspelling = er wordt geen korting verleend Orderbedrag = €44,00 TF-2: ACTIE: BESTEL BOEK-03 RESULTAATVOORSPELLING: er wordt korting verleend van 10% Orderbedrag = €58,50 (€65,00 - €6,50) LT beschreven in vorige dia worden nu fysiek gemaakt. 7

8 Dekking, Dekkingsvorm en Dekkingsgraad
Dekking is de verhouding tussen datgene wat getest kan worden en datgene wat met de testset getest wordt Zegt iets over: hoeveel van alle mogelijkheden die getest kunnen worden er ook daadwerkelijk getest wordt. Dekkingsvorm is de vorm waarin het afdekken van de te testen situaties die afleidbaar zijn uit de testbasis uitgedrukt worden Geeft aan wat voor soort mogelijkheden beschouwd worden.(mogelijke combinaties van paden) Dekkingsgraad geeft aan hoeveel percentage er getest gaat worden 8

9 Waarom dekking Als het toch onmogelijk is om alles te testen en we dus gedwongen zijn om slechts een subset van alle mogelijkheden te testen, wat is dan de beste subset Wat is nu eigenlijk precies het verschil tussen iets zwaar testen en iets licht testen? Wat betekent dat concreet voor de testgevallen die we daarvoor nodig hebben. Dekking heeft alles te maken met de wens om met zo min mogelijk testgevallen zo veel mogelijk fouten te vinden. 9

10 Voorbeelden van bruikbare combinaties
Paden + equivalentieklassen: Procesverloop van “Orders – Leveren – Betalen” is gespecificeerd in een processchema. Dit wordt getest met paden-dekking testmaat-2. Variaties in soorten orders en in manieren van betalen worden ontworpen met behulp van equivalentieklassen CRUD + Beslispunten: Van de gegevens order, levering en betaling wordt een CRUD matrix samengesteld. Er zijn integriteitsregels gespecificeerd voor de mogelijke bewerkingen van de gegevens. Deze zijn formeel beschreven, zoals bv: “Als conditie-A OF (conditie-B EN conditie-C) DAN bewerking niet toegestaan”. Deze regels worden afgedekt door het toepassen van modified condition / descision coverage. 10

11 Belang testontwerptechnieken
Geeft een onderbouwde invulling van de teststrategie: afgesproken dekking op de afgesproken plaats Tests zijn reproduceerbaar Gestandaardiseerde werkwijze maakt testproces onafhankelijk van persoon die de testgevallen specificeert en uitvoert Gestandaardiseerde werkwijze maakt de specificaties overdraagbaar en onderhoudbaar Testproces is beter planbaar en beheersbaar 11

12 Syntactische test (1) Verificatie van user-Interface
Kwaliteitsattributen Functionaliteit Gebruikersvriendelijkheid Validatie test waarmee de geldigheid van de invoergegevens getest wordt. Vaststellen in hoeverre het systeem bestand is tegen ongeldige of onzinnige invoer. Syntactische regels kunnen in verschillende documenten vastgelegd zijn: Data dictionary, functionele specificaties 12

13 Syntactische test (2) Doel:
Ontdekken van fouten in de lay-out van schermen, overzichten en in de primaire invoercontroles met betrekking tot de rubrieken Als toetscriteria kunnen geldende standaards worden gebruikt en specifiek beschrijvingen van schermen en overzichten in de functionele specificaties 13

14 Syntactische test (3) Stappen:
1: Identificeren testsituaties / checklisten Rubriekcontroles, voor de validatietest Datatype [numeriek, alfanumeriek,etc] Veldlengtes [invoervelden, min/max] Invoer/Uitvoer [geen waarde getoond, waarde niet te wijzigen, waarde mag gewijzigd worden] Defaults Verplicht / niet verplicht Selectiemechanisme Opmaakcontroles, voor de presentatietest. Kopregels / voetregels Schermnaam / lijstnaam Systeemdatum / afdrukdatum Versienummer Rubrieken Naamgeving van de rubriek Plaats van de rubriek op het scherm Weergave van de rubriek (lettertype, kleur) 14

15 Syntactische test (3) Stappen: Opstellen logische testgevallen
De testsituaties uit stap 1 zijn direct de logische testgevallen Opstellen fysieke testgevallen (zie volgende sheet voor voorbeeld) Vaststellen uitgangssituatie: meestal zijn er geen speciale eisen aan de uitgangssituatie 15

16 Syntactische test (4) Voorbeeld van fysieke testgevallen bij de SYN-test Scherm 2.6 Altijd fout Altijd goede Waarde Veld Te vel tekens Te weinig tekens Verkeerde Buiten range Min waarde Max waarde Bankgroep >5 <5 Num Nvt 00001 55555 Vervaldatum >4 <4 **01-**02 0001 9912 Postcode >6 <6 Alfanum 9999XX 1000AA 9999ZZ Pinind >1 <1 alfa {J,N} J N 16

17 Syntactische test (5) Opstellen checklist:
Dient gedaan te worden gedurende de testspecificatie fase (TMap NEXT® fasering) Vaststellen welke syntactische controles uitgevoerd dienen te worden Resultaat: checklist voor de geselecteerde schermen checklist voor de geselecteerde overzichten 17

18 Semantische test (1) Vooral gebruikt bij online systemen (systeemtest, acceptatietest) Black Box testtechniek Testbasis: functionele specificaties, business rules die overkoepelend voor alle functies gelden Kwaliteitsattributen Beveiliging Functionaliteit Gebruikersvriendelijkheid Validatietest Behoort samen met de syntactische test tot de validatietests waarmee de geldigheid vd invoergegevens getestt wordt. 18

19 Semantische test (2) Doel:
De relaties tussen gegevens bij het invoeren verifiëren De relaties tussen gegevens binnen een scherm verifiëren De relaties tussen verschillende schermen verifiëren De relaties tussen invoer en reeds aanwezige input in database verifiëren 19

20 Semantische test (3) Stappen: Inventariseren relatiecontroles;
Uitwerken relatiecontroles; Vaststellen testacties en controles; Vaststellen initiële gegevensverzameling; Opstellen testscripts. 20

21 Semantische test (4) Inventariseren relatiecontroles:
Doorlezen testbasis Bepalen relatiecontroles (op scherm niveau) Controles krijgen een unieke identificatie 21

22 Semantische test (5) Uitwerken relatiecontrole:
Gevonden relaties controles uitschrijven in de vorm van enkelvoudige vergelijking Terminologie die gebruikt wordt: ALS, DAN, ANDERS Bij samengestelde vergelijking tevens de termen: EN, OF 22

23 Semantische test (6) Voorbeeld: A EN B (beiden dienen waar te zijn)
ALS A DAN ALS B DAN correcte invoer/actie ANDERS Foutboodschap A OF B (één hoeft maar waar te zijn) ALS A ANDERS ALS B ANDERS foutboodschap ALS (semantische regel). Semantischeregel is een beslispunt die bestaat uit 1 of meer condities verbonden door EN en OF 23

24 Semantische test (7) Voorbeeld
ALS einddatum oude adres >= ingangsdatum nieuwe adres (a) DAN foutboodschap testpad 1 ANDERS correcte invoer testpad 2 Twee testpaden onderkend: Testpad 1: conditie A is waar Testpad 2: bewering is onwaar Voorbeeld met meerdere paden ALS minimum voorraadcode gelijk is aan S(ignaal) a DAN ALS aantal minimum voorraad = 0 b foutboodschap 103 testpad 1 ANDERS correcte invoer testpad 2 correcte invoer testpad 3 24

25 Semantische test (8) Vaststellen testacties en controles
Het testen van de testpaden gebeurt door het uitvoeren van testacties In principe genereert ieder testpad en bijbehorende testactie en eventuele controle Met betrekking tot het voorraadsysteem: A01: invoeren min. voorraadcode S en aantal minimum = 0 A02: invoeren min. voorraadcode S en aantal minimum = 200 A03: invoeren min. voorraadcode = B Bij het uitvoeren van A01: juiste foutboodschap wordt getoond 25

26 Semantische test (9) Initiële gegevensverzameling
Controleren of dit noodzakelijk aanwezig dient te zijn voor het kunnen uitvoeren van de opgestelde testscenario’s Opstellen testscripts Acties beschreven die dienen te worden uitgevoerd bij de daadwerkelijke testuitvoer en op volg tijdelijke wijze Testuitvoering en beoordeling Uitvoering middels de opgeleverde scripts Beoordeling middels verwachte resultaat versus daadwerkelijke resultaat 26

27 Semantische test Uitwerken meegeleverde oefening in cursusmap:
Functioneel Ontwerp: “Opvoeren Klant” 27

28 Semantische test Samenvatting: Validatietesten (Syntactisch)
Geldigheid van de invoer Testbasis:Semantische regels die specificeren waar een gegeven aan moet voldoen om als geldige invoer te worden geaccepteerd. Relatie tussen gegevens Functionele specificaties, Business rules Semantische regels = Beslissingspunten die bestaan uit samengestelde condities Default keuze testcoverage: condition / decision coverage 28

29 Semantische test Samenvatting: Varianten
Condition / decision: lichte variant Multiple condition coverage: zware variant Aandachtspunten: Identificeren testsituaties Opstellen logische testgevallen Opstellen fysieke testgevallen Vaststellen uitgangssituatie. 29

30 Semantische test Voorbeeld:
Semantische controle regel: Als klant in Nederland woont EN (postcode voldoet niet aan Nederlands formaat OF landcode is niet gelijk aan 31) DAN resulteert dit in een foutmelding B1 A EN (B of C) 1 Foutmelding 0n Geldige invoer A: klant in Nederland 1,1, (1) 0,1, (3) B: postcode niet in NL 1,1,0 1,0, (4) C: landcode ongelijk aan 31 1,0,1` (2) 1,0,0 Enkelvoudige conditie zijn er slechts twee testsituaties: geldige invoer, ongeldige invoer Samengestelde condities worden de testsituaties afgeleid door het toepassen van modified condition / decision coverage (MCDC) 30

31 Semantische test Voorbeeld:
Semantische controle regel: Als klant in Nderland woont EN (postcode voldoet niet aan Nederlands formaat OF landcode is niet gelijk aan 31) DAN resulteert dit in een foutmelding Testgevallen B1-1 B1-2 B1-3 B1-4 Klant In NL Niet NL Postcode Niet in NL Landcode 31 Ongelijk 31 resultaatverwachting foutmelding OK 31

32 Testtechnieken EINDE Testtechnieken deel I 32

33 Testtechnieken deel II
VERVOLG Testtechnieken deel II Grenswaarde analyse CRUD-MATRIX Exploratory Testing Use case testing 33

34 Grenswaarde analyse Als het systeemgedrag verandert zodra de waarde van een parameter een bepaalde grens overschrijdt, is er sprake van een zogenaamde grenswaarde Voorbeeld: Voor wat betreft de leeftijd zijn de regels voor het al of niet Verstrekken van een lening als volgt: Jonger dan 18: geen lening Van 18 t/m 55: standaard lening verstrekken Ouder dan 55: duurdere lening verstrekken Drie equivalentieklassen aanwezig voor de parameter leeftijd 18 en 55 zijn de grenswaarden 34

35 Grenswaarde analyse Techniek:
Bepaal de grenswaarden bij de betreffende equivalentieklasse of conditie Definieer de volgende drie testsituaties: Precies op de grens Direct erboven Direct er onder 35

36 Grenswaarde analyse De parameter leeftijd heeft drie equivalentieklassen en twee grenswaarden (18 en 55) Aantal testsituaties: Geen grenswaarde: 3 testsituaties (12, 32, 64) Normale: 6 testsituaties (17, 18, 19 en 54, 55, 56) Lichte: 4 testsituaties (17, 18, 55, 56) 36

37 Grenswaarde analyse Niet alleen van toepassing op de invoerkant van een systeem, maar ook op de uitvoerkant. Voorbeeld: Offertepagina mag maximaal 10 regels bevatten Grenswaarde analyse wordt dan: 9 regels 10 regels( alle regels op 1 pagina 11 regels (elfde regel op tweede pagina) 37

38 CRUD Gegevens opgeslagen in een systeem kennen een levensloop.
Creëren gegeven (C) Gegeven wordt geraadpleegd (R) Gegeven wordt gewijzigd (U) Gegeven wordt verwijderd (D) Create, Read, Update, Delete Samenstellen CRUD-matrix: hiervoor worden alle functies van het systeem doorlopen Welke entiteiten door deze functie gebruikt worden Welke acties ( C, R,U,D) op deze entiteiten worden uitgevoerd. 38

39 CRUD Levensloop: Volledigheidscheck: statische test waarbij in de matrix onderzocht wordt of alle vier mogelijke acties (CRUD) bij iedere entiteit voorkomen Is voor iedere entiteit de volledige levensloop geïmplementeerd Consistentietest: dynamische test die zich richt op de integratie van de verschillende functies. Controle: of de verschillende functies op een consistente manier een gegeven gebruiken Controleer iedere wijziging van de entiteit middels een R (read)Gegeven correct bewerkt is en bruikbaar is voor andere functies 39

40 CRUD-Matrix 40 Factuur Artikel Beheren artikelen - C,U,D
Aanmaken factuur C R Balie-betaling C,R,D …………. ……… ………… Voorbeeld van en CRUD-Matrix 40

41 CRUD Een zware dekking van CRUD kan gerealiseerd worden door te eisen dat ook combinaties van acties volledig gedekt zijn. B.v: door te eisen dat na iedere “U” alle functies met een “R” uitgevoerd moeten worden. Zie uitwerking volgende dia 41

42 CRUD Stel dat de entiteit “ORDER”door de volgende functies als volgt bewerkt wordt: Aanmaken order (C); Annuleren order (D); Deellevering (U); Overzicht orders (R); Voorraadplanning (R) De standaard dekking van CRUD wordt dan al bereikt met het volgende testgeval Aanmaken order (C) Voorraadplanning (R) Deellevering (U) Overzicht orders (R) Annuleren order (D) Risico: de volgende fout zou niet gevonden worden: Na een deellevering klopt de voorraadplanning niet meer, omdat die (onterecht) de gehele order als geleverd beschouwt. Hoe vinden deze fout wel 42

43 CRUD Met zware dekking wordt deze fout wel gevonden:
Aanmaken order (C) Overzicht orders (R) Voorraadplanning (R) Deellevering (U): (veroorzaakt fout in “Voorraadplanning”) Voorraadplanning (R) (fout wordt ontdekt) Annuleren order (D) 43

44 Explorarory testing Door James Bach als begrip en aanpak neergezet en beschreven: “het simultaan leren, ontwerpen en uitvoeren van tests, met andere woorden elke vorm van testen waarbij de tester zijn testen ontwerpt tijdens de testuitvoering en de informatie die wordt verkregen tijdens het testen wordt gebruikt om nieuwe en betere testgevallen te ontwerpen.” 44

45 Exploratory testing(2)
Geen pure test specificatietechniek Tester maakt tijdens de testuitvoering telkens een keuze over welke test hij wil uitvoeren Tester ontwerpt ter plekke een test, gebruikmakend van zijn kennis van test specificatietechnieken, zonder deze te documenteren Geen plaats in de fase specificatie Geen specifieke fase Specificatie aanwezig. Testgevallen worden gedurende fase uitvoering gemaakt. 45

46 Exploratory testing(3)
Elementen van Exploratory testing: Wat ga je testen (binnen de scope, testopdracht) Wat gaan we niet testen (buiten de scope) Waarom gaan we dit testen Hoe gaan we dit testen Verwachte problemen (waar denk je dat het mis gaat) Referentie gegevens Deze gegevens worden gedocumenteerd in een Test Charter. Deze wordt meegegeven. Testgevallen worden gedurende fase uitvoering gemaakt. 46

47 Exploratory testing(4)
Tester verkent steeds een stukje van het te testen systeem Tester denkt na over wat er getest moet of kan worden (testontwerp) Tester brengt dit ter uitvoering (testuitvoer) Hierdoor doet de tester gelijk weer nieuwe kennis op over het systeem, en denkt na over wat er vervolgens getest moet worden Testgevallen worden gedurende fase uitvoering gemaakt. 47

48 Exploratory testing(5)
Ontwerpen en uitvoeren van de tests gebeurt daarmee zeer dicht op elkaar Vastleggen van het testgeval is niet nodig Er vindt dus wel testontwerp plaats in tegenstelling tot ad-hoc of ongestructureerd testen Testgevallen worden gedurende fase uitvoering gemaakt. 48

49 Exploratory testing(6)
Moeilijk op één lijn te plaatsen met de overige testontwerp technieken Niet gebaseerd op een van de basis technieken Laat keuze te gebruiken techniek vrij aan de tester Geeft geen gegarandeerde dekking Testgevallen worden gedurende fase uitvoering gemaakt. 49

50 Exploratory testing(7)
Testen zonder formele testbasis zoals een functioneel ontwerp Legt minder nadruk op een beschreven testbasis en meer op andere manieren om te beoordelen of het testobject voldoet Testgevallen worden gedurende fase uitvoering gemaakt. 50

51 Exploratory testing(8)
Toe te passen als: Ervaren testers met materiekennis beschikbaar zijn waarin men voldoende vertrouwen heeft Zo goedkoop mogelijk testen verreweg de belangrijkste overweging is Er onvoldoende gedocumenteerde testbasis is Aanvulling op het testen volgens formele technieken met als doel creatief testen te stimuleren Er geen tijd beschikbaar is om de tests voor te bereiden Testgevallen worden gedurende fase uitvoering gemaakt. 51

52 Exploratory testing(9)
Niet toe te passen als: Er hogere eisen aan de aantoonbaarheid/verslaglegging van testen worden gesteld, bijvoorbeeld door opgelegde standaards Er sprake is van kritische functionaliteit waarvan het falen grote schade kan veroorzaken Het testteam bestaat uit onervaren testers De testgevallen moeten kunnen worden uitgevoerd door een andere tester De testgevallen herbruikbaar moeten zijn Testgevallen worden gedurende fase uitvoering gemaakt. 52

53 Exploratory testing(10)
Niet toe te passen als: Er geen rechtstreekse feedback van testuitvoering is, zodat de resultaten niet direct beschikbaar zijn Er sprake is van testen die veel voorbereiding vergen Testen zo kort mogelijk op het kritieke pad van het project moeten zitten Testgevallen worden gedurende fase uitvoering gemaakt. 53

54 Exploratory testing(11)
Stappen: Input velden Juiste data Onjuiste data Veldlengte = max. Veldlengte = max. +1 Acties Toevoegen Updaten verwijderen Testgevallen worden gedurende fase uitvoering gemaakt. 54

55 Exploratory testing(12)
Benodigde vaardigheden van de tester: Testontwerp vaardigheden Observatievermogen Kritisch kunnen denken Terug kunnen vallen op ervaringen Juiste vragen kunnen stellen Verder kunnen denken dan gewenst Materiedeskundigheid ET dan ook allen gebruiken met ervaren testers Testgevallen worden gedurende fase uitvoering gemaakt. 55

56 Exploratory testing(13)
Voordelen Exploratory testing Snel schakelen Adequaat reageren Snel kunnen starten Teamwork Bredere kennisontwikkeling tussen ontwikkelaar en tester Snel resultaat Geschikt voor kleine projecten Testgevallen worden gedurende fase uitvoering gemaakt. 56

57 Exploratory testing(14)
Nadelen Exploratory testing Gezelligheid binnen team/balans zien te vinden Veredelde error guessing Charter moeten opstellen Kosten aspect Kritische/risicovolle delen Testgevallen worden gedurende fase uitvoering gemaakt. 57

58 Exploratory testing(15)
Status van Exploratory testing: Er is nog geen eenduidige aanpak Goeroes: James Bach Cem Kaner Stale Almland James Whittaker Testgevallen worden gedurende fase uitvoering gemaakt. 58

59 Exploratory testing(15)
Verschillen tussen Error guessing en ET Error guessing Exploratory testing Maakt geen gebruik van de basistechnieken Maakt afhankelijk van de situatie gebruik van de meest passende basistechniek Geschikt voor testers, gebruikers, beheerders Geschikt voor ervaren tester met kennis van de basistechnieken De testgevallen worden in de fase Specificatie of tijdens testuitvoering ontworpen De testgevallen worden tijdens fase uitvoering ontworpen Richt zich op de uitzonderingen en moeilijke situaties Richt zich op het totaal van een te testen aspect (scherm, functie) Niet systematisch, geen enkele zekerheid over dekking Enigszins systematisch Testgevallen worden gedurende fase uitvoering gemaakt. 59

60 Use Cases(1) Bevat een typische interactie tussen een gebruiker en
een systeem. De use case beschrijft een compleet stuk functionaliteit dat een systeem aanbiedt aan een gebruiker en dat een voor de gebruiker observeerbaar resultaat oplevert Testgevallen worden gedurende fase uitvoering gemaakt. 60

61 Use Cases(2) Definitie volgens Tmap-Next: Een Use case bevat een typische interactie tussen een gebruiker en een systeem. De use case beschrijft een compleet stuk functionaliteit dat een systeem aanbiedt aan een gebruiker en dat een voor de gebruiker observeerbaar resultaat oplevert Testgevallen worden gedurende fase uitvoering gemaakt. 61

62 Use Cases(3) Testbasis Bevat minimaal de use cases en bij voorkeur ook het bijbehorende use case diagram Wordt gebruikt bij het testen van de kwaliteitsattributen Inpasbaarheid; Bruikbaarheid; Gebruikersvriendelijkheid. Testgevallen worden gedurende fase uitvoering gemaakt. 62

63 Use Cases(4) Use case kan op diverse manieren worden beschreven: controle uit voeren om te onderzoeken of de gehanteerde use case beschrijving voldoende informatie bevat om voor de use case te kunnen worden gebruikt. Gebruik van een checklist Use case: om te bepalen of een use case bruikbaar is voor het toepassen van de use case test, is afhankelijk van de manier waarop de use case is beschreven Op de volgende dia staan een aantal controles beschreven Testgevallen worden gedurende fase uitvoering gemaakt. 63

64 Use Cases(5) Is de (standaard voor project/organisatie) use case sjabloon volledig ingevuld? Is de use case diagram aanwezig Is de use case een op zichzelf staande taak Is het duidelijk voor welke actor de use case is bedoeld Heeft de use case betrekking op functionaliteit (dus niet op schermverloop) Zijn alle bekende uitzonderingen beschreven Zijn de beschreven stappen uitvoerbaar Is het resultaat van de stappen controleerbaar Use case test richt zich op het afdekken van de interacties tussen de gebruikers en het systeem. De basis techniek die hierbij gebruikt is: Afvinklijst Testgevallen worden gedurende fase uitvoering gemaakt. 64

65 Use Cases(6) Use case diagram: beschrijft een (gedeelte van de) functionaliteit. Een use case diagram geeft de systeemgrenzen aan, geeft mogelijke onderlinge relaties tussen use cases weer, en laat vooral zien welke relaties er zijn tussen de actoren (gebruikers) en de use case. Bestaat uit de volgende symbolen: Poppetje om de actor aan te geven Ovaal om een use case aan tegeven Lijnverbinding tussen actor en use case, of tussen use cases onderling 65

66 Use Cases(7) Use case onderlinge relaties Extend:
Wordt gebruikt als een al aanwezige use case overeenkomt met een andere use case, maar iets extra’s doet. Dit extra is uit de use case gehaald en in een aparte use case geplaatst Include: Als een bepaald gedrag in meerdere use cases voorkomt, wordt dit er meestal uitgemodelleerd in plaats van herhaald voorbeeld: use case die de burgerlijke staat van een persoon nagaat. Deze kan gebruikt worden voor; Bepalen belastingtarief Aanpassen burgerlijke staat 66

67 Use Cases(8) Use case sjabloon: name = naam use case
actor = naam persoon om wie het gaat precondities= waar moet aan voldaan zijn alvorens je kunt starten primaire scenario = normaal scenario uitzondering(en) = andere scenario’s die mogelijk zijn Scope (betreft het een systeem of subsysteem) Level (betreft het een primaire taak of subtaak) Stakeholder Trigger 67

68 Use Cases(8a) Voorbeeld Use Case template 68 Name Toets starten Actor
Cursist Pre conditions Cursist heeft opleiding testtechnieken gevolgd Primary scenario 1: cursist start het “Testontwerptechniek Toest”programma 2: Include <inloggenTot toets> 3: maakt keuze uit de technieken 4: kiest evt voor de optie “geven van Uitleg” 5: kiest evt voor de optie “geven van tussenstanden 6: programma staat klaar voor de eerste vraag Exceptions 1: cursist drukt op vraag knop, terwijl de vorige vraag niet is beantwoord 2: tikt iets in het invoerveld terwijl de vraag al is beantwoord 3: stopt terwijl er nog geen 10 vragen zijn beantwoord Post condition Cursist kan beginnen met de uitgekozen test 68

69 Use Cases(9) Stappen: Identificeren testsituaties
Zoek variabelen die een reactie van het systeem of omgeving tot gevolg hebben Bepaal het domein van de variabelen Bepaal welke variabelen een relatie met elkaar hebben Opstellen logische testgevallen Opstellen fysieke testgevallen Vaststellen uitgangssituatie 69

70 Huiswerkopdracht TMap Next®, doorlezen:
Hoofdstuk 14 : Testontwerptechnieken (besproken testontwerptechnieken Overige testontwerptechnieken vrijblijvend doorlezen 70

71 Testtechnieken deel II
Einde dag 3 Testtechnieken deel II 71

72 Dag 4 Testtools Testorganisatie Ondersteunende processen
Testomgevingen 72

73 Testtools (1) Definitie: Een testtool is en geautomatiseerd hulpmiddel dat ondersteuning biedt aan een of meer testactiviteiten, zoals plannen, beheren, specificeren en uitvoeren. Voorwaarde voor succesvol gebruik van testtools: aanwezigheid van een gestructureerde testaanpak. 73

74 Testtools (2) Soorten testtools:
Tools voor het plannen en beheren van de tests Tools voor het ontwerpen van de tests Tools voor het uitvoeren van de tests Tools voor het debuggen en analyseren van de code De eerste drie testtools worden voornamelijk gebruikt door de testers in het onafhankelijke testteam 74

75 Testtools (3) Plannen en beheren van de test: Testware beheertool
Bevindingen beheertool: TestDirector/Quality Center Plannings- en voortgangsbewakingstool: MS-Project Workflow tool 75

76 Testtools (4) Ontwerpen van de test: Testdatatool Testontwerptool
“Model based testing”-tool: Dit is een aanpak waarbij op basis van een model van het testobject, testgevallen worden ontworpen. 76

77 Testtools (5) Uitvoeren van de test:
Geautomatiseerde testuitvoerings tool: Record & Playback (GUI) Performance- load- en stresstool Monitor: Geheugenbeslag, CPU-gebruik, Netwerkbelasting Code coveragetool: leveren informatie over welke delen van de programmacode tijdens het testen zijn doorlopen Comparator: Vergelijkingstool, vergelijkt data en rapporteren de verschillen Databasemanipulatietool: SQL, controles uitvoeren in de database Simulator: bootst de werking van de omgeving van het te testen testobject na. Stubs and drivers: 77

78 Testtools (6) Uitvoeren van de test: Stubs and drivers: A A Driver B
78

79 Testtools (7) Voordelen gebruik van tools: Hogere productiviteit;
Hogere kwaliteit testen; Hogere arbeidsvreugde; Uitbreiding testmogelijkheden. 79

80 Testprojectorganisatie
Voorbeeld Projectmanager Testmanager Testcoördinator Testcoördinator Testcoördinator per project invulling gegeven aan een bepaald aspect van het testproces. Rollen, taken, bevoegdheden en veranntwoordelijkheden worden voor het testproject gedefinieerd. Testanalisten Testers Testanalisten Testers Testautomatiseerders 80

81 Testorganisatie orbeeld Manager testafdeling Testmanagers
Testcoördinatoren Testanalisten Project W Project Y Project X Project Z 81

82 Ondersteunende processen
Testbeleid: Het testbeleid beschrijft hoe een organisatie omgaat met de mensen, middelen en methoden rondom het testproces in de verschillende situaties. Dient te gelden voor alle typen systemen, infrastructuren en ontwikkelmethoden. 82

83 Ondersteunende processen
Strategische ondersteuning: Voorwaarden stellen aan de interne (IT) organisatie Kwaliteitsdoelstellingen Welke mogelijkheden er zijn waarmee die verwezenlijkt moeten worden Kan gevormd worden door wensen eisen die van binnen de organisatie komen Factoren van buiten af kunnen ook een rol spelen (eisen die gesteld worden vanuit externe toezichthouders, (lokale) wettelijke verplichtingen waaraan voldaan moet worden of brancheafspraken 83

84 Ondersteunende processen
Tactische ondersteuning: strategisch beleid wordt vertaald naar HOE het in de operatie uitgevoerd gaat worden. Opstellen van voorschriften die aangeven: binnen welke randvoorwaarden en normen, de middelen en de methoden moeten worden ingezet om de strategische doelstellingen te realiseren. Beschrijven hoe binnen een organisatie, afdeling, productgroep, programma of project (afhankelijk van de inrichting van de betreffende organisatie), inhoud gegeven moet worden aan een gestructureerde testaanpak 84

85 Ondersteunende processen
Operationele ondersteuning: Ondersteuning van het testproces: Onderwerpen rond methodisch, technisch en functioneel advies aan de tester(s) Ondersteuning werkelijke uitvoering van het testproces Het testen zelf Testmanagement 85

86 Testomgevingen Voor het dynamisch testen van een testobject (runnen van software) is een passende testomgeving nodig Inrichting en beheren van de testomgevingen is een expertise waar testers over het algemeen geen kennis van hebben Definitie: een testomgeving is een samenstel van onderdelen zoals hard- en software, koppelingen, omgevingsdata, beheertools en processen waarin een test wordt uitgevoerd. 86

87 Testomgevingen Eisen die aan de inrichting worden gesteld:
Representatief: de testomgeving dient (zoveel mogelijk) de eigenschappen te hebben die nodig zijn voor de beoogde test. Beheersbaar: noodzakelijk om het testobject steeds onder dezelfde omstandigheden te kunnen testen, duidelijk zijn welke versie er in de omgeving staat (software, besturingssysteem, databasemanagementsysteem, etc) Flexibel: Moet snel aangepast kunnen worden Continu: De gevolgen van een storing moten tot een minimum beperkt blijven. Hulpmiddel kan zijn, het maken van back-ups aan het einde van bv iedere testdag.(hierdoor kun je altijd terug naar de beginsituatie van de dag) 87

88 Testomgevingen OTAP-model: Ontwikkeling, Test, Acceptatie, Productie.
Het model heeft als uitgangspunt dat iedere gebruiker van de infrastructuur ongestoord zijn werk wil doen en van niemand anders last wil hebben. Model schrijft niet voor dat er 4 omgevingen zijn, maar dat er 4 typen omgevingen zijn. Ieder type met zijn eigen kenmerken 88

89 Testomgevingen OTAP-model: Ontwikkeling, Test, Acceptatie, Productie.
Het is dus mogelijk dat er 7 omgevingen gebruikt worden volgens het OTAP-model (2 ontwikkelomgevingen, 1 testomgeving, 2 acceptatieomgevingen en 2 productieomgevingen) 89

90 Testomgevingen OTAP-model: Ontwikkeling, Test, Acceptatie, Productie.
Mogelijke eigenaren en beheerders van de 4 typen omgevingen: Type omgeving Eigenaar Beheerder Ontwikkeling Ontwikkelaars Test Testers Ontwikkelaars, Testers, beheerderorg Acceptatie Gebruikersorg Productie Gebruikersorg. Beheerorganisatie 90

91 Tips Kijk eens op www.tmap.net. U vindt daar onder andere
downloads (checklists, testontwerptechnieken, woordenlijst) de TMap Test Topics presentaties in de pers verschenen Tmap artikelen Tmap nieuwsbrieven 91

92 Einde cursus TMap NEXT