B.4 Metod
C.5.2 Hur energieffektiva är de olika programmeringsspråken?
Cunha, S. et al. [55] gjorde en studie där de analyserade energiförbrukningen hos 27 olika programmeringsspråk. Detta gjorde de genom att analysera hur dessa språk presterade när de användes för att lösa tio olika programmeringsproblem. I studien beskrev de hur detta är ett komplext problem och svaret inte var så enkelt som att ta reda på det snabbaste språket och dra slutsatser om att den var grönast. Det finns ett antal faktorer som kunde manipulera resultatet. De behövde bland annat ta hänsyn till kompilatorn, skräpsamlaren och de tillgäng- liga biblioteken. Deras resultat kan ses nedan i figur C.1. Med hjälp av dessa resultat lyckades de svara på ett antal frågeställningar. En av dem var huruvida ett snabbare programmerings- språk medgav att det var grönare eller inte. Vad de kom fram till gällande denna fråga är att ett snabbare språk inte alltid är grönare. Trots att deras resultat ofta visade att det snabbaste språket var även det mest energieffektiva, kunde de inte dra några slutsatser. Detta var för att förhållandet mellan körningstiden och energförbrukningen skilde sig mellan de tio olika programmeringsprogrammen som analyserades. Ett mönster de såg är dock att kompilerade programmeringsspråk presterade bäst i både tids- och energiskalan vilket var något de hade förutsett. I genomsnitt förbrukade dessa 120J och tog 5103ms för att köra de tio programmen.
C.6. Diskussion
Samtidigt förbrukade virtuell maskinsspråk i genomsnitt 576J och tog 20623ms. För interpre- terande programspråk tog det 87614ms och förbrukningen låg på 2365J.
C.5.2.1 Minnesanvändning och dess energiförbrukning
En annan intressant fråga som besvarades med hjälp av resultaten i studien var om hur min- nesanvändning påverkar dess energiförbrukning. De 5 språken som i genomsnitt krävde minst minne är kompilerade språk som till exempel Pascal och Go. De två som använde sig av mest minne var de interpreterande språken JRuby och Dart. I studien undersöktes möjligheten till en korrelation mellan DRAM-energiförbrukningen och den maximala min- nesanvändningen. Vad de kom fram till var att korrelationen inte fanns och att DRAM- energiförbrukningen har väldigt lite att göra med den maximala minnesanvändingen.
C.5.2.2 Vad är det bästa språket?
Studiens sista frågeställning var om det var möjligt att automatiskt bestämma det bästa pro- grammeringsspråket att använda när utvecklaren vill ta hänsyn till energiförbrukningen, kör- ningstiden samt den maximala minnesanvändningen. Vad som upptäcktes var att det är möj- ligt att automatiskt bestämma det om utvecklaren lägger mest vikt på bara körningstiden och energiförbrukningen. Språket som presterade klart bättre än andra var då C. Detta är dock inte möjligt om utvecklaren ska även ta hänsyn till minnesanvändningen. Eftersom då var det fler språk som presterade lika bra och att utvecklaren måste i sådana fall hoppa in och bestämma det bästa språket utifrån andra kriterier så som funktionella och icke-funktionella krav.
Figur C.1: Resultat av undersökningen som gjordes av Cunha, S. et al. [55]
C.6
Diskussion
Det som presenterades under resultatdelen visar hur studierna inom området miljövänlighet inom mjukvaruutveckling är relativt nya. Ett antal studier som användes i denna undersök- ning uppmanade till ytterligare undersökningar för att kunna dra slutsatser. Detta förknippas med vad som skrevs i rapportens inledning. Mjukvaruutveckling antas vara en grön industri
C.6. Diskussion
på grund av dess frånkoppling från fysiska konsekvenser. Programmeringsspråken som an- vänds idag är på en så pass hög nivå att utvecklare inte längre kan observera vad deras kod har för konsekvenser på bland annat datorns energiförbrukning och minne. En annan faktor som kan ha orsakat denna brist på studier är att hårdvaran har blivit billigt att utveckla. Det gör att utvecklare inte bekymrar sig om mjukvarans prestation då hårdvaran kan täcka för mjukvarans brister.
Hur mäts energiförbrukningen inom de olika områden i
mjukvaruutveckling?
Av litteraturstudien kunde man se vilka utmaningar detta område har. Om man observerar ovanstående jämförelse under C.2 kan man notera varför det är svårare att lägga en miljö- märkning på en applikation jämfört med exempelvis en vitvara. Applikationens miljöpresta- tion beror bland annat på problemet den löser, antalet operationer den utför per tidsenhet och hårdvaran den körs på. Att miljömedvetenhet är relativt nytt inom området mjukvaruteknik gjordes tydligt med en brist på publicerade studier och undersökningar om ämnet. Även i vissa studier som användes i denna undersökning hade författarna svårt att dra slutsatser då de ansåg sin undersökning inte är tillräcklig för det. Dock uppmanades intresset för ämnet sedan bärbara datorsystem och mobiltelefoner blev populära. Detta kan bero på att dessa sy- stem bygger sin användbarhet till en stor del på att vara energieffektiva. En annan anledning till att ämnet blir mer aktuellt nu kan vara rädslan över att utvecklingen inom hårdvaran når sina gränser för hur optimerade de kan bli för att vara miljövänliga.
Hur väljer en utvecklare det grönaste språket?
Återigen har en studie med denna typ av undersökning haft det svårt att dra slutsatser. Detta var för att det fanns ett antal faktorer som gjorde det svårt att ta reda på ett pålitligt resultat. Olika programmeringsspråkfamiljer fungerar annorlunda och olika programmeringsspråk använder sig av olika bibliotek, skräpsamlare och kompilatorer. Studiens resultat visade att kompilerade programmeringsspråk presterade bäst i både tids- och energiskalan. Detta kan bero dels på att i kompilerade språk översätts koden direkt till maskinkod som processorn kan köra och dels på att kompilerade språk ger utvecklaren mer kontroll över hårdvarua- spekter som minnesanvändning.
En fråga som undersöktes är om huruvida det finns en korrelation mellan minnesanvänd- ning och DRAM-energiförbrukning. Studien använde sig av den maximala minnesanvänd- ningen för att ta reda på resultat och de kom fram till att korrelationen inte fanns. Det vore dock intressant med en undersökning som försöker finna en korrelation mellan den kontinu- erliga minnesanvändning och DRAM-energiförbrukning.
Som slutsats kunde författarna dra att C är det bästa språket på tids- och energiskalan. Det kompilerade språket gav bättre resultat när den användes för att lösa de 10 problemen som presenterades i studien. Men om minnesanvändningen är en viktig faktor måste utveck- laren välja bland ett antal språk då C inte var det enda språket som presterade bäst. Återigen ses det ett mönster i hur kompilerade språk är grönare än andra. Den extra tiden som andra programmeringsspråkfamiljer behöver för att översättas till maskinkod under körningen på- verkar körningstiden och minnesanvändningen. Därmed påverkar den även energiförbruk- ningen då programmet behöver exekvera längre i minnet.
Metod
Bristen på studier inom området ledde till att urvalskriterierna inte kunde sättas på en hög nivå. Detta medger att en viss osäkerhet kan finnas i dessa studiers reslutat och egna experi- ment hade behövts för att stärka det som källhänvisades i denna rapport.
C.7. Slutsatser
Dock kommer ett antal källor från publicerade tidsskrifter och konferenspapper vilket styrker deras trovärdighet. Även källorna som varken är konferenspapper eller publicerade som tidsskrifter har citerats ett relativt stort antal gånger. Detta ansågs vara ett tecken på dessa studiers trovärdighet.
C.7
Slutsatser
Det finns en brist om data när det gäller verktyg för att mäta miljövänligheten hos mjukvaror. Detta råder på grund av att industrin är relativt ny och har en frånkoppling från dess fysiska konsekvenser. Dock ses det en förändring nu och utvecklare kommer snart behöva tänka om. Detta beror till en viss del på att hårdvaran någon gång kommer att nå sina gränser i hur mycket den kan optimeras. Detta kommer att få företag som bland annat utvecklar mobiltelefoner och bärbara datorer att rikta sin forskning på att försöka optimera mjukvaran. Kompilerade programmeringsspråk presterar klart bättre jämfört med andra program- meringsspråkfamiljer. De kan vara vägen för en grönare mjukvaruutveckling. Detta betyder dock inte att interpreterade programmeringsspråk kommer att försvinna då dessa har sina fördelar som till exempel flexibilitet. Men om kraven för en grönare mjukvaruindustri höjs kan det vara bra för utvecklare som vanligtvis använder denna sort programmeringsspråk att tänka om. Val av programmeringsspråk kommer att bli mer begränsat desto mer fokus läggs på miljöaspekten inom mjukvaruutveckling.
D
Automatisk testning och testning
på distans
av Edwin Forsberg
Denna del är skriven av Edwin Forsberg som har verkat i rollen som testansvarig under projektet
D.1
Inledning
Denna del av rapporten är en kortare självstående rapport, som ska undersöka frågeställ- ningar rörande testning och mer specifikt, automatisk testning och testning på distans. Majo- riteten av arbetet kommer att bestå i en fallstudie på utvecklingen av kandidatprojektet och rollen som testning haft i den. Det kommer också att finnas delar som istället är baserade på litteraturstudier inom området för att bättre kunna svara på frågeställningarna och kunna göra mer generella iakttagelser.
I projektet har ett frågesportssystem utvecklats för att användas vid teknikåttan. Utveck- lingen skedde iterativt och demonstrerades i omgångar så att kunden kunde ge återkoppling. Ungefär halvvägs in på terminen bröt Coronapandemin ut, vilket resulterade i att projek- tet blev utvecklat på distans. Detta hade en viss effekt på våra förutsättningar och ändrade i viss mån vårt arbetssätt. Förändringen kom efter ungefär en tredjedel av tidsbudgeten hade förbrukats och efter första sprinten, vilket motsvarar tre veckors utveckling. Det betyder att majoriteten av utvecklingen och testningen utfördes på distans.
D.1.1
Syfte
Syftet med denna undersökning är att besvara frågor kring automatisk testning samt testning på distans genom en fallstudie på utvecklingen av projektet som detta dokument är en rap- port till. Denna undersökning har som mål att utreda hur testning kan automatiseras samt vilka för- och nackdelar det finns med automatisk testning, när automatisk testning bör an- vändas istället för manuell. Dessutom ska testning på distans undersökas och vilka hinder och möjligheter det kan föra med sig.
D.1.2
Frågeställning
1. Hur kan automatisk test användas i ett mindre mjukvaruprojekt? 2. Vilka skillnader finns mellan testning på distans och testning på plats?
D.2. Bakgrund
D.2
Bakgrund
Projektet utvecklades från grunden och arbetssättet förändrades allt eftersom gruppen ut- vecklades och provade nya metoder. På samma sätt så förändrades testning. Taget som hel- het så var projektet ett tillfälle att lära sig. Tidigare kunskap rörde sig ofta om teoretisk eller begränsad kunskap. vilket betydde att nya metoder behövde användas under utvecklingens gång och att teoretisk kunskap behövde implementeras för första gången. Allt detta påver- kade processen och slutprodukten.
D.3
Teori
För att säkerställa att en mjukvara uppfyller de krav som ställs på det måste det testas. Det bekräftas i så kallade acceptanstest, se definition nedan, där kunden testar och godkänner eller underkänner produkten. Om produkten underkänns är det användbart om man kan avgöra var brister finns, då går det lättare att åtgärda problem. I mjukvaruutveckling testas vanligt- vis logiskt sammanhängande delar tillsammans i flera nivåer för att på så sätt bygga upp förtroende i att designen fungerar och att implementationen uppfyller kraven. Komplexitet växer exponentiellt med antalet separata delar som interagerar med varandra eftersom det finns mycket större mängd möjliga tillstånd och förlopp.[56] [57]
D.3.1
Enhetstest
De allra minsta testen kallas unit test[56] på engelska och enhetstest på svenska. Deras syfte är att testa små delar av koden, ofta egna funktioner eller klasser. Tack vare sin storlek är de mindre komplexa och kan testas genom att jämföra utdata med indata och passar på så sätt till automatisk testning. Enhetstester är ofta automatiserade då det finns tydligt defini- erade relationer mellan indata och utdata vilket gör det lättare att göra en programmatisk lösning.[56] [57]
D.3.2
Integrationstest
Större tester benämns ofta som integrationstester[57] där flera separata moduler kopplas ihop och testas. Det är alltså själva integrationen av separata system som testas eftersom de indi- viduellt redan blivit testade på enhetstest. För varje ingående enhet finns det ett antal indata som ger upphov till ett antal utdata. När två sådana system sammankopplas kombineras dess relation mellan in- och utdata, och växer därmed exponentiellt. Den totala sökrymden blir mycket större för dessa och kan därmed vara svårare att automatisera.[56]
D.3.3
Acceptanstest
Avsikten med acceptanstest[56] är att säkerställa att produkten går att använda i praktiken och uppfyller de krav som specificerats i kravspecifikationen. Acceptanstest kan delas upp i många olika typer av subtyper, de kan utföras av utvecklare, beställare eller tredje part. Det som är gemensamt är syftet med dem, att verifiera om en del av produkten eller hela produkten uppfyller krav och kan användas.[57]
D.3.4
Kontinuerlig leverans
Ett koncept inom mjukvaruutveckling är kontinuerlig leverans[58]. Vilket innebär att man in- te endast levererar en produkt då den är färdigutvecklad och sedan är klar med projektet, utan har en process där iterationer av produkten levereras till kund. Då produkten levere- ras fångas återkoppling och nya erfarenheter upp för att inkorporeras till nästa iteration av produkten.[57] [58]
D.4. Metod
D.4
Metod
För att ta besvara frågeställningarna utfördes en fallstudie på utvecklingen av frågetävlings- systemet som utvecklades i detta kandidatprojekt. Erfarenhetsfångsten som testansvarig låg till grund för arbetet, tillsammans med testplanen och testrapporterna som producerades un- der projektets gång.
Litteraturstudiedelen av undersökningen har utförts dels genom att använda kurslittera- tur från tidigare kurser, men också webbsökningar via sökmotorerna, google scholar, IEEE xplore med sökorden: Automatisk testning, distans testning, kontinuerlig leverans. Syftet med lit- teraturstudien var att ge stöd till de påståenden som gjordes kring olika testningstermer och för att beskriva användningen och uppbyggnaden bakom dessa metoder. Litteraturstudien användes alltså till att motivera delar av fallstudien som är majoriteten av rapporten.
D.5
Resultat
Här presenteras resultatet som metoden producerade. Först presenteras resultat som rör förs- ta frågeställningen och automatisk testning. Detta underkapitel är en sammanställning av de erfarenheter som fångades upp under utvecklingen. Därefter presenteras resultat rörande testning på plats som sedan ska jämföras med resultatet från testningen som utfördes på di- stans.
D.5.1
Automatisk testning
Automatisk testning användes för att testa att koden som testades kunde installeras och kom- pileras. Det gav upphov vid ett flertal tillfällen till falska negativa resultat. Dessa test misslyc- kades att installera kodpaket och bibliotek som systemet använde sig utav då deras distrubi- tionsmetoder var temporärt otillgängliga. Att dessa test misslyckades berodde alltså inte på system som utvecklats i projektet utan på externa faktorer.
D.5.2
Testning på plats
Under utvecklingen var andra delar av projektet prioriterat högre än testning då typen av projekt inte krävde rigorösa metoder utan kunde fortgå utan officiella tester. De tester som utfördes under första halvan av projektet var ostrukturerade och skedde då en utvecklare ville verifiera om den egna koden fungerade som tänkt. De tester uppstod organiskt och var pragmatiska. Framförallt var det enhetstest och integrationstest på lägre nivå.
D.5.3
Testning på distans
I andra halvan av projektet var behovet för strukturerad testning större och de tester som tidi- gare utförts i samband med utveckling dokumenterades i testrapporter. Enhetstest utfördes fortfaranda utan dokumentation för att effektivisera processen, medan integrationstest och acceptanstest dokumenterades enligt en testmall. Den överväldigande majoriteten av tester blev godkända. Nedan följer ett exempel från testrapportsdokumentet:
D.6. Diskussion
Tabell D.1: Exempel på testrapport
Testnum- mer
Datum Testområde Testare Typ av test Branch
2020-04-29 Frontend, tävlingskör- ning Edwin Forsberg, Evelina Holmgren Integration 50-Adjust- code-to- new-schema Beskrivning
Testa synkronisering mellan användare och domare genom att simulera en tävling.
1. Logga in (/home)
2. Starta tävling (/createSession)
3. Skriv in kod för första användaren i ett separat fönster (/competitorLo- gin)
4. Skriv in kod för andra användaren i ett separat fönster (/competitorLo- gin)
5. Skriv in kod för en domare i ett separat fönster (/competitorLogin) 6. Tryck på knappen “Starta tävling!” i första fönstret (/competitionCodes) 7. Skriv in en textsträng i textfältet för första och andra användaren 8. Verifiera att texten finns i domarvyn
Resultat
Steg 1-6 fungerade som planerat.
Dock så krävdes det att domarvyns sida uppdaterades innan resultatet syntes där. Efter det så fungerade steg 7 och 8 som planerat. GODKÄNT
D.6
Diskussion
Här diskuteras resultatet och metoden som användes för att besvara frågeställningarna.
D.6.1
Metod
Eftersom tester inte utfördes på samma sätt under de två halvorna är det svårare att göra en meningsfull jämförelse. Det finns också en problematik i hur testerna dokumenterades. På grund av detta blir den komparativa delen av studien begränsad till de enhetstest och mindre integrationstest som utfördes i båda halvorna.
D.6.2
Resultat
Här diskuteras resultatet som metoden producerade. Under arbetets gång förändrades ar- betssätt, frågeställningar och metod vilket har påverkat resultatet. Först diskuteras vad resul- tatet kan säga om automatisk testning och vad det gav för konsekvenser i det här projektet. Därefter jämförs hur testning gick till innan och efter utvecklingen gick över till distansläge.
D.6.2.1 Automatisk testning
Omfånget på projektet har begränsat användbarheten för automatiserad testning då den initi- ala tidskostnaden för att skriva automatiserade test har bedömts vara högre än den tiden man
D.7. Slutsatser
skulle ha sparat. De automatiserade testerna som användes i projektet var därför begränsade till att testa om koden kunde installeras och kompileras.
I resultatet var det flera tester som gav falska negativa resultat. Detta var oväntat och var en extra tidskostnad för projektet. Dock gav dessa en rimlig simulering av vilka typer av problem som kan uppstå när en produkt levereras. För att få en värdefull approximation av verkligheten och de situationer som kan uppstå måste förutsättningarna och händelseförlop- pet vara så likt ett faktiskt användarfall som möjligt. I detta är installation och uppdatering inkluderat.
D.6.2.2 Testning på distans och på plats
Skillnaden i testning var relativt liten i de två halvorna av utvecklingen. Test som utfördes på distans hade en mer stabil testmiljö. Där var det alltid samma dator och internetuppkoppling vilket betyder att man bättre kan jämföra test mellan varandra, men också att man täcker in färre av de potentiella situationerna som systemet ska utsättas för. Till exempel skulle vissa typer av problem med synkronisering endast uppstå om man testar på ett system som har en sämre internetuppkoppling.
D.7
Slutsatser
Syftet med detta kapitel var att undersöka och utreda hur testning på distans skiljer sig från testning på plats, samt hur man kan utnyttja automatisk testning i mindre mjukvaruprojekt. Utifrån dessa frågeställningar kommer de slutsatser som drogs presenteras här.