Testing – hvem trenger det og hvorfor? Teknologisk testprosess.

Programvaretesting identifiserer feil, feil og feil i koden som må elimineres. Det kan også defineres som evalueringsprosessen funksjonalitet og programvareriktighet gjennom analyse. Hovedmetodene for integrasjon og testing av programvareprodukter sikrer kvaliteten på applikasjonene og består i å sjekke spesifikasjon, design og kode, vurdere pålitelighet, validering og verifikasjon.

Metoder

Hovedmålet med programvaretesting er å bekrefte kvalitet Software pakke ved systematisk å feilsøke applikasjoner under nøye kontrollerte forhold, fastslå deres fullstendighet og korrekthet, og oppdage skjulte feil.

Metoder kan deles inn i statiske og dynamiske.

Førstnevnte inkluderer uformell, kontroll og teknisk gjennomgang, inspeksjon, gjennomgang, revisjon og statisk analyse av dataflyt og kontroll.

De dynamiske teknikkene er som følger:

Hvit boks testing. Dette er en detaljert studie av den interne logikken og strukturen til et program. Dette krever kunnskap om kildekoden.
Black box testing. Denne teknikken krever ingen kunnskap om den interne funksjonen til applikasjonen. Bare de viktigste aspektene ved systemet som ikke er relatert eller har liten sammenheng med dets interne logiske struktur, vurderes.
Gråboksmetoden. Kombinerer de to foregående tilnærmingene. Feilsøking med begrenset kunnskap om applikasjonens interne funksjon kombineres med kunnskap om de grunnleggende aspektene ved systemet.

Transparent testing

White box-metoden bruker testskript for å kontrollere strukturen til en prosedyredesign. Denne teknikken lar deg identifisere implementeringsfeil, for eksempel dårlig kodeadministrasjon, ved å analysere den interne funksjonen til et stykke programvare. Disse testmetodene er anvendelige på integrasjons-, modul- og systemnivå. Testeren må ha tilgang til kildekoden og ved å bruke den finne ut hvilken blokk som oppfører seg upassende.

White box-testing av programmer har følgende fordeler:

lar deg identifisere feil i skjult kode når du fjerner ekstra linjer;
mulighet for bivirkninger;
maksimal dekning oppnås ved å skrive et testskript.

Feil:

en svært kostbar prosess som krever en kvalifisert debugger;
mange stier vil forbli uutforsket, siden en grundig sjekk av alle mulige skjulte feil er svært vanskelig;
noe av den manglende koden vil gå ubemerket hen.

White box testing kalles noen ganger også transparent eller transparent testing. åpen boks, strukturell, logisk testing, testing basert på kildetekster, arkitektur og logikk.

Hovedvarianter:

1) flytkontrolltesting - en strukturert strategi som bruker programkontrollflyt som modell og prioriterer mer enkle måter før et mindre antall mer komplekse;

2) grenfeilsøking tar sikte på å undersøke hvert alternativ (sant eller usant) for hver kontrollsetning, som også inkluderer den kombinerte beslutningen;

3) grunnleggende banetesting, som lar testeren etablere et mål på den logiske kompleksiteten til en prosedyredesign for å identifisere et grunnleggende sett med utførelsesbaner;

4) dataflytkontroll - en strategi for å undersøke kontrollflyt ved å kommentere grafen med informasjon om deklarasjon og bruk av programvariabler;

5) syklustesting - helt fokusert på riktig utførelse av sykliske prosedyrer.

Behavioral debugging

Black box-testing behandler programvare som en "black box" - informasjon om den interne funksjonen til programmet tas ikke i betraktning, og bare hovedaspektene ved systemet testes. I dette tilfellet må testeren kjenne systemarkitekturen uten tilgang til kildekoden.

Fordeler med denne tilnærmingen:

effektivitet for et stort kodesegment;
enkel oppfatning av testeren;
Brukerens perspektiv er tydelig atskilt fra utviklerens perspektiv (programmerer og tester er uavhengige av hverandre);
raskere testoppretting.

Å teste programmer ved hjelp av black box-metoder har følgende ulemper:

i virkeligheten blir et utvalgt antall testtilfeller utført, noe som resulterer i begrenset dekning;
mangelen på en klar spesifikasjon gjør det vanskelig å utvikle testcases;
lav effektivitet.

Andre navn for denne teknikken er atferdstesting, ugjennomsiktig testing, funksjonell testing og lukket boks-feilsøking.

1) ekvivalent partisjonering, som kan redusere testdatasettet, siden inngangsdataene til programvaremodulen er delt inn i separate deler;

2) kantanalyse fokuserer på å teste grenser eller ekstreme grenseverdier - minimum, maksimum, feil og typiske verdier;

3) fuzzing - brukes til å søke etter implementeringsfeil ved å legge inn forvrengte eller semi-forvrengte data i automatisk eller halvautomatisk modus;

4) grafer over årsak-virkningsforhold - en teknikk basert på å lage grafer og etablere en sammenheng mellom en handling og dens årsaker: identitet, negasjon, logisk ELLER og logisk OG - fire grunnleggende symboler som uttrykker den gjensidige avhengigheten mellom årsak og virkning;

5) testing av ortogonale arrays, brukt på problemer med et relativt lite inngangsområde som overgår mulighetene til en uttømmende studie;

6) testing av alle par - en teknikk hvis sett med testverdier inkluderer alle mulige diskrete kombinasjoner av hvert par inngangsparametere;

Black Box-testing: Eksempler

Teknikken er basert på spesifikasjoner, dokumentasjon og beskrivelser av programvaren eller systemgrensesnittet. I tillegg er det mulig å bruke modeller (formelle eller uformelle) som representerer den forventede oppførselen til programvaren.

Denne feilsøkingsmetoden brukes vanligvis for brukergrensesnitt og krever interaksjon med applikasjonen ved å legge inn data og samle resultater – fra skjermen, fra rapporter eller utskrifter.

Testeren samhandler dermed med programvaren gjennom inngang, betjeningsbrytere, knapper eller andre grensesnitt. Valget av inngangsdata, rekkefølgen de legges inn i, eller rekkefølgen av handlinger kan føre til et gigantisk totalt antall kombinasjoner, som kan sees i følgende eksempel.

Hvor mange tester må utføres for å sjekke alle mulige verdier for 4 avmerkingsbokser og ett toposisjonsfelt som spesifiserer tiden i sekunder? Ved første øyekast er beregningen enkel: 4 felt med to mulige tilstander - 24 = 16, som må multipliseres med antall mulige posisjoner fra 00 til 99, det vil si 1600 mulige tester.

Imidlertid er denne beregningen mangelfull: vi kan definere at et toposisjonsfelt også kan inneholde et mellomrom, dvs. det består av to alfanumeriske posisjoner og kan inkludere alfabetiske tegn, spesialtegn, mellomrom osv. Hvis systemet er en 16. -bit datamaskin, det er 216 = 65 536 alternativer for hver posisjon, noe som resulterer i 4 294 967 296 testtilfeller, som må multipliseres med 16 kombinasjoner for flaggene, noe som gir totalt 68 719 476 736. med en hastighet på 1 test per sekund, den totale testvarigheten blir 2.177,5 år. For 32- eller 64-bits systemer er varigheten enda lengre.

Derfor er det behov for å redusere denne perioden til en akseptabel verdi. Teknikker må derfor brukes for å redusere antall testtilfeller uten å redusere testdekningen.

Tilsvarende partisjon

Ekvivalent partisjonering er en enkel teknikk som kan brukes for enhver variabel som finnes i programvaren, det være seg inngangs- eller utdataverdier, symbolske, numeriske osv. Den er basert på prinsippet om at alle data fra samme ekvivalente partisjon vil bli behandlet på samme måte og etter de samme instruksjonene.

Under testingen velges én representant fra hver definert ekvivalent partisjon. Dette lar deg systematisk redusere antall mulige testtilfeller uten å miste kommando- og funksjonsdekning.

En annen konsekvens av denne partisjonen er reduksjonen av kombinatorisk eksplosjon mellom ulike variabler og den tilhørende reduksjonen av testtilfeller.

For eksempel, i (1/x)1/2 brukes tre datasekvenser, tre ekvivalente partisjoner:

1. Alle positive tall vil bli behandlet på samme måte og skal gi korrekte resultater.

2. Alle negative tall vil bli behandlet på samme måte, med samme resultat. Dette er feil fordi roten til et negativt tall er imaginær.

3. Null vil bli behandlet separat og vil gi en divisjon med null feil. Dette er en enkelt betydningsdel.

Så vi ser tre forskjellige seksjoner, hvorav den ene koker ned til en enkelt betydning. Det er en "riktig" del, som gir pålitelige resultater, og to "feil" med feil resultater.

Regional analyse

Databehandling ved tilsvarende partisjonsgrenser kan utføres annerledes enn forventet. Grenseverdistudier er en velkjent måte å analysere programvareatferd på i slike områder. Denne teknikken lar deg identifisere følgende feil:

feil bruk av relasjonsoperatorer (<,>, =, ≠, ≥, ≤);
enkeltfeil;
problemer med looper og iterasjoner,
feil typer eller størrelser av variabler som brukes til å lagre informasjon;
kunstige restriksjoner knyttet til data og variabeltyper.

Gjennomsiktig testing

Gråboksmetoden øker dekningen av revisjonen, slik at du kan fokusere på alle nivåer komplekst system ved å kombinere hvite og svarte metoder.

Ved bruk av denne teknikken skal testeren ha kunnskap om indre strukturer data og algoritmer. Eksempler på testteknikker for grå bokser er:

arkitektonisk modell;
Unified Modeling Language (UML);
tilstandsmodell (finite state machine).

I gråboksmetoden studeres kodene til modulene ved hjelp av den hvite teknikken for å utvikle testcases, og selve testingen utføres på programgrensesnittene ved hjelp av den svarte teknikken.

Slike testmetoder har følgende fordeler:

kombinere fordelene med hvite og svarte boksteknikker;
testeren er avhengig av grensesnittet og funksjonsspesifikasjonen i stedet for kildekoden;
feilsøkeren kan lage utmerkede testskript;
verifisering utføres fra brukerens synspunkt, ikke programdesigneren;
opprettelse av tilpassede testutviklinger;
objektivitet.

Feil:

testdekningen er begrenset på grunn av manglende tilgang til kildekoden;
problemer med å oppdage defekter i distribuerte applikasjoner;
mange stier forblir uutforskede;
hvis programvareutvikleren allerede har kjørt testen, kan ytterligere undersøkelser være overflødige.

Et annet navn for gråboksteknikken er gjennomskinnelig feilsøking.

1) ortogonal matrise - ved å bruke en delmengde av alle mulige kombinasjoner;

2) matrisefeilsøking ved bruk av programtilstandsdata;

3) utføres når det gjøres nye endringer i programvaren;

4) en maltest som analyserer utformingen og arkitekturen til en god applikasjon.

programvaretesting

Bruk av alle dynamiske metoder fører til en kombinatorisk eksplosjon i antall tester som må designes, implementeres og gjennomføres. Hver teknikk bør brukes pragmatisk, med tanke på dens begrensninger.

Det er ingen enkelt korrekt metode, bare de som er bedre egnet til en bestemt kontekst. Strukturelle teknikker kan finne ubrukelig eller ondsinnet kode, men de er komplekse og ikke anvendelige for store programmer. Spesifikasjonsbaserte metoder er de eneste som er i stand til å identifisere manglende kode, men de kan ikke identifisere uteliggere. Noen teknikker er mer egnet for et bestemt testnivå, feiltype eller kontekst enn andre.

Nedenfor er hovedforskjellene mellom de tre dynamiske testteknikkene - en sammenligningstabell mellom de tre formene for programvarefeilsøking er gitt.

Aspekt	Black box-metoden	Gråboksmetoden	White box metode
Tilgjengelighet av informasjon om programmets sammensetning	Kun grunnleggende aspekter analyseres	Delvis kunnskap om intern struktur programmer	Full tilgang til kildekoden
Grad av programfragmentering
Hvem gjør feilsøkingen?	Sluttbrukere, testere og utviklere	Sluttbrukere, debuggere og utviklere	Utviklere og testere
	Testing er basert på eksterne nødsituasjoner.	Databasediagrammer, dataflytdiagrammer, interne tilstander, kunnskap om algoritme og arkitektur	Den interne strukturen er fullstendig kjent
Dekning	Minst omfattende og krever minimalt med tid		Potensielt den mest omfattende. Tar mye tid
Data og interne grenser	Feilsøking kun ved prøving og feiling	Datadomener og interne grenser kan sjekkes hvis kjent	Bedre testing av datadomener og interne grenser
Egnethet for å teste algoritmen

Automasjon

Automatiserte testmetoder for programvare forenkler verifiseringsprosessen i stor grad, uavhengig av det tekniske miljøet eller programvarekonteksten. De brukes i to tilfeller:

1) å automatisere kjedelige, repeterende eller grundige oppgaver, for eksempel å sammenligne filer på flere tusen linjer, for å frigjøre testerens tid til å konsentrere seg om viktigere punkter;

2) å utføre eller spore oppgaver som ikke enkelt kan utføres av mennesker, for eksempel ytelsestesting eller responstidsanalyse, som kan måles i hundredeler av et sekund.

Testinstrumenter kan klassifiseres på forskjellige måter. Følgende inndeling er basert på oppgavene de støtter:

teststyring, som inkluderer støtte for prosjektstyring, versjonsadministrasjon, konfigurasjonsstyring, risikoanalyse, testsporing, feil, defekter og rapporteringsverktøy;
kravstyring, som inkluderer lagring av krav og spesifikasjoner, kontroll av dem for fullstendighet og tvetydighet, deres prioritet og sporbarhet for hver test;
kritisk gjennomgang og statisk analyse, inkludert overvåking av flyt og oppgaver, registrering og lagring av kommentarer, oppdage defekter og planlagte rettelser, administrere referanser til sjekklister og regler, spore forholdet mellom kildedokumenter og kode, statisk analyse med å oppdage defekter, sikre samsvar med kodestandarder , analyse av strukturer og deres avhengigheter, beregning av metriske parametere for kode og arkitektur. I tillegg brukes kompilatorer, lenkeanalysatorer og kryssreferansegeneratorer;
modellering, som inkluderer verktøy for modellering av forretningsatferd og testing av de opprettede modellene;
testutvikling sikrer generering av forventede data basert på forholdene og brukergrensesnitt, modeller og kode, deres ledelse for å opprette eller endre filer og databaser, meldinger, dataverifisering basert på styringsregler, analyse av statistikk over forhold og risikoer;
kritisk gjennomgang ved å legge inn data via GUI, API, kommandolinjer bruke komparatorer for å finne vellykkede og mislykkede tester;
støtte for feilsøkingsmiljøer som lar deg erstatte manglende maskinvare eller programvare, inkludert maskinvaresimulatorer basert på et undersett av deterministisk utdata, terminalemulatorer, mobiltelefoner eller nettverksutstyr,miljøer for testing av språk, OS og maskinvare ved å erstatte,manglende komponenter med drivere, dummymoduler, etc., samt,verktøy for å avskjære og modifisere OS-forespørsler, simulere,CPU, RAM, ROM eller nettverksbegrensninger;
sammenligning av datafiler, databaser, kontroll av forventede resultater under og etter testing, inkludert dynamisk og batch-sammenligning, automatiske "orakler";
dekningsmåling for å lokalisere minnelekkasjer og feil minnehåndtering, evaluere systematferd under simulerte belastningsforhold, generere applikasjons-, database-, nettverks- eller serverbelastninger under realistiske vekstscenarier, for å måle, analysere, sjekke og rapportere om systemressurser;
sikkerhet;
ytelsestesting, lasttesting og dynamisk analyse;
andre verktøy, inkludert stavekontroll og syntakskontroll, nettverksikkerhet, tilgjengelighet av alle nettsider osv.

Perspektiv

Etter hvert som trender i programvareindustrien endres, kan også prosessen med feilsøking endres. Eksisterende nye metoder for testing av programvareprodukter, som tjenesteorientert arkitektur (SOA), trådløse teknologier, mobiltjenester osv. har åpnet for nye måter å teste programvare på. Noen av endringene som forventes i denne bransjen i løpet av de neste årene er listet opp nedenfor:

testere vil gi lette modeller som utviklere kan sjekke koden deres med;
utvikling av testmetoder som inkluderer visning og simulering av programmer på et tidlig stadium vil eliminere mange inkonsekvenser;
tilstedeværelsen av mange testavskjæringer vil redusere tiden for å oppdage feil;
statiske analysatorer og deteksjonsverktøy vil bli brukt mer utbredt;
bruken av nyttige matriser som spesifikasjonsdekning, modelldekning og kodedekning vil lede prosjektutviklingen;
kombinatoriske verktøy vil tillate testere å bestemme prioriterte områder for feilsøking;
testere vil gi mer synlige og verdifulle tjenester gjennom hele programvareutviklingsprosessen;
feilsøkere vil være i stand til å lage programvaretestingsverktøy og teknikker skrevet i og interoperable med forskjellige språk programmering;
Feilsøkingsspesialister vil bli mer profesjonelt trent.

Nye forretningsorienterte metoder for å teste programmer vil komme for å erstatte dem, endre måten vi samhandler med systemer og informasjonen de gir, samtidig som de reduserer risiko og øker fordelene ved forretningsendringer.

Opplæringen

God dag!

Jeg ønsker å samle all den mest nødvendige teorien om testing, som spørres under intervjuer med traineer, juniorer og litt mellomstore. Egentlig har jeg allerede samlet en del. Hensikten med dette innlegget er å kollektivt legge til det som ble savnet og korrigere/parafrasere/legge til/gjøre noe annet med det som allerede er der, slik at det blir bra og du kan ta det hele og gjenta det før neste intervju, for sikkerhets skyld . Generelt, kolleger, spør jeg under kuttet hvem som skal lære noe nytt, hvem som skal systematisere det gamle, og hvem som skal bidra.

Resultatet bør være et omfattende jukseark som du må lese på nytt på vei til intervjuet.

Alt som er oppført nedenfor er ikke oppfunnet av meg personlig, men er hentet fra ulike kilder, hvor jeg personlig likte ordlyden og definisjonen mer. På slutten er en liste over kilder.

Emne: definisjon av testing, kvalitet, verifisering / validering, mål, stadier, testplan, testplanpunkter, testdesign, testdesignteknikker, sporbarhetsmatrise, tets case, sjekkliste, defekt, feil/deffekt/feil, feilrapport , alvorlighetsgrad vs prioritet, testnivåer, typer/typer, tilnærminger til integrasjonstesting, testprinsipper, statisk og dynamisk testing, utforskende/ad-hoc testing, krav, bug-livssyklus, programvareutviklingsstadier, beslutningstabell, qa/qc/testingeniør, koblingsskjema.

Gå!

Programvaretesting- sjekke samsvaret mellom den faktiske og forventede oppførselen til programmet, utført på et begrenset sett med tester valgt på en bestemt måte. I en bredere forstand er testing en av kvalitetskontrollteknikkene som inkluderer aktivitetene arbeidsplanlegging (Test Management), testdesign (Test Design), testutførelse (Test Execution) og analyse av resultatene (Test Analysis).

Programvarekvalitet er et sett med egenskaper ved programvare relatert til dens evne til å tilfredsstille uttalte og forventede behov.

Bekreftelse er prosessen med å evaluere et system eller dets komponenter for å avgjøre om resultatene fra det nåværende utviklingsstadiet tilfredsstiller betingelsene som ble dannet i begynnelsen av dette stadiet. De. om våre mål, tidsfrister og prosjektutviklingsoppgaver definert i begynnelsen av den nåværende fasen blir overholdt.
Validering- dette er en avgjørelse av om programvaren som utvikles oppfyller brukerens forventninger og behov, og systemkrav.
Du kan også finne en annen tolkning:
Prosessen med å vurdere et produkts samsvar med eksplisitte krav (spesifikasjoner) er verifisering, samtidig som vurdering av produktets samsvar med brukernes forventninger og krav er validering. Du kan også ofte finne følgende definisjon av disse begrepene:
Validering – ‘er dette riktig spesifikasjon?’.
Verifikasjon - 'er systemet korrekt i henhold til spesifikasjonen?'.

Testingsmål
Øk sannsynligheten for at applikasjonen som er beregnet på testing vil fungere riktig under alle omstendigheter.
Øk sannsynligheten for at applikasjonen som testes vil oppfylle alle de beskrevne kravene.
Gir oppdatert informasjon om den nåværende tilstanden til produktet.

Teststadier:
1. Analyse
2. Utvikling av en teststrategi
og planlegging av kvalitetskontrollprosedyrer
3. Arbeid med krav
4. Oppretting av testdokumentasjon
5. Prototypetesting
6. Grunnleggende testing
7. Stabilisering
8. Drift

Testplan- dette er et dokument som beskriver hele omfanget av testarbeid, fra en beskrivelse av objektet, strategien, tidsplanen, kriterier for start og slutt på testing, til utstyret som er nødvendig i arbeidsprosessen, spesiell kunnskap, samt risikovurderinger med alternativer for løsning.
Svarer på spørsmålene:
Hva bør testes?
Hva vil du teste?
Hvordan vil du teste?
Når skal du teste?
Kriterier for å starte testing.
Kriterier for gjennomføring av test.

Hovedpunkter i testplanen
IEEE 829-standarden viser punktene som en testplan bør (kan) bestå av:
a) Testplanidentifikator;
b) Introduksjon;
c) Testelementer;
d) Funksjoner som skal testes;
e) Funksjoner som ikke skal testes;
f) Tilnærming;
g) Kriterier for bestått/ikke bestått element;
h) Suspensjonskriterier og gjenopptakelseskrav;
i) Test leveranser;
j) Testoppgaver;
k) Miljøbehov;
l) Ansvar;
m) Bemanning og opplæringsbehov;
n) Tidsplan;
o) Risikoer og uforutsette hendelser;
p) Godkjenninger.

Testdesign- dette er stadiet i programvaretestprosessen der testcaser (testcases) utformes og opprettes i samsvar med tidligere definerte kvalitetskriterier og testmål.
Roller ansvarlig for testdesign:
Testanalytiker - bestemmer "HVA skal teste?"
Testdesigner - bestemmer "HVORDAN teste?"

Test designteknikker

Ekvivalenspartisjonering (EP). For eksempel, hvis du har et område med gyldige verdier fra 1 til 10, må du velge én riktig verdi innenfor intervallet, for eksempel 5, og én feil verdi utenfor intervallet, 0.

Grenseverdianalyse (BVA). Hvis vi tar eksemplet ovenfor, vil vi velge minimums- og maksimumsgrensene (1 og 10) som verdier for positiv testing, og verdier større og mindre enn grensene (0 og 11). Grenseverdianalyse kan brukes på felt, poster, filer eller enhver form for begrenset enhet.

Årsak/virkning - CE. Dette er som regel å legge inn kombinasjoner av forhold (grunner) for å få et svar fra systemet (Effekt). Du tester for eksempel muligheten til å legge til en kunde ved hjelp av en bestemt skjerm. For å gjøre dette, må du skrive inn flere felter som "Navn", "Adresse", "Telefonnummer" og deretter klikke på "Legg til"-knappen - dette er "Årsaken". Etter å ha klikket på "Legg til" -knappen, legger systemet til klienten til databasen og viser nummeret hans på skjermen - dette er "Undersøkelse".

Uttømmende testing (ET)– Dette er et ekstremt tilfelle. Innenfor denne teknikken bør du teste alle mulige kombinasjoner av inngangsverdier, og i prinsippet skal dette finne alle problemer. I praksis er bruken av denne metoden ikke mulig på grunn av det store antallet inngangsverdier.

Sporbarhetsmatrise- Kravsamsvarsmatrisen er en todimensjonal tabell som inneholder samsvaret mellom funksjonskravene til produktet og de forberedte testtilfellene. Tabellkolonneoverskriftene inneholder krav, og radoverskriftene inneholder testscenarier. I krysset er det et merke som indikerer at kravet til gjeldende kolonne er dekket av testtilfellet til gjeldende rad.
Kravoverholdelsesmatrisen brukes av QA-ingeniører for å validere produkttestdekningen. MCT er en integrert del av testplanen.

Testforsøk er en artefakt som beskriver et sett med trinn, spesifikke forhold og parametere som er nødvendige for å kontrollere implementeringen av funksjonen som testes eller dens del.
Eksempel:
Handling Forventet resultat Testresultat
(bestått/ikke bestått/blokkert)
Åpne side "pålogging" Påloggingssiden åpnes Bestått

Hver testcase må ha 3 deler:
Forhåndsbetingelser En liste over handlinger som bringer systemet til en tilstand som er egnet for grunnleggende testing. Eller en liste over betingelser, hvis oppfyllelse indikerer at systemet er i en tilstand som er egnet for å gjennomføre hovedtesten.
Testtilfellebeskrivelse En liste over handlinger som overfører systemet fra en stat til en annen for å oppnå et resultat på grunnlag av hvilket det kan konkluderes med at implementeringen tilfredsstiller kravene
PostConditions Liste over handlinger som overfører systemet til starttilstanden (tilstand før testen - starttilstand)
Typer testtilfeller:
Testtilfeller er delt inn i positive og negative i henhold til forventet resultat:
Et positivt testtilfelle bruker kun korrekte data og bekrefter at applikasjonen utførte den oppkalte funksjonen riktig.
Et negativt testtilfelle opererer med både korrekte og ukorrekte data (minst 1 feil parameter) og har som mål å se etter eksepsjonelle situasjoner (validatorer utløses), og også sjekke at funksjonen som kalles opp av applikasjonen ikke blir utført når validatoren utløses.

Sjekkliste er et dokument som beskriver hva som skal testes. I dette tilfellet kan sjekklisten være absolutt ulike nivåer detaljering. Hvor detaljert sjekklisten vil være avhenger av rapporteringskrav, nivået på produktkunnskapen til ansatte og kompleksiteten til produktet.
Som regel inneholder en sjekkliste kun handlinger (trinn), uten forventet resultat. Sjekklisten er mindre formalisert enn testmanuset. Det er hensiktsmessig å bruke det når testskript er overflødige. Sjekklister er også knyttet til fleksible tilnærminger til testing.

Defekt (aka bug)- dette er et avvik mellom det faktiske resultatet av programgjennomføringen og det forventede resultatet. Defekter oppdages under programvareteststadiet, når testeren sammenligner resultatene av programmet (komponent eller design) med forventet resultat beskrevet i kravspesifikasjonen.

Feil- brukerfeil, det vil si at han prøver å bruke programmet på en annen måte.
Eksempel - legger inn bokstaver i felt der du må skrive inn tall (alder, varemengde osv.).
I kvalitetsprogram Slike situasjoner er tilrettelagt og det gis en feilmelding med rødt kryss.
Feil (defekt)- en feil fra programmereren (eller designeren eller noen andre som deltar i utviklingen), det vil si når noe i programmet ikke går som planlagt og programmet kommer ut av kontroll. For eksempel, når brukerinndata ikke kontrolleres på noen måte, forårsaker feil data krasjer eller andre "glede" i driften av programmet. Eller programmet er bygget internt på en slik måte at det i utgangspunktet ikke samsvarer med det som forventes av det.
Feil- en feil (og ikke nødvendigvis en maskinvare) i driften av en komponent, et helt program eller system. Det vil si at det er defekter som fører til feil (En defekt forårsaket feilen) og det er de som ikke gjør det. UI-defekter for eksempel. Men maskinvarefeil, som ikke har noe med programvare å gjøre, er også en feil.

Feilrapport er et dokument som beskriver situasjonen eller sekvensen av handlinger som førte til feil drift av testobjektet, og angir årsakene og det forventede resultatet.
En lue
Kort beskrivelse (sammendrag) En kort beskrivelse av problemet, som tydelig indikerer årsak og type feilsituasjon.
Prosjekt Navn på prosjektet som testes
Application Component (Component) Navnet på delen eller funksjonen til produktet som testes
Versjonsnummer Versjonen som feilen ble funnet på
Alvorlighet Det vanligste systemet med fem nivåer for å gradere alvorlighetsgraden av en defekt er:
S1 blokkerer
S2 Kritisk
S3 major
S4 Minor
S5 trivielt
Prioritet Prioriteten til defekten:
P1 Høy
P2 Middels
P3 Lav
Status Statusen til feilen. Avhenger av prosedyren som brukes og Livssyklus feil arbeidsflyt og livssyklus

Forfatter (forfatter) Skaper av feilrapporter
Tildelt til Navnet på personen som er tildelt problemet.
Miljø
OS / Service Pack, etc. / Nettleser + versjon /... Informasjon om miljøet der feilen ble funnet: operativsystem, oppdateringspakke, for WEB-testing - nettlesernavn og versjon, etc.
…
Beskrivelse
Trinn for å gjenskape Trinn som du enkelt kan gjenskape situasjonen som førte til feilen.
Faktisk resultat Resultatet oppnådd etter å ha gått gjennom trinnene for å reprodusere
Forventet resultat Forventet riktig resultat
Tillegg
Vedlegg En loggfil, skjermbilde eller ethvert annet dokument som kan bidra til å klargjøre årsaken til feilen eller indikere en måte å løse problemet på.

Alvorlighet vs prioritet
Alvorlighet er en egenskap som karakteriserer virkningen av en defekt på ytelsen til en applikasjon.
Prioritet er et attributt som indikerer prioriteten for å utføre en oppgave eller eliminere en defekt. Vi kan si at dette er et arbeidsplanleggingsleders verktøy. Jo høyere prioritet, desto raskere må feilen repareres.
Alvorlighetsgraden avsløres av testeren
Prioritet - leder, teamleder eller kunde

Gradering av defektens alvorlighetsgrad (alvorlighetsgrad)

S1 blokkerer
En blokkeringsfeil som gjør applikasjonen ute av drift, og gjør videre arbeid med systemet som testes eller dets nøkkelfunksjoner umulig. Løsning av problemet er nødvendig for videre funksjon av systemet.

S2 Kritisk
En kritisk feil, en funksjonsfeil nøkkelforretningslogikk, et hull i sikkerhetssystemet, et problem som førte til en midlertidig krasj av serveren eller gjorde en del av systemet ute av drift, uten mulighet for å løse problemet ved hjelp av andre inngangspunkter. Å løse problemet er nødvendig for videre arbeid med nøkkelfunksjoner i systemet som testes.

S3 major
En betydelig feil, en del av hovedforretningslogikken fungerer ikke riktig. Feilen er ikke kritisk eller det er mulig å arbeide med funksjonen som testes ved hjelp av andre inngangspunkter.

S4 Minor
En mindre feil som ikke bryter forretningslogikken til den delen av applikasjonen som testes, et åpenbart problem med brukergrensesnittet.

S5 trivielt
En triviell feil som ikke påvirker forretningslogikken til applikasjonen, et dårlig reproduserbart problem som knapt er merkbart gjennom brukergrensesnittet, et problem med tredjeparts biblioteker eller tjenester, et problem som ikke har noen innvirkning på den generelle kvaliteten på produktet.

Gradering av defektprioritet (Prioritet)
P1 Høy
Feilen må rettes så raskt som mulig, fordi... dens tilstedeværelse er avgjørende for prosjektet.
P2 Middels
Feilen må rettes, dens tilstedeværelse er ikke kritisk, men krever en obligatorisk løsning.
P3 Lav
Feilen må rettes, dens tilstedeværelse er ikke kritisk og krever ingen hasteløsning.

Testing nivåer

1. Enhetstesting
Komponent(enhets)testing sjekker funksjonalitet og ser etter defekter i deler av applikasjonen som er tilgjengelige og kan testes separat (programmoduler, objekter, klasser, funksjoner osv.).

2. Integrasjonstesting
Samspillet mellom systemkomponenter kontrolleres etter komponenttesting.

3. Systemtesting
Hovedmålet med systemtesting er å verifisere både funksjonelle og ikke-funksjonelle krav i systemet som helhet. Dette identifiserer defekter som feil bruk av systemressurser, utilsiktede kombinasjoner av data på brukernivå, inkompatibilitet med miljøet, utilsiktede brukstilfeller, manglende eller feil funksjonalitet, uleilighet med bruk, etc.

4. Driftstesting (Release Testing).
Selv om et system oppfyller alle krav, er det viktig å sikre at det møter brukerens behov og oppfyller sin rolle i sitt driftsmiljø slik det er definert i systemets forretningsmodell. Det bør tas i betraktning at forretningsmodellen kan inneholde feil. Det er derfor det er så viktig å driftstesting som det siste valideringstrinnet. I tillegg lar testing i driftsmiljøet oss identifisere ikke-funksjonelle problemer, som: konflikter med andre systemer knyttet til forretningsområdet eller i programvare og elektroniske miljøer; utilstrekkelig systemytelse i driftsmiljøet osv. Å finne slike ting på implementeringsstadiet er åpenbart et kritisk og kostbart problem. Det er derfor det er så viktig å utføre ikke bare verifisering, men også validering, fra de tidligste stadiene av programvareutvikling.

5. Aksepttesting
En formell testprosess som verifiserer at et system oppfyller kravene og utføres for å:
bestemme om systemet oppfyller akseptkriterier;
ta en beslutning fra kunden eller annen autorisert person om søknaden aksepteres eller ikke.

Typer/typer av testing

Funksjonelle typer testing
Funksjonstesting
Sikkerhets- og tilgangskontrolltesting
Interoperabilitetstesting

Ikke-funksjonelle typer testing
Alle typer ytelsestesting:
o belastningstesting (ytelse og belastningstesting)
o Stresstesting
o Stabilitets-/pålitelighetstesting
o Volumtesting
Installasjonstesting
Brukbarhetstesting
Failover og gjenopprettingstesting
Konfigurasjonstesting

Endringsrelaterte typer testing
Røyktesting
Regresjonstesting
Re-testing
Byggverifiseringstest
Sanitetstesting

Funksjonstesting vurderer forhåndsspesifisert atferd og er basert på en analyse av spesifikasjonene for funksjonaliteten til komponenten eller systemet som helhet.

Sikkerhetstesting er en teststrategi som brukes til å sjekke sikkerheten til systemet, samt å analysere risikoene forbundet med å gi en helhetlig tilnærming til å beskytte applikasjonen, angrep fra hackere, virus, uautorisert tilgang til konfidensielle data.

Interoperabilitetstesting er funksjonstesting som tester en applikasjons evne til å samhandle med én eller flere komponenter eller systemer og inkluderer kompatibilitetstesting og integrasjonstesting

Stresstesting– dette er automatisert testing som simulerer arbeid et visst beløp brukernes virksomhet på en felles (delt) ressurs.

Stresstesting lar deg sjekke hvor effektiv applikasjonen og systemet som helhet er under stress og også vurdere systemets evne til å regenerere, dvs. å gå tilbake til det normale etter opphør av stress. Stress i denne sammenheng kan være en økning i intensiteten av operasjoner til svært høye verdier eller en nødendring i serverkonfigurasjonen. En av oppgavene med stresstesting kan også være å vurdere prestasjonsforringelse, så målene for stresstesting kan overlappe med målene for prestasjonstesting.

Volumtesting. Hensikten med volumtesting er å få en vurdering av ytelse etter hvert som datavolumet i applikasjonsdatabasen øker

Stabilitets-/pålitelighetstesting. Oppgaven med stabilitet (pålitelighet) testing er å sjekke funksjonaliteten til applikasjonen under langtidstesting (mange timer) med et gjennomsnittlig belastningsnivå.

Tester installasjonen rettet mot å verifisere vellykket installasjon og konfigurasjon, samt å oppdatere eller avinstallere programvare.

Brukbarhetstesting er en testmetode rettet mot å etablere graden av brukervennlighet, lærebarhet, forståelighet og attraktivitet for brukere av produktet som utvikles i konteksten gitte forhold. Dette inkluderer også:
UI-testing er en type forskningstesting som utføres for å avgjøre om et kunstig objekt (som en nettside, brukergrensesnitt eller enhet) er egnet for den tiltenkte bruken.
User eXperience (UX) er følelsen en bruker opplever mens han bruker et digitalt produkt Brukergrensesnitt er et verktøy som tillater interaksjon mellom brukeren og nettressursen.

Failover og gjenopprettingstesting validerer produktet som testes med tanke på dets evne til å tåle og lykkes med å komme seg fra mulige feil forårsaket av programvarefeil, maskinvarefeil eller kommunikasjonsproblemer (for eksempel nettverksfeil). Formålet med denne typen testing er å teste gjenopprettingssystemer (eller systemer som dupliserer hovedfunksjonaliteten), som i tilfelle feil vil sikre sikkerheten og integriteten til dataene til produktet som testes.

Konfigurasjonstesting- spesiell type testing rettet mot å sjekke driften av programvaren under forskjellige systemkonfigurasjoner (erklærte plattformer, støttede drivere, forskjellige datamaskinkonfigurasjoner, etc.)

Røyk testing betraktes som en kort syklus med tester utført for å bekrefte at etter å ha bygget koden (ny eller fast), starter den installerte applikasjonen og utfører grunnleggende funksjoner.

Regresjonstesting- dette er en type testing som tar sikte på å sjekke endringer som er gjort i en applikasjon eller miljø(fikse en defekt, slå sammen kode, migrere til et annet operativsystem, database, webserver eller applikasjonsserver), for å bekrefte det faktum at eksisterende funksjonalitet fungerer som før. Regresjonstester kan være både funksjonelle og ikke-funksjonelle tester.

Tester på nytt- testing, hvor testskript som identifiserte feil under siste kjøring utføres for å bekrefte suksessen med å rette disse feilene.
Hva er forskjellen mellom regresjonstesting og re-testing?
Re-testing - feilrettinger er sjekket
Regresjonstesting - sjekker at feilrettinger ikke påvirket andre programvaremoduler og ikke forårsaket nye feil.

Monteringstesting eller byggeverifiseringstest- testing med sikte på å fastslå samsvar av den utgitte versjonen med kvalitetskriterier for å starte testing. Når det gjelder målene, er det analogt med Smoke Testing, rettet mot å akseptere en ny versjon for videre testing eller drift. Den kan trenge dypere inn, avhengig av kvalitetskravene til den utgitte versjonen.

Sanitær testing- Dette er en snevert fokusert testing som er tilstrekkelig til å bevise at en spesifikk funksjon fungerer i henhold til kravene angitt i spesifikasjonen. Det er en undergruppe av regresjonstesting. Brukes til å bestemme ytelsen til en bestemt del av applikasjonen etter endringer gjort i den eller miljøet. Gjøres vanligvis manuelt.

Feil ved gjetning - EG. Dette er når testanalytikeren bruker sin kunnskap om systemet og evnen til å tolke spesifikasjonen til å "forutsi" under hvilke inngangsforhold systemet kan svikte. For eksempel sier spesifikasjonen "brukeren må angi en kode." Testanalytikeren vil tenke: "Hva om jeg ikke skriver inn koden?", "Hva om jeg går inn feil kode? ", og så videre. Dette er prediksjonen om feil.

Tilnærminger til integrasjonstesting:

Bottom Up-integrasjon
Alle lavnivåmoduler, prosedyrer eller funksjoner samles og testes deretter. Deretter samler det seg neste nivå moduler for gjennomføring av integrasjonstesting. Denne tilnærmingen anses som nyttig hvis alle eller nesten alle moduler på nivået som utvikles er klare. Denne tilnærmingen hjelper også med å bestemme nivået av søknadsberedskap basert på testresultater.

Top Down integrasjon
Først testes alle høynivåmoduler, og gradvis legges lavnivåmoduler til én etter én. Alle moduler på lavere nivå simuleres som stubber med lignende funksjonalitet, og når de er klare, erstattes de med ekte aktive komponenter. På denne måten tester vi fra topp til bunn.

Big Bang ("Big Bang"-integrasjon)
Alle eller nesten alle de utviklede modulene settes sammen som et komplett system eller dets hoveddel, og deretter utføres integrasjonstesting. Denne tilnærmingen er veldig bra for å spare tid. Men hvis testtilfellene og deres resultater ikke registreres riktig, vil selve integrasjonsprosessen være svært komplisert, noe som vil bli en hindring for testteamet i å oppnå hovedmålet med integrasjonstesting.

Testprinsipper

Prinsipp 1- Testing viser tilstedeværelse av defekter
Testing kan vise at mangler er tilstede, men kan ikke bevise at de ikke er tilstede. Testing reduserer sannsynligheten for defekter i programvaren, men selv om ingen feil blir funnet, beviser ikke dette at det er korrekt.

Prinsipp 2– Uttømmende testing er umulig
Fullstendig testing med alle kombinasjoner av input og forutsetninger er fysisk umulig, bortsett fra i trivielle tilfeller. I stedet for uttømmende testing, bør risikoanalyse og prioritering brukes for å fokusere testarbeidet bedre.

Prinsipp 3- Tidlig testing
For å finne defekter så tidlig som mulig, bør testaktiviteter startes så tidlig som mulig i programvare- eller systemutviklingens livssyklus, og bør fokuseres på spesifikke mål.

Prinsipp 4- Defekter grupperer seg
Testarbeidet bør konsentreres i forhold til forventet, og senere den faktiske, moduldefekttetthet. Som regel er de fleste feilene som ble oppdaget under testing, eller som forårsaket de fleste systemfeil, inneholdt i et lite antall moduler.

Prinsipp 5- Plantevernmiddelparadoks
Hvis de samme testene kjøres om og om igjen, vil dette settet med testtilfeller ikke lenger finne nye feil. For å overvinne dette "pesticidparadokset" må testtilfeller gjennomgås og revideres regelmessig, og nye tester må være omfattende for å dekke alle komponenter i programvaren eller systemet og finne så mange defekter som mulig.

Prinsipp 6– Testing er konseptavhengig
Testing gjøres forskjellig avhengig av konteksten. For eksempel testes sikkerhetskritisk programvare annerledes enn en e-handelsside.

Prinsipp 7- Fravær-av-feil feilslutning
Å finne og rette feil vil ikke hjelpe hvis det opprettede systemet ikke passer brukeren og ikke oppfyller hans forventninger og behov.

Statisk og dynamisk testing
Statisk testing skiller seg fra dynamisk testing ved at den utføres uten lansering programkode produkt. Testing utføres ved å analysere programkoden (kodegjennomgang) eller kompilert kode. Analysen kan utføres enten manuelt eller ved hjelp av spesial verktøy. Formålet med analysen er å tidlig identifisere feil og potensielle problemer i produktet. Statisk testing inkluderer også testspesifikasjoner og annen dokumentasjon.

Utforskende/ad-hoc testing
Den enkleste definisjonen av utforskende testing er å designe og kjøre tester samtidig. Noe som er det motsatte av scenariotilnærmingen (med sine forhåndsdefinerte testprosedyrer, enten manuelle eller automatiserte). Utforskende tester, i motsetning til scenariotester, er ikke forhåndsbestemt og blir ikke utført nøyaktig som planlagt.

Forskjellen mellom ad hoc og eksplorativ testing er at teoretisk sett kan ad hoc testing utføres av hvem som helst, mens utforskende testing krever ferdigheter og kunnskap om visse teknikker. Vær oppmerksom på at visse teknikker ikke bare er testteknikker.

Krav er en spesifikasjon (beskrivelse) av hva som skal implementeres.
Krav beskriver hva som skal implementeres, uten å detaljere den tekniske siden av løsningen. Hva, ikke hvordan.

Krav Krav:
Korrekthet
Entydighet
Fullstendighet av kravsettet
Konsistens av et sett med krav
Verifiserbarhet (testbarhet)
Sporbarhet
Forståelighet

Bug livssyklus

Programvareutviklingsstadier- Dette er stadiene som programvareutviklingsteam går gjennom før programmet blir tilgjengelig for et bredt spekter av brukere. Programvareutvikling begynner med det innledende utviklingsstadiet (pre-alfastadiet) og fortsetter med stadier der produktet foredles og moderniseres. Den siste fasen av denne prosessen er utgivelsen av den endelige versjonen av programvaren til markedet ("generelt tilgjengelig utgivelse").

Programvareproduktet går gjennom følgende stadier:
analyse av prosjektkrav;
design;
gjennomføring;
produkt testing;
implementering og støtte.

Hvert stadium av programvareutvikling er tildelt et spesifikt serienummer. Hvert stadium har også sitt eget navn, som kjennetegner produktets beredskap på dette stadiet.

Programvareutvikling livssyklus:
Pre-alfa
Alfa
Beta
Frigjøringskandidat
Utgivelse
Etter utgivelsen

Beslutningstabell- et utmerket verktøy for å organisere komplekse forretningskrav som må implementeres i et produkt. Beslutningstabeller presenterer et sett med betingelser, hvis samtidig oppfyllelse bør føre til en spesifikk handling.

QA/QC/testingeniør

Dermed kan vi bygge en modell av hierarkiet av kvalitetssikringsprosesser: Testing er en del av QC. QC er en del av QA.

Tilkoblingsskjema er et kvalitetsstyringsverktøy basert på å identifisere logiske sammenhenger mellom ulike data. Dette verktøyet brukes til å sammenligne årsaker og virkninger på problemet som studeres.

Testmodell- Dette logisk struktur, som beskriver funksjonaliteten til systemet og/eller brukeratferd, basert på hvilke testtilfeller som genereres. Konstruksjon testmodell begynner med å bygge en struktur, og deretter fylles den godkjente strukturen med testcases.

Modeller bygges vanligvis basert på kravene og/eller forventet oppførsel til systemet. Test modell konstruksjon og ledelse er egnet for store systemer med kompleks forretningslogikk og er vanskelig å bruke på prosjekter ved hjelp av fleksible metoder, fordi kostnadene ved å opprettholde testmodellstyringen og kvalitetssikringsprosessen vil være for høye.

Testmodellstyring refererer til prosessen som kontrollerer dekningen av testmodellen, kvaliteten på skriptene som beskriver testmodellen og dens oppdatering.

Testmodellstyring er en pågående prosess gjennom hele produktets livssyklus.

Testmodelldekning

For å kontrollere dekningen av alle krav, kan du bruke sporingsmatriser, som bestemmer dekningen av krav ved testtilfeller (se eksempel).
Før testtilfeller beskrives, skal oppbygningen av testmodellen godkjennes med kunden.

Skriptkvalitet

For å administrere kvaliteten på skript, er det nødvendig å kontrollere ikke bare nivået på beskrivelsen av testtilfeller, men også kvaliteten deres.

Før man begynner å beskrive testtilfeller, er det nødvendig å fastsette kravene for hvert beskrivelsesnivå og kvalitetskriterier for å beskrive testtilfeller.

Mulige nivåer av testcasebeskrivelse:

På nivå 4 kan koordinering med kunden erstattes med godkjenning.

Kvalitetskriterier for testcasebeskrivelser kan være som følger:

Prøvesaker skal skrives i henhold til kravene

Testing er prosessen med å bekrefte at et produkt oppfyller kravene. Derfor delvis generell beskrivelse testtilfelle (i testsporingssystemer brukes vanligvis begrepet «sammendrag») er det nødvendig å referere til et spesifikt krav i forbindelse med fragmenter av kravteksten. Dermed vil det være klart for alle prosjektdeltakere som denne testcasen ble skrevet på grunnlag av.

Bruk detaljerte forutsetninger

Hvordan spare tid på testsaker?

Angi formateringsregler for alle testtilfeller. På denne måten vil testsaken være lett å forstå og lese for enhver prosjektdeltaker. For eksempel, på et prosjekt kan du angi følgende regler:

Alle inngangsparametere må merkes med rødt.
Alle skript må være uthevet i blått,
Alle navn på knapper, felt, blokker er uthevet i kursiv og fet skrift.
Viktige steder er markert med understreking.
Hvert trinn som utføres må ha et forventet resultat.
Hvert trinn i testtilfeller skal kun beskrive én handling og det forventede resultatet for den. De. Når du mottar et mislykket testtilfelle i et spesifikt trinn, bør det være tydelig ved hvilken handling feilen oppstår.
Det forventede resultatet bør være entydig.

Testtilfeller skal være entydige, d.v.s. må være utformet og formulert på en slik måte at de ikke gir rom for tvetydig tolkning, men er klart forstått av alle deltakere.

Hvis det tar lang tid å skrive testtilfeller, kan det oppstå en situasjon når en spesialist slutter å se sine feil. Dette krever et perspektiv utenfra – her vil det hjelpe gjennomføre kryssvurderinger. Dette stadiet anbefales gjennomført i tilfeller der utviklingen av en testmodell er utvidet og tar lang tid. For eksempel når utviklingen av testscenarier tar mer enn 1 måned.

Skriptkvalitetskontrollprosessen kan utføres Med ved hjelp av Test Modellkontroll– en spesiallaget mal.

Testmodelloppdatering

Det er nødvendig å jevnlig oppdatere testmodellen og selve testsakene for samsvar med kravene, samt gjennomgå prioriteringene til testsakene.

Å oppdatere du kan opprettholde en "kravmatrise"(Requirement Traceability Matrix): etter hver endring i et spesifikt krav, velges alle testtilfeller knyttet til dette kravet fra testsporingssystemet og oppdateres.

Testmodellkontroller:

TestRail
TestLink
Jira+Zephyr
Microsoft Test Manager (MTM)
utmerke

Kapittelet introduserer kvalitetsbegrepet, beskriver testprosessen og diskuterer hvordan kvalitet og testing forholder seg til ulike produksjonsprosesser. Det tradisjonelle synet på testing som en mekanisme for å vurdere kvaliteten på et produkt presenteres, og det beskriver også hvordan testing bidrar til å styrke og styrke arkitekturen tidlig i utviklingssyklusen.

Mål

Formålet med testingen er å vurdere kvaliteten på produktet. Dette betyr ikke bare å evaluere sluttproduktet, men også å evaluere arkitekturen fra de tidlige stadiene av prosessen til den endelige leveringen av produktet til kundene. inkluderer følgende.

Sjekke komponentinteraksjoner

Kontrollere riktig integrering av komponenter

Kontrollere nøyaktigheten av implementeringen av alle krav

Identifisere defekter og iverksette nødvendige tiltak for å eliminere dem før
programvaredistribusjon

Kvalitet

Standard bruk av begrepet kvalitet inkluderer mange ting: som regel betegner dette ordet fravær av defekter og (hva er mye viktigere!) Overholdelse av det tiltenkte formålet; Med kvalitetsbegrepet forbinder vi det vi trenger av et produkt. Et produkt (eller en komponent av det) er kanskje ikke defekt, men hvis det ikke gjør det vi trenger det, er det like ubrukelig som et produkt med feil. Hovedformålet med testing er å evaluere kvaliteten på sluttproduktet, samt å evaluere kvaliteten på komponentene som utgjør det og arkitekturen som bestemmer formen til disse komponentene. Dette er for å sikre at produktet er

Kapittel 12. G67

oppfyller eller overgår visse krav (vurdert etter tiltak og akseptkriterier).

Kvaliteten på et produkt kan ikke vurderes fullt ut alene; programvare er utviklet av en organisasjon som bruker en prosess, så dårlig kvalitet kan skyldes en dårlig prosess eller en prosess som er vanskelig å følge. Som en konsekvens vurderer kvalitetsvurdering ofte ikke bare kvaliteten på selve produktet, men også organisatoriske faktorer og prosesskvalitet.

Hvem er ansvarlig for kvaliteten på produktet

Alle medlemmer av prosjektgruppen er ansvarlige for å produsere et kvalitetsprodukt. Hvis kvalitet ikke opprinnelig var innebygd i produktet, kan det ikke lenger "legges til senere" ved å utføre noen aktive handlinger for å garantere kvalitet.

Oppgaven med å teste er det ikke garanti kvalitet og anslag mens du gir tilbakemelding for å løse kvalitetsproblemer til en rimelig pris og tid. Testerens jobb er å evaluere kvalitet og gi tilbakemelding, og prosjektgruppens jobb er å lage artefakter som oppfyller kravene og kvalitetsparameterne.

Testing i en iterativ livssyklus

Testing er ikke en egen aktivitet eller en fase i et prosjekt der det utføres kvalitetsvurdering. Hvis utviklere trenger rettidig tilbakemelding på problemer med produktkvalitet, bør testing utføres gjennom hele livssyklusen: funksjonaliteten til tidlige prototyper kan testes; stabilitet, dekning og ytelse av arkitekturen (samtidig kan mislykkede beslutninger alltid korrigeres); I tillegg kan du teste sluttproduktet og vurdere dets beredskap for overføring til kundene. Det er en vanlig oppfatning at testing er den siste kontrollen av global ytelse; Denne situasjonen går imidlertid glipp av hovedfordelen med testing: muligheten til å gi tilbakemelding mens det fortsatt er tid (og ressurser) til å iverksette nødvendige tiltak.

Klassifisering av prøver

For å vurdere kvaliteten på et produkt kreves det ulike typer tester. Følgende egenskaper kan brukes til å klassifisere tester.

Testet kvalitetsparameter - hvilken kvalitetsparameter testes?

Testfase- punkt i livssyklusen der den utføres
testing

Testtype- en spesifikk oppgave for en individuell test, vanligvis knyttet til en
kvalitetsparameter

Kvalitetsparametere

Det er mønstre som lar deg identifisere problemer knyttet til kvalitet (som regel har nesten alle systemer samme type problemer). Som et resultat bør følgende vurderes for hvert produkt.

Pålitelighet

Programvaren "motstår" utseendet til feil under utførelse: det er ingen krasjer, fryser, minnelekkasjer, etc.

Funksjonalitet

Programvaren implementerer de nødvendige brukstilfellene eller har forventet oppførsel.

I Produktivitet

Programvaren og systemet fungerer, reagerer raskt på forhåndsbestemte hendelser og fortsetter å fungere akseptabelt under virkelige driftsforhold (f.eks. tung belastning, lengre driftsperioder osv.). Ytelsestesting fokuserer på å gi den nødvendige funksjonaliteten samtidig som de tilfredsstiller de ikke-funksjonelle kravene til systemet.

Hver av de spesifiserte kvalitetsparametrene krever at en eller flere tester utføres på ett eller flere teststadier. I tillegg er det andre kvalitetsparametere, vurderingen av disse kan være mer subjektiv: brukervennlighet, utvidbarhet, fleksibilitet, etc. En kvalitativ vurdering av disse kvalitetsparametrene bør gjøres ved enhver anledning.

Teststadier

Testing bør ikke betraktes som en egen aktivitet som utføres helt på en gang. Testing utføres på ulike stadier av programvareutvikling og er rettet mot å sjekke ulike objekter (testmål). Teststadiene går fra å teste små elementer i systemet som komponenter (enhetstesting) til testing. testing av ferdige systemer (systemtesting). La oss liste opp de eksisterende teststadiene og deres oppgaver.

Enhetstesting

Minimumselementene i systemet testes. Testtiden faller som regel sammen med implementeringstiden for elementene.

Integrert testing

Integrerte enheter (eller komponenter, eller delsystemer) testes.

Systemtesting

Fullførte applikasjoner og systemer (bestående av en eller flere applikasjoner) testes.

Aksepttesting

Den ferdige applikasjonen (eller systemet) testes av sluttbrukere (eller representanter for sluttbrukere). Mål med testing: Bestem produktets beredskap for distribusjon.

Det bør huskes at på ulike tidspunkt i livssyklusen finner teststadier sted med forskjellig vekt. Den tidlige konseptprototypen, brukt i forskningsfasen for å evaluere levedyktigheten til produktvisjonen, vil bli gjenstand for ulike aksepttester. Den arkitektoniske prototypen som ble utviklet under planforbedringsfasen vil bli gjenstand for integrert testing og systemtesting rettet mot å verifisere den arkitektoniske integriteten og ytelsen til nøkkelarkitektoniske elementer, selv om mye av systemkoden på dette tidspunktet er i form av surrogatprogrammer. Teststadier er ikke forhåndsdefinerte "faser" som utføres sekvensielt nærmere slutt prosjekt; i kontrast, i en iterativ livssyklus, starter testing tidlig og forekommer ofte.

Typer tester

Det finnes mange typer tester, som hver fokuserer på et spesifikt testmål og tester kun ett aspekt av programvarekvalitet. Fordi testing foregår gjennom hele livssyklusen, kan programvaren som testes være et enkelt stykke kode, en integrert enhet eller en komplett applikasjon (eller system). La oss nevne de vanligste typene tester.

Sertifiseringstest

Sammenligner ytelsen til et testmål og et standardobjekt, for eksempel eksisterende programvare, eller evaluerer ytelsen i henhold til et system av tiltak.

Konfigurasjonstest

Kontrollerer akseptabel funksjon av testmålet under ulike konfigurasjoner (programvare eller maskinvare).

Funksjonstester

Funksjonen til måltestobjektet generelt kontrolleres, dvs. riktig implementering av de nødvendige presedensene.

Installasjonstester

Sjekker riktig installasjon av testmålet, muligheten for vellykket installasjon under forskjellige konfigurasjoner eller i ulike forhold(for eksempel hvis det ikke er nok diskplass).

Integritetstesting

Påliteligheten til måltestobjektet, dets stabilitet og motstand mot feil under utførelse kontrolleres.

Lasttest

Verifiserer at ytelsen til testmålet er akseptabel under en rekke driftsforhold (inkludert annet nummer brukere, transaksjoner osv.) med en uforanderlig konfigurasjon.

Ytelsestester

Verifiserer den akseptable ytelsen til testmålet i ulike konfigurasjoner samtidig som det opprettholdes konstante driftsegenskaper.

Hard modus testing

Verifiserer den akseptable ytelsen til testmålet under nødsituasjoner eller kritiske forhold, for eksempel begrensede ressurser eller et ekstremt stort antall brukere.

Regresjonstesting

Regresjonstesting er en testteknikk der tidligere utførte tester utføres på nytt på en ny versjon av målobjektet. Målet med denne typen testing er å sikre at kvaliteten på målobjektet ikke forringes (regress) når nye funksjoner legges til det objektet. Regresjonstesting er nødvendig for

Maksimal tidlig oppdagelse av defekter;

Kontroller at kodeendringer ikke introduserer nye defekter eller
gjenopprette gamle.

Regresjonstesting kan innebære å kjøre alle typer tester om og om igjen. Vanligvis utføres slik testing i hver iterasjon og består av gjenkjøringstester utført i tidligere iterasjoner.

Testmodell

Teste modell- det er en representasjon av hva som skal testes og hvordan testingen skal utføres. Denne modellen er en representasjon av design- og implementeringsmodellene, og viser de faktiske testene og testrelaterte målparametere. Testmodellen inkluderer et sett med kontrolloppgaver, testprosedyrer, testscenarier og forventede testresultater, samt en beskrivelse av deres forhold.

La oss se nærmere på komponentene i testmodellen.

Kontrolloppgaver

Et sett med testdata, testutførelsesbetingelser og forventede resultater designet for å spesifikk oppgave testing. Kontrolloppgaver kan bestemmes ut fra presedenser, designdokumentasjon eller programkode. Kontrolloppgaven kan implementeres ved hjelp av en eller flere testmetoder.

Testmetoder

Et sett med detaljerte instruksjoner for å sette opp og utføre kontrolloppgaver og evaluere de oppnådde resultatene. Ved hjelp av én testmetode kan en eller flere kontrolloppgaver implementeres. En testmetodikk kan også brukes til å implementere bare deler av en testoppgave, for eksempel en alternativ brukscaseflyt.

Test scenarier

Instruksjoner som automatiserer implementeringen av deler av eller hele en testprosedyre (eller testprosedyrer).

Testklasser og komponenter

Klasser og komponenter som implementerer testprosjekter, inkludert drivere og surrogatprogrammer.

Test interaksjoner

Interaksjoner er representert i form av et interaksjonsdiagram eller sekvensdiagram og reflekterer den tidsordnede flyten av meldinger mellom testkomponenter og testmålet som oppstår under testprosessen.

Notater

Tekstinformasjon som beskriver restriksjonene, eller Tilleggsinformasjon, brukt i testmodellen. Notater kan festes til et hvilket som helst element i testmodellen.

Hovedelementene i testmodellen og deres relasjoner er vist i fig. 12.1.

Ris. 12.1. Testoppgaver, testmetoder og testscenarier for en minibank

Utøvere og artefakter

To hovedutøvere er involvert i testprosessen.

Testutvikler ansvarlig for planlegging, utvikling, gjennomføring av tester og
testvurdering. Hans ansvar inkluderer å lage en testplan og modell
utvikling, implementering av testmetoder og evaluering av testdekning, resultater
tats og test effektivitet.

Tester Ansvarlig for å utføre systemtesting. I sin forpliktelse
inkluderer å sette opp og kjøre tester, vurdere testytelse,
gjenoppretting fra feil, evaluering av testresultater og registrering
identifiserte mangler.

Hvis spesifikk kode er nødvendig for å støtte testing (for eksempel må drivere eller surrogater utvikles), må prosessen også involvere en utvikler og designer i roller som ligner på de som er definert i kapittel 10 og 11.

Utøverne og artefaktene til testprosessen er presentert i fig. 12.2. La oss se på de viktigste artefaktene i denne prosessen.

Testplan, som inneholder informasjon om målene og målene for testingen.
Testplanen bestemmer hvilke strategier som skal brukes og hvilke
ressurser kreves for å utføre testing.

Testmodell beskrevet tidligere.

Testresultater og data samlet inn under testkjøring.

Arbeidsbelastningsmodell for ytelsestester; det definerer
variabler og deres verdier brukt i ulike operasjonelle
tester for å modellere eller simulere egenskapene til eksterne
utøvere, funksjoner utført sluttbrukere, volum
disse funksjonene og belastningen som skapes av disse funksjonene.

defekter, oppnådd som et resultat av "mislykkede tester" er en av
typer endringsforespørsler (se kapittel 13).

I tillegg til artefaktene som er oppført, må følgende artefakter opprettes ved utvikling av programvarestøtte for en test.

Testpakker og klasser

Delsystemer og testkomponenter

Den endelige testevalueringen brukes som en del av design-iterasjonsevalueringen og periodisk statusevaluering (se kapittel 7, " Teknologisk prosess prosjektledelse").

Teknologisk prosess

En typisk testprosess, dens hovedelementer og avhengigheter mellom dem er vist i fig. 12.3.

Forbereder for testing

Formålet med dette arbeidsflytelementet er å definere og beskrive testingen som skal utføres. For å gjøre dette lages en testplan som inneholder testkrav og teststrategier. En enkelt testplan kan utvikles som beskriver alle typer tester som skal utføres, eller det kan lages en egen plan for hver type test. Testforberedelse utføres på en slik måte at testaktiviteter er målbare og håndterbare.

Testutvikling

Formålet med dette arbeidsflytelementet er å definere, beskrive og lage testmodellen og dens tilknyttede artefakter. Et testprosjekt opprettes for å sikre at programvaren som brukes til testing er riktig organisert og oppfyller de spesifiserte kravene. Under dette elementet i arbeidsflyten analyserer testdesigneren testmålet, utvikler en testmodell og (i tilfelle ytelsestesting) en arbeidsbelastningsmodell. Testdesign forvandler brukstilfeller til aksept- og systemkontrolloppgaver, som deretter veileder utformingen av programvareelementene som utfører testing.

Testimplementering

Formålet med dette prosesselementet er å implementere testprosedyrene definert i avsnitt Forbereder for testing. Testmetoder lages som regel i et testautomatiseringsmiljø eller i et programmeringsmiljø. Den resulterende artefakten er en elektronisk versjon av testprosedyren, kalt et testskript.

Hvis spesifikk kode er nødvendig for å støtte eller utføre testing (for eksempel må testverktøy, drivere eller surrogatprogrammer utvikles), så er utvikleren, designeren og testutvikleren involvert i arbeidet med å lage den.

Utføre tester på integrert teststadiet

Hensikten med dette arbeidsflytelementet er å sikre at systemkomponenter kombineres riktig og å sikre at kombinasjonen oppfører seg riktig. Systemintegratoren er ansvarlig for å kompilere og kombinere systemet til økende funksjonsblokker. For hver slik blokk testes de tilførte funksjonene, regresjonstester utføres og testresultater hentes.

I løpet av en iterasjon utføres integraltesting flere ganger til hele systemet er vellykket integrert (bestemt av målet med iterasjonen).

Utføre tester under systemtestfasen

Hensikt av dette elementet teknologisk prosess er å sikre at hele systemet fungerer som det skal. Systemintegratoren kompilerer og integrerer systemer i økende funksjonelle enheter. Hvert element lagt til

må bestå funksjonalitetstesting; i tillegg utføres alle tidligere utførte tester på hvert design (regresjonstester).

I løpet av en enkelt iterasjon utføres systemtesting flere ganger til hele systemet er vellykket integrert (bestemt av iterasjonsmålet) og testsuksess- eller systemfullføringskriteriene er tilfredsstilt.

Testvurdering

Formålet med dette elementet i den teknologiske prosessen er å utvikle og evaluere kvantitative testtiltak som gjør det mulig å bestemme kvaliteten på måltestobjektet og testprosessen. Dette oppnås ved å gjennomgå og evaluere testresultater, identifisere og registrere endringsforespørsler og beregne viktige testtiltak.

Verktøystøtte

Fordi testing er en iterativ innsats som utføres gjennom hele utviklingssyklusen, er verktøystøtte nødvendig for å sikre at testing starter tidlig og skjer ofte; Manuell testing er ikke effektiv nok og lar deg ikke evaluere programvaren som utvikles grundig. Dette siste punktet gjelder spesielt for ytelses- og belastningstesting, hvor arbeidsbelastningen må simuleres og en betydelig mengde data må samles inn.

Rational Software Corporation tilbyr følgende verktøy for å støtte testautomatisering og testprosessen generelt.

TestStudio er et sett med verktøy som støtter utførelse av
gjennomføre tester og evaluere testresultater. TestStudio-verktøy tillater
tester for å lage testskript med grafisk grensesnitt
brukerens ansikt. Disse scenariene fokuserer på slike parametere
kvaliteter som pålitelighet, funksjon og ytelse. Inkludert i settet
TestStudio inkluderer følgende verktøy.

Robot støtter testkjøring, slik at testere kan lage og reprodusere testskript med et grafisk brukergrensesnitt og sammenligne oppnådde resultater og forventede resultater.

LogViewer fanger opp testresultater og gir en rapport for å evaluere testytelsen.

TestManager støtter testplanlegging, design og evaluering, lar deg bestemme testdekning og genererer teststatusrapporter.

TestFactory støtter pålitelighetstesting av automatisk opprettelse og utførelse av testskript. I tillegg rapporterer dette verktøyet programmatisk testdekning.

PerformanceStudio kjører virtuelle brukertestskript
body, ved hjelp av ytelsestester og enkelte funksjoner
onale tester.

DevelopmentStudio støtter testarbeidsflyten og
inkluderer følgende verktøy.

Rational Purify for å isolere vanskelige kjøretidsfeil.

Rational PureCoverage* for å identifisere områder med kode som feiler testing og utføre kodedekningsanalyse.

Rational Quantify* for å identifisere ytelsesbegrensende kodebiter.

I tillegg tilbyr Rational Unified Process verktøyveiledere for de fleste av disse verktøyene.

Sammendrag

Testing lar deg evaluere kvaliteten på det produserte produktet.

Testing er en iterativ prosess som utføres i alle faser av livet.
lang syklus; det lar deg organisere tidlig omvendt kommunikasjon om kvalitetsspørsmål
va, brukes til å forbedre produktet under utvikling og konstruksjon
nia. Testing bør ikke bare utføres ved slutten av livssyklusen
(å godta eller avvise sluttproduktet); det må være uatskillelig
en integrert del av den konstante tilbakemeldingsmekanismen.

Alle har ansvar for kvalitet. Kvalitet kan ikke innføres av testorganet
sjon. Testing er kun rettet mot å vurdere kvalitet og organisering
rettidig tilbakemelding for å forbedre kvaliteten på systemet.

Tilbyr en tilbakemeldingsmekanisme,
slik at kvaliteten kan måles og defekter identifiseres. Testing utført
foregår i tidlig fase av prosjektet - starter med planleggingsprøver og noen
andre vurdering (noen ganger utført selv i forskningsfasen) og fortsatte
vokser etter hvert som prosjektet skrider frem.

Testing av webtjenester

Den beste måten å vurdere om vi har testet et produkt godt, er å analysere feilene vi gikk glipp av. De som våre brukere, implementere og virksomheter har møtt. Basert på dem kan du evaluere mye: hva vi ikke har sjekket grundig nok, hvilke områder av produktet som bør vies mer oppmerksomhet, hva den totale prosentandelen av utelatelser er og hva dynamikken i endringene er. Med denne beregningen (kanskje den vanligste i testing) er alt bra, men... Da vi ga ut produktet og fikk vite om de tapte feilene, kan det allerede være for sent: en sint artikkel om oss dukket opp på Habré, konkurrenter er raskt spredte kritikk, vi mistet kundenes tillit til oss, ledelsen er misfornøyd.

For å forhindre at dette skjer, prøver vi vanligvis å vurdere kvaliteten på testingen på forhånd, før utgivelse: hvor godt og grundig tester vi produktet? Hvilke områder mangler oppmerksomhet, hvor er de viktigste risikoene, hva er fremgangen? Og for å svare på alle disse spørsmålene, evaluerer vi testdekningen.

Hvorfor evaluere?

Eventuelle evalueringsberegninger er bortkastet tid. På dette tidspunktet kan du teste, lage feil og forberede autotester. Hva slags magisk fordel får vi av testdekningsmålinger for å ofre testtid?

Finn dine svake områder. Naturligvis trenger vi dette? ikke bare for å sørge, men for å vite hvor forbedringer er nødvendig. Hvilke funksjonsområder dekkes ikke av tester? Hva har vi ikke sjekket? Hvor er den største risikoen for manglende feil?
Sjelden får vi 100 % basert på våre dekningsvurderingsresultater. Hva skal forbedres? Hvor skal du dra? Hva er prosenten nå? Hvordan kan vi øke den med en hvilken som helst oppgave? Hvor raskt kan vi komme til 100? Alle disse spørsmålene gir åpenhet og klarhet i prosessen vår., og svarene på dem er gitt av dekningsvurderingen.
Fokus for oppmerksomhet. La oss si at produktet vårt har rundt 50 forskjellige funksjonsområder. En ny versjon kommer ut, og vi begynner å teste 1 av dem, og vi finner skrivefeil der, og knapper som har flyttet et par piksler, og andre småting... Og nå er testtiden over, og denne funksjonaliteten er testet i detalj... Og de andre 50? Dekningsvurdering gjør at vi kan prioritere oppgaver basert på gjeldende realiteter og tidsfrister.

Hvordan evaluere?

Før du implementerer noen beregning, er det viktig å bestemme hvordan du vil bruke den. Start med å svare på akkurat dette spørsmålet - mest sannsynlig vil du umiddelbart forstå hvordan du best beregner det. Og i denne artikkelen vil jeg bare dele noen eksempler og min erfaring på hvordan dette kan gjøres. Ikke for å blindt kopiere løsninger - men slik at fantasien din er basert på denne opplevelsen, og tenke gjennom en løsning som er ideell for deg.

Vi vurderer dekningen av krav ved tester

La oss si at du har analytikere på laget ditt, og de kaster ikke bort tiden sin. arbeidstid. Basert på resultatene av arbeidet deres ble det opprettet krav i RMS (Requirements Management System) - HP QC, MS TFS, IBM Doors, Jira (med ekstra plugins), etc. De legger inn krav i dette systemet som oppfyller kravkravene (unnskyld tautologien). Disse kravene er atomære, sporbare, spesifikke... Generelt ideelle forhold for testing. Hva kan vi gjøre i dette tilfellet? Når du bruker en skripttilnærming, koble krav og tester. Vi kjører tester i samme system, lager en krav-test-kobling, og vi kan til enhver tid se en rapport om hvilke krav som har tester, hvilke som ikke har det, når disse testene ble bestått, og med hvilket resultat.
Vi får et dekningskart, vi dekker alle avdekkede krav, alle er glade og fornøyde, vi går ikke glipp av noen feil...

Ok, la oss gå tilbake fra himmelen til jorden. Mest sannsynlig har du ikke detaljerte krav, de er ikke atomære, noen av kravene er fullstendig tapt, og du har ikke tid til å dokumentere hver test, eller i det minste hver andre. Du kan fortvile og gråte, eller du kan innrømme at testing er en kompenserende prosess, og jo verre det er med analyser og utvikling på prosjektet, jo mer må vi prøve oss frem og kompensere for problemene til andre deltakere i prosessen. La oss se på problemene separat.

Problem: Kravene er ikke atomare.

Analytikere gjør også noen ganger feil i hodet, og vanligvis er dette full av problemer med hele prosjektet. For eksempel utvikler du deg tekstredigerer, og du kan ha to krav i systemet ditt (blant annet): "html-formatering må støttes" og "når du åpner en fil i et format som ikke støttes, skal et popup-vindu med et spørsmål vises." Hvor mange tester kreves for den grunnleggende verifiseringen av det første kravet? Og for 2.? Forskjellen i svar er mest sannsynlig rundt hundre ganger!!! Vi kan ikke si at hvis det er minst 1 test for 1. krav, er dette nok - men for 2. er det mest sannsynlig.

Tilstedeværelsen av en test for et krav garanterer oss derfor ingenting i det hele tatt! Hva betyr vår dekningsstatistikk i dette tilfellet? Nesten ingenting! Vi må bestemme oss!

I dette tilfellet kan den automatiske beregningen av kravdekning ved tester fjernes - den bærer fortsatt ingen semantisk belastning.
For hvert krav, starter med høyeste prioritet, utarbeider vi tester. Når vi forbereder oss, analyserer vi hvilke tester dette kravet vil kreve, hvor mange vil være nok? Vi utfører en fullverdig testanalyse, og børster den ikke av "det er én test, vel, ok."
Avhengig av systemet som brukes, eksporterer/laster vi opp tester på forespørsel og... tester disse testene! Er det nok av dem? Ideelt sett bør selvfølgelig slik testing utføres med en analytiker og utvikler av denne funksjonaliteten. Skriv ut testene, lås kollegene dine i et møterom, og ikke la dem gå før de sier «ja, disse testene er nok» (dette skjer kun med skriftlig avtale, når disse ordene sies å kvittere, selv uten analysere testene. Under en muntlig diskusjon vil kollegene helle ut kritikk, tapte tester, misforståtte krav osv. - dette er ikke alltid hyggelig, men det er veldig nyttig for testing!)
Etter å ha fullført testene etter behov og blitt enige om deres fullstendighet, kan dette kravet gis statusen "dekket av tester" i systemet. Denne informasjonen vil bety mye mer enn "det er minst 1 test her."

En slik godkjenningsprosess krever selvfølgelig mye ressurser og tid, spesielt i begynnelsen, før man får praksis. Utfør derfor kun høyprioriterte krav og nye forbedringer. Over tid vil du skjerpe de resterende kravene, og alle blir fornøyde! Men... hva om det ikke er noen krav i det hele tatt?

Problem: det er ingen krav i det hele tatt.

De er fraværende fra prosjektet, diskutert muntlig, alle gjør det han vil/kan og som han forstår. Vi tester det på samme måte. Som et resultat får vi stor mengde problemer ikke bare i testing og utvikling, men også i den opprinnelige feilimplementeringen av funksjoner - de ville ha noe helt annet! Her kan jeg anbefale alternativet «definer og dokumenter kravene selv», og jeg brukte til og med denne strategien et par ganger i min praksis, men i 99 % av tilfellene er det ikke slike ressurser i testteamet - så la oss ta mye mindre ressurskrevende rute:

Lag en funksjonsliste. Samisk! I form av et Google-skilt, i PBI-format i TFS - velg hvilket som helst, så lenge du ikke gjør det tekstformat. Vi mangler fortsatt å samle inn statuser! Vi legger til alle funksjonsområdene til produktet til denne listen, og prøver å velge ett generelt nivå dekomponering (du kan skrive ut programvareobjekter, eller brukerskript, eller moduler, eller nettsider, eller API-metoder, eller skjermskjemaer...) – men ikke alt på en gang! ETT nedbrytningsformat, som er enklere og mer visuelt for deg, lar deg ikke gå glipp av viktige ting.
Vi er enige om FULLSTENDIGHETEN til denne listen med analytikere, utviklere, næringsliv, i teamet vårt... Prøv å gjøre alt for ikke å miste viktige deler av produktet! Hvor dypt du skal analysere er opp til deg. I min praksis har det kun vært noen få produkter vi har laget mer enn 100 sider for i tabellen, og dette var gigantiske produkter. Oftest er 30-50 linjer et oppnåelig resultat for påfølgende nøye behandling. I et lite team uten dedikerte testanalytikere større antall funksjonslisteelementer vil være for vanskelige å vedlikeholde.
Etter det går vi etter prioriteringer og behandler hver linje i funksjonslisten som i kravseksjonen beskrevet ovenfor. Vi skriver prøver, diskuterer, blir enige om tilstrekkelighet. Vi markerer statusene for hvilken funksjon det er nok tester. Vi får status, fremgang og utvidelse av tester gjennom kommunikasjon med teamet. Alle er glade!

Men... Hva om kravene opprettholdes, men ikke i et sporbart format?

Problem: Kravene er ikke sporbare.

Det er en enorm mengde dokumentasjon på prosjektet, analytikere skriver med en hastighet på 400 tegn per minutt, du har spesifikasjoner, tekniske spesifikasjoner, instruksjoner, sertifikater (oftest skjer dette på forespørsel fra kunden), og alt dette fungerer som krav, og alt har vært på prosjektet i lang tid Forvirret om hvor du skal lete etter hvilken informasjon?
Vi gjentar forrige avsnitt, og hjelper hele teamet med å organisere seg!

Vi lager en funksjonsliste (se ovenfor), men uten en detaljert beskrivelse av kravene.
For hver funksjon samler vi inn lenker til tekniske spesifikasjoner, spesifikasjoner, instruksjoner og andre dokumenter.
Vi går etter prioriteringer, forbereder tester, blir enige om deres fullstendighet. Alt er det samme, bare ved å kombinere alle dokumenter i én tabell øker vi enkel tilgang til dem, transparente statuser og konsistens i tester. Til slutt er alt bra med oss og alle er fornøyde!

Men... Ikke så lenge... Det ser ut til at analytikere i løpet av den siste uken har oppdatert 4 forskjellige spesifikasjoner basert på kundeforespørsler!!!

Problem: kravene endres hele tiden.

Selvfølgelig ville det vært fint å teste et slags fast system, men produktene våre lever vanligvis. Kunden ba om noe, noe endret i lovverket utenfor produktet vårt, og et sted fant analytikere en feil i analysen for i fjor... Krav lever sitt eget liv! Hva å gjøre?

La oss si at du allerede har samlet lenker til tekniske spesifikasjoner og spesifikasjoner i form av en funksjonslistetabell, PBI, krav, Wiki-notater, etc. La oss si at du allerede har tester for disse kravene. Og nå endrer kravet seg! Dette kan bety en endring i RMS, eller en oppgave i TMS (Task Management System), eller et brev i posten. Uansett fører dette til samme konsekvens: testene dine er irrelevante! Eller de er kanskje ikke relevante. Dette betyr at de krever oppdatering (å dekke den gamle versjonen av produktet med tester teller på en eller annen måte ikke, ikke sant?)
I featurelist, i RMS, i TMS (Test Management System – testrails, sitechco, etc) må tester nødvendigvis og umiddelbart merkes som irrelevante! I HP QC eller MS TFS kan dette gjøres automatisk ved oppdatering av krav, men i en Google-plate eller wiki må du legge det inn manuelt. Men du bør se med en gang: tester er irrelevante! Dette betyr at vi står overfor en fullstendig gjentatt bane: oppdater, kjør testanalysen på nytt, skriv testene på nytt, bli enige om endringene, og først etter det merker funksjonen/kravet igjen som "dekket av tester".

I dette tilfellet får vi alle fordelene med testdekningsevaluering, og i dynamikk! Alle er glade!!! Men…
Men du har brukt så mye tid på å jobbe med krav at du nå ikke har nok tid til verken å teste eller dokumentere tester. Etter min mening (og det er rom for en religiøs tvist her!) er krav viktigere enn prøver, og det er bedre sånn! De er i hvert fall ok, og hele teamet er klar over, og utviklerne gjør akkurat det som trengs. MEN DET ER IKKE TID IGJEN TIL Å DOKUMENTERE TESTER!

Problem: Det er ikke nok tid til å dokumentere tester.

Faktisk kan kilden til dette problemet ikke bare være mangel på tid, men også ditt svært bevisste valg om ikke å dokumentere dem (vi liker dem ikke, vi unngår effekten av et plantevernmiddel, produktet endres for ofte osv.) .). Men hvordan evaluere testdekningen i dette tilfellet?

Du trenger fortsatt kravene, enten som fullstendige krav eller som en funksjonsliste, så noen av seksjonene beskrevet ovenfor, avhengig av analytikernes arbeid med prosjektet, vil fortsatt være nødvendige. Har du kravene/funksjonslisten?
Vi beskriver og blir muntlig enige om teststrategien, uten å dokumentere konkrete tester! Denne strategien kan spesifiseres i en tabellkolonne, på en wiki-side eller i et krav i RMS, og må igjen avtales. Denne strategien vil teste annerledes, men du vil vite: Når ble denne sist testet og med hvilken strategi? Og dette, skjønner du, er heller ikke dårlig! Og alle vil være glade.

Men… Hva annet "men"? Hvilken???

Si at vi kommer rundt alt, og kanskje kvalitetsprodukter er med oss!