Integrationstest

Integrationstest syftar till att verifiera att systemets moduler fungerar i samverkan. Fr¨amst b¨or m˚alet med dessa test vara att testa gr¨anssnitten mellan moduler f¨or att s¨akerst¨alla att de f¨oljer samma protokoll.

D.3.5

Regressionstest

Under utvecklingen av ett system f¨or¨andras ofta kodbasen ¨over tid. F¨or att uppt¨acka och f¨orebygga situationer d¨ar f¨or¨andringar i en modul, som tidigare ansetts klar, skapar of¨orutsedda problem i en annan del av systemet utf¨ors regressionstest. Regressionstest b¨or utf¨oras kontinuerligt under projektets g˚ang p˚a de delar som anses f¨ardiga f¨or att tidigt hitta nya buggar som smugit sig in.

D.3.6

Systemtest

Systemtest utf¨ors p˚a systemet i sin helhet. De anv¨ands f¨or att verifiera att systemet fungerar korrekt och uppfyller satta krav.

D.4

Metod

F¨or att unders¨oka effektiviteten av enhetstestning i ett agilt projekt har jag samlat in och ana- lyserat mina egna och andras erfarenheter av testning i det h¨ar projektet. Andras erfarenheter har i huvudsak insamlats genom informella intervjuer under projektets g˚ang. Jag har tittat p˚a de testloggar som skrivits och j¨amf¨ort med information fr˚an andra skriftliga k¨allor, vetenskapliga artiklar och erfarenhetsdokument.

Jag vill j¨amf¨ora enhetstest med mer formella och utf¨orliga metoder s˚a som mer utf¨orliga modultest. F¨or att unders¨oka detta har jag genomf¨ort mer ing˚aende test p˚a en utvald del av systemet. Jag har sedan j¨amf¨ort f¨orbrukade resurser och m¨angden funna buggar med en annan del av systemet och analyserat effektiviteten.

Till sist har jag analyserat mina nyvunna erfarenheter och kunskaper och j¨amf¨or med andra testmetoder fr˚an skriftliga k¨allor f¨or att f¨ors¨oka dra en slutsats om vi hade kunnat utf¨ora testandet p˚a ett b¨attre och mer effektivt s¨att i projektet.

D.5

Resultat

I det h¨ar avsnittet redog¨or jag f¨or den data som samlats in under projektets g˚ang.

D.5.1

Arbetss¨att

Under f¨orstudien var planen att vi skulle anv¨anda en agil utvecklingsmetodik i projektet. Vi hade dock problem med att komma ig˚ang med n˚agot organiserat arbetss¨att. F¨or det mesta var det snarare fr˚agan om att n˚agon hade insyn i en modul som denne sedan utvecklade vidare. Det innebar ocks˚a att modultesten, som egentligen borde skrivits av n˚agon annan, skrevs av utvecklaren sj¨alv. Modultesten blev allts˚a mer formella enhetstest.

D.5.2

Testplan

Under f¨orstudien skrev jag en testplan som var baserad p˚a ett agilt arbetss¨att d¨ar vi hade v¨aldigt t¨at kommunikation inom gruppen. Den gick ut p˚a att utvecklaren sj¨alv var ansvarig f¨or att en- hetstesta den kod denne skrev. Dessa enhetstest beh¨ovde inte dokumenteras, ty jag hoppades p˚a att vi skulle f˚a en bra bild av vad som fungerar genom att diskutera systemets status tillsammans. N¨ar v¨al flera moduler b¨orjade f¨ardigst¨allas skulle dessa integrationstestas och systemtestas. Dessa st¨orre test skulle dokumenteras.

I tredje och sista iterationen av projektet hade n¨astan ingenting testats ordentligt varf¨or jag skrev en ny testplan d¨ar alla moduler dessutom skulle genomg˚a modultest som skulle dokumenteras. Detta gjordes i syfte att tvinga gruppen att dokumentera systemets nuvarande status p˚a ett tydligt, formellt s¨att. Samtliga gruppmedlemmar fick lista vad som fungerade, vad som inte fungerade, vad som testats och inte testats. Detta gjorde att vi fick en tydlig bild av systemets status, n˚agot vi hade beh¨ovt tidigare.

D.5.3

Enhetstest

Enhetstestning utf¨ordes under projektet utan att dokumenteras. Informella intervjuer med grup- pens medlemmar g¨or dock klart att inte s¨arskilt mycket tid lades ner p˚a denna typ av test, de utf¨ordes helt och h˚allet direkt i utvecklingsmilj¨on utan n˚agon automation.

N¨ar testplanen skrivits om under den tredje iterationen utf¨ordes mer formella modultest p˚a samtli- ga moduler. Vissa moduler testades mycket mer utf¨orligt ¨an andra. De som testades extra intensivt

var PruHandler och pru_interface. S¨arskild mjukvara designades f¨or PRU:n d¨ar testprogrammet kunde styra PRU:n att skicka olika m¨atdata f¨or att simulera alla m¨ojliga testfall.

D.5.4

Integrationstest

F¨orst integrationstestades modulerna PRU och PruHandler tillsammans. Detta gjordes ganska utf¨orligt, de flesta m¨ojliga testfall testades. Sedan integrationstestades m¨atklienten mot servern. Under detta test uppt¨acktes att det protokoll som anv¨andes mellan dem varken var v¨aldefinierat eller dokumenterat n˚agonstans, det uppstod flera situationer d¨ar de helt enkelt inte f¨oljde samma protokoll.

D˚a de modultest vi utf¨ort inte t¨ackte alla m¨ojliga testfall, uppstod ocks˚a ett antal buggar. Det var tydligt att de moduler som testats mer utf¨orligt (PruHandler, pru_interface, PRU) producerade f¨arre buggar ¨an de som inte testats s˚a utf¨orligt (webbgr¨anssnitt, server, m¨atklient). Detta m¨arktes genom att integrationstest och debug av m¨atklient ↔ server tog oproportionerligt l˚ang tid j¨amf¨ort med motsvarande test p˚a PRU-sidan.

D.5.5

Systemtest

Vi utf¨orde inte n˚agra stora automatiserade systemtest d¨ar alla funktionalitet systematiskt testats. De test som genomf¨orts skedde informellt d¨ar systemet sattes ihop i sin helhet med en eller flera m¨atenheter, b˚ade riktiga BeagleBones med dummy-h˚ardvara och simulerade BeagleBones med p˚ahittad m¨atdata. Vi gick sedan igenom systemets funktionalitet, fr¨amst funktionaliteten som ¨ar tillg¨anglig via webbgr¨anssnittet, och kontrollerade den respons vi fick b˚ade genom att titta p˚a den data som syns i webbgr¨anssnittet och genom att skriva ut debugmeddelanden p˚a server och m¨atenheter.

D.5.6

Effektivitet

Till synes gjorde inte de odokumenterade enhetstesten s¨arskilt mycket f¨or att garantera moduler- nas funktionalitet. De senare modultesten gav ett b¨attre kvitto p˚a vad som fungerade, s¨arskilt de delar p˚a vilka extra tid lades p˚a modul och integrationstest. Att designa automatiska mer utf¨orliga test kostar dock tid. Trots att vi inte anv¨ande n˚agot separat verktyg f¨or modultest, utan skrev dem direkt i Python i form av drivers och stubs, s˚a spenderades 25 arbetstimmar p˚a att testa PruHandlern och dess kommunikation med PRUn. Av dessa 25 timmar ¨ar dock 5 timmar integra- tionstest mot PRU. J¨amf¨or med m¨atklienten f¨or vilken design och utf¨orande av modultest endast tog 12 timmar, men integrationstest och tillkommande debug av kommunikation mot server tog tv˚a personer n¨astan 35 timmar sammanlagt.

D.6

Diskussion

I det h¨ar diskuterar jag min metod och mina resultat.

D.6.1

Resultat

Det ¨ar f¨or mig ganska uppenbart att v˚ar ursprungliga testplan inte fungerade v¨al i v˚art projekt. Ett problem med v˚ar plan var att de f¨orsta test som skulle dokumenteras var integrationstest, vilka ¨ar sv˚ara att genomf¨ora i ett tidigt stadie. Det tog allts˚a l˚ang tid innan test officiellt gjor- des och det var sv˚art att f˚a en tydlig, konkret bild av vilka delar av systemet som faktiskt fungerar. Hade vi haft ett mer strukturerat arbetss¨att ¨ar det m¨ojligt att de ursprungliga enhetstesten hade genomf¨orts mer utf¨orligt och bidragit mer till ett b¨attre system. Erfarenheten fr˚an det h¨ar pro- jektet ¨ar att det i ett tidigt stadie kr¨avs dokumenterade, formella test f¨or att kartl¨agga systemets

status och s¨akerst¨alla att samtliga moduler fungerar som f¨orv¨antat.

En id´e skulle kunna vara att ha en mer test-driven utvecklingsmetod, d¨ar automatiserade mo- dultest skrivs v¨aldigt tidigt. F¨ordelarna med ett s˚adant arbetss¨att ¨ar m˚anga, s¨arskilt i ett st¨orre projekt med m˚anga utvecklare. Dessa automatiserade test kan utf¨oras med j¨amna mellanrum och agera regressionstest n¨ar modulen anses f¨ardig. Projekt- och utvecklingsledare kan f˚a en samman- fattning p˚a vilka testfall som ¨ar godk¨anda och vilka som inte ¨ar det och p˚a s˚a vis f˚a en tydlig bild av vilka delar av systemet som ¨ar f¨ardiga.

Under ett fler˚arigt projekt i USA till¨ampades en v¨aldigt strikt testpolicy, d¨ar systemets samtliga statements skulle testas i en egenbyggd testmilj¨o (Artho & Biere, u. ˚a.). De f¨ordelar de n¨amner innefattar, f¨orutom ¨okat f¨ortroende f¨or systemets funktionalitet, ¨aven saker som b¨attre dokumen- tation av kod och minskat behov av detaljstyrning fr˚an ledningen. B˚ada dessa saker kom av sig sj¨alv d˚a utvecklarna bearbetade koden i samband med utvecklandet och utf¨orandet av test. Jag drar slutsatsen att test inte utf¨ors bara f¨or att f¨ors¨akra sig om systemets kvalitet, utan ¨aven kan verka positivt f¨or projektets struktur i ett st¨orre sammanhang. Detta st¨ammer v¨al ¨overens med de erfarenheter jag haft i detta projekt och talar f¨or att vi hade haft nytta av mer ing˚aende och strukturerad testning.

Problemet med utf¨orliga, automatiska, formella test ¨ar att det tar mycket tid att utveckla dem. Erfarenheter har till exempel visat att det kan ta mer tid ¨an det ¨ar v¨art att automatisera alla enhetstest (Collins & de Lucena Jr., 2012). I v˚art projekt med begr¨ansad tidsbudget var det aldrig aktuellt att anv¨anda en avancerad testmilj¨o och sikta p˚a fullst¨andig t¨ackning. Vi gjorde tillsammans bed¨omningen att vi hellre tar fram ett system med den funktionalitet kund vill ha och bara utf¨or tillr¨ackligt mycket test f¨or att kunna f¨ors¨akra oss om att det fungerar v¨al i de vanligaste situationerna.

D.6.2

Metod

V˚art bristf¨alliga arbetss¨att har haft en negativ inverkan p˚a den h¨ar utredningen. Tanken var att utreda testning speciellt i ett projekt med ett agilt arbetss¨att. M¨angden data som kunnat samlas in ¨ar allts˚a begr¨ansad och den data som har samlats in ¨ar inte n¨odv¨andigtvis representativ f¨or agila projekt.

Det faktum att protokollet mellan server och m¨atklient inte definierades och dokumenterades som det borde, bidrar till att mitt resultat blir skevt d˚a det tog oproportionellt mycket tid att testa och debugga p˚a grund av de m˚anga buggar det orsakade.

F¨or att erh˚alla b¨attre data att dra slutsatser fr˚an, hade det hj¨alpt att ha en b¨attre och tydligare testplan fr˚an b¨orjan. Denna skulle g¨arna ha f¨orklarats och diskuterats mer ing˚aende med resten av projektgruppen redan under f¨orstudien s˚a att hela projektgruppen f¨orst˚ar syftet med dess inneh˚all. Det hade ocks˚a varit f¨ordelaktigt om samtliga test, ¨aven enhetstest, dokumenterades ytterligare i form av hur mycket tid det tog att designa respektive utf¨ora testen och hur m˚anga buggar som upphittades och hur l˚ang tid det tog att fixa dessa. I b¨orjan av projektet gjordes bed¨omningen att insamlandet av alla dessa data skulle haft en negativ inverkan p˚a utf¨orandet av projektet, d˚a utvecklarna hade beh¨ovt l¨agga icke f¨orsumbara m¨angder tid p˚a administration och tidsredovising.

¨

Aven om det inte tar s¨arskilt l˚ang tid att registrera tid s˚a p˚averkas arbetsfl¨odet. Det ¨ar en sak ytterligare att h˚alla koll p˚a och om du m˚aste avbryta ditt arbete f¨or att registrera tid s˚a ¨ar det mer troligt att du gl¨ommer av vad det var du egentligen satt och arbetade med och hur du t¨ankte l¨osa det aktuella problemet.

D.7

Slutsatser

Min utredning visar att ostrukturerade och odokumenterade enhetstest inte garanterar att en mo- dul ¨ar buggfri. F¨or att vara s¨aker p˚a att systemet fungerar som det skall kr¨avs n˚agot mer formell som till exempel n˚agot mer utf¨orliga modultest och integrationstest. Jag gjorde en j¨amf¨orelse mel- lan tv˚a delar av systemet, d¨ar den ena modultestades mer utf¨orligt ¨an den andra. Utfallet blev att integrationstestningen gick avsev¨art snabbare f¨or den del som testats mer utf¨orligt.

Jag har kommit fram till att en test-driven utvecklingsmetodik med automatiserade modultest hade kunnat vara f¨ordelaktigt f¨or v˚art projekt, med nackdelen att det potentiellt hade tagit f¨or mycket tid fr˚an utvecklandet. Utifr˚an tidigare n¨amnda test g¨allande modul- och integrationstest drar jag ocks˚a slutsatsen att mer formella, dokumenterade och utf¨orliga modultest hade haft en positiv inverkan p˚a det slutgiltiga systemet.

E. Sebastian - Implementation av realtidsfunktionalitet

E.1

Inledning

I det h¨ar projektet s˚a var ett huvudfokus att implementera avl¨asning av en sensor som skulle kunna samplas i upp till 1 kHz, med s˚a stabil periodtid p˚a avl¨asningen som m¨ojligt. I den h¨ar delen unders¨oker jag hur man p˚a b¨asta s¨att g¨or det med en BeagleBone Black (h¨adanefter ben¨amnd BBB).

E.1.1

Syfte

Syftet med denna utredning ¨ar att unders¨oka hur man till l¨agst kostnad implementerar en m¨atenhet p˚a BBB.

E.1.2

Fr˚agest¨allning

• Kan BBB:s PRU-k¨arnor anv¨andas f¨or att implementera stabil sampling i 1 kHz?

• Vad finns det f¨or eventuella f¨ordelar och nackdelar med att anv¨anda PRU-k¨arnorna framf¨or att anv¨anda t.ex. extra h˚ardvara som en FPGA eller ett realtidsoperativsystem som RTLi- nux?

E.1.3

Avgr¨ansningar

Jag kommer inte analysera andra alternativ ¨an de tidigare n¨amnda PRU-k¨arnorna, FPGA eller RTLinux. De f˚ar ses som en generell representation av vardera typ av system de motsvarar. D˚a jag inte har m¨ojlighet att g¨ora en full implementation av systemet p˚a varje alternativ s˚a kommer j¨amf¨orelsen mot FPGA och RTLinux endast basera sig p˚a efterforskningar och tidigare erfarenheter.

E.2

Bakgrund

Det befintliga datorsystemet som vi skulle ers¨atta med BBB anv¨ander en FPGA och en relativt avancerad realtidsdator f¨or att l¨asa av sensorn. Detta nuvarande system ¨ar dyrt, stort och klumpigt, d¨arf¨or vill v˚ar kund att vi ska ers¨atta det med enbart en BBB, om m¨ojligt.

E.3

Teori

E.3.1

Tidskritisk kod under normalt operativsystem

En normal modern processor k¨or normalt i ˚atskilliga GHz, ¨aven en mindre processor som den i BBB k¨or p˚a ˚atminstone 1 GHz. Med m¨ojligheten d˚a att utf¨ora miljarder operationer i sekunden s˚a kan det tyckas enkelt att ˚astadkomma sampling i relativt l˚aga 1 kHz, endast tusen g˚anger i sekunden. Problemen kommer dock n¨ar datorn k¨or ett vanligt h¨ogniv˚a-operativsystem, exempelvis Linux. Det ¨ar inte ovanligt att hundratals processer k¨ors samtidigt p˚a en dator, som alla m˚aste dela p˚a processorns tid. Operativsystemet till¨ampar vanligtvis en teknik kallad ”time-slicing”, s˚a att varje process blir tilldelad en kort tidsperiod att k¨oras p˚a processorn och sedan byts till n¨asta process som f˚ar k¨ora. Under operativsystem som Linux och Windows ¨ar det vanligt att processer kan bli tilldelade slices p˚a ˚atskilliga millisekunder. Att d˚a f˚a en samplande process att k¨oras varje millisekund (1 kHz), ¨aven om varje sampling tar upp mycket kort tid, blir n¨astintill om¨ojligt d˚a operativsystemet inte l¨amnar n˚agra garantier p˚a n¨ar processen f˚ar k¨oras n¨asta g˚ang. (Silberschatz, Galvin & Gagne, 2014)