Effektanalyse i programvaretesting
Charles Moore
⚡ Smart oppsummering
Konsekvensanalyse i programvaretesting evaluerer hvordan en foreslått endring påvirker krav, design, kode, tester og leveringsplanen.ping Team estimerer innsats, prioriterer regresjonsdekning og forhindrer utilsiktede feil før utgivelse.
Hva er effektanalyse?
Konsekvensanalyse er prosessen med å analysere virkningen av endringer gjort i et distribuert produkt eller en applikasjon. Den identifiserer områdene i systemet som kan bli påvirket når en bestemt del eller funksjon i applikasjonen endres.
Effekten vurderes på tvers av Krav, Design og ArchiTekstur, test og leveringsplan.
Når nye funksjoner legges til i en applikasjon eller et produkt, er det viktig å sjekke hvordan disse endringene vil påvirke systemets ytelse og stabilitet. Impact Analysis utføres av denne grunn.
Hvorfor utføres endringskonsekvensanalyse?
- For å forstå det mulige resultatet av å implementere endringen. Å legge til for mye funksjonalitet i et produkt kan redusere den generelle ytelsen.
- Å identifisere alle filer, dokumenter og modeller som kanskje må endres hvis teamet bestemmer seg for å implementere endringen.
- Å beregne innsatsen som kreves for å implementere endringen.
- Å identifisere oppgavene som kreves for å implementere endringen.
- For å liste opp avhengighetene til det spesifikke elementet som endres.
Hva er et konsekvensanalysedokument?
Et dokument med konsekvensanalyse kan brukes som en sjekkliste for å evaluere en endringsforespørsel før teamet begynner å jobbe med den. Dokumentet bør fange opp detaljer som:
- En kort beskrivelse av problemet.
- En forklaring eller et eksempel på hvordan feilen forårsaker feil eller ineffektivitet.
- Et estimat av kompleksitet.
- Et estimat av kostnad og tid for reparasjonen.
- Funksjonaliteten som skal testes.
- De nye testtilfellene som ble opprettet for endringen.
- Referansedokumenter som teknisk spesifikasjon eller relaterte designnotater.
Eksempel:
Konsekvensanalysedokument.
- Endre forespørsels-ID:
- Tittel:
- Description:
- Dato utarbeidet:
- Prioriteringsestimat:
- Relativ fordel
- Relativ straff
- Relativ kostnad
- Relativ risiko
- Estimert total innsats: ______ timer
- Estimert tapt innsats: ______ timer
- Beregnet innvirkning på tidsplanen: ______ dager
- Kvalitet påvirket:
- Andre krav som berøres:
- Andre berørte oppgaver:
- Integreringsproblemer:
Hvordan presentere påvirkningsnivået for konsekvensanalysen
Konsekvensanalyse kan representeres med en fargekode som viser hvor kritiske endringene er på systemet. En vanlig fargekode vises nedenfor:
- Rød – Sterk innvirkning
- Gul – Moderat innvirkning
- Grønn — Svak innvirkning
Tabellen ovenfor forklarer virkningen av de implementerte endringene:
- Funksjoner markert med rødt er hovedfunksjonene som endres. Funksjoner markert med gult påvirkes mindre av endringen. Funksjoner markert med grønt påvirkes minst.
- Funksjoner som er oppført vertikalt er de som endres. Funksjoner som er oppført horisontalt er de som endringen kan påvirke. I eksemplet ovenfor påvirker en endring i funksjon 1 funksjon 3.
- I et større prosjekt der det er mange funksjoner og funksjonaliteter, er tabellen ovenfor kanskje ikke praktisk. I så fall benyttes en annen tilnærming der utvikleren direkte markerer påvirkningsnivået forårsaket av endringene i hovedfunksjonene, som vist nedenfor, der virkningen av hovedfunksjonen er markert mot hver underfunksjon.
Eksempelspørsmål å ta opp når du utfører konsekvensanalyse:
- Hva er de negative bivirkningene eller risikoene ved å gjøre den foreslåtte endringen?
- Trenger man å anskaffe noe nytt verktøy for å implementere og teste endringen?
- Hvis endringen blir akseptert, hvor mye av den allerede investerte innsatsen vil gå tapt?
- Påvirker de foreslåtte endringene ytelseskravene negativt?
- Kreves det ytterligere brukerinndata for å bekrefte den foreslåtte endringen?
- Øker endringen produktkostnadene?
- Har de nåværende ansatte kunnskapen og ferdighetene til å gjennomføre den foreslåtte endringen?
- Stiller den foreslåtte endringen noe uakseptabelt krav til en datamaskinressurs?
Beste praksis for analyse av endringseffekter
- Før du starter konsekvensanalysen, må du sørge for at testforespørselen identifiserer alle deler av prosjektet som påvirkes av endringene.
- Kontinuerlig kommunikasjon mellom utvikler og tester er et must, slik at ingen nødvendige endringer i det endelige produktet blir oversett.
- Identifiser om det er behov for endringer, slettinger eller tillegg i brukergrensesnittet.
- Estimer antallet aksept-, system- og integrasjonstesttilfeller som vil være nødvendige.
- Identifiser eventuelle konsekvenser av den foreslåtte endringen for prosjektplanen, konfigurasjonsplanen eller kvalitetssikringsplanen.
Typer av konsekvensanalyse i programvaretesting
Analyse av endringseffekter er ikke én enkelt teknikk. Utøvere bruker vanligvis én av tre komplementære typer for å svare på ulike spørsmål om en foreslått endring.
- TracAnalyse av bærekraftspåvirkning: Bruker kravene TracEability Matrise og designkoblinger for å kartlegge alle krav til modulene, testene og dokumentene som implementerer det. Når et krav endres, avslører matrisen alle nedstrøms artefakter som må oppdateres eller testes på nytt.
- Analyse av avhengighetspåvirkning: Studerer anropsgrafene, dataflytene og grensesnittkonfigurasjonentracts inne i kodebasen. En endring i én modul er tracgjennom direkte innringere, indirekte innringere og delte datastrukturer, slik at skjulte ringvirkninger avdekkes før endringen sendes.
- Eksperimentell (historisk) konsekvensanalyse: Ser på historiske endringsdata – tidligere defekter, mislykkede sprinter og regresjonsutslipninger – for å forutsi hvordan den nåværende endringen vil oppføre seg. Moderne verktøy kombinerer utvinning av versjonskontrollhistorikk med statistiske modeller eller maskinlæringsmodeller for å vurdere risikoen for hver endring.
De fleste lag kombinerer minst to av disse typene. Traceability forteller deg hvilke dokumenter som er berørt, avhengighetsanalyse forteller deg hvilken kode som er berørt, og historisk analyse forteller deg hvor risikabel endringen sannsynligvis vil være.
Populære verktøy for analyse av endringseffekter
Moderne endringskonsekvensanalyse gjøres sjelden i et regneark. Team kobler et kravstyringsverktøy med et kodeanalyseverktøy og et teststyringsverktøy som deler en felles tracevneryggraden.
- Jama Connect, IBM DØRER, Modern Requirements, og krav til synlighet: Registrer krav, vedlikehold grunnlinjer og generer konsekvensrapporter på tvers av tilknyttede krav, tester og risikoer når en endring foreslås.
- Atlassian Jira med Xray eller Zephyr: Track brukerhistorier, defekter og testtilfeller. Effektrapporter viser alle historier og tester som en foreslått endring berører i en sprint eller et utgivelsestog.
- SonarQube, Forstå med SciTools og Structure101: Analyser kildekodeavhengigheter og lag kallegrafer og koblingsrapporter slik at ingeniøren kan se nedstrømskode påvirket av en endring.
- Lanseringsbar, Testim Automatisk helbredelse, og TestGrid: Bruk maskinlæring til å forutsi hvilke tester som mest sannsynlig vil fange opp feil introdusert av en endring, noe som muliggjør smart testvalg og raskere regresjonssykluser.
- Microsoft Excel eller Google ark: Fortsatt mye brukt for det innledende konsekvensanalysedokumentet, fargekodet påvirkningstabell og endringsforespørselslogg på mindre prosjekter.
Den riktige kombinasjonen avhenger av størrelsen på kodebasen, det regulatoriske miljøet og leveringsmetoden. Regulerte bransjer bruker Jama eller DOORS for reviderbare data. traceffektivitet, mens smidige produktteam er avhengige av Jira, SonarQube, og et verktøy for testpåvirkning.
