Syklomatisk kompleksitet i programvaretesting med eksempel

โšก Smart oppsummering

Cyclomatic Complexity er en programvaremetrikk utviklet av Thomas McCabe i 1976 som teller de uavhengige banene gjennom et program. Den beregnes fra en kontrollflytgraf og gir antall testtilfeller som kreves for full grendekning.

  • ๐Ÿ“ To formler: V(G) = E โ€“ N + 2 fra grafen, eller V(G) = P + 1 fra antallet beslutningspunkter.
  • ๐Ÿงฎ Direkte betydning: Verdien er lik det maksimale antallet uavhengige stier, og dermed antall testtilfeller som trengs.
  • ๐Ÿ—บ๏ธ Grafgrunnlag: Noder representerer behandlingstrinn, og kanter representerer kontrollflyten mellom dem.
  • ๐ŸŸข 1 til 10: Strukturert, velskrevet kode med hรธy testbarhet og lave vedlikeholdskostnader.
  • ๐ŸŸ  21 til 40: Svรฆrt kompleks kode med lav testbarhet, hvor refaktorering vanligvis koster mindre enn testing.
  • ๐Ÿ› ๏ธ verktรธy: SonarQube, Visual Studio Code Mรฅlinger, radon og Lizard beregner det automatisk.

Syklomatisk kompleksitet i programvaretesting

Hva er McCabes syklomatiske kompleksitet?

Syklomatisk kompleksitet i programvaretesting er en testmรฅling som brukes for รฅ mรฅle kompleksiteten til et program. Det er et kvantitativt mรฅl pรฅ uavhengige stier i kildekoden til et program. Syklomatisk kompleksitet kan beregnes ved รฅ bruke kontrollflytgrafer eller med hensyn til funksjoner, moduler, metoder eller klasser i et programvareprogram.

Uavhengig bane er definert som en bane som har minst รฉn kant som ikke har blitt krysset fรธr i noen andre baner.

Denne metrikken ble utviklet av Thomas J. McCabe i 1976, og den er basert pรฅ en kontrollflytrepresentasjon av programmet. Kontrollflyt viser et program som en graf som bestรฅr av noder og kanter.

I grafen representerer noder behandlingsoppgaver mens kanter representerer kontrollflyt mellom nodene.

McCabes syklomatiske kompleksitet

Flytgrafnotasjon for et program

Flow Graph-notasjon for et program definerer flere noder koblet gjennom kantene. Nedenfor er flytdiagrammer for utsagn som if-else, While, until og normal sekvens av flyt.

Flytgrafnotasjon for et program

Hvordan beregne syklomatisk kompleksitet

Matematisk representasjon:

Matematisk sett er det et sett med uavhengige baner gjennom grafdiagrammet. Code Programmets kompleksitet kan defineres ved hjelp av formelen โ€“

V(G) = E - N + 2

Hvor,

E โ€“ Antall kanter

N โ€“ Antall noder

V (G) = P + 1

Hvor P = Antall predikatnoder (node โ€‹โ€‹som inneholder betingelse)

Eksempel -

i = 0;
n=4; //N-Number of nodes present in the graph

while (i<n-1) do
j = i + 1;

while (j<n) do

if A[i]<A[j] then
swap(A[i], A[j]);

end do;
j=j+1;

end do;

Flytdiagram for dette programmet vil vรฆre

Beregn syklomatisk kompleksitet

Beregning matematisk,

  • V(G) = 9 โ€“ 7 + 2 = 4
  • V(G) = 3 + 1 = 4 (Tilstandsnoder er 1,2 og 3 noder)

Basissett, de fire uavhengige utfรธrelsesstiene:

  • 1, 7
  • 1, 2, 6, 1, 7
  • 1, 2, 3, 4, 5, 2, 6, 1, 7
  • 1, 2, 3, 5, 2, 6, 1, 7

Egenskaper ved syklomatisk kompleksitet

Fรธlgende er egenskapene til syklomatisk kompleksitet:

  1. V (G) er det maksimale antallet uavhengige baner i grafen
  2. V (G) >=1
  3. G vil ha รฉn bane hvis V (G) = 1
  4. En vanlig retningslinje er รฅ holde V(G) pรฅ 10 eller lavere for en enkelt modul.

Hvordan denne metrikken er nyttig for programvaretesting

Basis Path-testing er en av hvitboksteknikkene, og den garanterer รฅ utfรธre minst รฉn setning under testing. Den sjekker hver lineรฆrt uavhengige bane gjennom programmet, noe som betyr at Antall nรธdvendige testtilfeller tilsvarer programmets syklomatiske kompleksitet.

Denne beregningen er nyttig pรฅ grunn av egenskapene til syklomatisk kompleksitet (M) -

  1. M kan vรฆre antall testtilfeller for รฅ oppnรฅ grendekning (รธvre grense)
  2. M kan vรฆre antall baner gjennom grafene. (nedre grense)

Tenk pรฅ dette eksemplet -

If (Condition 1)
Statement 1

Else
Statement 2

If (Condition 2)
Statement 3

Else
Statement 4

Syklomatisk kompleksitet for dette programmet vil vรฆre 8-7+2=3.

Siden kompleksiteten har beregnet som 3, er tre testtilfeller nรธdvendige for รฅ fullfรธre banedekningen for eksemplet ovenfor.

Trinn som skal fรธlges

Fรธlgende trinn bรธr fรธlges for beregning av syklomatisk kompleksitet og design av testtilfeller.

Trinn 1 โ€“ Konstruksjon av graf med noder og kanter fra koden

Trinn 2 โ€“ Identifisering av uavhengige veier

Trinn 3 โ€“ Beregning av syklomatisk kompleksitet

Trinn 4 โ€“ Design av testcaser

Nรฅr det grunnleggende settet er dannet, TESTKASSER skal skrives for รฅ utfรธre alle banene.

Mer om V (G)

Syklomatisk kompleksitet kan beregnes manuelt hvis programmet er lite. Automatiserte verktรธy mรฅ brukes hvis programmet er veldig komplekst da dette innebรฆrer flere flytgrafer. Basert pรฅ kompleksitetstall kan teamet konkludere om handlingene som mรฅ tas for รฅ mรฅle.

Tabellen nedenfor gir en oversikt over kompleksitetstallet og den tilhรธrende betydningen av v (G):

kompleksitetsnummer Betydning
1 til 10

Strukturert og velskrevet kode

Hรธy testbarhet

Kostnad og innsats er mindre

11 til 20

Kompleks kode

Middels testbarhet

Kostnad og innsats er middels

21 til 40

Svรฆrt kompleks kode

Lav testbarhet

Kostnadene og innsatsen er hรธy

> 40

Ikke testbar i det hele tatt

Svรฆrt hรธye kostnader og innsats

Verktรธy for beregning av syklomatisk kompleksitet

Mange verktรธy er tilgjengelige for รฅ bestemme kompleksiteten til applikasjonen. Noen kompleksitetsberegningsverktรธy brukes for spesifikke teknologier. Kompleksiteten kan bli funnet ved antall beslutningspunkter i et program. Beslutningspunktene er if, for, for-each, while, do, catch, saksuttalelser i en kildekode.

Eksempler pรฅ verktรธy er

  • OCLint โ€“ Statisk kodeanalysator for C og relaterte sprรฅk
  • SonarQube โ€“ Rapporterer syklomatisk og kognitiv kompleksitet pรฅ tvers av mer enn 25 sprรฅk
  • Visual Studio Code Mรฅlinger โ€“ Innebygd syklomatisk kompleksitetsanalyse for .NET-samlinger
  • Radon og Lizard โ€“ Kommandolinjekompleksitetsanalysatorer for Python og for henholdsvis flersprรฅklige prosjekter
  • Gmetrikk โ€“ Finn beregninger i Java relaterte applikasjoner

Bruk av syklomatisk kompleksitet

Syklomatisk kompleksitet kan vise seg รฅ vรฆre svรฆrt nyttig i

  • Hjelper utviklere og testere med รฅ bestemme uavhengige banekjรธringer
  • Utviklere kan forsikre seg om at alle stiene har blitt testet minst รฉn gang
  • Hjelper oss รฅ fokusere mer pรฅ de avdekkede stiene
  • Forbedre kodedekningen i Engineering programvare
  • Vurder risikoen forbundet med applikasjonen eller programmet
  • Bruk av disse beregningene tidlig i syklusen reduserer mer risiko for programmet

Hvordan redusere syklomatisk kompleksitet

Et hรธyt kompleksitetstall er et signal, ikke en dom. Fire refaktoreringer stรฅr for mesteparten av reduksjonen som er oppnรฅelig i praksis.

  • Extract-metoden. ร… flytte en gren til sin egen funksjon deler kompleksiteten mellom to moduler. Totalen pรฅ tvers av systemet er uendret, men hver enhet blir uavhengig testbar.
  • Erstatt en betinget kjede med et oppslag. En lang hvis-ellers-hvis-stige som tester den samme variabelen blir et kart eller en bryter, som kollapser mange beslutningspunkter til ett.
  • Bruk vaktklausuler. Tidlig retur av ugyldig input fjerner nestinget som en enkelt stor if-else-blokk oppretter, uten รฅ endre oppfรธrsel.
  • Erstatt kondisjonalis med polymorfisme. Der en betinget type aktiveres, fjerner det รฅ flytte hver gren til sin egen klasse avgjรธrelsen fullstendig.

Fรธr, med V(G) = 4:

if (user != null) {
    if (user.isActive()) {
        if (user.hasRole("admin")) {
            return grantAccess();
        }
    }
}
return denyAccess();

Etter, med samme oppfรธrsel og nestingen fjernet:

if (user == null) return denyAccess();
if (!user.isActive()) return denyAccess();
if (!user.hasRole("admin")) return denyAccess();
return grantAccess();

En advarsel om metrikken. Syklomatisk kompleksitet teller avgjรธrelser, ikke vanskelighetsgrad. En switch-setning med tjue enkle tilfeller gir en score pรฅ 21, men er lett รฅ lese, mens en dypt nestet blokk som gir en score pรฅ 8 kan vรฆre langt vanskeligere รฅ forstรฅ. Bruk tallet til รฅ finne kandidater for gjennomgang, ikke som et mรฅl รฅ bli lurt pรฅ.

Spรธrsmรฅl og svar

Ti eller fรฆrre per modul er den vanlige retningslinjen. Mellom 11 og 20 er koden kompleks, men hรฅndterbar. Over 20 faller testbarheten kraftig, og over 40 anses modulen generelt som utestbar slik den er skrevet.

Begge gir samme resultat. P + 1 er raskere for manuell beregning fordi du bare teller beslutningspunkter. E โ€“ N + 2 er det verktรธyene bruker, siden de allerede bygger kontrollflytgrafen.

Ikke nรธdvendigvis. Syklomatisk kompleksitet teller beslutninger snarere enn vanskelighetsgrad, sรฅ en flat bryter med tjue enkle tilfeller scorer hรธyt samtidig som den er lett รฅ lese. Behandle tallet som en oppfordring til repetisjon.

De kombinerer det med endringsfrekvens og feilhistorikk for รฅ rangere hvilke moduler som bรฆrer stรธrst risiko, og retter gjennomgang og testinnsats mot koden som har stรธrst sannsynlighet for รฅ mislykkes.

Ja. AI-assistenter foreslรฅr vaktklausuler, f.eks.tracted-metoder og oppslagstabeller som reduserer antallet. Bekreft oppfรธrselen med den eksisterende testsuiten, fordi en refaktorering som endrer logikken motvirker formรฅlet.

Oppsummer dette innlegget med: