Test av Metria Maps avseende Användbarhet och prestanda

Transkript

1 GeoTest Testrapport draft.4 för Metria Maps Test av Metria Maps avseende Användbarhet och prestanda Solgerd Tanzilli, Projektledare Tomas Rosendal, Testledare Xin He, Testare Lars Palm, Testare Anders Östman, Vetenskaplig ledare 1

2 GeoTest Testrapport draft.4 för Metria Maps Sammanfattning Syftet med testerna har varit att testa Metria Maps med avseende på prestanda och användbarhet. För test av prestanda har de kriterier som specificeras av INSPIRE använts. För användbarhetstesterna har följande utgångspunkter använts Är Metria Maps lätt att använda? Var finns svårigheterna? Var finns styrkorna? Vad saknas? Användbarhet Användbarhetstestet är baserat på empirisk metod där användare observeras medan de utför uppgifter för olika testscenarios. Syftet med användbarhetstestet är att kunna bestämma hur bra och hur snabbt en ny användare kan lära sig Metria Maps gränssnitt för webtjänsten. Bland annat testades hur lång tid som användes för att lösa en uppgift, operationella mönster och som en helhet kan dessa aspekter ge en översiktlig uppfattning om användbarheten i Metria Maps. Prestanda Prestanda och kvalitet mäts i termer av systemets förmåga att svara upp mot användbarhet för att nyttja tjänsterna med avseende på systemets tillförlitlighet över tid. Prestanda för Geodata tjänster är besläktade med och relaterar till; klient, server och nätverk. Genomsläpplighet och svarstid används som mätbara indikatorer för prestanda. Här skall arkitekturen för nätverkstjänster, obligatoriska kvalitets kriterier sammanföras med data- och tjänsteleverantörer hos medlemsstaterna, som det beskrivs i Commission Regulation (EC) No 976/2009 of 19 October 2009 (Official Journal of the European Union, 2009) : Resultat användbarhetstester En tydligare kravbild för vem Metria Maps och dess tjänster skall utformas för saknades. Den hade avsevärt underlättat utformningen av testerna. Av de testscenarios och uppgifter som genomfördes under de tre testdagarna kan man säga att Metria Maps har förmåga att ge service till dom flesta i kommuner och myndigheter. En introduktion/kortare utbildning av tjänsten kan dock vara på sin plats för att lättare komma igång. Erfarenheten baseras på att testpanelen med olika bakgrund och kompetens inom IT och GIS, uppvisar stora skillnader i förmåga att genomföra testerna. Är Metria Maps lätt att använda? Ja, Metria Maps är ett system som är lätt att använda och komma igång med. Det är lätt att hitta och förstå knapparna och dess funktioner. Var finns svårigheterna? Att hantera och hitta information om lagren, att veta när systemet arbetar upplevde testarna som trögt. (detta kan bero på att vi testade mot Metria Maps testmiljö) Sökfunktionen upplevdes som opålitlig och ologisk. 2

3 GeoTest Testrapport draft.4 för Metria Maps Var finns styrkorna? Gränsnittet upplevdes som användarvänligt och lättillgängligt, knapparna beskrivs på ett bra och enkelt sätt, kartografin är bra och funktionen att lägga till egna VMS lager uppskattas. Systemet är lätt att lära sig. Vad saknas? Attributtabell Fritextsökning, möjlighet att kunna rensa sökkriterina samt rent generellt, en bättre sökfunktion Resultat prestandatester Testsammanfattningen nedan visar att Metria Maps begränsning I samtidiga användare ligger mellan 31 0ch 51. Metria Maps möter INSPIREs krav för Get Download Service Metadata och Get Spatial Objects och möter inte INSPIREs krav för Get Map och Describe Spatial Objects Types. System limit test Table i. Results of system limit test for the view service of MetriaMaps 3

4 GeoTest Testrapport draft.4 för Metria Maps Test against INSPIRE performance requirements Services INSPIRE Requirements MetriaMaps Performance WMS WFS GetMap Get Download Service Metadata Get Spatial Objects Describe Spatial Objects Types For a 470Kb image, should be of maximum 5 second in normal situation, with a frequency of request of 20 requests per second. 10 seconds in normal situations, with a frequency of request of 10 requests per second. 30 second initial response, then the service shall maintain a sustained response > 0.5 MB/s, alternatively 500 spatial objects/s in normal situations, with a frequency of request of 10 requests per second. 10 second initial response, then the service shall maintain a sustained response > 0.5 MB/s, alternatively 500 spatial objects types per second in normal situations, with a frequency of request of 10 requests per second. 11.2s, when there are 20 concurrent requests. 0.2s, when there are 10 concurrent requests. 0.4s, when there are 10 concurrent requests for a data set containing 1,000 spatial objects. 43.0s, when there are 10 concurrent requests for a description file containing 162 spatial object types. Table ii. Summary of test results against INSPIRE performance requirements 4

5 Innehåll 1. Introduktion Projektplan för testuppdraget Test strategi och testprocess identifiera testbehov och testupplägg utifrån föreslaget testkoncept med projektledningen identifiera och välja testscenarios och testpanel för användbarhetstesterna förbereda testpanelen via intervjuer förbereda och välja testfall säkerställa testfall i pilottest testgenomförandet rapport och analys Målet med testerna Testpanelen Krav från Metria / Metria Maps Genomförande i GeoUsability lab Rapportering Användbarhetstester Metod Scenarioutveckling och design Uppgifter Resultat Analys av testresultaten Rekommendation - användbarhet Prestanda tester Introduction Methods and materials Results and analyses System limit test Test against INSPIRE requirements Discussions Test Summary System limit test Test against against INSPIRE performance requirements Appendix... 24

6 1. Introduktion GeoTest är ett utvecklingsinitiativ mellan Lantmäteriet, FPX och Högskolan i Gävle för att utveckla testmetodik för geodata enligt INSPIRE direktivets krav på geodata. Lantmäteriet är samordnare av INSPIRE direktivets implementering på nationell nivå, FPX är ett ledande GIS-kluster i Sverige. GIS-klustrets uppgift är bland annat att stödja och utveckla medlemmarnas nätverkande inom GIS sektorn. GIS Institutet vid Högskolan i Gävle är GeoTest projektets vetenskapliga garant och har i den rollen också kopplingar till andra Europeiska institutioner för FoU samverkan enligt INSPIRE direktivet. Metria och GeoTest samverkar inom GeoTest projektram med syfte att bistå varandra med erfarenheter och kompetens inom testområdet. Inom Metria finns erfarenhet från affärs- och tjänstesidan som är värdefulla för GeoTest där Metrias användare och kundkontakter nyttjas för uppsättning av valideringsfall, viktiga för kvalitetssäkring av testmetodik och testprocess. I detta projekt har valideringsfallet Metria Maps testats med avseende på användbarhet och prestanda. För Metria är GeoTest erfarenheter av systematisk utveckling av testmetoder och kopplingen till vetenskap och forskning en viktig del. Frågor som belysts och som testerna besvarar är: Hur bra är Metria Maps, hur bra kan en användare tillgodogöra sig tjänsten? Vilka är styrkorna? Vilka är svagheterna? Fattas viktiga delar eller funktioner? Uppfyller Metria Maps de krav som INSPIRE ställer? Valideringsfallet Metria Maps täcker två typer av tester och anlyser inom GeoTest tjänsteportfölj, nämligen: Användbarhet; Användbarhet av användargränssnitt är ett viktigt mål för all utveckling av applikationer och geodatatjänster. Vid användbarhetstesterna är fokus satt att utvärdera Metria Maps utifrån slutanvändarnas perspektiv. Huvudfokus ställs till vilka mänskliga krav (kognitiva krav) som kan ställas på tjänsten och vilket genomslag detta får till slutanvändaren. Systemets uppbyggnad enkelt eller komplext- leder vidare till systemets användbarhet lätt- eller svårt att använda. Övergripande mål med användbarhetstesterna är att peka på de delar i Metria Maps gränssnitt som försvårar användningen samt varför dessa problem uppstår. Prestanda: Profilen för prestandatesterna sätts upp mot de krav som ställs på nätverkstjänster enligt INSPIRE. Kraven skall kunna svara upp mot användarnas hantering av operationer och funktioner, satt i relation till tjänstens tillförlitlighet över tid. Prestanda hos webtjänster består av tre komponenter, klient, server och nätverk vilka det tas hänsyn till i mätningarna. Genomsläpplighets- och svarstid används som mätbara indikatorer. Fokus ligger i huvudsak på prestanda hos klienten. Under projektet har GeoTest mätmetod, som tagits fram i tidigare valideringsprojekt, vidareutvecklats. Testmetodik Testmetoderna är framtagna för att möta INSPIREs standard och krav på prestanda för geodatatjänster. EU direktivet INSPIRE sätter press på producenter och användare av geodata att anpassa sina geodata till den INSPIRE standard som direktivet anger. Alla medlemsländer, i första hand ansvariga myndigheter, skall kunna anpassa sina geodata till genomförandebestämmelser och standards i en tidsplan från 2010 till 2019.

7 Metoderna utvecklas vetenskapligt tillsammans med GIS Institutet och Högskolan i Gävle för att möta INSPIREs behov av att testa geodatatjänster systematiskt inom EU och medlemsländerna. Tjänsteportfölj Tjänsteportföljen består av fem delar, nämligen test av datakvalitet, transformationstester, prestandatester, användbarhetstester och kostnads-nytto-analys. I detta uppdrag ingår prestandatester och användbarhetstester. 2. Projektplan för testuppdraget Projektstart skedde den 31 mars, då projektgruppen formerades med deltagare från FPX test team bestående av Anders Östman, Tomas Rosendal (testledare), Lars Palm och Xin He (testare FPX) Medverkande kravställare från Metria var Johan Esko, Anna Halvarsson, Johan Lindberg och Greger Lundbäck, samtliga från Luleå. Genomförandetiden för hela testfallet har varat i sammanlagt 15 veckor från april till juni I genomförandet har sju steg hanterats; 1) identifiera testbehov och testupplägg utifrån föreslaget testkoncept med projektledningen 2) identifiera testscenarios, urval av testområde och testpanel, 3) förbereda testpanelen via intervjuer, 4) förbereda testfall, 5) säkerställa testfall i Demo, 6) testgenomförande samt 7) rapport och analys 2.1 Test strategi och testprocess Syftet med detta kapitel är att klargöra vilka tester som är planerade att genomföras, vilka resurser som behövs och vad in- och out -put är i varje steg. Strategin är att mäta graden av hur Metra Maps svarar upp mot prestandabehovet kopplat till användarens krav samt mäta hur Metra Maps tillhandahåller ett enkelt, tydligt och logiskt gränssnitt som är självinstruerande för användaren. Kontroller kommer inte att göras på data som Metria Maps använder, inga tester kommer att göras på system som är integrerade med Metria Maps. Strategin för att uppnå dessa mål är: Testfallen beskriver processer som användarna kommer att använda. Använda kunskap ifrån användare/utvecklare av Metria Maps. Användare kommer att genomföra användbarhetstester Daglig uppföljning av testarbetet. Avvikelser kommer att loggas och rapporteras till projektledningen. V-modellen beskriver hur utveckling och test av IT-system sker. Vi kommer att använda denna modell för att testa Metria Maps. Användbarhetstesterna är en del av User Acceptance test Prestanda testerna är en del av System tests

8 2.1.1 identifiera testbehov och testupplägg utifrån föreslaget testkoncept med projektledningen Lämpligt testobjekt för Metria bestämdes till en WMS/WFS tjänst, Metria Maps, som utvecklats och som snart skulle lanseras som en karttjänst i Metrias produktportfölj. Metria Maps ansågs lämpligt då tjänsten snabbt kunde sättas upp. Testbehovet var att få en värdering av Metria maps med avseende på tjänstens användbarhet hur bra är tjänsten? Vilka är styrkorna och svagheterna och hur svarar den upp mot INSPIRES krav på prestanda. Testupplägget ur GeoTest tjänsteportfölj som valdes för att nå behovet var användbarhetstest och prestandatest identifiera och välja testscenarios och testpanel för användbarhetstesterna Testscenarios valdes utifrån INSPIREs krav och det testupplägg som bestämdes. Testpanelen för användbarhetstesterna utsågs med råd från Metria. FPX/GeoTest bokade kandidaterna för en intervju och testdag förbereda testpanelen via intervjuer Testpanelen kallades till enskilda intervjuer där de erbjöds svara på frågor enligt en förutbestämd mall. Uppgifter som t.ex. testpersonens bakgrund och vana från liknande produkter samt möjliga användarfall sammanställdes och utgjorde grundmaterial för testscenarierna. Intervjuerna skedde i form av personligt möte eller per telefon. Samtalen avslutades med att testpersonen fick ge önskemål om lämplig testdag förbereda och välja testfall Prestandatester: Utifrån testscenarios och INSPIRE-krav skapades förslag på testfall. I samråd med driftansvarig bestämdes körtider för dessa testfall under testveckan.

9 Användarbarhetstester: Utifrån intervjuerna och den kunskap som har införskaffats om applikationen skapades 11 st testfall. Testfallen och frågorna skall ge svar på: Är Metria Maps lätt att använda? Var finns svårigheterna? Var finns styrkorna? Vad saknas? säkerställa testfall i pilottest Testverktygen preparerades med dom utvalda testfallen och frågorna (anv.testerna). Sedan kördes testet ett par gånger inkl. frågorna(anv. testerna). Därefter analyserades testet och svaren på frågorna(anv. testerna). Om detta inte gav svar på de krav/frågor enligt ovan så justerades testfallen/frågorna. Därefter bad vi ett par kollegor att köra användartesten för att få deras kommentarer och en analys av deras testkörning gjordes också testgenomförandet Prestandatesterna genomfördes under kvälls-/nattid enligt övernskommelsen med driftansvarig för Metria Maps. Under testet använde GeoTest en separat maskin för att registrera svarstider enligt INSPIRE begäran. En annan maskin används för att lasta systemet genom att ett antal virtuella användare utförde samma Inspire begäran. Eftersom produktionsmiljön för MetriaMaps gick ned under den sista delen av testet är testet för Get spatial Objects utförd på MetriaMaps testmiljön. För att göra testrapporten konsekvent behövs yttligare tester göras på denna funktion då på MetriaMaps produktionsmiljö. Användarbarhetstesterna kördes mot Metris Maps testmiljö, då det visade sig att den har flera funktioner än driftmiljön rapport och analys När testerna avslutades analyserades testresultatet baserade på kvalitativ analys där man möter fler aspekter än bara de beskrivande testresultaten, som oftast består av ett antal frågeenkäter eller observationer, i detta fall film- och ljudinspelningar. Analysen reflekterar över testsvaren och andra vidkommande aspekter. Analysen av resultaten från prestandatesterna har skett utifrån INSPIREs krav. Rapporten presenteras för Metria och blir vid godkännande ett dokument som bekräftar leveransen av utförda tester/uppdrag. 2.2 Målet med testerna Användbarhetstest

10 Målet är att mäta till vilken grad ett system tillhandahåller, ett enkelt, tydligt och logiskt gränssnitt som är själv instruerande för dess användare. Mäter tillfredsställelsen, bra resultat här ger positiva attityder till användningen av systemet. Användbarhetstest utvärdering syftar till att identifiera styrkor och svagheter i systemet och ger tips för att förbättra dess användbarhet. Prestandatest Målet är att mäta hur ett system svarar upp mot prestandabehov kopplade till funktionella krav. Detta kan innefatta svarstid, genomströmning/kapacitet av data etc. 2.3 Testpanelen Testpanelen valdes ut med hjälp av Metrias kundkontakter och bedömda potentiella användare av Metria Maps. Tänkt slutanvändare är en professionell användare knuten till en myndighet, kommun eller annan organisation som bedöms ha behov av en karttjänst på webben. Testpanelen bestod av 15 respondenter. Testpanel för användbarhetstester Metria Maps. Lantmäteriet Division F Falu kommun Gävle kommun, Bygg och miljö Ockelbo kommun anv av GIS-Arena Polhemsskolan, GIS lärare Gävle energi Studenter Gästrike vatten Uppsala kommun Medarbetare FPX 2.4 Krav från Metria / Metria Maps I förberedelserna för testgenomförandet har ett antal möten hållits med testteamet från GeoTest och utvecklings- och driftpersonal på Metria. I ett initialt möte har en avstämning generellt, om testläget och för att identifiera ett möjligt case skett. Mycket tid har lagts på att ge en bild av tjänstens tekniska utformning, hur den fungerar. En överföring av kunskap om tjänsten från utvecklingsteamet i Metria. Kravspecifikation för att sätta upp testprofiler mm har inte varit tillgänglig.

11 2.5 Genomförande i GeoUsability lab Under tre dagar genomfördes användbarhetstesterna, med fem deltagare varje dag. Resultaten av testerna, ljudupptagningar, filmer och redovisade lösningar på textfiler har arkiverats på server. Sammanlagt har 45 filmer med bild och ljudupptagningar producerats samt ett stort antal svar och lösningar för varje uppgift. GeoUsabiliy lab finns fysiskt på FPX i Gävle. Testbänken bestårav fem st PC med kamera och headset, två st PC för testledningens observationer och en server för att lagra resultaten av testerna. Labbets utformning och testerna baserades på att man för att identifiera bristerna i mjukvaror genomför tester med 15 personer uppdelat i tre grupper om fem personer. Dessa användare får ett antal uppgifter att utföra med hjälp av den mjukvara som skall testas och under tiden testen pågår dokumenteras det som sker. Dokumentationen består av dels en videofil som visar vad som sker på skärmen, detta synkroniseras i realtid med en videofil från en (eller flera) kamera som visar användarens ansiktsuttryck/mimik etc samt en ljudfil som består av användarens kommentarer under övningen. Användaren uppmanas att prata med sig själv under övningen för att få en hörbar koppling till vad som sker på skärmen. Fler kameror går att använda om man vill se testen ur fler vinklar eller liknande. Under testen kan testledare i realtid göra anteckningar i mjukvaran som loggas på rätt plats i den sammanslagna presentationen av video/ljud-filer och man kan enkelt få ut test resultat i powerpoint format för snabb feedback eller djupare analyser. Labbet går även att använda för tester av hårdvara och andra typer av produkter då man istället för att ta en videofil av skärmarbetet använder fler kameror eller annan upptagningsutrustning (pulsmätare etc) för att övervaka användaren under testet 2.6 Rapportering Testresultatet planeras att rapporteras i informationsblad, i nyhetsblad och webbsidor. 3. Användbarhetstester 3.1 Metod Testpanelen, de potentiella användarna, delades in i tre grupper med vardera fem testpersoner. Valet av antal respondenter och testgrupper baseras på (Nielsen, 2000) som säger att test med 5 personer kan identifiera 85% av användbarhetsproblemen medan 15 testpersoner kommer att identifiera nära 100% av alla problem Användbarhetstestet är baserat på empirisk metod där användare observeras medan de utför uppgifter för olika testscenarios. Syftet med användbarhetstestet är att kunna bestämma hur bra och hur snabbt en ny användare kan lära sig Metria Maps gränssnitt för webtjänsten. Bland annat testades hur lång tid som användes för att lösa en uppgift, antal fel, operationella mönster och som en helhet kan dessa aspekter ge en översiktlig uppfattning om användbarheten i Metria Maps. Användbarhetstesterna ger information om hur Metria Maps fungerar för varje användare och vilka problem som hon eller han stöter på. Testpanelen bestod av deltagare med olika bakgrund och utbildning, två studenter på gymnasienivå med GISinriktning, sex professionella GIS användare, sju mer eller mindre vana IT eller GIS användare. 3.2 Scenarioutveckling och design

12 Tänkta användare finns i kommuner och myndigheter. Ett antal potentiella användare inom dessa sektorer valdes för att sedan intervjuas med syfte att 1) förberedas för kommande användbarhetstester, 2) för att få veta dessa användares förväntningar och krav på Metria Maps, 3) ta reda på vilken roll de har i respektive organisation och 4) be dem beskriva sin roll och uppgift, som sedan nyttjades i scenario design och analys 5) önskemål om användarfall Testscenariona skapades med åtanke på att kunna ge svar på: Är Metria Maps lätt att använda? Var finns svårigheterna? Var finns styrkorna? Vad saknas? Övningsarna stregrades i svårighets/komplexitets grad där övning 1 gick ut på att leta rätt på och använda alla knappar/funktioner som finns i Metria Maps. Under övning 2 och 3 användes dessa funktioner i olika kombinatiner. 3.3 Uppgifter Deltagarna ombads att gå igenom tre testfall där varje fall har ett antal uppgifter som skulle genomföras. Efter varje uppgift fick deltagaren besvara ett antal frågor om uppgiften. Frågorna besvaras genom värdemätare inom ett intervall, t ex från 1 5. Testschema Fig 3.3 ovan visar schematiskt angreppssätt för att genomföra de tre scenarioövningarna med hjälp av uppgifter och frågor. 3.4 Resultat

13 Resultaten från användbarhetstesterna finns redovisade i särskild bilaga tillsammans med respektive testscenario och ingående uppgifter. (se Bilaga Metria_användbarhetstest_v1.0) 3.5 Analys av testresultaten Analysen för användbarhet baseras på teorin för kvalitativ analys där man möter fler aspekter än bara de beskrivande testresultaten, som oftast består av ett antal frågeenkäter eller observationer, i detta fall film- och ljudinspelningar. Det betyder att den som genomför analysen reflekterar över svaren och andra vidkommande aspekter. Är Metria Maps lätt att använda? Ja, Metria Maps är ett system som är lätt att använda och komma igång med. Det är lätt att hitta och förstå knapparna och dess funktioner. Var finns svårigheterna? Att hantera och hitta information om lagren, att veta när systemet arbetar upplevde testarna som trögt. (detta kan bero på att vi testade mot Metria Maps testmiljö) Sökfunktionen upplevdes som opålitlig och ologisk. Var finns styrkorna? Gränsnittet upplevdes som användarvänligt och lättillgängligt, knapparna beskrivs på ett bra och enkelt sätt, kartografin är bra och funktionen att lägga till egna WMS lager uppskattas. Systemet är lätt att lära sig. Vad saknas? Attributtabell Fritextsökning, möjlighet att kunna rensa sökkriterina samt rent generellt, en bättre sökfunktion 3.6 Rekommendation - användbarhet Det visade sig när testpanelen för användartester, som var sammansatt av testare med olika bakgrund och olika kompetens visar upp stor skillnad i förmågan att genomföra testerna. En tydligare kravbild för vem Metria Maps och dess tjänster skall utformas för är på sin plats. Av de testscenarios och uppgifter som genomfördes under de tre testdagarna kan man säga att Metria Maps har förmåga att ge service till dom flesta i kommuner och myndigheter. En introduktion/kortare utbildning av tjänsten kan dock vara på sin plats. Sammanfattningen nedan kan ge en viss uppfattning om vilka områden som behöver förbättras. För varje uppgift som testpanelen har genomfört har de också fått möjlighet att skriva ner omdömen om svårighetsgraden i uppgiften. Testpanelens kommentarer i anslutning till genomförda uppgifter (Bilaga Anvtest) kan vara ingångsvärden till förbättringsbehovet i nästa version. Användbarhetstester. Layout och grafisk utformning Navigering - struktur Terminologi Resultat Bra layout och design. Enkelt att navigera, alla navigeringsverktyg användes dock inte av testgruppen. ( hittade dom inte) Tillfredsställande, fyller sitt syfte

14 Feed back och hjälp från systemet Funktionalitet Hjälpknappen ok, dock ingen feedback ifrån systemet t.ex. vid resultatet inga sökträffar vid sökning med fel detaljtyp. Lätt att hitta och använda knapparna och dess funktioner. Dock hade 50-60% av testarna svårt att hitta till Lägg till lager (WMS lager) Sökfunktionen är svår och ibland obegriplig att använda. Svårt att hitta information om lager m.m. Felhantering Generell uppfattning om systemet i stort Ingen alls Metria Maps är ett modernt och lättanvänt system, dock har sökfunktionen en del att önska. Presentation av fastighetsinformation kan bli mera användarvänlig. Tabell 3.6 Testade områden 4 Prestanda tester 4.1 Introduction The purpose of this study is to find out the system limit of MetriaMap, and; if MetriaMaps meets the INSPIRE requirements for the web service performance.

15 Table 4.1. INSPIRE requirements for the web service performance. 4.2 Methods and materials Basically, GeoTest measures the response time of a specific request under different conditions. All requests specified by INSPIRE are concerned. Different conditions are also simulated by GeoTest to assess the capacity of a web service. For an example, GeoTest tries to answer the question like how long it will take for a view service to respond to a GetMap request for a 800x600, 8bit, TIFF format map image under a condition that the server is facing another 19 same requests at the same second. INSPIRE states that the web service performance shall be measured at the server side. The influence of the network connection and traffic, if possible, should therefore be excluded. At this stage of GeoTest, the performance test for MetriaMaps is carried out at the client side. In order to eliminate the influence of the network, additional measurement have to be carried out at the server side. To reduce the influence of the network bandwidth, GeoTest establishes a testing system consisting of two machines which are separately connected to the internet. One machine focuses on loading a number of requests, while another machine records the response time of a specific request under that simulated circumstance. Table X shows the specifications.

16 Table Specifications for the GeoTest testing system Following table shows the test cases and the HTTP requests that are used during this test.

17 Table HTTP requests and parameters used for testing MetriaMaps

18 4.3 Results and analyses System limit test Table System limit test for the view service of MetriaMaps Figure Rate of Error and the number of successful sessions

19 During the test, a number of virtual user are loaded at the same time. For a virtual user, it sends a prespecified request to the server. When the virtual user gets the response from the server, it finishes a session. The virtual user continuously repeat this process during the testing period. The recording machine records the total number of session performed as well as the number of session with errors. As the number of simultaneous users increases, the probability for service errors increases. Examples of service errors are Timeout error, Socket error and HTTP error. The system limit test aims at finding a breakpoint where the error frequency drastically increases. As seen in figure X, this breakpoint occurs at somewhere between 31 and 51 simultaneous users. In addition, the number of successful sessions maintains at about 1000 when the number of simultaneous users is between 6 and 51. This number dramatically decreases when the number of simultaneous users goes up beyond 51. It also suggests the system has a breakpoint around 51 simultaneous users Test against INSPIRE requirements Table Test results for view service against INSPIRE requirements

20 Figure Average response times against the number of simultaneous users During the test, GeoTest uses a separate machine for recording the response time of a INSPIRE request under a specific condition. Another machine is used to simulate the specific condition through loading a number of virtual users executing the same INSPIRE request. Table X and figure x show the results collected at the recording machine. INSPIRE requires the maximum time for responding a 470KByte map image is 5 seconds under the normal situation or 90% of the time. MetriaMaps meets this performance requirement when there is only one user. However, it is not qualified when the number of simultaneous users are more than 5. The frequency of the response which is shorter than 5 seconds goes down to or below 75%. Furthermore, when the number of simultaneous user reaches 20, the average response time goes up to about 11 seconds, and only about 49% requests are replied within 5 seconds. It therefore fails to meet the INSPIRE capacity requirement.

21 Table Test results for download service against INSPIRE requirements Similar tests are also carried out for the download service. Different requests are employed to test MetriaMaps against the INSPIRE requirements for the download service. Table X shows the results. As seen in table X, MetriaMaps meets the INSPIRE performance requirements for the operations Get Download Service Metadata and Get Spatial Objects. These two operations are handled very well by MetriaMaps. Both of them are qualified even the number of the simultaneous users goes up to 51. On the other hand, the operation Describe Spatial Object Types fails to meet the INSPIRE requirements. It meets the INSPIRE performance requirement when there is only one user. But when there are 10 simultaneous users only 50% of the users can expect their requests can be replied in seconds (10s initial response + 162/500s processing time). It therefore fails to meet the INSPIRE requirements for capacity. 4.4 Discussions Several things need to be noticed for this performance test. Firstly, INSPIRE states that the performance test shall be carried out at the server side. The reason for this might be the consideration of excluding the influence of network connection and traffic. However, so far the test is carried out at the client side. To eliminate the influence of the network, additional measurements have to be conducted at the server side.

22 Secondly, at this time GeoTest does not use any dummy random variables in forming the virtual user requests. It means that all the requests sent out by the virtual users are same for each of the testing conditions. It perhaps relates to the issue of server caching that MetriaMaps needs not go through all the processes for generating the requested result for all the virtual users. As a result, the measured response times may be smaller than they should be. To fully avoid this potential problem, another test have to be carried out with the randomly generated requests. Thirdly, since the public site of MetriaMaps broke down during the final part of this test, the test for the GetFeature function of the download service is actually done at the test environment of MetriaMaps. To make a consistency report, further test on this function should be conducted at the MetriaMaps public site.

23 4.5 Test Summary System limit test Table Results of system limit test for the view service of MetriaMaps Test against against INSPIRE performance requirements Services INSPIRE Requirements MetriaMaps Performance WMS GetMap For a 470Kb image, should be of maximum 5 second in normal situation, with a frequency of request of 20 requests per second. 11.2s, when there are 20 concurrent requests. Get WFS Download Service Metadata 10 seconds in normal situations, with a frequency of request of 10 requests per second. 0.2s, when there are 10 concurrent requests. Get 30 second initial response, then the service shall maintain a sustained response > 0.5 MB/s, alternatively 500 spatial objects/s in normal 0.4s, when there are 10 concurrent requests for a data set containing 1,000

24 Spatial Objects Describe Spatial Objects Types situations, with a frequency of request of 10 requests per second. 10 second initial response, then the service shall maintain a sustained response > 0.5 MB/s, alternatively 500 spatial objects types per second in normal situations, with a frequency of request of 10 requests per second. spatial objects. 43.0s, when there are 10 concurrent requests for a description file containing 162 spatial object types. Table Summary of test results against INSPIRE performance requirements Appendix Bilaga Metria_användbarhet_v1.1