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

 

Kvalitetskarakteristikker

Kvalitetskarakteristikker


Kvalitetskarakteristikker:

 

Funktionalitet (Funktionel test: Hvad systemet gør)

  • Nøjagtighed
  • Egnethed
  • Tværoperationalitet
  • Overensstemmelse

Brugervenlighed (Ikke-funktionel test: Hvordan systemet gør det)

  • Forståelsesegnethed
  • Læringsvenlighed
  • Brugsegnethed
  • Attraktivitet
  • Overensstemmelse
  • Adgangstest

 

 

Nøjagtighedstest – Funktionel test


Her tester vi på hvor nøjagtigt systemet er – regner systemet rigtig på decimaler ? Kan systemet oversætte rigtigt ? f.eks. Google Translate.

 

Egnethedstest – Funktionel test


Er der de rigtige funktioner i systemet – kan det de funktioner, som vi har brug for ?

Tænk på Usecases.

 

Tværoperationalitetstest – Funktionel test


Her tester vi i hvilken grad to eller flere systemer kan udveksle information – og efterfølgende anvende den information.

 

Brugervenlighedstest – Ikke funktionel test


Brugervenlighedstest tester hvor let brugeren kan anvende eller lære at anvende systemet til et specifikt formål.

Brugervenlighedstesten måler:

  • Egnethed – Systemets evne til at brugeren kan opnå bestemte mål.
  • Effektivitet – Systemets evne til at for brugeren at bruge systemet med en passende indsats.
  • Tilfredshed – Systemets evne til at tilfredsstille brugeren i en specificeret brugssammenhæng.

Under brugervenlighedstesten måler vi på:

  • Forståelsesegnethed – Hvor let er det at forstå systemets logiske koncept.
  • Læringsegnethed – Hvor meget indsat kræver det at lære systemet at kende.
  • Brugsegnethed
  • Attraktivitet – Systemets evne til at gøre bruger glad.

Brugervenlighedstest udfører vi i to trin:

  • Informativ brugervenlighedstest – Test vi udfører i design og prototypefasen. Altså FØR implementeringen.
  • Opsummerende brugervenlighedstest – Test vi udfører EFTER implementeringen, eks. standardsystemer.

Guidelines til brugervenlighedstest

  • Tilgængelighed af instruktioner
  • Klarhed af prompts
  • Antal klik
  • Fejlmeldinger
  • Arbejdsindikator (timerglas)
  • Skærmdesign
  • Farver og lyd
  • Andre faktorer, der påvirker brugerens oplevelse

Standardiserede undersøgelser til indsamling af brugeradfærd:

  • SUMI   – Software (Software Usability Measurement Inventory)
  • WAMMI    – Websites (Website Analysis and MeasureMent Inventory)

 

Adgangstest – Ikke funktionel test


Her tester vi adgangen til systemet for personer med specifikke behov, eksempelvis handikap eller andre begrænsninger.

Her skal vi være opmærksomme på, at der kan være lovmæssige krav.

 

 

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.