Automatiserad test i en CI/CD pipeline - Statisk kodanalys

Den första nivån av automatiserade tester i en CI/CD pipeline är ofta statisk kodanalys. Statisk analys av mjukvara utförs utan att egentligen exekvera koden, i motsats till dynamisk analys, som är analys som utförs då mjukvaran körs.

Man använder verktyg som skannar och analyserar källkoden, vilket är ett effektivt sätt att hitta defekter i koden och visualisera dem för programmeraren. På det här viset kan defekter fångas upp tidigt, långt innan de hamnar i systemet och orsakar förödelse när koden byggs och produktionssätts.

Detta är den andra artikel i en artikelserie med fyra delar som beskriver hur man kan införa en automatiserad test-pipeline och fokusera på de aktiviteter som kan göras så tidigt som möjligt i implementationsarbetet.

Statisk analys anses vara det mest grundliga sättet att analysera kod och kan också vara det mest kostnadseffektiva sättet att testa. Att identifiera defekter tidigt innebär att de är billigare att fixa än fel hittas senare i det färdiga systemet.

Moderna verktyg för statisk analys klarar inte bara mängder av olika programmeringsspråk och att hitta mängder av olika programmeringsfel utan kan analysera och sammanställa information om flera olika aspekter som i följande exempel.

Reliability

Under den här kategorin hamnar rena programmeringsfel och andra direkta nackdelar med koden som dålig felhantering, undantagshantering och funktionalitet som är deprecated. Verktyget föreslår ofta lösningar och konkreta anvisningar för hur problem åtgärdas.

Clean code

Verktyget kan också varna för kod som egentligen fungerar som den ska men innehåller så kallade code smells (se tidigare artikel om Clean Code). Den här typen av nackdelar med koden påverkar läsbarheten och underhållbarheten. Ofta räknar verktyget ut en kostnad för den tekniska skuld den här typen av dålig kod innebär (uttryckt i timmar eller dagar det kostar att åtgärda).

Med ren kod spenderar utvecklare mindre tid på att lista ut hur saker fungerar och mer tid på att skriva bra kod som löser problem!

Security

Via statisk analys kan man också upptäcka säkerhetsrelaterade sårbarheter. Säkerhetsproblem kräver omedelbar åtgärd och verktygen tillhandahåller även här detaljerade beskrivningar och förklarar varför koden är en säkerhetsfara.

I applikationssäkerhetsbranschen används också namnet Static Application Security Testing (SAST). SAST är en viktig del av Security Development Lifecycle (SDL) såsom SDL definieras av Microsoft och är en vanlig praxis i mjukvarubranchen.

Code Coverage

Många verktyg för statisk kodanalys har även funktionalitet för att samla in och rapportera kodtäckning. Detta för att visualisera hur stor del av kodmängden som alla körda tester har täckt.

Code coverage (kodtäckning eller täckningsgrad) är ett viktigt mått på hur vältestad en viss kodbas är.

Duplicated Lines

Duplicerad kod är en sekvens av källkod som förekommer mer än en gång, antingen inom samma modul eller över olika moduler som ägs eller underhålls av samma enhet. Duplicerad kod är i allmänhet oönskad av ett antal skäl.

Rating

Ett pedagogiskt sätt att presentera de olika aspekter av kodbasen som ett verktyg för statisk analys hittar och sammanställer är ratings. Detta ger en överskådlig bild av hur kodbasen mår med avseende på buggar, säkerhet, underhållbarhet, m.m. Ratingen kan antingen presenteras i form av färg (grön, gul eller röd) eller betyg (A, B, C, osv.).

Quality Bars

Genom att tillämpa en Quality Bars (en viss nivå som koden måste vara bättre än) säkerställs att nya funktioner levereras med en viss grundkvalité. Det går exempelvis att förhindra utvecklare att leverera/checka in kod som inte uppfyller kravet grön (eller A) på buggar. Det betyder att det finns en eller flera kända defekter i koden. Det går att definiera Quality Bars (ibland även kallat Quality Gate) med avseende på olika aspekter av koden, så som kodtäckning, duplicerad kod, säkerhet, underhållbarhet, m.m.

Målet med Quality Bars är att se till att varje levererad/in checkad version är bättre än den förra.

Sammanfattning

Även om den första nivån av automatiserade tester i en CI/CD pipeline är statisk kodanalys och detta är ett effektivt sätt att tidigt identifiera defekter i koden så är kanske den största fördelen pedagogisk:

Statisk analys tränar organisationen till att hålla hög standard på koden. Feedback som verktyget ger föreslår förbättringar och tränar organisationen till att bli bättre. Programmerare följer anvisningar, ändrar sin kod, lär sig och blir kontinuerligt bättre.

Vill du veta mer om hur du kan leverera bättre produkter snabbare till kund, med både lägre kostnad och lägre risk. Då tycker jag att du ska titta på vårt webinar där jag pratar om det kontinuerliga arbetssättet som inkluderar CI, CD och CQA (Continuous Quality Assurance) och att det snart kommer vara nästintill ett måste för organisationer att gå åt det hållet. Speciellt om du jobbar med mjukvaruutveckling av produkter som ska gå till en slutanvändare.

webinar on-demand: kontinuerlig transformation

Alla blogginlägg

Vi rekommenderar också