Flight Progress Strips System for Air Traffic Control Fag:

Transkript

1 Verifikasjon og validerings plan: Flight Progress Strips System for Air Traffic Control Fag: Gruppe nr: Veiledere: Versjon: 1.0 Dato: Software Engineering Filformat: 1 Filnavn: Børre Ludvigsen/Ky Van Ha PDF format vvp.pdf Gruppemedlemmer: Navn: Signatur: Dato: Christian Raspotnig Kjell Gunnar Guttormsen Petter Larsen Eva Sandved Therese Røsholdt

2 Innholdsfortegnelse 1 Introduksjon 1.1 Hensikt Scope Muligheter for videreutvikling Hva FPSS ikke gjøre Definisjoner og forkortelser Definisjoner Forkortelser Referanser Bøker Artikler Annet Oversikt 8 Side: 2 Reviews, Walkthroughs, Inspections og Audits 2.1 Procedure Review, walkthrough, inspection og audit Oversikt over review, walkthrough, inspection 10 og audit 2.3 Schedule Hvilke oppgaver som må gjøres innenfor VVP: 11 3 Component test plans 3.1 Component test strategy overview Testing process Requirement Traceability Features to be tested Testing schedule and resources Hardware and software requirements Constraints Unit test case Test case for metoden 13 changedynamicinformation Test case for metoden changestatusvectors Test case for metoden maketransponder Test case for metoden removetransponder Test case for metoden checkstripexists Test case for metoden sortstrip Test case for metoden splitfpd Test case for metoden deletestrip 20 4 System test plans 4.1 System test strategy overview Testing process Requirement Traceability 22 Side: 2

3 4.1.3 Features to be tested Testing schedule and resources Hardware and software requirements Constraints Integration testing Test case for Strip Test case for FPSS Test case for GUIStrip Test case for GUIStripContainer Test case for GUIStripBoard Function testing Test case for Endre status på strip Test case for Forandre dynamisk flightinfomasjon 32 5 Traceability from SRS to SDS 33 6 Test cross-reference 35 Side: 3

4 1 Introduksjon 1.1 Hensikt Hensikten med dette dokumentet er å sjekke om vi lager programmet riktig (verifikasjon). Sjekker da om systemet gjør det som spesifiseres i SDS lager riktig program (validering). Sjekker da om systemet utfører det brukerne vil det skal gjøre. Sjekker da om systemet er slik det spesifiseres i SRS For å verifisere og validere produktet har vi laget ulike testcases som skal gi svar på om programmet tilfredstiller krav som er beskrevet. Vi har ikke laget testcases som dekker opp alle krav. Dette fordi at det er selve forståelsen som er viktig og ikke nødvendigvis å levere ett fullstendig dokument med alle tester og testcases som dekker all funksjonalitet. For utfyllende kommentarer rundt temaet henviser vi til møtereferat 39/02 (SPPR uke 47). Ved å utarbeide de ulike testcasene øker kvaliteten på programmet som utarbeides. Etter endt testing vil forhåpentligvis antall feil være på en akseptabelt nivå. 1.2 Scope Dette er et dokument som tar for seg verifikasjon og validering av produktet FPSS. FPSS som utvikles skal være en del av hovedsystemet for ATC. FPSS skal lagre strips til generell backup, skrive ut strips for å sikre en kritisk backup-løsning, og presentere strips på skjerm. Disse skal kunne manipuleres på skjerm i henhold til flygekontrolltjenesten. Strips skal inneholde alle relevante data for flygekontolltjenesten for hver enkelt flight. FPSS skal brukes i kontrolltårn som et hjelpemiddel for den FLL som flighten har kontakt med under avgang, landing og eventuelt underveis. Fordelene med dette produktet er at det er enkelt å implementere, samtidig som det ivaretar en sikker og effektiv trafikkavvikling. FPSS vil gi en større mobilitet enn dagens system med tanke på fysisk plassering av arbeidsposisjonen, da FPSS kan kjøres på en PC, eventuelt bærbar PC. Dette gjør det mulig å sette opp og konfigurere PC en hvor som helst på arbeidsstedet som har tilkoblingsmuligheter til nettverk som har kontakt med AFTN. Det vil være enkelt å bytte ut HW-komponenter da FPSS benytter seg av standardutstyr. Gjennom å lagre klareringer og informasjon som gis til flighter, og presentere disse på strips på en forståelig måte, kan FLL lett og raskt skaffe seg oversikt over hvordan han har klarert og informert flighter. Det at all informasjon vises digitalt istedenfor å bli skrevet for hånd på papirstrips minsker risikoen for misforståelser på grunn av uleslig håndskrift. En annen fordel ved digital visning er at uvesentlig informasjon på strips, for eksempel tidligere gitte høydeforandringer, kan fjernes underveis. I motsetning til et stripbord har et digitalt system muligheten til å automatisk logge tidspunkt for forskjellige endringer gitt av FLL. Dette vil gjøre det lettere å avklare eventuelle spørsmål om nødsituasjoner når dette er aktuelt, for eksempel som et hjelpemiddel for Havarikommisjonen ved flyulykker og nesten-ulykker. Dette fordi alle forandringer, med tidspunktet for når forandringen skjedde, blir lagret i en generell backup. Side: 4

5 Hvis FPSS faller ut har man en kritisk backup, som til enhver tid inneholder en papirutgave av lufttrafikken Muligheter for videreutvikling FPSS skal tilrettelegges for framtidig videreutvikling, og skal benytte seg av teknologi som støtter presentasjon av data på mange ulike måter. Man kan legge til funksjonalitet for å lage en lydfil. Lydfilen kan inneholde ting som blir meddelt FLL eller en flight Man kan legge til funksjonalitet hvor man oversender klareringer og informasjon til flighter digitalt som tekst, samtidig som det blir formidlet via radio Det vil være mulig å lage funksjonalitet som automatisk markerer situasjoner som kan bli eller er kritiske direkte på skjerm. Dette kan for eksempel være to flighter som er på kollisjonskurs FPSS vil i opplæringsøyemed av FLL-aspiranter være effektivt, da man i større grad kan se nøyaktig når klareringer og informasjon blir gitt og skrevet ned Man kan kombinere FPSS med spesialutstyr som Touchscreen og Pen-Pad Ved å koble arbeidsposisjoner i nettverk vil man kunne legge til funksjonalitet som gjør det mulig å flytte strips fra en arbeidsposisjon til en annen Hva FPSS ikke gjør FPSS tar ikke imot ATFN-change melding, AFTN-delay melding, AFTN-cancel melding og Metar Vi forutsetter at FPD inneholder korrekt informasjon og vil derfor ikke validere dataene Hver strip inneholder dynamisk og statisk flightinformasjon. Vi skal ikke kunne forandre den statiske flightinformasjonen FPSS tar ikke for seg exceptions som blant annet feil ved skriving til printer og lagringsmedium Vi lager ikke et brukergrensesnitt opp mot databasen (generell backup) Side: 5

6 1.3 Definisjoner og forkortelser Definisjoner Arbeidsposisjon Dynamisk flightinformasjon Flight FLL-aspirant Flygekontrolltjenesten Generell backup Kontrolltårn Kritisk backup Statisk flightinformasjon Stripbord Strips En posisjon på en enhet hvor man yter lufttrafikktjeneste fra Informasjon som blir produsert av FPSS og som flygeleder kan oppdatere En flight er en flygning bestående av ett eller flere luftfartøy, som identifiseres ved et kallesignal En person som utdanner seg til å bli FLL Omfatter områdekontrolltjeneste, innflygningskontrolltjeneste og tårnkontrolltjenester Database som dokumenterer alle forandringer som blir gjort på strips Backup i form av utskrift av strips til matriseskriver Informasjon som blir produsert av FPSS ut fra en FPD Et manuelt hjelpemiddel for FLL med holdere for papirstrips Flight Progress Strip, hjelpemiddel hvor FLL får informasjon om en flygning, og kan endre dynamisk flightinformasjon for denne. FPSS har 3 ulike striptyper; departure-, transit- og arrivalstrip Side: 6

7 1.3.2 Forkortelser AFTN ATC FLL FPD FPSS HW SDS SRS VVP Aeronautical Fixed Telecommunication Network Air Traffic Controll Flygeleder. En person som kontrollerer lufttrafikk innen et bestemt luftrom etter bestemte regler Flight Plan Data Flight Process Strip System Hardware Software Design Specification Software Requirement Specification Validation og Verification plan 1.4 Referanser Bøker: Software Engineering, Ian Sommerville, 2001 Software Engineering, Theory and practice, Shari Lawrence Pfleeger, Artikler: Appendix D: Inspection Checklists, John T. Bladwin, 1992 Guide to software verification and validation, ESA Board for Software Standardisation an Control, 1995 VVP dokument utlevert av faglærer Andre: SRS, versjon 3.0 SDS, versjon Side: 7

8 1.5 Oversikt Kapittel 2 gir en beskrivelse av Reviews, Walkthrough, Inspection and Audits. Kapittel 3 gir en beskrivelse over ulike unit-testcase. Hver testcase vurderes/beskrives med identification, testing approach, pass/failure criteria, test case set, environment, special procedures og precedence and dependencies Kapittel 4 gir en beskrivelse over ulike integrasjons- og system-testcase. Hver testcase vurderes/beskrives med identification, testing approach, pass/failure criteria, test case set, environment, special procedures og precedence and dependencies Kapittel 5 viser tabell over sporing fra ulike testcase til SRS og SDS. Dette omfatter unit-, integrasjons- og system-test case Kapittel 6 gir en oversikt over test cross-reference Side: 8

9 2 Reviews, Walkthrough, Inspection og Audits 2.1 Procedure Modellen som vi har tatt utgangspunt i under utviklingen av FPSS er prototypingmodellen, som har fossefallsmodellen som utgangspunkt. Figur 1: Fossefallsmodellen med prototyping De ulike stegene innenfor testing: Unit testing Programmet deles inn i ulike deler, komponenter. Hver komponent testes, isolert fra andre komponenter i systemet. Dette gjøres for å sjekke at de ulike komponentene fungere med den typen input som er. Sammenligningsgrunnlaget til denne testfasen er detaljdesigndokumentet. Integration testing Etter at hver komponenet er testet kombineres komponentene for å teste om komponentene fungere sammen slik som det står beskrevet i architectual design. System testing Tester her om programmet dekker SW-kravene. Acceptance testing Her testes det om systemet funger ut i fra kundens forventninger og krav. Side: 9

10 Figur 2: VVP-livssyklus I forhold til dette prosjektet skal vi kun beskrive de ulike testcasene, vi skal ikke utføre selve testene. 2.2 Review, walkthrough, inspection og audit Oversikt over reviews, walkthroughs, inspections og audits Review, walkthrough, inspection og audit utføres for å verifisere og validere produktet. Grunnen til at man utfører disse aktivitetene før man starter med test caseene er for å forsøke å avdekke feil så tidlig som mulig i utviklingsforløpet. Desto tidligere feil oppdages, desto lettere og billigere vil det være å fjerne disse. Reviews Teamet består av programmerere og designere. Ingen fra kundeorganisasjonen skal være representert her. Hvert medlem av testgruppen tildeles et spesielt produktområde. Medlemmene leser dokumentasjonen, verifiserer layout og innhold, og sjekker om det finnes missforståelser, inkonsistens eller feil i kode eller dennes dokumentasjon. Gruppemedlemmene konsulterer med hverandre når det gjelder forbedringer av innhold og stil på de skrevne dokumentene. Produktet blir derfor sett over for å sikre samsvar mellom krav og dokumentasjonsstandard. Walkthroughs Det finnes to typer (kode) review; walkthrough og inspection. I en walkthrough skal man evaluere en spesifikk del av programvaren. Koden og tilhørende dokumentasjon presenteres for review teamet, som kommenterer dennes korrekthet. En person leder og kontrollerer diskusjonen. Atmosfæren er uformell og fokus er på koden og ikke på programmereren. Her gjelder at man skal finne eventuelle feil, men nødvendigvis ikke rette dem. Side: 10

11 Inspections Kode inspection er liknende walkthrough, men er mer formell. Review teamet sjekker kode og dokumentasjon opp mot en forhåndsdefinert liste. Inspeksjon av kode gjøres normalt i flere steg. Først møtes medlemmene i gruppe for å få oversikt over koden og en beskrivelse av inspeksjonens mål. Så forbereder medlemmene seg individuelt for et nytt gruppemøte ved å studere koden og relevant dokumentasjon. Til slutt møtes gruppen igjen og medlemmene presenterer det de har funnet for de andre. Dette diskuteres i gruppen og det tas avgjørelse om funnene ansees som feil eller ikke. Audits Audits er uavhengige reviews som skal fange opp feil som er oversett. Audits skal fastsette graden av samsvar mellom krav til programvaren, spesifikasjoner, retningslinjer, standarder, prosedyrer, instruksjoner, kode relaterte og godtatte krav. Feedback gis til gruppemedlemmene slik at produktet kan forbedres. 2.3 Schedule Hvilke oppgaver som må gjøres innenfor VVP: Siden prosessen vår ikke omfatter å gjennomføre selve testingen er det vanskelig å sette opp en plan for når og hvordan testingen skal utføres. Vi har derfor valgt å ikke lage en slik oversikt. Side: 11

12 3 Component test plan 3.1 Component test strategy overview Testing process Her testes ulike metoder i utvalgte klasser. Det er testteamet som skal velge hvilke metoder som skal testes ut ifra viktighet og mulighet for test. Hvert medlem av testteamet vil ha ansvar for noen metoder, og for hver av disse skal de lage testkode som skal forsyne metodene med forskjellig input. Testkoden skal iterere gjennom et forhåndsvalgt sett av mulige parametere, og skal verifisere at metodene kan ta i mot og respondere tilfresstillende på de ulike parametere. Enhver feil som oppdages skal rapporteres til utviklingsteamet umiddelbart etter at den er funnet. Når feil er rettet skal testsyklusen gjentas Requirement Tracebility Testingen relateres til SDS Features to be tested Moduler: changedynamicinformation (metode i klassen ChangeDynamicInformation) changestatusvectors (metode i klassen ChangeStatus) maketransponder (metode i klassen ChangeStatus) removetransponder (metode i klassen ChangeStatus) checkstripexists (metode i klassen CheckData) sortstrip (metode i klassen Sort) splitfpd (metode i klassen FPSS) deletestrip (metode i klassen FPSS) Testing schedule and resources Unit testingen skal begynne så fort metodene er ferdig implementert. Når ferdig produkt foreligger skal integrasjon og system testingen begynne. Hele utviklingsteamet vil være involvert i testingen Hardware and software requirements Testkoden som lages for å teste metodene skal skrives som javakode. For å kjøre en testcase må koden kompileres og eksekveres. Testkoden skal ha navn etter følgende standard: metodenavn_test.java, og legges i mappen Test på SMS serveren Constraints Ingen constraints på nåværende tidspunkt Side: 12

13 3.2 Unit Test Case Test cases for metoden changedynamicinformation Kategori Identification Testing approach Pass/fail criteria Beskrivelse UTC-1 Testes ved å sende ulike parametere til metoden Om metoden vil kunne utføres tilfredsstillende er avhengig av parameterene metoden mottar, dvs hvilke parametere den mottar og innholdet i disse. Dersom parameterene som mottas er korrekte vil metoden kunne kjøres og returnerer: Akseptabel verdi: - invector(vektor med oppdatert stripobjekt) Uakseptabel verdi: - Alt annet Test case set 1. stripobjektet(stripen som skal endres), changevector (en vektor som inneholder alle endringene i dynamisk flightinformasjon), invector (vektoren som inneholder stripen som skal endres). En vektor (invector) som inneholder det oppdaterte stripobjektet 2. stripobjektet, changevector(som ikke inneholder noe) og invector En vektor (invector) som er uendret Environment Special procedures Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert. Metoden skal testes ved at den kalles opp fra en mainmetode i en enkel javaklasse. Dataene som sendes inn lages av testpersonale og sendes som parametere til checkdynamicinformation. Testpersonale gjør vurdering utifra resultatet som metoden returnerer. Prosedyre: - Opprette forskjellig testdata (parametere) til checkdynamicinformation - Kalle checkdynamicinformation med forskjellige parametere fra mainmetoden - Vurdere resultatet som returneres fra metoden Svært viktig Side: 13

14 3.2.2 Test cases for metoden changestatusvectors Kategori Identification Testing approach Pass/fail criteria Beskrivelse UTC-2 Testes ved å sende ulike parametere til metoden Om metoden vil kunne utføres tilfredsstillende er avhengig av parameterene metoden mottar, dvs. hvilke parametere den mottar og innholdet i disse. Dersom parameterene som mottas er korrekte vil metoden kunne kjøres og returnerer: Akseptabel verdi: - oppdaterte vektorer: fromvector og tovector, samt stripobjektet Uakseptabel verdi: - Alt annet Test case set 1. To vektorer (fromvector, som inneholder strip som skal flyttes, og tovector, som er vektoren som strip skal flyttes til), samt stripobjektet som skal flyttes To oppdaterte vektorer(stripobjektet er fjernet fra fromvector og lagt i tovector), samt stripobjektet 2. To vektorer (fromvector, som er en tom), og tovector, som er vektoren som strip skal flyttes til), samt stripobjektet som skal flyttes 0 (forteller klassen som kalte metoden at noe gikk galt) Environment Special procedures Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert. Metoden skal testes ved at den kalles opp fra en mainmetode i en enkel javaklasse. Dataene som sendes inn lages av testpersonale og sendes som parametere til changestatusvectors. Testpersonale gjør vurdering utifra resultatet som metoden returnerer Prosedyre: - Opprette forskjellig testdata (parametere) til changestatusvectors - Kalle changestatusvectors med forskjellige parametere fra mainmetoden - Vurdere resultatet som returneres fra metoden Svært viktig Side: 14

15 3.2.3 Test cases for metoden maketransponder Kategori Identification Testing approach Pass/fail criteria Beskrivelse UTC-3 Testes ved å sende ulike parametere til metoden Om metoden vil kunne utføres tilfredsstillende er avhengig parameterene metoden mottar, dvs. hvilke parametere den mottar og innholdet i disse. Dersom parameterene som mottas er korrekte vil metoden kunne kjøres og returnerer: Akseptabel verdi: - Integer med verdi mellom 1 og 7777, men ikke verdiene 7500, 7600 og 7700 Uakseptabel verdi: - Alt annet Test case set 1. transpondervector(vektoren som inneholder alle transponderkodene som på dette tidspunkt brukes i FPSS) unik transponderkode transpondervector er oppdatert Environment Special procedures Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert. Metoden skal testes ved at den kalles opp fra en mainmetode i en enkel javaklasse. Dataene som sendes inn lages av testpersonale og sendes som parametere til maketransponder. Testpersonale gjør vurdering utifra resultatet som metoden returnerer. Prosedyre: - Opprette forskjellig testdata (parametere) til maketransponder - Kalle maketransponder med forskjellige parametere fra mainmetoden - Vurdere resultatet som returneres fra metoden Svært viktig Side: 15

16 3.2.4 Test cases for metoden removetransponder Kategori Identification Testing approach Pass/fail criteria Beskrivelse UTC-4 Testes ved å sende ulike parametere til metoden Om metoden vil kunne utføres tilfredsstillende er avhengig av parameterene metoden mottar, dvs. hvilke parametere den mottar og innholdet i disse. Dersom parameterene som mottas er korrekte vil metoden kunne kjøres og transponderkoden fjernes fra vektoren Test case set 1. transpondervector(vektoren som inneholder alle transponderkodene som på dette tidspunkt brukes i FPSS) og transponderkoden som skal fjernes fra denne Ingen transpondervector er oppdatert Environment Special procedures Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert. Metoden skal testes ved at den kalles opp fra en mainmetode i en enkel javaklasse. Dataene som sendes inn lages av testpersonale og sendes som parametere til removetransponder. Testpersonale gjør vurdering utifra resultatet til metoden. Prosedyre: - Opprette forskjellig testdata (parametere) til removetransponder - Kalle removetransponder med forskjellige parametere fra mainmetoden - Vurdere resultatet som returneres fra metoden Svært viktig Side: 16

17 3.2.5 Test cases for metoden checkstripexists Kategori Identification Testing approach Pass/fail criteria Beskrivelse UTC-5 Testes ved å sende ulike parametere til metoden Om metoden vil kunne utføres tilfredsstillende er avhengig av antall parametere metoden mottar, hvilke parametere den mottar og innholdet i disse. Dersom parameterene som mottas er korrekte vil metoden kunne kjøres og returnerer: Akseptabel verdi: - Boolsk verdi: true eller false Uakseptabel verdi: - Alt annet Test case set 1. Strings(callsign og adep), Date(etd) og vektor(fpdvector) true eller false 2. Strings og Date som ikke inneholder verdier, samt vektor 0 Environment Special procedures Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert. Metoden skal testes ved at den kalles opp fra en mainmetode i en enkel javaklasse. Dataene som sendes inn lages av testpersonale og sendes som parametere til checkstripexists. Testpersonale gjør vurdering utifra resultatet til metoden. Prosedyre: - Opprette forskjellig testdata (parametere) til checkstripexists - Kalle checkstripexists med forskjellige parametere fra mainmetoden - Vurdere resultatet som returneres fra metoden Svært viktig Side: 17

18 3.2.6 Test cases for metoden sortstrip Kategori Identification Testing approach Pass/fail criteria Beskrivelse UTC-6 Testes ved å sende ulike parametere til metoden Om metoden vil kunne utføres tilfredsstillende er avhengig av antall parametere metoden mottar, hvilke parametere den mottar og innholdet i disse. Dersom parameterene som mottas er korrekte vil metoden kunne kjøres og returnerer: Akseptabel verdi: - Sortert vektor Uakseptabel verdi: - Usortert vektor Test case set 1. Stripobjekt(som skal sorteres inn i en vektor) og en vektor(som strip skal legges inn i) Sortert vektor Environment Special procedures Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert. Metoden skal testes ved at den kalles opp fra en mainmetode i en enkel javaklasse. Dataene som sendes inn lages av testpersonale og sendes som parametere til sortstrip. Testpersonale gjør vurdering utifra resultatet til metoden. Prosedyre: - Opprette forskjellig testdata (parametere) til sortstrip - Kalle checkstripexists med forskjellige parametere fra mainmetoden - Vurdere resultatet som returneres fra metoden Svært viktig Side: 18

19 3.2.7 Test cases for metoden splitfpd Kategori Identification Testing approach Pass/fail criteria Beskrivelse UTC-7 Testes ved å sende ulike parametere til metoden Om metoden vil kunne utføres tilfredsstillende er avhengig av antall parametere metoden mottar, hvilke parametere den mottar og innholdet i disse. Dersom parameterene som mottas er korrekte vil metoden kunne kjøres og returnerer: Akseptabel verdi: - Vektor med FPD-data Uakseptabel verdi: - Alt annet Test case set 1. String-objekt og StringTokenizer-objekt vektor Environment Special procedures Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert. Metoden skal testes ved at den kalles opp fra en mainmetode i en enkel javaklasse. Dataene som sendes inn lages av testpersonale og sendes som parametere til splitfpd. Testpersonale gjør vurdering utifra resultatet til metoden. Prosedyre: - Opprette forskjellig testdata (parametere) til splitfpd - Kalle splitfpd med forskjellige parametere fra mainmetoden - Vurdere resultatet som returneres fra metoden Svært viktig Side: 19

20 3.2.8 Test cases for metoden deletestrip Kategori Identification Testing approach Pass/fail criteria Beskrivelse UTC-8 Testes ved å sende ulike parametere til metoden Om metoden vil kunne utføres tilfredsstillende er avhengig av antall parametere metoden mottar, hvilke parametere den mottar og innholdet i disse. Dersom parameterene som mottas er korrekte vil metoden kunne kjøres og returnerer: Akseptabel verdi: - Ingenting, men strip-objekt er fjernet fra handoffstripsvector Uakseptabel verdi: - Alt annet Test case set 1. Strip-objekt Ingen, men strip-objektet er fjernet fra handoffstripsvector Environment Special procedures Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert. Metoden skal testes ved at den kalles opp fra en mainmetode i en enkel javaklasse. Dataene som sendes inn lages av testpersonale og sendes som parametere til deletestrip. Testpersonale gjør vurdering utifra resultatet til metoden. Prosedyre: - Opprette forskjellig testdata (parametere) til deletestrip - Kalle deletestrip med forskjellige parametere fra mainmetoden - Vurdere resultatet som returneres fra metoden Svært viktig Side: 20

21 4 System test plans 4.1 System test strategy overview Testing process Etter å ha testet komponentene hver for seg og kommet frem til et tilfredsstillende resultat, ønsker vi å sammenføye komponentene gradvis til et komplett system. Denne typen testing kalles integrasjonstesting og tester interfaces og kommunikasjonen mellom komponentene. Det er viktig med en gradvis sammenføyning av komponentene, fordi det ellers vil være vanskelig å lokalisere feil. Man lager seg et hierarki av komponentene, som gjenspeiler i hvilken rekkefølge komponentene kan testes i forhold til hverandre. Komponentene som er minst avhengige av kommunikasjon med andre komponenter for å bli testet, kommer nederst i hierarkiet. Avhengigheten øker desto lenger opp i hierarkiet man kommer. Når man har et hierarki av komponentene må man bestemme en testingstrategi. De mest kjente strategiene er bottom-up, top-down, big-bang og sandwich. Valget av strategi faller ikke bare på systemets karakteristikk, men også på kundens forventninger. Ofte ønsker kunden å se en fullt fungerende system så tidlig som mulig. Da er det mulig å begynne med integrasjonstesting av de mest grunnleggende komponentene, mens de mer kompliserte komponentene fortsatt er i utviklingsstadiet. For å teste de mest grunnleggende komponentene, lager man drivere som simulerer komponentene med deres interface og kommuikasjon over i hierarkiet. Drivere utvikles for bottom-up strategien. Stubs brukes ved top-down strategi, når man ønsker å simulere komponentene med interfaces og kommunikasjon under i hierarkiet. For vårt system vil det ikke være aktuelt å få det tidlig ferdig for å vise det frem til kunder. Slik hierarkiet vårt er utformet ligger grunnklassene nederst med hovedklassen FPSS og GUI-klassene GUIStripContainer og GUIStripboard i neste stadie. Øverst i hierarkiet har vi Change-komponenten, som trenger klassene GUIStripContainer, GUIStripboard og FPSS for å utføre oppgavene sine. Denne komponenten ønsker vi først å teste når vi har sammenføyet de andre komponentene. Vår strategi for integrasjon testing derfor være bottom-up, fordi det vil være svært vanskelig å finne feil om komponentene oppe i hierarkiet blir testet sammen på et tidlig stadie. Etter å ha gjennomført integrasjonstestingen ønsker man å teste funksjonaliteten til systemet. Man flytter fokuset fra komponentene og deres samspill, til ren funksjonalitet. Systemet ses som et lukket system, eller en såkalt black box. Man sammenligner det systemet gjør med de funksjonelle kravene til systemet. Man ønsker som oftest å gjennomføre acceptance testing. Dette for å se om kundene får det produktet de ønsker. Denne testingen skal gjennomføres av kundene, for å se om den virkelig møter behovene og forventningene deres. Utviklerne skal kun assistere ved eventuelle tekniske spørsmål om systemet. De forskjellige formene for evaluering av systemet som gjøres under acceptance testing, er benchmark test, pilot test og alpha og beta tests. Benchmark test vil være en rekke tester som ser hvordan systemet vil fungere i den tilstanden det vil ha når det er installert. Kunden vurderer systemets utførelse av hver enkel test, og tester ofte også de uvanlige bruksområdene. Under en pilot test installerer man systemet på en eksperimentell basis. Brukeren bruker systemet som om det skulle vært installert permanent og tester de typiske ordinære oppgavene systemet skal ha. Side: 21

22 Denne typen testing kalles også i enkelte tilfeller en beta test. Alpha test vil være lik beta test, men vil utføres av brukere fra vår egen organisasjon. Denne typen testing brukes kun når systemet skal brukes av mange forskjellige brukere, som eksempelvis systemer som har grensesnitt mot internett. For vårt system vil det ikke være aktuelt å gjennomføre acceptance test, da vi ikke har noen reelle brukere. Alpha testing vil heller ikke være i samsvar med det systemet vi utvikler, da dette er for en bestemt brukergruppe Requirement Tracebility Testingen relateres til SRS og SDS Features to be tested Integrasjonstesting: Komponenten Strip (klassene StripCreator, Strip, ArrivalStrip, DepartureStrip og TransitStrip) Komponenten GUIStrip (klassene GUIStripCreator, GUIStrip, GUIArrivalStrip, GUIDepartureStrip og GUITransitStrip) Komponenten GUIStripcontainer Komponenten GUIStripboard Komponenten FPSS Funksjonstesting: Endre status på strip Forandre dynamisk flightinformasjon Testing schedule and resources Integrasjon testingen skal begynne når komponentene er ferdigstilt. Integrasjon testingen må være ferdig, før det er mulig å begynne med funksjon testingen. Hele utviklingsteamet vil være involvert i testingen Hardware and software requirements Driverne og stubs som lages for å teste Komponentene skal skrives i javakode. For å kjøre en testcase må koden for driverne og stubs kompileres og eksekveres. Driverne skal ha navn etter følgende standard: modulnavn_driver.java, og legges i mappen Test på SMS serveren. Stubs legges sammen sted og vil ha navn etter type: modulnavn_stub.java Constraints Ingen constraints på nåværende tidspunkt. Side: 22

23 4.2 Integration testing Change GUIStripBoard GUIStripContainer FPSS FPSSMenuBar GUIStipHeader GUIStrip Strip Sort CheckData Backup Change Inneholder klassene ChangeDynamicInformation og ChangeStatus Backup Inneholder klassene PrintOut og SaveDatabase Strip Inneholder klassene StripCreator, Strip, ArrivalStrip, DepartureStrip og TransitStrip GUIStrip Inneholder klassene GUIStripCreator, GUIStrip, GUIArrivalStrip, GUIDepartureStrip og GUITransitStrip Side: 23

24 4.2.1 Test cases for Strip Kategori Identification Testing approach Pass/fail criteria Beskrivelse ITC-1 Testmodulen Strip skal teste interfacet mellom klassene StripCreator, Strip, ArrivalStrip, DepartureStrip og TransitStrip, samt om disse klassene prosesserer og leverer riktig data. Klassene skal testes ved det lages en driver som skal prosessere fpd data, og legge disse dataene inn i en vektor. Driveren skal sende fpd data til metoden createstrip i klassen StripCreator. Dataene som sendes skal variere avhengig av type strip som skal lages(departure, Arrival eller Transit). Det som returneres til driveren skal sjekkes for innhold, dvs. om det returneres vektor med korrekt stripobjekt og om innholdet i stripobjektet er riktig Dersom testen kan kjøres uten feil og avleverer riktig type strip, med riktig innhold, er den vellykket. Hvis testen feiler, eller dataene som returneres ikke stemmer med input har testen feilet Akseptabel returverdi: - Vektor med riktig(e) stripobjekt(er) Uakseptabel returverdi: - alt annet Test case set 1. fpd-vektor, med ArrivalStrip- og DepartureStrip-data Vektor med et ArrivalStrip- og et DepartureStrip-objekt 2. fpd-vektor, med ArrivalStrip-data Vektor med et ArrivalStrip-objekt 3. fpd-vektor, med DepartureStrip-data Vektor med et DepartureStrip-objekt 4. Input fpd-vektor, med TransitStrip-data Vektor med et TransitStrip-objekt Environment Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert Svært viktig Side: 24

25 4.2.2 Test cases for FPSS Kategori Identification Testing approach Pass/fail criteria Beskrivelse ITC-2 Testmodulen FPSS skal teste interfacet mellom klassene FPSS, CheckData, Strip, Sort, PrintOut og SaveDatabase, samt om disse klassene prosesserer og leverer riktig data. Klassene skal testes ved det lages en driver som skal sende stringer som inneholder hele FPDer til metoden splitfpd i klassen FPSS. Det skal ikke returneres noe til driveren, men det skal gjøres en sjekk om stripobjekt blir laget, om det inneholder riktige data og om den legges i riktig vektor. I tillegg sjekkes at strip blir skrevet ut på papir, samt lagres i database. Dersom testen verifiserer at: koden kjøres uten feil det ikke lages et stripobjekt som finnes fra før i FPSS riktig type stripobjekt lages stripobjekt av typen departure og arrival sorteres på ETD eller ETA stripobjektene legges i riktig vektor stripobjektet skrives ut på papir stripobjektet lagres i database fungerer klasser og tilhørende metoder tilfredsstillende Ved feil i et av disse punktene fungerer ikke testmodulen tilfredsstillende Test case set 1. String med hele FPDen Riktig stripobjekt Sorterte departure og arrivalstrip Stripobjekt i riktig vektor Stripobjekt ut på papir Stripobjekt lagret i database 2. String med hele FPDen, der dataene finnes i FPSS fra før 0 Environment Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert Testmodeulen er avhengig av at systemet har tilkoblet en printer, samt at det er opprettet og tilgang til database Side: 25

26 4.2.3 Test cases for GUIStrip Kategori Identification Testing approach Pass/fail criteria Beskrivelse ITC-3 Tester klassene som ligger i test-modulen GUIStrip. Vi lager en driver, som kaller opp metoden createguistrip i klassen GUIStripCreator. Dataene som sendes inn lages av testpersonale og sendes som parametere til createguistrip med et Stripobjekt, int med bredde for stripboard og høyde på stripcontainer. Testpersonale gjør vurdering utifra resultatet til metoden. Om testen utføres tilfredsstillende er avhengig av at klassene med tilhørende metoder, som guistripcreator kaller opp, fungerer. Dessuten må parameterene være korrekte. Ukorrekte parametere kan være for mange parametere, hva slags type parametere og deres innhold. Dersom klassene og metodene fungerer og parameterne er korrekt, vil metoden kjøre og returnere: Akseptabel verdi: - GUIStrip-objekt med riktig bredde og høyde Uakseptabel verdi: - Alt annet Test case set 1. ArrivalStrip-objekt, int for bredde og int for høyde GUIStrip-objekt 2. DepartureStrip-objekt, int for bredde og int for høyde GUIStrip-objekt 3. TransitStrip-objekt, int for bredde og int for høyde GUIStrip-objekt 4. Strip-objekt, int for bredde og int for høyde, som ikke inneholder verdier 0 Environment Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert Svært viktig Side: 26

27 4.2.4 Test cases for GUIStripContainer Kategori Identification Testing approach Pass/fail criteria Beskrivelse ITC-4 Tester klassen GUIStripContainer som ligger i test-modulen GSContainer. Vi lager en driver som kaller opp konstruktøren og metodene addguistrip, removeguistrip og showstrips. Dataene som sendes inn lages av testpersonale og sendes som parametere til de forskjellige metodene og konstruktøren. Testpersonale gjør vurdering utifra resultatet til metoden. Om testen utføres tilfredsstillende er avhengig av at klassen med tilhørende metoder fungerer. Kommunikasjonen mellom denne klassen og de andre involverte klassene blir også testet. Parameterne til konstruktøren må være korrekte. Dette gjelder også for parameterne for de forskjellige metodene. Ukorrekte parametere kan være for mange parametere, hva slags type og deres innhold. Dersom klassene og metodene fungerer og parameterne er korrekt, vil metodene kjøre og returnere: Akseptabel verdi konstruktør: - String med container type, riktig bredde og høyde Uakseptabel verdi konstruktør: - Alt annet Akseptabel verdi metoden addguistrip: - Strip-objekt Uakseptabel verdi konstruktør addguistrip: - Alt annet Akseptabel verdi removeguistrip: - Strip-objekt Uakseptabel verdi removeguistrip: - Alt annet Akseptabel verdi showstrip: - Vector med GUIStrip-objekter Uakseptabel verdi showstrip: - Alt annet Test case set 1.1 Input konstruktør: String med type container (pending, taxi, departure, inbound, arrival eller handoff) int for bredde og int for høyde GUIStripcontainer 1.2 Input konstruktør: String med type container, int for bredde og int for høyde, som ikke inneholder verdier Side: 27

28 0 2.1 Input addguistrip: ArrivalStrip-objekt Oppdatert vector med ny GUIArrivalStrip-objekt 2.2 Input addguistrip: DepartureStrip-objekt Oppdatert vector med ny GUIDepartureStrip-objekt 2.3 Input addguistrip: TransitStrip-objekt Oppdatert vector med ny GUITransitStrip-objekt 2.4 Input addguistrip: Strip-objekt som ikke innholder verdier Input removeguistrip: ArrivalStrip-objekt Oppdatert vector uten GUIArrivalStrip-objekt 3.2 Input removeguistrip: DepartureStrip-objekt Oppdatert vector uten GUIDepartureStrip-objekt 3.3 Input removeguistrip: TransitStrip-objekt Oppdatert vector uten GUITransitStrip-objekt 3.4 Input removeguistrip: Strip-objekt som ikke innholder verdier 0 Side: 28

29 4.1 Input showstrip: Vector med GUIStrips Oppdatert panel med GUIStrips 4.2 Input showstrip: Vector med GUIStrips som ikke inneholder verdier 0 Environment Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert Svært viktig Side: 29

30 4.2.5 Test cases for GUIStripBoard Kategori Identification Testing approach Pass/fail criteria Beskrivelse ITC-5 Tester klassen som ligger i test-modulen GSBoard. Vi lager en driver, som kaller opp konstruktøren i klassen GUIStripboard. Dataene som trengs lages av testpersonale og settes slik at stripbordet kommer opp riktig. Testpersonale gjør vurdering utifra resultatet til metoden. Om testen utføres tilfredsstillende er avhengig av at klassen med tilhørende metoder, som konstruktørem kaller opp, fungerer. Dessuten må modulene som har vært testet før være korrekte, slik at kommunikasjonen med dem vil være feilfri. Dersom klassene og metodene fungerer og kommunikasjonen er korrekt, vil konstruktøren og metodene kjøre og returnere: Akseptabel verdi: - GUIStripboard med riktig bredde og høyde, riktig utseende Uakseptabel verdi: - Alt annet Test case set 1. Kall av konstruktøren GUIStripboard 2. Intet kall av konstruktøren Intet GUIStripboard Environment Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert Svært viktig Side: 30

31 4.3 Function testing Test cases for Endre status på strip Kategori Identification Functions to be tested Testing approach Pass/fail criteria Beskrivelse FTC-1 Funksjonene som skal testes inkluderer å flytte strips under ny status på skjerm, få generert eller fjernet transponderkode fra strip, samt at strip automatisk fjernes fra skjerm når den har ligget 10 minutter i handoff Testen utføres ved å flytte strips på skjermen. Man forsøker å legge strips under ny status og i forskjellige posisjoner under denne statusen Dersom testen verifiserer at: programmet kjøres uten feil at strip kan legges under ønsket status at strip kan legges i ønsket posisjon under ønsket status at strip som flyttes fra pendinglisten til aktiv får tildelt en unik transponderkode at transponderkode fjernes fra strip som flyttes fra aktiv til pendingliste at strip fjernes fra skjerm 10 minutter etter er lagt i handoff fungerer programmet tilfredsstillende Ved feil i et av disse punktene fungerer ikke testmodulen tilfredsstillende Test case set 1. Flytte strip fra pendingliste til ønsket status og i ønsket posisjon (dvs. aktivere strip) Strip under ønsket status og i ønsket posisjon Strip har fått tildelt en unik transponderkode 2. Flytte strip fra aktiv status til ønsket posisjon i pendingliste Strip i ønsket posisjon i pendingliste Transponderkode fjernet fra strip 3. Strip som er flyttet til handoff Strip fjernes automatisk fra skjermen etter 10 minutter Transponderkode som blir frigjort til gjenbruk Environment Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert Svært viktig Side: 31

32 4.3.2 Test cases for Forandre dynamisk flightinformasjon Kategori Identification Functions to test Testing approach Pass/fail criteria Beskrivelse FTC-2 Funksjonene som skal testes er: forandring i høyde, å sette aktuell landingstid og forandring i flygerute, på strip Tester funksjonene under forandringer i dynamisk informasjon. Vi tester funksjonene på GUIStrips ved å legge inn data i de forskjellige feltene på GUIStrips på skjerm. Dersom testen verifiserer at: programvaren kjøres uten feil man kan legge inn ny høyde ny høyde legges inn riktig man kan sette aktuell landingstid aktuell landingstid vises riktig mulig å forandre flygerute flygerute vises riktig Test case set 1. Ny høyde Ny høyde inn i felt for høyder 2. Aktuell landingstid Aktuell landingstid i felt for ETA/ATA 3. Ny Flygerute Ny flygerute i felt for flygerute Environment Precedence and dependencies Kan testes under hvilket som helst OS som har Java 1.4 installert Svært viktig Side: 32

33 5 Tracebility from SRS to SDS Tabellen linker Software Requirements i SRS til deres korresponderende design egenskaper i SDS Test case SRS SDS UTC-1: Endre dynamisk F , flightinformasjon UTC-2: Forandre vektorstatus F-21-F , UTC-3: Lage transponderkode F-27, F UTC-4: Fjerne transponderkode F-34, F UTC-5: Sjekk om strip eksisterer F , UTC-6: Sortere strips F-12, F-15, F , UTC-7: Splitte FPD F UTC-8: Slette strip F ITC-1: Lage riktig type strip F-3, F-5-F-9 3.2, 3.2.1, 3.3, , 3.4, 3.4.1, 3.5, 3.5.1, 3.6, ITC-2: Starte FPSS F-3, F-5-F18, F-22, F-23, 3.1, 3.1.1, 3.1.3, 3.1.4, F-36, IF-1-IF-6, TI , 3.1.6, 3.1.7, 3.1.8, 3.1.9, 3.2, 3.2.1, 3.3, , 3.4, 3.4.1, 3.5, 3.5.1, 3.6, 3.6.1, 3.11, , 3.12, ITC-3: Lage GUIStrip-objekt G-8-G-10, G-17, G , , 3.18, , 3.19, , 3.20, , 3.21, ITC-4: Lage GUIStrip-container F-24, G-8-G-10, G-14-G- 18, G-20 ITC-5: Lage GUIStripboard F-24, G-5-G-10, G-14 - G-21 FTC-1: Endre status på strip F-24, F-27, F-28, F-33 F35, IF-7, G-3, G-11-G- 13, G-15, G , 3.2.1, 3.3, , 3.4, 3.4.1, 3.5, 3.5.1, 3.6, 3.6.1, 3.16, , 3.17, , 3.18, , 3.19, , 3.20, , 3.21, , 3.2.1, 3.3, , 3.4, 3.4.1, 3.5, 3.5.1, 3.6, 3.6.1, 3.13, , , 3.15, , 3.16, , 3.17, , 3.18, , 3.19, , 3.20, , 3.21, , 3.1.6, 3.1.7, 3.1.8, 3.10, , 3.16, , 3.17, , 3.18, , 3.19, , 3.20, , 3.21, Side: 33

34 FTC-2: Endre dynamisk flightinformasjon F-29, G-2, G , 3.3.3, 3.3.4, 3.4, 3.5, 3.6, 3.9, 3.9.1, 3.16, , 3.17, , 3.18, , 3.19, , 3.20, , 3.21, Side: 34

35 6 Test cross-reference Required Id UTC-1 UTC-2 UTC-3 UTC-4 UTC-5 Description Test Option Test Variables System functionality Forandre Inspection, Ingen Sikre at dynamisk Test Data stripobjektet flightinformasjon oppdateres når det gjøres endringar i dynamsik flightinformasjon Forandre vektorstatus Lage transponderkode Fjerne transponderkode Sjekk om strip eksisterer Inspection, Test Data Inspection, Test Data Inspection, Test Data Inspection, Test Data UTC-6 Sortere strips Inspection, Test Data UTC-7 Splitte FPD Inspection, Test Data UTC-8 Slette strip Inspection, Test Data ITC-1 Lage riktig type strip Inspection, Test Data ITC-2 Starte FPSS Inspection, Test Data ITC-3 Lage Inspection, GUIStripobjekt Test Data ITC-4 Lage GUIStripcontainer Inspection, Test Data Ingen Ingen Ingen Ingen Ingen Ingen Ingen Ingen Ingen Ingen Ingen Sikre at strip flyttes til riktig vektor når den endrer status Sikre at det at en strip får unik transponderkode Sikre at transponderkode blir frigjort når strip forsvinner fra handoff Sikre at enhver strip som finnes i FPSS er unik Sikre at strips flyttes til pendinglisten 30 minutter for den blir aktiv Sikre at riktig data legges på riktig sted i vektor Sikre at strip slettes fra FPSS når strip forsvinner fra handoff Sikre at riktig type strip lages: Arrival, Transit eller Departurestrip Sikre at FPSS starter korrekt Sikre at riktig type GUIstrip lages: GUIArrival, GUITransit eller GUIDeparturestrip Sikre at riktig GUIStrip-container opprettes og at Side: 35

36 ITC-5 FTC-1 FTC-2 Lage GUIStripboard Endre status på strip Endre dynamisk flightinformasjon GUIStrip-objekt kan legges til og fjernes fra denne Inspection Ingen Sikre at GUIStripboard vises riktig på skjerm Black Box, Test Data Black Box, Test Data Strip i ny status Oppdatert dynamisk flightinformasjo n Sikre at stripobjekt kan flyttes mellom forskjellige status Sikre at dynamisk flightinformasjon på strip-objekt kan forandres og sikre at denne informasjonen kommer opp på riktig sted på strip Side: 36