vi er her !!!

02120

DifferentielGPS
home

Testning af serveren

Den eneste måde vi kan lave en egentlig test af selve serveren, er ved at køre en praktisk test over lang ting og se om programmet er stabilt. Vi ønsker ikke at aflevere én kopi af serveren, som udskriver meddelelser til kommandoprompten til test brug, og én til slutbrugeren, som ikke gør. Derfor har vi lavet mulighed for, at vi kan udskrive meddelelser til kommandoprompten uden at slutbrugeren skal se på det. Dette har vi gjort med Tester interfacet. Når programmet startes normalt udskrives intet. Programmet skal startes med bestemte argumenter før det udskriver meddelelser.

Tester interfacet

Da vores program i høj grad er afhængig af hvilken data, vi får ind via enhederne, giver en fastlås test ikke et godt billede af om programmet virker. Der kan opstå mange forskellige situationer, som vi ikke kan forudsige. Derfor har vi valgt, at indbygge udskrifter af forskellige fejl til kommandoprompten. Dette skal slutbrugeren dog ikke udsættes for. Derfor har vi lavet et interface Tester.java, som har to implementeringer. NonTester, som skal bruges normalt, hvor alle metoder tomt implementerede, og en TestWriter, hvor der udskrives fejlbeskeder til kommandoprompten. Når programmet startes normalt vælges NonTester. Men hvis det startes med "-test" som argument, bliver TestWriter valgt. Alle klasser, som har relevant at udskrive, har en Tester variabel i sig. Da dette er et interface, kan man frit vælge hvilken af de to implementeringer man vil vælge. Klasserne har metoden setTester til at ændre testeren. De starter alle med en NonTester, så hvis der ikke ændres noget, vil der ikke blive udskrevet noget. Reciver kræver dog at få testeren som argument, da den skal indstille hvilken Tester der skal bruges til enhederne.

Stabilitetstest

Vi har kørt to lange test af programmet. Den første test kørte fra 27/4-2005 klokken 17:36 til 28/4 klokken 9.43. Den anden kørte fra d. 28/4 klokken 13:58 til d. 30/4 klokken 17:39. Vi har logget testene og filerne ligger under 060-test mappen på WebDav'en. Det drejer sig om filerne dGPSlog1.log og dGPSlog2.log, som af pladshensyn er pakket ned i dGPSlog.zip. Da der bliver udskrevet en linje for hver eneste besked der bliver sendt til databasen er disse filer enormt store og ikke til at håndterer uden en betragtelig mængde hukommelse i computeren.
Under begge test brugte vi følgende enheder:<\P>

  • Trimble GPS modtageren (seriel)
  • TaarnbyDGPS (GPSNet)
  • VestermarieDGPS (GPSNet)

Ved den første test konkluderede vi, at der var fejl i WordBuffer koden. Derfor ændrede vi strukturen af den (se under Analyse). Det lykkedes os at rette fejlen, så den ikke opstod under 2. test. Forbindelsen til databasen blev under denne test nulstillet, men blev succesfuldt oprettet igen.
Testen blev i begge tilfælde stoppet ved, at Trimble enheden blev fysisk fjernet. Dette resulterede i, at al modtagelsen stoppede. Programmet er således ikke stabilt over for, at hardware fjernes. Dette er ikke hensigten, men vi har ikke haft tid til at finde grunden til at programmet stopper. Vi betragter det som en ubetydelig fejl, da hardwaren sandsynligvis ikke fjernes ved brug af programmet. I så fald må man ellers stoppe modtagelsen og starte den igen.
I første test udskrev vi besked ved paritetsfejl. Vi kan konstatere, at der opstår paritetsfejl til at starte med. Dette er forventeligt, da det første hele ord skal identificeres. Efter starten kom der ikke nogen paritetsfejl.
Under begge tests udskrev vi fejl, hvis beskederne er af ugyldig længde (for eksempel 3, 6 eller 11). Grundet bufferfejlen i første test, kom der også en del ekstra fejl om beskeder med forkert længde. Men selv efter fejlrettelsen, kommer der en del beskeder, som har ugyldige længder. Fejlene med de forkerte beskedlængder kom fra alle enheder. Dette kan vi ikke forklare. Vi har set koden efter meget grundigt og konstateret, men har ikke kunnet finde fejl der. Vi har snakket kort med en anden gruppe, som laver samme projekt, som også har fået denne fejl.
Vi må således gå ud fra, at GPSNet og Trimble GPS modtageren ikke sender data i det RTCM format, som vi forventer. Vi har lavet en test af dataene (se Annas test), som viser, at de data vi har modtaget er plausible korrektioner. Men da vi ikke har lavet nogen en til en sammenligning med et autoriseret program, kan vi ikke vide med sikkerhed om de korrektioner vi får er korrekte.

Konklusion på stabilitetstesen

Under den første test konstaterede vi en fejl i bufferen, som er blevet rettet. Under den anden test kørte programmet uafbrudt i 52 timer uden nedbrud. Programmet stopper med at modtage data, når hardwaren bliver fjernet, hvilket ikke er hensigten. Denne fejl er ikke blevet rettet. Hvis forbindelsen til databasen bliver nulstillet, kan den oprettes igen. Vi har altså et stabilt program.
Under begge test har vi modtaget en række ord, som har en ugyldig længde. Dette kan vi ikke forklare. Det skyldes muligvis, at enhederne bruger en anden version af RTCM formatet end vi bruger. Vores uddata er ifølge Annas test plausible korrektioner. Men vi kan konkludere, at vi muligvis ikke afkoder signalet rigtigt og alle vores korrektioner muligvis er forkerte. Alt udstyret vi modtager med er fra fabrikanten Trimble, da GPSNet.dk også bruger Trimble. Det kan derfor være, at Trimble udstyret ikke udsender i det korrekte format.
For at afklare problemet, sendte vi en mail til udbyderen af GPSNet.dk. De kendte ikke noget til, at der skulle være problemer med RTCM formatet og henviste til, at deres andre kunder ikke havde problemer med det. Men de ville ikke kategorisk afvise, at de ikke overholder RTCM standarden. Her skal man tænke på, at GPSNet.dk er en virksomhed, som ikke er interesserede i, at der kommer pletter på deres ry. Det er derfor ikke sikkert, at de ville indrømme hvis de sender i et forkert format. Således kan vi egentligt ikke konkludere noget ud fra svaret. Vi har vedlagt en kopi af deres svar i bilag D.

Andre tests af serveren

Serveren kan gemme indstillingerne for databasen og de serielle enheder samt standard indstillingerne for GPSNet. Vi har testet, at man både kan gemme og læse indstillingerne. Hvis filen er skrivebeskyttet, får man en fejlmeddelelse. Vi har ikke haft mulighed for at simulerer andre skrivefejl. Hvis felter ikke er defineret i filen, bruges standardværdier. Hvis der er ændret i filen, så de numeriske værdier ikke er gyldige heltal, vil også blive brugt standardværdier.
En mulighed for fejl er, at det ikke undersøges om port indstillingerne for serielportene er gyldige. Det drejer sig om databits, stopbits og parity, som er defineret ud fra nogle konstanter. Hvis der er ændret, så disse ikke er gyldige kastes der en exception, når programmet forsøger, at sætte indstillingerne. Der er ingen problemer med at ændre variablene igen i indstillingsdialogen. Således udgør fejl i indstillingsfilen intet problem.


home