1
Innholdsfortegnelse 1. Testing... 3 1.1 Feiltesting av koden... 3 1.2 Funksjonstesting:... 7 2. Kilder.10 2
1. Testing Testing av et system er nødvendig for å finne ut om systemet fungere slik det skal og har nådd sitt mål. Vi har gjennomført ulike typer tester ved bruk av ulike metoder både under utvikling og etter det. 1.1 Feiltesting av koden Utviklingen av systemet bestod av flere iterasjoner. Programkoden ble testet underveis i hver iterasjon. Metoder og tekniker vi har brukt for å finne og rette eventuelle feil og svakheter i kildekoden og de ulike typer feil, som oppstod under utvikling av systemet og måten vi har løst de utfordringene beskrives under. Formål: Formålet met kodetesting var at å sjekke hver impementerte funksjon fungerer på riktig måte. Testområde: hele systemet Verktøy: Visuellstudio 2013, nettleser, Postman Teknikker: Vi har benyttet forskjellige teknikker og verktøyer for feilsøking under utviklingen blant annet Runtime tilbakemeldinger, Exceptions, Break pointing og IntelliSense. Runtime error og exception Under kompilering av kodelinje for å teste en funksjon eller et spesifikk view, opplever man at applikasjonen stopper. Når du kjører, er den lagrede informasjonen kontrollert, og eventuelle erklæringer som ikke er gyldig, ender du opp med en run-time exception. Slike informative feilmeldinger gir utvikleren informasjon om hvilken type feil og hvor feilen ligger. Det er ikke alle Exceptions som for eksempel NullReferenceException, som er ikke nok beskrivende og det er mange feil som kan skje under kjøring av metoder. Ved hjelp av Break pointing er det ikke så vanskelig å finne og rette opp slike feil. 3
Breakpoints : Teknikken å stoppe kjøring av programmet i et bestemt punkt, kan være veldig effektivt for å finne feil plassering. Man kan sjekke verdiene til lokale variabler og se hva som skjer linje for linje. Slik er det enklere å finne årsaken til at programmet ikke fungerer (Developer Network, udatert). IntelliSense: IntelliSense er en kraftig funksjon som i betydelig grad kan øke produktiviteten, fordi det gir logiske kode elementer, som man kan velge fra en rullegardin meny når man koder. Den er designet for å gjøre utviklingen mye enklere ved å foreslå hvilke funksjoner som passer. Den utfører også automatisk feilretting mens man skriver ved å streke under feil eller gi forslag til endringer. Denne prosessen kan redusere tiden man bruker på skriving og for å unngå skrivefeil i koden (Developer Network, udatert). 4
Postman: Postman er en REST Client som er et veldig nyttig verktøy for å teste funksjonaliteten under utviklingsprosessen. Postman kan dramatisk redusere tiden å teste APIer. Postman tilpasser seg for individuelle utviklere, små grupper eller store organisasjoner like godt. Den støtter 11 ulike HTTP-metoder blant annet Get, Post, Put og Delete som blir mest brukt under utvikling. Den støtter både JSON og XML format (Ullnæs, 2013). Alle Controller arver ApiController og ApiController klassen er base klasse av web API kontrolleren som inneholder samme metoder som http, det vil si, Get (for å få resurser), Post (for å legge til resurser), Put (for å oppdatere resurser) og Delete (for å fjerne resurser) For å sende en kall, kjører man prosjektet og fyller inn en URL i postman, velger en httpmetoden blant annet, Get, Post, Put eller Delete. Etter å trykke på send får man resultatet av kallet i form av Pretty, Raw eller Preview. I vår tilfelle, et eksempel på URL for å liste alle serverne er http://localhost:55355/servers/ og for hver enkel server kommer serveren sin id i slutten, for eks.: http://localhost:55355/servers/1043 5
Hver forespørsel man sender ved hjelp av Postman blir lagret i historien og kan brukes senere. Man kan lagre forespørsler om en API sammen i Collections. Vi har brukt Postman til å teste verdier vi vet skal fungere, som id'en til et visst objekt. Vi har også testet på id'er vi vet ikke finnes for å bekrefte et "null" resultat. Vi har også testet verdier vi vet ikke passer inn i typen, for eksempel et tall som er større enn en integer for å sjekke at vi får forventet oppførsel fra systemet 6
1.2 Funksjonstesting: For å sikre at de funksjonelle kravene ble oppnådd har vi gjennomført en funksjonstesting. Her under vises en liste over de viktigste kravene samt tester og kommentarer. Krav Testresultat Kommentar Systemet skal kunne hente info om status på tjenester tjenester på en server via WMI Systemet skal kunne hente informasjon om server objekter fra Active Directory Ok, vi mottar status på tjeneste fra WMI Ok, vi mottar alle serverobjekter som matcher den insendte RegEx verdien Her har vi selvsagt ikke testet mot hver server, men gjort et lite utvalg og testet med metoden GetServiceStatus fra WmiAccessTest klassen Testet med metoden GetServersTest i klassen AdAccessTest Systemet skal kunne fungere på tvers av soner (domener) fra et sentralt system Ok, vi kan aksessere et domene fra et annet domenet. Vi har testet mot et domenet. Testmaskinen ble plassert i et annet domenet Systemet skal kunne opprette restartjobber Systemet skal kunne kontrollere servere etter boot via WMI Ok, Metoden oppretter de jobber som skal opprettes i det innsendte tidsrommet Ok Testet fra metoden CreateJobsTest i JobManagerTest klassen Vi har testet TestWmiConnection metoden mot et utvalg 7
servere Systemet skal kunne sende meldinger til påloggede brukere før restart. Brukeren skal kunne legge inn eksisterende regler på nye servere Brukeren skal kunne se og søke i server logg Brukeren skal kunne søke etter servere og se hvilke regler som treffer den N/A Ok N/A Regler velger hvilke servere som booter utifra en RegEx verdi, nye servere vil automatisk bli tatt med i regler dersom noen treffer. Ved å trykke på logg i serverlisten får man opp en logg liste for den serveren med et søkefelt Ikke implementert Brukeren skal kunne opprette nye regler for restart og sjekk av tjenester etter restart Bruker skal ikke kunne opprette en regel uten å spesifisere navn og regex Ok Ok. Regler kan opprettes via regel siden Det gis en melding i brukergrensesnittet dersom man forsøker å legge inn en ugyldig regel. Spesifiserer man ajax kallet selv er egen input 8
Brukeren skal kunne legge til og fjerne mottakere av dagsrapport Systemet skal kunne generere en daglig rapport med utgangspunkt i loggene. Denne skal formateres på en slik måte at det er lett og skaffe seg oversikt uten å bli overlesset med informasjon. N/A validering i modellen. Dette ble testet via Postman1 Det er implementert en rapportside istedenfor utsending av dagsrapport Dette har vi løst med widgets på rapportsiden som gir deg en oversiktover tilstanded til systemet og de siste utførte jobbene. 1 Postman er en verktøy som hjelper til å bli mer effektiv når man arbeider med APIer (Postman-REST client, 2014). 9
Kilder: Developer Network. (udatert a). Using IntelliSense: Visual C# IntelliSense. Hentet Mai 24. 2014 fra: http://msdn.microsoft.com/en-us/library/43f44291.aspx Postman REST Client. (2014). Beskrivelse: Postman helps you be more efficient while working with APIs. Postman is a scratch-your-own-itch project. The need for it arose Hentet Mai 25, 2014 fra: https://chrome.google.com/webstore/detail/postman-restclient/fdmmgilgnpjigdojojpjoooidkmcomcm/details Developer Network. (udatert b). Debugger Roadmap: Breakpoints and Tracepoints. Hentet Mai 24. 2014 fra: http://msdn.microsoft.com/en-us/library/ktf38f66(v=vs.90).aspx Ulnæs, Anders. (2013). Testing av REST-tjenester med Postman. Hentet Mai 25, 2014 fra: http://fagblogg.mesan.no/test-av-rest-med-postman/ 10