Databas

Rapportverktyget använder Microsoft SQL 2019 som databas och under utveck-lingen har databasen skapats i en lokal utvecklingsmiljö för att lättare kunna uppdateras och utvärderas. Tack vare att det inte finns någon skarp information ännu i databasen har den kunnat tömmas ett antal gånger under utvecklingen för att testa så att inläsning, uppdatering och radering fungerar som tänkt. När det sedan är dags för publicering kommer detta ske till en server i Hitachi ABB Power Grids nätverk där en installation gjorts av Microsoft SQL 2019.

För att få igång kopplingen till SQL har en dependency injection lagts till i star-tup.cs filen, anslutningsinformation har lagts till i appsettings.json och en con-text-fil skapats. Dependency injection används för att applikationen ska förstå vilka tillägg den ska starta och hur det ska gå till. Här definieras vilket context som ska användas, vilken typ av server samt anslutningsinformation (se figur 21).

DbString motsvarar anslutningsinformationen i appsettings.json och Percep-tionContext innehåller information om vilka modeller som hanterar vilka tabel-ler. PerceptionContext ärver från DbContext där de olika klasserna och meto-derna för Entity Framework finns.

Code first

För att skapa databasen används tekniken code first och Entity Framework Core. När modellerna redan är skapade och de innehåller information om rela-tioner mellan tabellerna så kan Entity Framework översätta detta till SQL och skapa samtliga tabeller automatiskt med hjälp av context-filen. Migreringen är väldigt enkel att göra genom att första skriva kommandot Add-Migration, i kon-solen, följt av en beskrivande text vad som ingår i migreringen. Då skapas mi-grerings-filerna som sedan används för att utföra ändringarna i databasen. När databasen ska uppdateras skriver man Update-Database i konsolen varpå uppda-teringen utförs. En bra funktion med migreringen är att filerna som används sparas i en katalog vilket gör att det går att se vilka ändringar som gjorts och det går att ångra migreringar om det inte blivit rätt.

När rapportverktygets första migrering genomfördes var inte strukturen i data-basen helt klar ännu och därför skapades inte tabellen TestType. När strukturen sedan ändrades var det lätt att åtgärda genom att lägga till modellen och infor-mation i context-filen och sedan migrera samt uppdatera. Det har sedan tillkom-mit mindre ändringar men tack vare Entity Framework behövs inga inställning-ar göras direkt i databasen utan allt sköts via applikationen.

4.4 Tester

Återskapa projekt

För att kunna återskapa ett tidigare projekt var det första steget att generera ex-porter ifrån Perception. När Hitachi ABB Power Grids genomför sina tester ska-par de en mall som bland annat håller reda på vad som ska exporteras från Per-ception. Eftersom vissa tillägg har gjorts i rapportmallarna i samband med ut-vecklingen av rapportverktyget behövde mallen uppdateras med dessa. När det var genomfört kunde exporterna skapas med rätt parametrar och filerna sedan importeras till rapportverktyget. För att återskapa projektet exporterades 24 filer och dessa lästes sedan in samtidigt med lyckat resultat.

Det tidigare projektets samtliga testresultat återskapades sedan genom att först ställa in de projektspecifika värdena för testtider (Project settings) och sedan genom att välja respektive rapportmall → Recording → Sweep. Värdena dub-belkollades dessutom direkt mot det beräknade resultatet i Perception.

Figur 21: Dependency injection som aktiverar funktion för Microsoft SQL-server services.AddDbContext<PerceptionContext>(options =>

options.UseSqlServer(Configuration.GetConnectionString("DbString")));

Validering av kod

Eftersom rapportverktyget inte finns publikt tillgängligt har HTML-kod valide-rats genom att starta applikationen i den lokala utvecklingsmiljön och sedan har den kod som genereras vid utskrift till skärmen testats i W3C:s HTML-valide-ringsverktyg.

CSS-koden har testats genom att kopiera den transpilerade SCSS-koden och di-rektinmatat i W3C:s CSS-valideringsverktyg.

Responsivitet

I Google Chromes utvecklingsverktyg aktiverades funktionen för att testa webbplatsen på olika enheter och olika upplösningar. Rapportverktyget funge-rar ganska bra i grunden ner till en bredd motsvarande 768 pixlar men viss an-passning var lämplig. På desktop har sidorna Project Settings och Create report drop down-listor, för val av projekt samt rapportmall, till vänster och resten av innehållet till höger. På surfplatta har dispositionen gjorts om så att drop down-listorna läggs ovanför resten av innehållet. Detta ger mer plats åt tabellerna som är de mest platskrävande. Motsvarande tester genomfördes i Mozilla Firefox och Microsoft Edge.

Tillgänglighet

Test för att kontrollera tillgänglighet har genomförts med hjälp av Lighthouse som generar en rapport för valda test-delar. För detta test har valen Performan-ce, Accessibility och Best Practice valts. Det finns också möjlighet att testa sök-motoroptimering men eftersom applikationen inte kommer vara publikt till-gänglig anses det inte nödvändigt. Eftersom det rör sig om en applikation som i första hand är avsedd för desktop har Lighthouse testat för detta. Lighthouse har en koppling till Google Chrome developer och rapporterna genereras genom att använda Lighthouse via den vägen. Tester har genomförts på sidorna Import logfile, Project settings samt Create report.

Test av olika webbläsare

För att testa rapportverktyget i olika webbläsare har applikationen startas i den lokala utvecklingsmiljön vilket i sin tur öppnar standardwebbläsaren. I detta fall är standardwebbläsaren Google Chrome vilket används hela tiden under utveck-lingen. Länken till den lokala servern har sedan använts i de andra webbläsarna för att öppna och utvärdera rapportverktyget.