Linköpings Universitet | Institutionen för datavetenskap Kandidatarbete, 16 hp| Datateknik Vårterminen 2020 | LIU-IDA/LITH-EX-G-20/029-SE
Automatiserad symboltestning i det
grafiska gränssnittet på Gripen NG
Automated testing of symbols in the graphical interface in
Gripen NG.
Martin Forsberg
Linnea Lindroth
Examinator: Ola Leifler Handledare: George Osipov
Linköpings universitet SE-581 83 Linköping 013-28 10 00, www.liu.se
Sammanfattning
Saab är i slutfasen av utvecklingen av Gripen Next Generation och söker därför en metod för att autonomt kunna regressionstesta symboler i det grafiska gränssnittet i cockpit. Detta examensarbete fokuserar på att utvärdera befintliga metoder av automatiserad GUI-baserad testning för att automatiskt kunna jämföra det grafiska gränssnittet på en skärm och implementera den mest lämpade metod för att ta fram ett bevis av koncept. Målet med implementationen är att kunna visa att metoden kan hitta de problem som kan uppstå vid mjukvaruuppdateringar och försäkra att ingen uppdatering av mjukvara påverkar symbolerna i det grafiska gränssnittet på ett negativt sätt. Implementationen är en metod av Visuell GUI Testning vilket är den tredje generationen av automatiserad GUI-baserad testning och har gjorts i C++ med OpenCV bibliotek för bildhantering och bildjämförelse. Det testmaterial som använts är i form av bilder och en video som insamlats med en intern funktion för skärminspelning i det grafiska gränssnittet. Slutsatsen av resultatet från testerna som genomförts visar att det är möjligt att verifiera statiska symboler i det grafiska gränssnittet men att verifiering av dynamiska symboler kräver vidare arbete då förutsättningarna för identiska tester inte är möjligt i dagsläget.
Abstract
Saab is in the final phase of development of the new Gripen Next Generation and is therefore looking for a method to autonomously test the graphical interface in the cockpit for visual regressions. This thesis evaluates existing methods of automated GUI-based testing to automatically compare the graphical interface on a screen and implement the most suitable method to produce a proof of concept. The goal of the implementation is to show that the method can solve the problems that can arise in software updates and ensure that no software updates adversely affect the symbols in the graphical interface. The implementation is a method of Visual GUI Testing which is the third generation of the automated GUI-based testing and has been made in C++ with OpenCV-library for image recognition and comparison. The test material that has been used is images and videos collected with an internal screen recording function in the graphical interface. The results indicate that it is possible to verify static symbols in the graphical interface, yet that verification of dynamic symbols require further work as the conditions for identical test are not possible in the current situation.
Förord
Vi vill rikta ett stort tack till alla som bidragit med hjälp under detta arbete. Speciellt tack till Saab AB och HMI-avdelningen i Tannerfors som försett oss med utrustning och arbetsplatser, vår ansvariga chef Jonas Norberg samt våra handledare Martina Granath och Elinor Särner.
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
Innehållsförteckning Figurlista... vii Tabellista ... vii 1. Inledning ... 1 1.1 Bakgrund ... 1 1.2 Syfte ... 2 1.3 Frågeställning ... 2 2. Teori ... 3 2.1 Regressionstestning ... 3
2.2 Automatiserad GUI-baserad testning ... 3
2.2.1 Generation tre av automatiserad GUI-baserad testning ... 5
2.2.2 Rendera egna data för jämförelse ... 6
2.3 Validering och Verifikation ... 6
2.4 Relaterat arbete ... 6
3. Metod ... 8
3.1 Förstudie ... 8
3.1.1 Val av metod för testning ... 9
3.2 Testning av metod för visuella avvikelser i det grafiska gränssnittet...10
3.2.1 Testbeskrivning och material ...10
...11
3.2.2 Testfall och testprogram ...11
4. Resultat ...14
4.1 Test ett: Inga förändringar ...14
4.2 Test två: Symboler som saknas ...15
...16
4.3 Test tre: Symboler som flyttats ...16
4.4 Test fyra: Symboler som modifierats ...17
4.5 Test fem: Olika färgkombinationer ...18
4.6 Test av dynamisk symbol, fartmätare ...18
5. Diskussion ...20 5.1 Metoden ...20 5.2 Resultat ...20 5.2.1 Precision ...20 5.2.2 Problem...21 5.3 Vidareutveckling ...22
5.4 Arbetet i ett vidare sammanhang ...22 6. Slutsats ...24 7. Referenser ...25
Figurlista
FIGUR 1.GRIPEN NG COCKPIT MED WIDE AREA DISPLAYEN. ... 1 FIGUR 2.TESTBILDEN SOM FÖRESTÄLLER EN PRIMÄR FLYGDISPLAY MED OLIKA STATISKA OCH DYNAMISKA SYMBOLER I VARIERANDE
FÄRGER...11 FIGUR 3.RESULTATET FRÅN TEST ETT SOM BLIR ETT IHOPSATT KOLLAGE AV TESTBILDER MED TEXTEN ”SUCCEEDED!” VILKET BETYDER
ATT INGA SKILLNADER FANNS MELLAN REFERENSBILD OCH TESTBILD. ...14 FIGUR 4.RESULTATET FRÅN TEST TVÅ SOM BLIR ETT IHOPSATT KOLLAGE MED ORIGINALBILD, MODIFIERAD BILD, DIFFERENS MELLAN
BILDER OCH MARKERADE RÖDA REKTANGLAR DÄR DIFFERENSER VAR PÅ DEN MODIFIERADEBILDEN. ...15 FIGUR 5.FÖRSTORING AV RESULTATET FRÅN TEST TVÅ DÄR RÖDA REKTANGLAR MARKERAR SKILLNADEN MELLAN TESTBILD OCH
REFERENSBILD. ...16
FIGUR 6.FÖRSTORING AV RESULTATET FRÅN RESULTATKOLLAGET PÅ TEST TRE DÄR STORA OCH SMÅ SYMBOLER FLYTTATS I OLIKA RIKTNINGAR. ...16 FIGUR 7.FÖRSTORING AV DEN RESULTATET FRÅN RESULTATKOLLAGET PÅ TEST FYRA DÄR STORA OCH SMÅ MODIFIKATIONER GJORTS PÅ SYMBOLER. ...17 FIGUR 8.FÖRSTORING RESULTATET FRÅN RESULTATKOLLAGET PÅ TEST FEM DÄR FÄRGKOMBINATIONER PÅ OLIKA BAKGRUNDSFÄRGER
TESTAS. ...18 FIGUR 9.BILDRUTA NR 92 FRÅN SEKVENSEN SOM HADE 8 AVVIKELSEKONTURER.DEN SVARA RUTAN ÄR DEN ABSOLUTA DIFFERENSEN
MELLAN DE BILDRUTOR SOM TESTAS. ...19
FIGUR 10.BILDRUTA NR 147 FRÅN SEKVENSEN SOM HADE 26 AVVIKELSEKONTURER.DEN SVARA RUTAN ÄR DEN ABSOLUTA DIFFERENSEN MELLAN DE BILDRUTOR SOM TESTAS VILKET ÄR EN MOTSÄGELSE DÅ SKILLNADER FINNS MEN INTE I DIFFERENSEN. ...19
Tabellista
TABELL 1.ALÉGROTH OCH FELDTS 14 RIKTLINJER FÖR INDUSTRIELL ANVÄNDNING AV VGT. ... 4 TABELL 2.FÖR- OCH NACKDELAR MED METODERNA VISUELL GUITESTNING OCH RENDERINGSDATA MED OPENGL. ... 8 TABELL 3.FÖR- OCH NACKDELAR MED OLIKA METODER FÖR INSAMLING AV MATERIALL TILL VGT. ... 8
1. Inledning
Saab Aeronautics har sedan 80-talet byggt och utvecklat stridsflygplanet Gripen i olika versioner och är nu i slutfasen för Gripen Next Generation. Den stora tekniska utvecklingen som skett de senaste tio åren medför att Saab måste uppdatera sina system kontinuerligt för att ligga i framkant gentemot företagets konkurrenter. Med ny teknik i cockpit som möjliggör pekskärmar med applikationer blir arbetet lättare för piloterna i luften medan processen att validera och verifiera funktionerna blir svårare för de ingenjörer som underhåller och uppdaterar systemen. Målet med detta arbete är att bestämma och utveckla en metod för att hjälpa ingenjörer till ett snabbare och enklare automatiserat arbete för att testa integriteten hos gränssnittet efter uppdatering.
1.1 Bakgrund
Saabs underavdelning Aeronautics har under sista halvåret av 2019 börjat leverera testflygplan av modell Gripen Next Generation till dess kunder, flygvapnet i både Sverige och Brasilien. Utvecklingsfasen av flygplanet håller på att övergå från utveckling, till service och underhåll. Saab efterfrågar nu en metod för att autonomt regressionstesta symboler i flygplanets cockpit för snabbare och enklare tester. Metoden som används för att kontrollera grafiska gränssnitt och symboler i tidigare generation av Gripen är att mäta för hand och kontrollera avstånd på skärmarna med en linjal för att upptäcka eventuella avvikelser.
Frågan om hur man ska regressionstesta visuella gränssnitt har tagits upp på olika sätt av flera olika forskare och företag inom teknikbranschen. Att verifiera att symboler i det visuella gränssnittet är oförändrat mellan systemuppdateringarna är av stor vikt, då förändringar med exempelvis symbolerna för höjd och fart möjligen kan sluta med en krasch och att människor skadas. Detta gör att utvecklarna som arbetar med att ta fram metoderna har stort ansvar att allt blir korrekt, samt att det överensstämmer med specifikationerna de blivit tilldelade för att garantera ett fungerande och säkert system i alla situationer. I det grafiska gränssnittet som ska testas finns både statiska och dynamiska symboler. Statiska symboler ska i regel alltid visas och aldrig ändras, exempelvis en textsymbol för en knapps innebörd som är placerad i displayramen, medan dynamiska symboler ändras för att exempelvis visa en rörlig fartmätare. Projektet kommer i första hand fokusera på en metod för regressionstestning av statiska symboler som sedan kan vidareutvecklas i ett andra steg till att testa dynamiska symboler. Detta arbete kommer genomföras på Saab, avdelningen Aeronautics som har huvudansvaret över de luftburna systemen och därmed ansvarar för Gripenprojektet. Gripen NG (Next Generation) är den fjärde generation i serien
Gripen multifunktionsplan som utvecklats av Saab. Stridsflygplanet marknadsförs med namnet “Smart Fighter”. Gripen NG finns i två modeller, E som är ensitsig samt F som är tvåsitsig. Svenska flygvapnet var första kund att beställa flygplanet och betecknar det med JAS (jakt, attack, spaning) 39E/F Gripen. Gripen NG har en ny uppdaterad cockpit jämfört med C/D där avionik och digitalisering haft stor betydelse. Den största skillnaden i cockpit mellan generationerna är att de tre skärmana i C/D byts ut mot en stor pekskärm på 19x8 tum med applikationer för navigation, radar och flygdata kallad ”Wide
Area Display” [8].
1.2 Syfte
Syftet att göra detta arbete är för att utvärdera befintliga metoder av automatiserad GUI-baserad testning, som är en samling av metoder för att automatiskt jämföra det grafiska gränssnittet på en skärm och identifiera felaktiga avvikelser mellan systemuppdateringar. Utifrån utvärderingen ska en metod anpassas för att påbörja utvecklingen av denna. Metoden ska hitta de problem som uppstår vid mjukvaruuppdateringar när systemet måste kontrolleras noggrant för att försäkra att ingen uppdatering påverkar en del på ett negativt sätt. Det är en process som är tidskrävande och lägger stor vikt och förtroende på de personer som utför mätningarna manuellt med linjal. Detta medför en säkerhetsrisk då den mänskliga faktorn inte är något som går att undvika. Den nya applikationsbaserade skärmen i Gripen E/F är flexibel och har fler funktioner än de tidigare modellerna. Detta medför att fler funktioner måste testats vilket gör processen mer ansträngd på Gripen E/F än på de tidigare modellerna Gripen C/D. En automatisk process kommer underlätta arbetet att hitta små och stora visuella avvikelser på skärmen, vilket skulle göra stor skillnad för utveckling och underhåll av Gripen E/F som planeras vara i bruk fram till minst år 2045.1
1.3 Frågeställning
Rapporten strävar efter att svara frågan nedan:
Är det möjligt att använda automatiserad GUI-baserad testning för att verifiera visuella avvikelser i det grafiska gränssnittet på Gripen Next Generation?
1https://saabgroup.com/media/news-press/news/2018-04/saab-presents-gripen-e-simulator-with-wide-area-display/
2. Teori
Under detta kapitel kommer somliga begrepp beskrivas, bland annat varför man regressionstestar, allmänt om bildtestning och Validering och Verifiering. Utöver detta presenteras relaterade arbeten med exempel på olika tillvägagångssätt.
2.1 Regressionstestning
Regressionstestning är en mjukvarutestningsmetod som innebär att man testar antingen hela eller delar av redan befintlig kod i ett system efter en ny funktion implementerats. Detta vill en organisation göra för att se om problem uppstått i och med en ny uppdatering, även kallat regressioner. Testar man uppdateringarna kontinuerligt är det lättare att felsöka för att upptäcka de nya buggarna och snabbt kunna åtgärda dessa, vilket sparar organisationen både tid och pengar. Överlag är regressionstestning något som är kostsamt att genomföra och kräver både tid och budget vilket gör att organisationer strävar till att processen ska genomföras snabbt och effektivt. Regressionstestning kan göras både i koden för att hitta förändringar, men även visuellt för att hitta synliga förändringar i det grafiska gränssnittet.
2.2 Automatiserad GUI-baserad testning
Det finns olika metoder och tillvägagångssätt att använda vid GUI testning, vilken metod som lämpar sig bäst beror på vilken data som finns tillgänglig och vad målet är. Automatiserad GUI-baserad testning är ett samlingsnamn för alla metoder som används för GUI testning, och är en automatiserad flexibel testteknik som är GUI-baserad. Testtekniken har utvecklats i tre avgränsade generationer som definieras av vilka metoder som används för att testa systemet. Första generationen bygger på exakta koordinater på skärmen vilket innebär att ett knapptryck kan spelas in för att sedan återanvändas i testning där identiska knapptryckningar på exakta koordinater behöver ske. Exempelvis genomfördes detta för att autonomt testa en symbols funktionalitet genom ett inspelat knapptryck på positionen där symbolen borde vara. Generationen testades i slutet på 80-talet men visade sig inte vara robust nog för användning i industrin då arbetet med att uppdatera referensbibliotek var för stort och avancerat då förändringar i det grafiska gränssnittet skedde ofta. Detta ledde till utveckling av den andra generationen som bygger på systemets användning av GUI-bibliotek vilket använder källkoden som referens för att hitta rätt testobjekt. Generationen kan använda exempelvis ett index för symboler källkoden där testfall för varje index kan skapas. Skillnaden mellan första och andra generationen blev att testningen inte förlitar sig på det visuella i det grafiska gränssnittet utan källkoden vilket minskade arbetet med referensbibliotek från generation ett. Generationen är väl implementerad i industrin idag där funktionalitet i det grafiska gränssnittet behöver testas. Med ett samhälle som allt mer förlitar sig på displayer av olika slag visade sig begränsningen med att använda källkoden och inte det faktiska visuella i testningen ledde till den tredje generationen av automatiserad GUI-baserad testning. Den tredje generationen bygger på bildigenkänning och kallas Visuell GUI testning (VGT) och använder skärmens renderade bild för testning vilket är likt generation ett som använde symbolers exakta positioner för testning av funktionalitet. Skillnaderna mellan generation ett och tre är att utvecklingen av avancerade algoritmer möjliggjort en mer flexibel testning som både kan användas med exakta positioner, eller med djupa inlärningsalgoritmer som identifierar symbolen autonomt. Det går att se VGT som en vidare utveckling av generation ett då principen att använda det grafiska gränssnittet är detsamma, men att de tekniska skillnaderna och möjligheterna är stora. [3] På senare tid har VGT börjat användas i fåtal industrier för testning av visuella system. Emil Alégroth och Robert Feldt [2] skrev 2017 om VGT för industrin med fokus på den långvariga effekten av testningen som visar att metoden är applicerbar på stora delar av branschen men att kunskapen om resultatet av en långsiktig användning av metoden är låg, då det är för få företag som implementerat metoden. Författarna har satt upp riktlinjer som ska ge organisationer beslutsstöd om
en implementation av VGT är rätt metod för problemet och undvika de fallgropar som finns med VGT (se tabell 1 nedan).
Tabell 1. Alégroth och Feldts 14 riktlinjer för industriell användning av VGT.
Fas # Riktlinjer Beskrivning
Implementation 1 Hantera förväntningarna
Det är inte lämpligt / möjligt att automatisera allt med VGT, fundera över vad som är automatiserat och varför?
2 Stegvis antagande En iscensatt adoptionsprocess som stegvis utvärderar värdet på VGT om det är lämpligt, för att minimera kostnaden om tekniken inte är lämplig.
3 Dedikerad grupp Dedikerade grupp ger inte upp enkelt och identifierar hur / när man ska använda VGT.
4 Bra ingenjörskap VGT-kostnader beror på arkitekturen för tester / testsviter och bästa tekniska metoder bör därför användas t.ex. modularisering.
5 Programvara Olika mjukvarulösningar t.ex. VGT-verktyg och programvara från tredje part bör utvärderas för att hitta den bästa lösningen för företagets behov.
Användning 6 Roller VGT kräver utbildning av nya roller, vilket är förknippat med extra kostnad.
7 Utvecklings process
VGT bör integreras i utvecklingsprocessen, t.ex. definition av gjort och SUT: s byggprocess, dvs. automatisk exekvering.
8 Organisation Organisationsförändringar stör utvecklingen tills nya sätt att arbeta löser sig.
9 Kodkonventioner Kodkonventioner förbättrar skriptläsbarheten och underhållbarheten.
10 Extern testning För distribuerade system bör VGT-skript köras lokalt eller använda VGT-verktyg med inbyggt stöd för extern testutförande.
Långsiktigt 11 Frekvent underhåll
Testprocessen måste förhindra försämring av testfall för att hålla kostnaden för underhåll av VGT möjlig på lång sikt.
12 Anpassa Kostnaderna och värdet av VGT bör mätas för att identifiera förbättringsmöjligheter, t.ex. nya sätt att skriva skripts.
13 Versionskontroll När antalet SUT-varianter växer, så gör testsviterna och de bör därför versionskontrolleras för att säkerställa
SUT-kombinationen.
14 Livscykel Positiv avkastning på investeringar vid antagande av VGT sker efter minst en iteration, så hur länge kommer SUT att leva?
Musikbolaget Spotify är ett företag som påbörjat en implementation av VGT, men senare avbrutit för en annan metod. I deras testning användes verktyget Sikuli som gav ett robust resultat i nästan alla tester, underhållet av scripts på stationära applikationer var lågt men de nackdelar som uppstod vägde över då underhållet av bilder var för stort, begränsad funktionalitet för mobila applikationer samt problem med dynamiska data. Från Alégroths och Feldts intervjuer med anställda på Spotify framkom anledningen att underhållet av bilder var stort för företaget eftersom systemen som testades bestod av olika typer av skärmar (laptops, tv, smartphone, etc.). Spotify valde efter den misslyckade implementationen av VGT, att använda en metod från generation två av automatiserad GUI testning som använder sig av krokar i källkoden. Kroken ger utvecklaren information om systemet så denna kan skriva ett testprogram för att testa detta. Metoden kallas “Test Interface” och uppfyller Spotifys krav för testning, men att metoden har stora nackdelar. “Test interface” bygger på individuella testprogram för det som ska testas, vilket kan bli ett problem då det snabbt blir en stor mängd program att administrera. Metoden testar även bara källkoden vilket betyder att den inte testar
renderingen på skärmen vilket gör att skärmen kan visa helt fel utan att fångas upp av testprogrammen [2].
2.2.1 Generation tre av automatiserad GUI-baserad testning
I detta projekt avser all benämning av VGT till generation tre av automatiserad GUI-baserad testning som bygger på bildigenkänning. Metoden jämför bild för bild, mer specifikt pixlarna i bilderna med varandra. Metoden är avancerad och tar mycket tid då programmen måste rendera bilderna på exakt samma sätt och avrundningsdecimalen, pixeldensitet och “anti-aliasing” måste betänkas. Även detaljer som att bestämma vilka pixlar som är viktigare än andra för att få korrekt analys försvårar arbetet med VGT. I Emil Alégroths doktorsavhandling vid Chalmers Universitet skriver han om negativa aspekterna med VGT där “Betydande kostnader i samband med underhåll av bilder” är en viktig punkt att tänka på vid val av datasamlingsmetod [1]. Anledningen till detta är att det är enklare att få ett mer korrekt resultat av jämförelsen om bilderna som jämförs har samma storlek och pixeltäthet. I det fall där bildhantering inte behövs, då data kommer från samma display och har samma mått, minskas kostnader vilket leder till färre nackdelar med metoden. I avsnitten nedan beskrivs två tredjehandsverktyg för VGT.
2.2.1.1 OpenCV
OpenCV är ett kraftfullt verktyg för bildigenkänning som består av bibliotek med öppen källkod för automatisk hantering av data genom Computer Vision. Verktyget skapades av Intel och släpptes första gången 1999. Biblioteket består av 2500 algoritmer för datorseende och maskininlärning och kan användas för exempelvis ansiktsigenkänning, bildjämförelse, objektidentifikation och 3D modellering av objekt. Biblioteket är portat till C++, Python, Java och MATLAB på de vanligaste operativsystemen (Linux/Windows/Mac) och används aktivt av företag som Google, Yahoo, Microsoft och Intel. OpenCV har 18 miljoner nedladdningar och ett “Community” på 46 000 användare som gemensamt hjälper till för att förbättra biblioteket.2 OpenCV använder sig av matriser för att representera pixlar i bilder där varje pixel är en plats i matrisen. Varje grå pixel består av 8-bitars heltalsvärde medan pixlar med färg består av tre 8-bitar med heltal. De olika bitarna beskriver färgen på pixeln med RGB (Röd, Grön, Blå) [9]. Verktyget är ofta återkommande i uppsatser och projekt som ska lösa olika former av bildjämförelse/analys och har visats fungera i andra projekt [4, 5, 6].
2.2.1.2 Sikuli
Sikuli är ett verktyg för att automatisera grafiska användargränssnitt med avbilder från en skärm och förlitar sig på bildigenkänning med hjälp av OpenCV. Det är ett verktyg med öppen källkod som är byggt i ett Jythonbibliotek (Python baserat på Java), detta gör att det är blir kompatibelt både Java och Python script. För att automatisera GUI-interaktioner, förser Sikuli också av ett visuellt API-script som genom skärmavbildningar kan dirigera mus- och tangentbordshändelser.3
Användningen av visuella funktioner har med de senaste framstegen inom datorseende visat att framställning av bilder som en uppsättning av visuella ord blir effektivare. Det som beskriver ett visuellt ord är en vektor som har värden vilket för att skildra de visuella tillhörigheterna hos en del av skärmavbilden. Dessa bilder som blir framställda som visuella ord kan bli indexerade, med det inverterade indexet vilken innehåller en adress för varenda visuella ord. En bild kan indexeras så att man tar fram visuella ord och sen för vartenda ord läggs det till ett bild-ID till varje port. Sikuli har tidigare använts av Saab samt varit del av andra projekt där det är frågan om testning av funktionalitet i grafiska gränssnitt [2, 12].
2 https://opencv.org/about/ [besökt: 2020-04-01] 3http://sikulix.com/ [besökt: 2020-05-19]
2.2.2 Rendera egna data för jämförelse
Data som används för att rendera en bild består av “råa” pixlar vilket är helt obehandlade pixlar. Resultatet av att använda data innan rendering blir pålitligt och mindre beroende av externa faktorer. Metoden är en blandning av generation ett och två, där den data som renderats till pixlar jämförs med dess koordinater och med hjälp av GUI bibliotek. Det finns olika program för detta, den vanligaste är OpenGL vilket finns i flera olika versioner. OpenGL är inte på något sätt en VGT metod, utan en standard för rendering av data som i sin tur kan användas för testning. OpenGL har API-kommandon som tar en identisk kopia av tidigare använd renderingsdata vilket kan användas för jämförelse mellan de olika versioner av renderingar.4
2.3 Validering och Verifikation
Saab arbetar ofta med Validering och Verifiering (VoV) i sina projekt eftersom de har mycket säkerhetsspecifikationer att ta hänsyn till. Syftet med validering och verifikation är att säkerhetsställa att en produkt uppfyller de krav som ställts vid beställning. Målet med att ha en VoV-plan är att kunna hitta felaktigheter i tidigt stadie men även vid slutprodukt. Detta underlättar för utvecklare då det finns en tydlig bild på vad som ska finnas och hur det ska fungera. Verifiering är att bevisa att systemet är genomfört i överensstämmelse med kundens beställning och motsvarar dess specifikation, att det är byggt “på rätt sätt” till skillnad från validering, som är att kunna bevisa att systemet är lämpligt för sitt syfte och blir godkänd av kunden. I detta projekt finns en VoV-plan att gå efter, den ställer olika krav på produkten som till exempel på vilken nivå i processen produkten ska testas. Senare i rapporten nämns olika nivåer på testningen där testning på hög nivå hänvisar till att testningen sker i slutskede där det faktiska visuella som piloten ser testats. Testning på låg nivå hänvisar till att testningen sker i ett tidigare skede i processen, exempelvis testning av källkod som senare används till renderingen vilket inte blir det faktiska som piloten ser i cockpiten.
Robert G. Sargent [13] har skrivit en litteraturstudie om de fyra vanligaste tillvägagångssätten för att testa validering på simuleringar. Den första metoden som ofta används är att utvecklarna helt enkelt subjektivt bestämmer gemensamt om validiteten av produkten vilket är en enkel lösning. Beroende på storleken av det team som utvecklar produkten finns metoder som ger ett mer korrekt resultat där små team kan involvera kunden under utvecklingen för att ge dom chansen att bedöma validiteten av det de beställt. Om projektet är stort och involverar flera team kan det vara enklare att använda metoden Independent Verification and Validation (IV&V) som innebär att man tar in en oberoende tredje part som genomför valideringen under utvecklingen eller vid färdig produkt [13].
2.4 Relaterat arbete
Chandan et al. [4] gjorde 2018 en studie med djupa inlärningsalgoritmer och OpenCV för objektdetektion och spårning. Studien undersöker olika djupinlärningsalgoritmer, exempelvis Single
shot Detector (SSD), You Only Look Once (YOLO) och Regin-based Convolutional Neural Networks (RCNN) för att sedan göra en implementation av den Google-utvecklade SSD algoritmen. Programmet
utvecklades i Python och OpenCV-bibliotek implementerades tillsammans med SSD algoritmen. För objektdetektion använde programmet stegen att först hitta differenser mellan bildrutorna och med algoritmer för optiskt flöde och självanpassning skapa en bild där konturerna är tydliga och bakgrunden kan tas bort. Programmet tränades med 21 olika objekt föreställande tåg, bussar, cyklar, hundar. Resultatet från simuleringen blev att realtids detektionen kunde med 99,99% säkerhet säga att det fanns ett tåg på bilden och med 97,77% säkerhet säga att det fanns en hund på en annan bild.
White et al. [7] studerade hur man kan förbättra slumpad GUI testning med hjälp av bildbaserad gadgetdetektion. Författarna såg ett behov till förbättrad testning av grafiska gränssnitt då GUI blir allt vanligare och att de vanligaste testmetoderna förlitar sig på funktionalitet i operativsystemet eller med specifika ramverk för applikationen. Det föreslås en teknik som ska förbättra testningen med automatisk identifikation av gadgets i det grafiska gränssnittet med hjälp av skärmavbilder och maskininlärning. Med slumpade tester som guidas med hjälp av maskininlärning och
gadgetdetektion blev resultatet att 42,5% mer av applikationens funktionalitet testade jämfört med endast slumpad testning.
Att använda kamera för att testa visuella system är smidigt då det visuella systemet inte har möjlighet att skapa en avbild av sig själv. Exempel på det är instrumentkluster (ICL) i bilar och lastbilar. Innan digitala infotainmentsystem fanns förlitade ingenjörer sig på analoga och enkla digitala mätare för att förmedla information om fordonet till föraren vilket var svårt att testa visuellt. I tidigare projekt som har testat och designat system för testning av ICL används “Machine Vision”, vilket inte ska blandas ihop med “Computer Vision”. Skillnaderna mellan de två är små, men att Computer Vision är bredare och inkluderar metoder för analys och förståelse för bilder.5 Huang, Y et al [11] gjorde 2008 ett projekt där de designade ett verktyg för att validera ICL med ”Machine Vision”. De använde en kamera, ljusverktyg och bildhanteringsmjukvara i sitt projekt för att testa ICL på en Jaguar XK. Bilen passade bra som experiment då den hade både digitala och analoga mätare. Kameran som användes var en ”Cognex In-sight CCD vision sensor “, vilket år 2008 var en kvalitets kamera med hög upplösning (1600 x 1200 pixlar). Då mätarna på ICL är av olika typ, exempelvis är vissa beroende på vinklar medan andra är en bar-graf för att symbolisera volymen av bränsle i tanken krävdes olika typer av tester. Funktionen ”Needle angular speed” användes för att beräkna vinkeln på hastighetsmätaren från utgångspunkten. Resultatet av testet visade att kameran kan avläsa hastigheten och testa systemet visuellt om kalibrering och vinkelberäkning är korrekt. “Bar graph position” testar bränslemätaren som representeras av en bar-graf. Testet använde funktionen FindLine() tre gånger för att hitta positionen för 0%, 100% och aktuellt värde. Med aktuellt värde i grafen kan den procentuella volymen i tanken beräknas med hjälp av förhållandet mellan aktuellt värde och max värdet. Slutsatsen från arbetet är att det utvecklade systemet förenklar valideringstester jämfört med en manuell metod och att den fungerar för upprepade tester [11].
Linus Molin och Gabriel Mucchiano [10] gjorde 2011 ett liknande arbete på Scania för att
automatisera deras testning av ICL på lastbilar. Arbetet gjordes till mestadels teoretiskt där för- och nackdelar samlades in med de olika kommersiella metoderna samt för en egenutvecklad lösning. I analysen av metoderna hade kostnad för implementation stor vikt. Undersökningen visade att priset för kommersiella metoder kunde skilja från 15000kr till flera miljoner vilket är bra att veta vid val av metod. De utvecklade även ett eget enkelt system som använde en webkamera för insamling av data från ICL. Avläsningen brister i precision då den missar ordet ”communication” men att den klara av att avläsa både ”ECU”, ”error” och ”14:38" vilket visar att precisionen i en lågpriskamera funkar till större symbol. Likt Huang, Y et al [11] kommer de till slutsatsen att visuell testning av ICL med kamera är möjligt och löser problemet med långdragen visuell testning automatiskt, men att kvalitén på den insamlade data måste vara hög för att ge godkänt resultat och validitet med testningen. Avvikelser i ljus och kameravinklar är något som påverkar visuell testning och måste hanteras, vilket är ett stort problem som måste betänkas vid användning av kamera för pixeljämförelse enligt författarna [10].
5https://www.quora.com/What-is-difference-between-machine-vision-and-computer-vision-Do-they-come-under-robotics
3. Metod
Detta kapitel beskriver förstudien hur den metod som används för att testa det visuella gränssnittet tas fram med för- och nackdelar samt hur programmet för detta konstrueras och testas.
3.1 Förstudie
Från avsnitt 2.2 och automatiserad GUI-baserad testning får vi olika metoder som teoretisk kan fungera för testning efter regressioner på visuella system. Metoderna skiljer sig åt då tillvägagångssätt och resultat är olika där att jämföra renderingsdata med OpenGL kopplas till som generation två som då renderar en egen 2D/3D modell av data, vilket sedan kan användas som jämförelseobjekt. Visuell GUI testning kopplas till generation tre som används tillsammans med OpenCV för bildjämförelse, vilket förlitar sig på en skärmbild för testning som i detta fall insamlas via antingen en extern kamera som spelar in en display, eller via en skärminspelningsfunktion som finns i operativsystemet. Alla metoderna kan teoretiskt fungera i projektet för att regressionstesta det grafiska gränssnittet, men vilken som är relevant för detta arbete beror på hur Saabs validering- och verifieringsspecifikation ser ut. Detta gör att en lista med för- och nackdelar med metoderna kan hjälpa i beslutet av vilken metod som stämmer bäst överens med de krav som ställs utifrån Saabs specifikationer. För- och nackdelarna togs fram av information som givits i teorikapitlet samt från diskussioner tillsammans med handledare från Saab.
Tabell 2. För- och nackdelar med metoderna Visuell GUI Testning och renderingsdata med OpenGL.
Fördelar Nackdelar
Visuell GUI Testning (VGT) Väldokumenterat.
Brett användningsområde. Enkel implementation. Testning på hög nivå.
Kan kräva mycket underhåll av bilder.
Mycket jobb med referensbibliotek. Kan kräva investering av hårdvara.
Renderingsdata med OpenGL ”Säkrare” då data inte blir beroende av externa faktorer som skärmen.
Renderar data själv, fördel om skärminspelning inte är ett krav, annars nackdel.
Komplex implementering. Mindre dokumenterat. Tidigt skede av data.
Tabell 3. För- och nackdelar med olika metoder för insamling av materiall till VGT.
Fördelar Nackdelar
VGT med
skärmavbildsfunktion
Testning på hög nivå. Intern funktionalitet – ingen extern hårdvara krävs.
Kan ge försämrad bildkvalité. Funktionen kan påverka validiteten.
VGT med kamerainspelning Krävs ingen
skärminspelningsfunktion. Testar den faktiska slutprodukten.
Dyr och omständlig. Hårdvaruberoende. Känslig för ljus och vinklar. Lägre precision vid billig hårdvara.
Från avsnitt 2.2 och tabell 1 finns Alégroth och Feldts 14 punkter som är till hjälp i beslutet om VGT är rätt lösning för det tänkte problemet och användningsområdet. I detta avsnitt besvaras de första 5 punkterna tillsammans med handledare och chef på Saab. Punkterna är de som hanterar införandet av VGT i projektet och utelämnar resterande 9 frågor då dessa fokuserar på den långsiktiga användningen som sträcker sig utanför detta projekt.
1. Hantera förväntningar: En gemensam bedömning måste göras på vad som kan automatiseras i testning av symboler för att inte komplicera processer i onödan. Bedömningen visar att testning av statiska symboler är efterfrågad och kan troligen automatiseras med VGT. Testning av dynamiska symboler är komplicerat och kommer eventuellt kräva mer arbete och tid med underhåll av referensbiblioteken även vad processen tar att utföra manuellt vilket är bra att vara medveten om vid implementation av metoden.
2. Stegvis implementation: En stegvis implementation av testning planeras och startas med statiska symboler för att sedan vidareutvecklas för testning av dynamiska symboler. Detta för att fånga upp problem i tid och hitta eventuella begränsningar i en implementation av VGT för denna automatisering.
3. Motiverat team: Teamet är motiverade att lösa problem med bra stöd från chefer och handledare på Saab som efterfrågar nya metoder och arbetssätt som underlättar deras arbete.
4. Använd bra ingenjörskap: Att använda bra ingenjörskap är viktigt för att lyckas med implementationer av en ny metod i en organisation. Vad som är bra ingenjörskap är svårt att säga generellt, varför denna fråga inte besvaras specifikt.
5. Undersök utvecklad mjukvara: I studien har fakta samlats in på ändamålsenliga tredjepartsverktyg som teoretiskt kan lösa problemet. Verktygen är kompatibla med olika programmeringsspråk och har en blandad nivå av dokumentation vilket är viktigt att veta om en redan utvecklad mjukvara ska användas eller om en egen mjukvara ska utvecklas. Från att studera och svara på de först fem av Alégroth och Feldts 14 punkter kan antagandet göras att en implementation av visuell testning för statiska symboler på en skärm är genomförbart med VGT. För att lyckas med implementationen kommer teamet behöva vara motiverat för att identifiera problem och begränsningar i tid för att undvika slöseri av tid och pengar på en metod som inte uppfyller kraven.
3.1.1 Val av metod för testning
Det Saab värdesätter och de krav VoV-planen ställer i denna testning är en väldokumenterad metod för testning på hög nivå med en enkel implementation utan investering av ny hårdvara, vilket VGT med testmaterial från skärmavbildsfunktion uppfyller från punkten 3.1. Dessa kännetecken är något som saknas med OpenGL samt med kamera. Något som också är av betydelse är att det kommer vara begränsat behov av underhåll av referensbilder vid testning av statiska symboler, då de
kommer från samma skärm med samma upplösning och mått samt att de sällan förändras. Detta gör att en av de stora nackdelarna med VGT minskas vilket leder till slutsatsen att metoden skulle fungera bra för projektet. Slutsatsen med OpenGL är att testning av egenrenderade data inte uppfyller kraven för VoV då det inte är den faktiska skärmen som testas samt att bristen på dokumentation kan komma att leda till en återvändsgränd i projektet vilket kan skapa problem för projektets resultat. Metoden att använda kamera för insamling av material kan vara känslig för ljusskillnader, avstånd och kan ha låg precision men att slutsatsen för metoden är att den kan vara användbar i projektet, men att investeringar i hårdvara är något som ska undvikas varför den väljs bort.
Utifrån detta resonemang är VGT med skärmavbildsfunktion den metod som stämmer överens med de förutsättningar som finns och blir metoden som är mest lämpad för projektet. Från teorin finns två verktyg, OpenCV och Sikuli som båda är verktyg som går att använda vid bildhantering och bildigenkänning. Vilket verktyg som fungerar bäst för detta projekt går inte att säga exakt, utan antaganden får göras utifrån den dokumentation som hittats från tidigare arbeten. OpenCV är väldokumenterat och har ett brett användningsområde som är under ständig utveckling medan Sikuli är relativt oanvänt och odokumenterat samt att Spotify övergav sin användning av Sikuli för deras visuella testning. Från relaterat arbete [4, 5, 6] har OpenCV visats vara effektiv och precist för den typ av uppgift som ska lösas i projektet vilket är den avgörande faktorn i beslutet att använda OpenCV som verktyg i detta projekt.
3.2 Testning av metod för visuella avvikelser i det grafiska gränssnittet
Detta avsnitt beskriver testerna, hur materialet för dessa samlats in och testprogrammet som är skrivet i C++ med bibliotek från OpenCV 4.3.0.
3.2.1 Testbeskrivning och material
Testprogrammet ska ge ett svar som antingen visar “Test succeeded” eller “Test failed” på antingen resultatbilden eller i terminalen. Detta svar grundar sig i om programmet hittar avvikelser när den ställer den muterade testbilden mot referensbilden. Programmet kommer rita ut rektanglar runt avvikelserna som upptäcks och utifrån hur många avvikelser som hittas motsvarar ett indextal. “Test
succeeded” fås endast om programmet hittar noll avvikelser, då korrekt beteende visas, och allt över
noll innebär att utfallet blir “Test failed”. I testning av statiska symboler behövs endast en bild på skärmen för jämförelse där hela bilden testas. Det som skiljer sig vid testning av dynamiska symboler är att en videofilm kommer brytas ner i 60 bilder per sekund, där bildruta för bildruta jämförs med referensbilder. Programmet kommer då läsa in första bildrutan, klippa ut den dynamiska symbol som ska testas och då hitta avvikelser mot referensbilden. Avvikelserna markeras med röda rektanglar på resultatbilden som skickas till en buffert för att sedan fortsätta med nästa bildruta. Efter programmet gått igenom alla bildrutor från videofilmen kommer resultatbilderna från bufferten skrivas till en
Avi-fil.
Som material i testningen kommer programmet “Active Presenter” som är ett gratisprogram för skärminspelning och videoredigering användas tillsammans med flygsimulatorn Microsoft flight
simulator X. Flygsimulatorn har möjlighet att förstora den primära flygdisplayen i det flygplan som
simuleras vilket blir detaljrikt och tydligt för skärminspelningsverktyget som spelar in både referenssekvensen och testsekvensen. Den primära flygdisplayen som i testningen kommer från en Boeing 737 har klassiska symboler i samma storlek och färger som liknar många andra flygdisplayer vilket gör testningen generell. Från materialet som spelats in i testerna för en dynamisk symbol kommer endast den symbolen som ska testas klippas ut av programmet för att minimera risken för påverkan av andra pixlar och symboler medan i testningen av statiska symboler kommer hela bilden användas.
3.2.2 Testfall och testprogram
Testningen kommer göras strukturerat och uppdelat för att kunna få så pålitliga resultat som möjligt. Det som ska kontrolleras på statiska symboler testas i fem olika testfall. Test ett är då inga mutationer gjorts på testbilden, test två genom att ta bort stor och liten symbol, test tre genom förflyttning av stor och liten symbol, test fyra genom modifiering av symbol samt test fem som kontrollerar färgkombinationer. Definitionen av en stor symbol har en omkrets som är större än 300px exempelvis DME-symbolen medan definitionen på en liten är mindre än 14px, exempelvis det lilla strecket i vertikala fartmätaren till höger i testbilen. För att testa färgkombinationer kommer konturer på 3x3 pixlar i färgerna svart, vit, grå, vinröd, röd, orange, gul, grön, ljusblå, marinblå och lila testas på bakgrunderna vit, grå, brun, marinblå och ljusblå för att se om testprogrammet missar någon färgkombination.
Det testfall som ska utföras i testning av dynamisk symbol är en enkel acceleration av flygplanet på marken där gasen går från 0% till 100% med en knapptryckning i cirka 5 sekunder och rörelsen av fartmätaren noteras. Målet med testfallet är att få två identiska sekvenser att jämföra, därav ska väderförhållandena i simuleringen ska vara så minimala som möjligt vilket innebär fint klart väder utan vind för att minska påverkan av yttre faktorer. Detta testfall är det enklaste sätt att testa en dynamisk symbol när det inte finns möjlighet att koda indata som ett script till simuleringen för identiska förutsättningar och att endast ett knapptryck är så nära script som det går att komma. Videosekvenserna behandlas i redigeringsprogrammet Activepresenter så sekvenserna startar på den första bildruta som rör sig vilket gör att resterande del av sekvensen bör vara identisk då båda testerna har samma förutsättningar. Motiveringen till de testfall som valts är att test två, tre, fyra och sex liknar
de tester som görs på den äldre generationen Gripen C/D efter systemuppdateringar för att verifiera det grafiska gränssnittet medan test fem är för att verifiera programmet och hitta eventuella brister. Test sex med den dynamiska fartmätaren har en högre noggrannhet med pixeljämförelse på varje bildruta än de tester som görs på Gripen C/D, där extremvärden har större fokus än förloppet när man mäter med linjal. Detta gör att testet kan ses överdrivet och onödigt noggrant jämfört med den gamla testning men att det är något som bör testas med OpenCV då det är genomförbart.
Testprogrammet är uppbyggt av olika OpenCV funktioner och variabler som löser olika problem och dessa behöver beskrivas kort för att ge förståelse för varför de används.
Mat: Bildvariabel i OpenCV som representerar bilder. Imread(): Läser in en bild från disk till en Mat.
VideoCapture(): Läser in en videofil till en buffer som sedan kan skrivas till en Mat för varje
bildruta.
Absdiff(): Tar två gråskaliga bilder som in-parametrar och beräknar skillnaden mellan de två
bilder och presenterar detta i en ny gråskalig Mat.
Threshold(): Tar en gråskalig Mat som in-värde och skapar en nya Mat där varje pixel
representeras av ett threshold värde. Om pixelvärdet är mindre än threshold-värdet så blir värdet 0.
FindContours(): Tar thresh som in-värde och hittar externa konturer i Mat’en med RETR_EXTERNAL och sparar dessa i en vektor av points (pixel positioner).
BoundingRect(): Skapar rektanglar runt konturerna. ArcLength(): Beräknar omkretsen på konturen i pixlar.
Rectangle(): Ritar ut rektanglar i färg från BoundingRect() på den modifierade testbilden. CopyTo(): Kopierar alla olika Mat till en gemensam bild som sedan kan skrivas till hårddisken
för enklare överblick av testet.
ImWrite(): Skriver Mat-variabeln till disk som en bildfil och ger denna ett namn.
VideoWriter(): Skriver en buffert av Mat till en videofil som specificeras med
uppdateringsfrekvens, filformat och storlek.
Funktionerna Threshold() och FindContours() har inparametrar som är framtestade för att programmet ska få den tänkta funktionaliteten. Funktionen Threshold() använder THRESH_BINARY som konverterar pixlar till binära tal och har de binära gränserna 0 till 255 vilket betyder att alla pixlar från den absoluta differensen är relevanta och kommer sparas till testningen. Med andra värden på threshold kan pixlar i vissa färger sorteras bort om man endast är intresserad av specifika värden. Även THRESH_BINARY | THRESH_OTSU testades där bilden antigen blev binär eller uppdelad i bakgrund/förgrund beroende på vad algoritmen ansåg som bäst. Under uppbyggnad av programmet märks det att programmet är känsligt för färgkombinationer varför test fem bestäms specifikt för detta. Problemet kan spåras till THRESH_OTSU som sätter threshold värden som den anser är bäst vilket sorterar bort vissa färger vilket THRESH_BINARY inte gör. Även fast algoritmen THRESH_BINARY är det som slutligen används i programmet, och att färger inte bör vara ett problem så genomförs test fem för att försäkra att problemet med färgkänslighet är löst. FindContours() använder THREE_EXTERNAL för att endast hitta de yttre konturerna och inte alla i en hierarki eller en lista samt CHAIN_APPROX_SIMPLE för att effektivisera processen med färre referenspunkter för konturen. Programmet kommer efter utfört test av statiska symboler skapat en ny bild, kollage.png som är ett kollage av originalbilden, den modifierade testbilden, differensbilden samt den modifierade testbilden med tydliga rektanglar runt differenserna. Testet av en dynamisk symbol kommer skapa en ny videofilm där avvikelserna i bildrutorna markerats renderats ihop. Programmet kommer sortera bort
alla avvikelser vars omkrets är mindre än 6px då detta motsvarar två pixlar i rad, vilket inte anses som en symbol i testningen då de är för små och dessa benämns som falska pixlar.
4. Resultat
I detta kapitel presenteras resultatet utifrån de sex testfall som utförs.
4.1 Test ett: Inga förändringar
I första testet jämförs två likadana bilder i programmet för att testa att inga falska värden hittas, att kollaget ser ut som tänkt och att testet kan leverera resultatet “Test Succeeded!” när inga avvikelser hittas. Resultatkollaget ser ut som tänkt med den modifierade bilden i första kvadranten, originalbild i andra, differensen mellan bilderna i tredje och markerade differenser på den modifierade bilden i fjärde. Testet blir “Succeeded!” då inga differenser hittas och konturindexet är noll vilket visar att testprogrammet fungerar som tänkt för då inga förändringar finns på testbilden.
Figur 3. Resultatet från test ett som blir ett ihopsatt kollage av testbilder med texten ”Succeeded!” vilket betyder att inga skillnader fanns mellan referensbild och testbild.
4.2 Test två: Symboler som saknas
I test två har fem symboler redigerats bort på testbilden för att testa programmet för symboler som saknas. Symbolerna är olika stora och består till viss del av olika färgkombinationer. Symbolen “DME“ är den största med en omkrets på 300px medan linjen i den vertikala fartmätaren till höger i testbilden är den minsta med en omkrets på 16px. Programmet ger resultatet ”Test Failed” vilket betyder att avvikelser har hittats mellan bilderna. Konturindexet från testet är sju vilket är mer än antal förändringar som gjorts. Från att studera resultatbilden ser man att symbolen ”DME” har brutits upp i tre röda rektanglar istället för en för alla tre bokstäver. De övriga avvikelser som hittats är markerade med en rektangel var och dessa stämmer överens med de mutationer som gjort på bilden. Resultatet visar att programmet hittar både små (16px) och stora (300px) statiska symboler som saknas på testbilden.
Figur 4. Resultatet från test två som blir ett Ihopsatt kollage med originalbild, modifierad bild, differens mellan bilder och markerade röda rektanglar där differenser var på den modifieradebilden.
4.3 Test tre: Symboler som flyttats
I test tre har fyra symboler muterats genom en förflyttning av symbolen. Symbolen ”DME”, strecken i det blå och bruna området samt lilla strecket i den vertikala fartmätaren är olika stora symboler som har flyttats olika långt från dess faktiska plats.
Figur 5. Förstoring av resultatet från test två där röda rektanglar markerar skillnaden mellan testbild och referensbild.
Figur 6. Förstoring av resultatet från resultatkollaget på test tre där stora och små symboler flyttats i olika riktningar.
Resultatet av detta är ”Test failed” eftersom programmet hittar de förflyttade symbolerna och markerar ut dessa med röda rektanglar både där symbolen var på referensbilden samt den nya positionen på testbilden. Av att studera resultatbilden syns det att symbolen ”DME “, som blivit nedflyttad 1px inte har markerats med en rektangel runt hela symbolen utan med en eller fler rektanglar per bokstav. Bokstaven “D” är markerad med två rektanglar som inte täcker hela bokstaven utan en del i mitten är omarkerad. Det är en rektangel runt bokstaven ”M” och bokstaven ”E” är markerad med tre rektanglar runt varje horisontellt streck medan det lodräta strecket inte har markerats med någon rektangel. Strecket på det blå området är markerat med en rektangel för var symbolen saknas på referensbilden och var den finns på modifierade bilden. Strecket på det bruna området är markerat på liknande sätt, eftersom strecket är flyttat till vänster men är på samma linje markerar programmet en rektangel för var det vita strecket saknas och en rektangel där det vita strecket upptäckts, men inget i mitten då det ser lika ut som på referensbilden. Vita strecket i den vertikala fartmätaren är förflyttad 1px till höger och programmet har ritat ut en rektangel runt symbolen inklusive den pixeln där strecket flyttats ifrån. Konturindex i resultatet är 11 där fyra mutationer gjorts.
4.4 Test fyra: Symboler som modifierats
I testet har fyra symboler modifierats. Symbolen ”DME” har förminskats, strecket på det blå området har förstorats, strecket på det bruna området har förstorats och det vita strecket i den vertikala fartmätaren har förminskats till 6px och flyttats några pixlar till höger.
Figur 7. Förstoring av den resultatet från resultatkollaget på test fyra där stora och små modifikationer gjorts på symboler.
Resultatet från testet blev att alla modifikationer på testbilden hittades, men att konturindexet blev högre än antal modifierade symboler. Även en falsk negativ kontur i det blåa fältet finns med i resultatet. “DME” symbolen har blivit uppdelad i två konturer, där en markerar symbolens nuvarande position samt en som tillsammans med den andra visar symbolens ursprungsposition och storlek. Markeringarna i blåa och bruna rutorna markerar mutationen tydligt med en stor rektangel runt hela förändringen. Det lilla strecket i den vertikala fartmätaren markeras ut med en liten rektangel runt den nya positionen för den modifierade symbolen samt ursprungsposition och storlek för symbolen. Markeringen på siffran tio i det blåa fältet är ingen medveten modifikation och inget som ska ändras varför den då blir falskt negativt. Konturindex i resultatet är sju där fyra mutationer gjorts.
4.5 Test fem: Olika färgkombinationer
I sista testet har olika färger ritats ut på fem olika bakgrundsfärger för att kolla hur känsligt programmet är för att hitta färgkombinationer vilket var ett problem under utveckling. De olika färgerna som testades var 3x3 pixlar på bakgrundsfärgerna marinblå, vit, grå, brun och ljusblå.
Resultatet visade att 54 konturer hittades (vit på vit exkluderades ur testningen) vilket är 100% av de modifikationer som gjorts på testbilden. På resultatbilden är alla färgmarkeringar omringade av röda rektanglar vilket visar att avvikelserna är funna av programmet.
4.6 Test av dynamisk symbol, fartmätare
Resultatet från testet blev att programmet hittade avvikelser i fartmätaren där konturindex varierade mellan 8 och 26 på de 300 bildrutor som testades och medeltalet på index blev 13. Den bildruta med minst konturer var nummer 92 som hade åtta medan den bildrutan med flest var nummer 147 med
Figur 8. Förstoring resultatet från resultatkollaget på test fem där färgkombinationer på olika bakgrundsfärger testas.
26 konturer. Ingen bildruta i videon var identisk med referensvideon för hur fartmätaren ska röra sig vilket då skulle innebära ett konturindex på noll. De svarta bilderna i figur 9 och figur 10 visar den absoluta differensen mellan de bildrutor som testas. I figur 9 visas en minimal förskjutning av symboler mellan bildrutorna som visar vilken har i testet. I testet. I att 26 konturer finns som markeras på resultatbilden. att 26 konturer finns som markeras på resultatbilden.
Figur 9. Bildruta nr 92 från sekvensen som hade 8 avvikelsekonturer. Den svara rutan är den absoluta differensen mellan de bildrutor som testas.
Figur 10. Bildruta nr 147 från sekvensen som hade 26 avvikelsekonturer. Den svara rutan är den absoluta differensen mellan de bildrutor som testas vilket är en motsägelse då skillnader finns men inte i differensen.
5. Diskussion
Detta kapitel diskuterar först de olika metoderna från förstudien samt källkritik, för att sedan diskutera resultaten från testerna.
5.1 Metoden
I förstudien undersöktes ett urval av olika metoder och verktyg där skillnaden är hur testningen av det grafiska gränssnittet sker och vad som behövs för att kunna genomföra testningen. Då Saab efterfrågar en metod som testar det faktiska visuella som piloten ser på skärmen måste de olika nivåerna av testning diskuteras. Metoderna kan delas in olika nivåer utifrån vad VoV-planen som hänger ihop med vilket skede testningen händer i processen där OpenGL är testning på låg nivå då metoden använder källkoden som testmaterial. En skärmavbild från både en funktion i skärmen samt med kamera är testning på högre nivå än OpenGL, men att dessa i sin tur är olika nivåer av testning där användning av kamera når den högsta nivån (slutprodukten). Skillnaden mellan en skärmavbild skapad av mjukvara (funktion) i skärmen och hårdvara (kamera) blir att funktionen i skärmen använder kodade data för att rendera bilden vilket inte är helt olikt metoden att använda OpenGL. Då skärmar och grafiska gränssnitt är komplicerade är det svårt att veta exakt hur en skärmavbild från en intern funktion skapats och om den är identisk mot verkligheten. Antaganden att samma mjukvara används vid både skärmavbild samt skärmrendering gör att metoden når testning på högnivå vilket en egen renderad 2D/3D modell med OpenGL inte kan nå upp till. Att använda en kamera för insamling av skärmbilder leder till testning av den högsta nivå då materialet som samlas in är samma som piloterna ser i cockpit. Även här finns osäkerheter där en kamera kan komprimera och skala om materialet vilket blir en mutation från verkligheten, men att antaganden är tillräckliga för att gör metoden godkänd utifrån VoV. Då Saab efterfrågade testning av det grafiska gränssnittet på hög nivå blir en metod med OpenGL utesluten då den inte klarar kraven på denna testning, men att metoden kan användas för att verifiera symboler i källkoden vilket kan vara användbart under utveckling av systemet. VGT uppfyller grundkravet med testning på hög nivå vilket leder till valet hur materialet ska samlas in, med kamera eller med intern funktionalitet som skapar en egen skärmavbild. Att använda skärmens egna funktioner blir billigare och smidigare då ingen investering i hårdvara behöver göras samt att det inte behövs någon tid för installation och kalibrering vilket är det största argument för metoden som valt att implementeras. Även argument som att precisionen riskerar att bli sämre då ljusförhållandet och vinklar måste vara identiska för att en kameratestning ska lyckas talar för att använda skärmens funktionalitet i testningen.
Källorna i denna studie är en blandning av hemsidor, vetenskapliga artiklar och olika examensarbeten. Artiklarna får ses trovärdiga då de är publicerade och flertalet av de är citerade och återkommande i olika studier. Att använda examensarbeten som referensen är inte det bästa då trovärdigheten i dessa är lägre, men att studien som gjorts ofta är smalare och mer specificerad än en vetenskaplig artikel vilket gör dessa till ett komplement till vetenskapliga artiklar. Trovärdigheten i hemsidor är helt okontrollerad och då låg, men att specifik information som exempelvis information om Gripen från Saabs hemsida är användbar i rapporten även om trovärdigheten är oklar.
5.2 Resultat
Diskussion av resultatet utifrån de sex testerna som genomfördes, därefter diskuteras problemen som uppstod med metoden och avslutningsvis vidareutveckling samt arbetet i ett vidare sammanhang.
5.2.1 Precision
Precisionen i testprogrammet är mycket hög och hittar enskilda felaktiga pixlar mellan referensbilden och testbilden. Programmet hittar både stora och små symboler som flyttats, tagits bort samt modifierats vilket täcker de tänkbara situationer som testningen kan utsättas för. Utifrån
resultatbilden där symboler flyttats ser man att det har betydelse hur stor en symbol är och hur långt den har förflyttats då programmet markerar ut dessa olika. Tanken är att en rektangel ska markera var symbolen befunnit sig på referensbilden och en rektangel ska markera symbolens nya plats, vilket strecket på det blå området på figur 6 visar. Resultaten från testerna är positiva då fem av sex tester fungerade som tänkt och hittade de avvikelser som testas utan att hitta någon extra avvikande pixel förutom i test fyra där en falsk negativ pixel hittades. Denna falska negativa uppkom vid mutationen av test fyra vilket är ett misstag när testbilderna muterades och inte något som programmet ansvar för. Test sex får ses misslyckat då målet var att skapa identiska sekvenser med en dynamisk symbol men att programmet hittade minst åtta fel i varje bildruta som byggde upp sekvensen. Testet visar att programmet hittar avvikelser mellan videosekvenser på dynamiska symboler likt för statiska symboler och markerar ut dessa, men att det är svårt att säga något om dess validitet då testet gick ut på att göra ett korrekt testfall utan avvikelser vilket misslyckades. Programmets pixelprecision är positivt men att det finns nackdelar med allt för hög precision, där det positiva är vid testning på statistiska symboler där hög precision är efterfrågad. Vid testning av dynamiska symboler hade det underlättat om precisionen var lägre då interna fördröjningar i simulatorn inte hade varit av lika stor betydelse. Testningen fungerar även för de olika tänkbara färgkombinationer som kan finnas på en flygdisplay vilket är positivt då metoden blir pålitlig för olika testfall på olika skärmar.
Testerna som genomförts har troligen hög reliabilitet då resultatet går att förvänta sig där testerna för statiska symboler fungerar som tänkt då de är betydligt enklare än testet för den dynamiska fartmätaren, och att metoden troligen skulle ge samma resultat om studien skulle göras om.
5.2.2 Problem
Det första problemet med metoden för detta projekt är att testprogrammet bygger på OpenCV som är tredjeparts bibliotek vilket inte fungerar i Saabs säkra utvecklingsmiljö som inte har kommunikation med omvärlden. Det går att få tredjeparts programvara godkända och installerad i en säker virtuell del för mindre projekt som detta med en säkerhetsrapport, men att det krävs omfattande utvärdering av säkerhet och framtidsutsikten för mjukvaran för att kunna användas i projekt som kommer pågå i många år framöver.
Om referensmaterialet samt textmaterialet har låg upplösning framstår bilden som suddig vilket kan bli ett problem vid pixelperfekt bildjämförelse. Risken finns då att det blir falska pixlar, alltså pixelkonturer som skiljer bilderna men att dessa inte är relevanta för testningen då de inte är en symbol. Ett test kan från konturindexet se misslyckat ut om dessa pixelavvikelser finns, men att de i verkligheten inte spelar någon roll. Detta problem löses enklast med att hålla hög kvalité på referens- och testmaterialet och ge testprogrammet så bra förutsättningar som möjligt, men att det är svårt att utesluta dessa till 100%. En specifik lösning på problemet är att utesluta konturer som exempelvis har en omkrets på mindre än 6px (två pixlar i rad) från indexet och inte markera dessa, men att risken då blir att små symboler som ska bli markerade blir sorterade som falska negativa och bortkastade. Det vanligaste problemet med VGT från tidigare studier är arbetet med referensbiblioteken och bildunderhåll. Problemet är mindre vid testning av statiska symboler från en skärm som inte ska ändras då referensmaterialet inte behöver uppdateras frekvent och att nytt referensmaterial är lätt att skapa vilket är grundfallet i detta projekt. Det stora problemet kommer vid testning av dynamiska symboler. För att testa dynamiska symboler behövs en testsekvens istället för en testbild, och varje bildruta som bygger testsekvensen behöver jämföras med motsvarande bildruta i referenssekvensen. Om sekvenserna inte jämförs exakt kommer bildjämförelsen bli inkorrekt och testet misslyckat. Förutsättningarna behöver även vara helt identiska i testfallen, vilket kräver kodade indata till testsimulatorn utan fördröjning för att exempelvis digitalt accelerera flygplanet utan att använda
faktiska reglage. Problemet med detta blev tydligt i test sex med dynamiska symboler där sekvenserna blev påverkad av felmarginalen att sekvenserna inte är helt identiska. Detta gör att det kommer bli svårt att lita på att programmet levererar ett pålitligt resultat när det gäller de dynamiska symbolerna. Arbetet med att uppdatera referenssekvenserna som ändras frekvent är krävande vilket kan vara ett stort och långdraget problem som behöver vidareutveckling.
Något som upptäcktes vid testning visas i resultatet av test sex i figur 10, där den absoluta differensen inte markerar att avvikelser finns, medan det finns 26 konturer utritade runt avvikelser på resultatbilden. Det blir en motsägelse mellan dessa bilder som ska visa ett och samma resultat där en helsvart bild ska innebära att inga avvikelser hittas, som figur 3 visar i test ett. Detta hände på ett flertal bildrutor utan någon som helst logik eller sammanhang kunde hittas. En hypotes är att problemet uppstår någonstans i programmet av någon typ av invertering eller liknande som inte upptäckts.
5.3 Vidareutveckling
Programmet som utvecklats i detta projekt testar endast en vy av skärmen i en körning vilket blir omständligt när skärmens innehåll och symboler bygger på applikationer vilket leder till många vyer att testa. En vidareutveckling på programmet till ett testgränssnitt som med tidsintervall eller knapptryck tar en skärmavbild på den aktuella vyn som direkt kan testas med referensvyn i testgränssnittet. Med ett testgränssnitt kan man stega genom alla vyer i displayen och testa de statiska symbolerna snabbare i ett svep vilket blir mer autonomt än att ta skärmavbilder manuellt och uppdatera koden med aktuellt filnamn. Testgränssnittet lämpar sig åt testning av statiska symboler då den dynamiska testningen inte är vy-baserad på samma sätt. För att lyckas med testning av dynamiska symboler krävs en del vidareutveckling av metoden som projektet testat där problemet är att få resultat med validitet från testerna som genomförs. Här krävs ett testscript för varje symbol som ska testas där indata till testet är identisk utan någon fördröjning eller extern påverkan. Precisionen i programmet är hög och förutsättningarna måste vara perfekta för att testerna ska lyckas och bli användbara. Hur och om detta är genomförbart ingår i den vidarestudie som behöver göras där fokus ligger på hur man kan mutera rörliga simuleringar efter vad som ska testas. En möjlighet att reglera precisionen i testningen kan också vara bra att forska vidare på då det inte alltid krävs 100% precision med ökat antal falska negativa som resultat, utan en lägre precision för testning av stora symboler och rörliga symboler kommer underlätta testningen. Även prestanda och effektivisering av programmet är av intresse vid vidare utveckling då en inspelning på 5 sekunder tar 60 sekunder att testa vilket går att förbättra genom snabbare processorer eller mindre kodeffektiviseringar.
5.4 Arbetet i ett vidare sammanhang
Saab är ett företag som utvecklar och säljer material för försvarsindustrin både nationellt och internationellt vilket är en stor etisk fråga. Vem som köper Saabs produkter och vad de ska användas till måste kontrolleras noggrant då export till länder med avsikt att använda produkterna i ett aggressivt syfte är förbjudet enligt svensk lag. Syftet med detta projekt är att undersöka nya tillvägagångssätt för Saab att utföra testning på det grafiska gränssnittet i Gripen E/F som är ett stridsflygplan vilket exporteras internationellt i syftet att försvara länders gränser och säkerhet. Projektet är ett litet steg på vägen att modernisera Saabs testteknik vilket kan göra både produkten, företaget Saab AB och Sverige mer efterfrågat som leverantör av krigsmaterial vilket organisationer i Sverige ifrågasätter.6 Varje individ måste själv ta ståndpunkt till de etiska frågor om vapenexport då det är upp till var och en att kunna ansvara och motivera sitt arbete. Vi anser att ett alliansfritt Sverige behöver möjligheterna att kunna utveckla försvarsmaterial för självförsörjning och att det då krävs
noga kontrollerad internationella kunder för att projekten ska bli ekonomiskt genomförbara vilket regeringen och svensk lag ansvara för.
För Saab så kommer en moderniserad autonom testning innebära förändringar för både individer och organisationen. Arbetssättet för den ansvariga personalen kommer övergå från de aktiva manuella mätningarna till underhåll och struktur av referensbibliotek och testfallen vilket kommer kräva utbildning och eventuell nyrekrytering. Även en tydlig struktur för hur testningen ska genomföras behövs då testerna kommer utföras hos internationella kunder av dess egna personal där kvalitén alltid måste hålla samma mått. Med modern datorsyn finns förutsättningarna för att lyckas med autonoma tester som håller högre precision och har högre kostnadseffektivitet jämfört med manuella tester vilket gör att förutsättningarna finns för att lyckas och leverera.
