Udforskende test

Udforskende test


Udforskende test er en uformel testteknik som samtidig er læring om systemet. Udforskende test er afhængig af testerens erfaring med at evaluerer resultatet af testen.

 

Definition


En uformel testdesignteknik hvor testeren aktivt kontrollerer designet af test cases efterhånden som disse afvikles og bruger informationen, som er opsamlet undervejs til at designe nye og bedre testcases.

 

Læring


Det hedder udforskende test fordi, vi udforsker/lærer systemet SAMTIDIG med at vi tester – vi tester uden scripts, men ofte styret af testcharters.

Med udforskende test finder vi ofte fejl, som scriptet testcases ikke ville have fundet.

 

Checklistebaseret test

Checklistebaseret test


Checklistebaseret test bygger på, at vi anvender en højniveau liste over elementer, som vi skal tjekke for/teste.

Checklisterne er organiseret omkring temaer som:

  • kvalitetsegenskaber
  • standarder for brugerinterface
  • lovpligtige krav
  • nøgleoperationer

 

Test foretager vi nu ud fra listen, så hvert element på listen evalueres/checkes. Vi skal have mindst én test pr. element/punkt på listen.

 

Anvendelse


Checklistebaseret test anvender vi, hvis vi kender til det område, listen dækker.

Checklister mangler de detaljerede trin, der er i testcasens. Dette gør dem nemmere at vedligeholde.

 

Begrænsninger


Checklistebaseret test mangler de detaljeret trin, som der er i testcase fra de andre teknikker. Dette gør det svært for testeren at genskabe testen/reproducere fejlen.

Checklister kan give forskellige resultater alt efter hvem, det er der udfører testen.

Checklister skal desuden vedligeholdes, således at vi ikke tester det samme om og om igen (også kaldet pesticid paradokset).

Fejlgætning

Fejlgætning


Fejlgætning baserer sig på at testeren gætter på fejltagelser, som udvikleren har begået, og tester for at finde dem.

Testeren bygger på fejlhypotesen på tidligere sete fejl i systemet, og stadig kan huske hvordan disse blev fundet.

 

Anvendelse


Fejlgætning benytter vi primært under integrations- og systemtest, men vi kan benyttes teknikken på alle niveauer.

Fejlgætning benytter vi ofte sammen med andre teknikker, men for at udvide omfanget af de eksisterende testcases.

 

Begrænsninger


Det er svært at vurdere testdækning for vores test.

 

Parvis test

Parvis test


Parvis test er måde til at reducere antallet af kombinationer på.

Eksempel:

Vis skal teste 3 webpages på 3 forskellige styresystemer og på 4 forskellige browsere:

  • Webpages: Page1, Page2 og Page3
  • Styresystem: Windows, Mac OS og Linux
  • Browser: Internet Explore, Firefox, Safari og Chrome

Test af alle kombinationer giver: 3 x 3 x 4 = 36 testcases.

Kigger vi på hvor mange kolonner vi skal have, så har vi 3 kolonner (3 betingelser):

Parvis_test_01Ved parvis test skal vi nedbringe alle parvis kombinationer til kun én for hver række. Altså hvor vi har kombinationer, der parvis allerede er testet.

Værdier pr. kolonne: 3, 3, 4

 

Ortogonale tabeller


Ved parvis test kan vi med fordel gøre brug af ortogonale tabeller. For at vi kan finde den rigtige tabel, skal vi bruge:

  • Mindst én kolonne til hver parameter
  • Et tal for hver værdi for hver parameter
  • Mindst antal rækker som du får ved at gange de to største antal værdier med hinanden.

 

Standardnotation for ortogonale tabeller


Standardnotationen for angivelse af ortogonale tabeller er:

ortonal_notifikation

 

Eksemplet viser en ortogonal tabel med:

  • 20 rækker
  • 3 kolonner
  • Max antal værdier er 5

 

På vores ovenstående eksempel med wepages, styresystemer og browsere har vi følgende:

  • 3 kolonner
  • 3 x 4 = 12 rækker
  • Max antal værdier er 4 (browsere)

Notationen bliver nu L12(4^3)

Klassifikationstræer

Klassifikationstræer


Klassifikationstræer er en metode til at generere testcases for vigtige kombinationer UDEN at generere redundante eller umulige testcases.

 

Trin 1 – Identificer klassifikationer og klasser/partitioner


En klassifikation identificerer et input (eksempel: feltnavn eller inputfelt som Alder).

En klasse specificerer et input (eksempel: svarende til indholdet af feltet som f.eks. Barn, Voksen, Pensionist)

Klassifikation_01

Trin 2 – Arranger klassifikationerne i et træ


Arranger nu klassifikationer i et træ ved at placere klassifikationer under klasser, hvor de er mest relevante:

 

Klassifikation_02x

Trin 3 – Udled testcases


I ovennævnte eksempel finder vi nu 4 testcases:

  1. Barn
  2. Voksen – Studerende
  3. Voksen – Ikke studerende
  4. Pensionist

 

Trin 4 – Specificer testcasene


Næste step er nu at specificere testcasene:

  • Vælge konkrete inputværdier (ikke intervaller)
  • Gør testcasene gentagelige

 

Tilstandsovergangstest

Tilstandsovergangstest


Tilstandsovergangstest anvender vi på applikationer, der har et endeligt antal forskellige tilstande og hvor overgangen fra en tilstand til en anden følgerne fastlagte regler. Tilstandsovergangsmodellen består af fire dele:

  1. de tilstand, som applikationen kan have
  2. de overgange, som leder fra en tilstand til en anden
  3. de hændelser, der udløser overgangen (input)
  4. de aktioner, der er resultatet af overgangen (output)

Tilstandsovergangsmodellen viser vi ofte som et tilstandsdiagram (se nedenstående figur) Eksemplet viser Tilstandsdiagram_01

Ud fra ovenstående tilstandsdiagram kan vi, ved at liste alle tilstande og overgange, danne følgende tilstandstabel:
Tilstandstabel_01

Vi skal nu skrive en testcase til hver overgang i diagrammet (hver udfyldt felt i tilstandstabellen). Det giver i alt 6 testcases:

Tilstandstabel_01_Testcases

0-switch dækning


Ved 0-switch dækning laver vi testcases til alle individuelle overgange – altså én overgang.

 

1-switch dækning


Ved 1-switch dækning dækker vi alle par af overgange. Ved at tilfører et ekstra trin på hver test, kan vi checke om sluttilstanden i 0-switch-dækningen faktisk er nået korrekt.

 

N-switch dækning


Dækker alle mulige sekvenser af n af overgange.

 

Beslutningstabeller

Beslutningstabeller


Beslutningstabeller benytter vi, når vi skal designe testcases til test af forretningsregler.

Beslutningstabeller hjælper os med at finde kombinationer af forskellige inputvariabler og handlinger som applikationen udfører afhængigt af inputtet.

Test af kombinationer kan være lidt af en udfordring, specielt hvis der er tale om mange mulige kombinationer. At test alle mulige kombinationer kan næsten være umuligt. Løsningen er at vi kun tester et lille udpluk af kombinationsmulighederne. Her er det så vigtigt, at vi vælger de “rigtige” kombinationer. Beslutningstabeller giver os en teknik til at afgrænse antallet af testcases på en intelligent måde.

En intelligent måde at begrænse antallet af testcases er at fjerne betingelserne og sæt af betingelser der:

  1. ikke er mulige
  2. redundante
  3. ikke relevante for resultatet

 

Eksempel:

Hos bilforskringsfirmaet BilFo kan kunder opnå to forskellige niveauer: 10% og 30%.

Regel for at opnå rabat : Hvis kunden ingen tidligere skader har haft, er over 25 år og har andre forsikringer hos BilFo, giver BilFo kunden 30% rabat. Til kunder over 25 år, der ikke har andre forsikringer hos BilFo, giver BilFo 10% rabat. Hvis kunden er 25 år eller yngre, giver BilFo 10% rabat, forudsat at kunden ingen tidligere skader har haft og har andre forsikringer hos BilFo. Hvis kunden tidligere har haft skader giver BilFo ingen rabat. Kunden kan maksimalt opnå 30% rabat hos BilFo.

 

Beslutningstabel – Step 1 (List alle kombinationsmuligheder):

beslutningstabel_01

I regel 1 – 4 får vi samme resultat (handlingerne er ens): Kunden får ingen rabat. Når betingelserne ikke påvirker handlingerne, kan kolonnerne slås sammen (kombineres).

Når vi kombinerer kolonnerne får vi følgende tabel (~ betyder at værdien er ligegyldig):

beslutningstabel_02

Som det ses, får vi færre testcases, når vi kombinerer kolonner/regler.

Beslutningstabeller kan meget let blive rigtig store.

 

Hvilke defektyper finder vi


Med testcases dannet ud fra beslutningstabeller finder vi:

  • Betingelseskombinationer, applikation ikke håndterer eller ikke bliver håndterer godt nok
  • Forkert behandling af specifikke kombinationer af betingelser
  • Defekter eller mangler i kravspecifikationen mens vi danner beslutningstabellerne

 

Grænseværdianalyse

Grænseværdianalyse


Grænseværdianalyse bygger på, at vi designer vores testcases til at teste grænseværdierne mellem ækvivalenspartitionerne.

Grænseværdianalyse eksisterer i to versioner: to værdi eller tre værdi test.

Lad os kigge på de to versioner:

 

To værdi

Givet at vi har en applikation, der kan modtage et kodeord på 6 – 10 karakterer.

Her skal vi nu teste og lige over grænseværdien. Vi tester med 10 karakterer og 11 karakterer (test af grænseværdien 10). Og så tester vi med 6 karakterer og 5 karakterer (test af grænseværdien 6).

 

Tre værdi

Giver at vi har en applikation, der kan modtage et kodeord på 6 – 10 karakterer.

Nu skal vi teste lige under, og lige over grænseværdien.

Testcasene bliver med 5, 6 og 7 karakterer, samt 9, 10 og 11 karakterer.

 

Forøgelsesenhed

Når vi arbejder med grænseværdianalyse, er det vigtigt at vi tager den mindste enhed i betragtning – også kaldet forøgelsesenhed. Hvis vi f.eks. taler om kontanter, så er forøgelsesenheden 25 øre.

 

Eksempel 1:

Netsitet UngeRejser sælger rejser til unge. For at komme ind på siden, skal du være i fra 18 år til og med 25 år.

Invalid
(minimum – 1)
Valid
(min, min + 1, max – 1, max)
Invalid
(maximum + 1)
1718, 19, 24, 2526

Det giver os 6 testcases:

  1. Inputværdi 17 = ingen adgang (invalid)
  2. Inputværdi 18 = adgang givet (valid)
  3. Inputværdi 19 = adgang givet (valid)
  4. Inputværdi 24 = adgang givet (valid)
  5. Inputværdi 25 = adgang givet (valid)
  6. Inputværdi 26 = ingen adgang (invalid)

Ækvivalenspartitionering

Ækvivalenspartitionering


Ækvivalenspartitionering er en test design teknik, der deler inputværdierne op i grupper/partitioner så et enkelt input kan repræsentere hele gruppen/partitionen. Hver inputværdi i partitionen skal udvise samme opførsel som de andre inputværdier i partitionen.

Denne teknik kan vi benytte til at finde klasser af fejl. Dermed kan vi reducere antallet af testcases vi skal danne – samtidig med at vi reducerer tiden vi skal bruge på at teste applikationen.

Vi skal vælge inputværdier fra alle partitioner – både gyldige og ikke gyldige.

 

Eksempel 1:

Vi skal teste en applikation, der tager månedsnummeret (heltal) som input. Den gyldige partition ligger i intervallet 1 – 12. De ugyldige partitioner ligger i to intervaller:  <= 0 og >= 13.

 

Tegnet ser vores partitioner således ud:

aekvivalenspartitionering

Eksemplet giver tre testcases – én for hver partition (huske både ugyldige og gyldige partitioner):

  1. Inputværdi: -3            (repræsenterer partitionen <= 0)
  2. Inputværdi: 6             (repræsenterer partitionen 1 – 12)
  3. Inputværdi: 15           (repræsenterer partitionen >= 13)

 

Eksempel 2:

Vi skal teste en applikation, hvor brugeren skal indtaste sit mobilnummer. Mobilnummeret skal indeholde 8 cifre. Den gyldige partition indeholder 8 cifre, f.eks. 12345678. De to ugyldige partioner er <=7 cifre og >= 9 cifre.

Dette eksempel giver også tre partitioner med tilhørende testcases:

  1. Inputværdi: 123456              (repræsenterer partitionen 7 cifre eller mindre)
  2. Inputværdi: 12345678          (repræsenterer partitionen 8 cifre)
  3. Inputværdi: 1234567890      (repræsenterer partitionen 9 cifre eller flere)

 

Eksempel 3:

Onlineboghandlen “BøgerMedPosten” giver rabat alt efter hvor mange bøger du køber hos dem af gangen. Hvis du køber mere end 2 bøger får du 10% rabat, og hvis du køber mere end 4 bøger får du 20% rabat, og endelig hvis du køber mere end 10 bøger, får du 50% rabat.

Det giver 4 partitioner med 4 tilhørende testcases:

  1. Inputværdi: 1 bog = ingen rabat        (repræsenterer partitionen 1-2 bøger)
  2. Inputværdi: 3 bøger = 10% rabat       (repræsenterer partitionen 3-4 bøger)
  3. Inputværdi: 7 bøger = 20% rabat       (repræsenterer partitionen 5-10 bøger)
  4. Inputværdi: 14 bøger = 50% rabat     (repræsenterer partitionen 10 bøger eller flere)

Testteknikker

Statisk Dynamisk Testteknikker

Testteknikker


Indenfor testteknikker skelner vi mellem to typer af teknikker:

  • Statiske
  • Dynamiske

 

Statiske testteknikker

Statisk test er en form for software test, hvor vi ikke benytter softwaren. Den statiske test er ikke en detaljeret test. Det primære formål ved statisk test er at finde fejl i dokumentation og kode. Dette gør vi gennem review, audit, inspektion og walkthrough. De statiske testteknikker kan vi benytte til at teste vores kravspecifikationer, funktionelle specifikationer, design dokumenter m.v. Statisk test kan vi udføre så snart de første idéer og tanker er dannet – med andre ord: vi kan begynde meget tidligt, og jo tidligere vi begynder jo billigere er det at rette.

 

Dynamiske testteknikker

Ved dynamisk test bliver koden eksekveret. Her tester vi funktionelle og ikke-funktionelle egenskaber ved koden.

Her angiver/indtaster vi input-variabler og validerer om vi får det forventet outputtet ud fra en række testcases. Dette kan bliver udført via manuel test eller automatisk test.

Dynamiske testteknikker bliver brugt i forbindelse med unit-test, integrationstest og systemtest.

 

Læs mere om dynamiske testteknikker under Testteknikker