vi er her !!!

02120

DifferentielGPS
home

Test af WordBuffer

For modtagelsen er WordBuffer den vigtigste klasse at teste. Under antagelse af, at vi modtager korrekt RTCM data, vil denne klasse være afgørende for, at modtagelsen lykkedes. Hvis denne klasse ikke virker korrekt, vil korrekt data måske blive forvansket, fordi den ikke bliver gemt ordentligt. Dette har været tilfældet før vi nåede til endelige version af programmet. WordBuffer har været den klasse, som vi har haft størst vanskeligheder med under testen. Derfor har vi valgt at teste denne klasse så grundigt, som det er os muligt.

Vi har lavet en testklasse til WordBufferen med tre test i. Vi har modtaget en række beskeder, som kommer lige efter hinanden. Vi har gemt byteværdierne, så vi kan simulere en modtagelsesproces. Det er en meget dårlig simulation, da vi skriver dataene kontinuert og meget hurtigt. I praksis kommer der jo kun 1 ord i sekundet per enhed, man modtager fra. Men da testen skal afsløre om bufferen kan håndtere et længere dataflow uden fejl, er det ligegyldigt om der kommer 1 eller 1000 beskeder per sekund.
Testen er implementeret i WordBufferTester.java. Den har en main funktion, som starter én af de 4 indbyggede tests, som er beskrevet nedenfor. ønsker man i test A, B eller C, at testen skal skrive et fast antal bytes og stoppe indsættes dette hele antal efter testnavnet med mellemrum mellem. Hvis man skal starte test A med 20.000 bytes, skal man skrive
java WordBufferTester A 20000
Hvis der ikke angives et gyldigt tal, som 2. argument til test A, B og C, vil en NullPointerException blive kastet og programmet stoppes. Vi håndterer ikke fejlen, da testen ikke skal bruges af slutbrugeren. I WordBufferen bruges en WriteTester, som udskriver alle fejlbeskeder.

Test Type Mål Resultat
A Ulæst skrive test Intet buffer underløb Der kom intet buffer underløb
B Læst skrive test Stabil læsning Stabil læsning af 4.680.000 beskeder
C Læst skrive test med fejldata Paritetsfejl og stabil læsning Paritetsfejl og stabil læsning af 2.030.000 beskeder
D Test af CRWBuffer Se nedenfor Testen blev bestået

Test A

Her tester vi hvad der sker, når man skriver til bufferen uden at læse fra den. Der skulle gerne komme fejlbeskeden:
Advarsel: Der er for mange ulæste beskeder i ordbufferen: 10001
Bufferen skal kunne køre videre på trods af advarselsbeskeden. Hvis opstår bufferoverrun, er der en fatal fejl i bufferen, som muligvis vil bevirke, at programmet er ustabilt.

Resultat af test A
Da vi kørte testen kom beskeden frem og der kom ingen bufferoverrun. Dermed bestod programmet denne test.

Test B

Vi ønsker også at teste om bufferen er stabil over tid, hvis der læses fra den. Derfor sætter vi en ny tråd til at læse fra bufferen, mens hovedtråden skriver til den. Der kan komme for mange beskeder i bufferen, som i test A, og dette skal programmet stadigvæk være stabilt overfor. Vi har valgt ikke at tvinge tråden til at vente, så det er ikke sikkert, at denne fejl opstår.

Resultat af test B
Vi lod testen køre i cirka en time, hvor der i alt blev læst 4.680.000 beskeder. Da computeren blev brugt til andre ting under testen kom der for mange beskeder i bufferen, som i test A. Men det var kun i korte perioder, at der var for mange. Så læsningen kan fortsætte stabilt efter, at der har været for mange beskeder i bufferen.
Programmet bestod dermed test B.

Test C

Vi ønsker også at sikre os, at programmet kan forsætte selvom det har modtaget forkert data. Dette gør vi ved, at ca. 0,0001% af bytene, der bliver skrevet til byteBuffer'en, er tilfældige. Vi laver et instans af Javas Random. Ved hver skrivning udtager vi et nyt tilfældigt tal mellem 0 og 999.999. Hvis et tallet er lig nul, udtager vi et nyt tal mellem 1 og 128, som skrives til byteBuffer'en i stedet for det tal, som egentligt skulle skrives.

Resultat af test C
Vi lod denne test køre ca. en time. Vi modtog 2.030.000 korrekte beskeder. Der kom mange paritetsfejl, men der kom på intet tidspunkt andre fejl. Programmet bestod dermed test C.

Test D: CRWBuffer

Denne test var den første vi lavede. Vi lavede den allerede før vi havde skrevet WordBuffer, men af tekniske årsager har vi placeret den nederst her. Da CRWBuffer'eren er grundfundamentet for WordBuffer, er test D vigtigere end test A, B og C. Hvis test D skulle fejle, ville test A, B og C også fejle.

Vi tester 4 grundlæggende ting i CRWBuffer'eren:

  1. Test af pop og popAll metoderne
  2. Grundig test af currentSize metoden.
    Det er vigtigt, at currentSize virker. Hvis det ikke er tilfældet vil det ikke kunne sikres, at der ikke opstår buffer over- eller underløb.
  3. Simultan skrive- og læsetest.
  4. Der kastes BufferUnderrunException når der læses fra en tom buffer og BufferOverrunException når der skrives til en fuld buffer. Som nævnt under beskrivelsen af bufferne (se under Buffere), har vi valgt, at man ikke kan skrive samtidigt med, at en skrive proces er i gang. For at teste, at denne sikring virker udfører vi en test med to tråde, som henholdsvist læser fra og skriver til bufferen.

Vi har på grund af tidspres ikke nået at lave egentlige testssæt til denne test, hvilket ville være den pæneste og grundigste måde at lave testen på. I stedet for har vi lavet en ud i ét praktisk test, som tester de fire nævnte testpunkter. Testen er delt ind i tre dele. Den første del består af, at der skrives data til bufferen, som læses med pop, popAll, read og readAll. Næste skridt er at teste om currentSize giver samme størrelse uanset hvordan læse- og skriveindekset står i forhold til hinanden. Samtidigt undersøger vi om der kastes BufferOverrunException når der skrives til en fuld buffer. Til sidst laver vi en simultanskrivetest. Her undersøger vi også, om der kasten BufferUnderrunException ved læsning fra en tom buffer.
Vi har valgt, at der skal være 6 pladser i bufferen under testen de to første dele af testen.
For at gøre testen overskueligt, har vi lavet et skema med de første trin af testen. "Forventet indhold af bufferen" bliver ikke testet, men er med, for at man kan følge med i testudviklingen.

Test punkt Handling Forventet resultat Resultat Forventet indhold af buffer
2 1 & 2 skrives, currentSize læses 2 2 [1,2]
1 readTop 1 2 [1,2]
1 readAll [1,2] [1,2] [1,2]
1 pop 1 1 [2]
2 currentSize 1 1 [2]
1 3, 4, 5 skrives, popAll [2,3,4,5] [2,3,4,5] []

Den grundige test af currentSize har vi lavet ved at fylde bufferen helt op. Tallene vi fylder bufferen med er ligegyldige for denne test, så vi indsætter 1 de tre første gange og herefter 2 til 6 de sidste fem gange. For hver gang vi skriver en gang til bufferen, skal dens størrelse stige med 1. Når vi er nået op på størrelsen 6, kan der ikke være flere data i bufferen. Vi tester om der kastes en BufferOverrunExcption, når vi forsøger at skrive til bufferen. Herefter popper vi en gang for at skrive bagefter og tjekker, at størrelsen er 5 efter pop kaldet. Vi skriver til bufferen igen, og tjekker om størrelsen er 6 efter write kaldet. Dette gentager vi 8 gange. Når vi har gentaget det 8 gange, har læseindekset og skriveindekset været på alle de forskellige positioner, de kan være i forhold til hinanden, når størrelsen er 6.
Som afslutning laver vi et popAll kald, som genre skulle give et array med [2, 3, 4, 5, 6].

Resultat af deltest 2:
Ved denne del af testen opstod ingen fejl. Vi fik alle de forventede resultater.

Til simultanskrivningstesten vil vi teste, at bufferen ikke bryder ned, hvis der forsøges læst og skrevet samtidigt. Til simultanskrivningstesten bruger vi en buffer med 20 pladser. Vi starter en ny tråd, som læser fra bufferen ind til den har læst 20. For hver gang, der læses fra en tom buffer, kastes en BufferUnderrunException. Den bliver fanger og punktum udskrives til kommandoprompten. Når tråden er startet, skriver vi fra 1 til 20 til bufferen. Vi er ikke interesserede i at risikerer buffer overløb, som er blevet testet. Derfor skriver vi ikke mere end der kan være i bufferen, selvom dataene med nogen sandsynlighed ville blive læst fra bufferen hurtigt nok til at undgå buffer overløb.

Resultat af deltest 3:
Resultatet af denne sidste test, vil afhænge af, hvordan trådene får fokus. Vi har kørt testen adskillige gange uden, at programmet på noget tidspunkt melder fejl eller går i stå. Vi fik en del BufferUnderrunException. Men da vi har med tråde at gøre, som vi ikke kan styre hvornår får fokus, kan vi ikke vide om der rent faktisk er en situation, hvor der forsøges at skrive og læses samtidigt. Men vi kan konkludere, at der sandsynligvist ikke sker fejl i sådan en situation.
Det kan nævnes, at vi under testen fangede den fejl, at vi ved buffer overløb blokerede læsning og skrivning og derefter kastede en exception. Dette resulterede i, at programmet hang. Dette viser, helt sikkert, at blokaden virker.

RTCM klasserne

Det kan nævnes, at klasserne til RTCM signalet GPSWord og GPSMessage er lige så vigtige at teste som WordBuffer. Skulle der være fejl i dem, ville det være lige meget om vi kan modtage data uden at forvanske det. For så ville den satellit data vi får ud alligevel ikke være rigtig. Men da vi ikke kan generere data, som vi kan teste dem med, har vi ingen måde at teste dem på. Den eneste måde vi kan teste dem på, er at sende fejl data til dem og se hvad der sker. Dette gør vi i test C, men på grund af tidsmangel undersøger vi ikke, om vi får de ord, som vi forventer at få ud af det. Men vi kan konstatere, at vi får paritetsfejl i test C, hvilket betyder, at ikke alle data modtages. Om det sker hver eneste gang vi skriver en tilfældig byte, har vi ikke undersøgt.

Konklusion på WordBuffer testen

Vi fandt ingen fejl i CRWBufferen. Da den er også er blevet testet intensivt under test A, B og C samt af stabilitetstesten af serveren, kan vi med stor sandsynligheden afvise, at der er fejl i denne buffer.
Vi har heller ikke fundet nogen fejl i WordBuffer'en under ideelle og under mindre ideelle omstændigheder. Da vi ikke har en egentlig generator af beskeder, kan vi ikke lave en rigtig god test.
En egentlig strukturtest ville være meget kompliceret at lave. Der er blandt andet en række fejlmuligheder, som aldrig burde opstå, men som vi på grund af exceptions må håndterer i koden. Disse er ikke testet, da det ville kræve indgreb i selve koden og så vi skulle have mange forskellige versioner af programmet. Vi har dog med disse test kommet ind under alle mulige stadier i WordBuffer klassen beskrevet under WordBuffer.java. Disse stadier er:

  1. Der er paritetsfejl i ordene. Der opstår fejl midt i en besked, så beskeden må droppes. Dette sker når en tilfældig byte skrives i test C.
  2. Første ord er ikke modtaget, men ordene vi modtager har rigtig paritet. Dette stadie når vi til efter at have været i 1. stadie, som følge af paritetsfejl. Vi kommer også kun til dette stadie i test C.
  3. Første ord er modtaget, og modtagelsen kører fint uden afbrydelser. Dette testes i test A og B, der aldrig modtager forkerte byte og aldrig kommer forkert ind i datastrømmer. Dermed er test A og B begrænset til dette stadie. Det bliver også testet af test C, som dog også forlader dette stadie.

home