Test – hvem har brug for det og hvorfor? Teknologisk testproces.

Softwaretest identificerer fejl, mangler og fejl i koden, som skal elimineres. Det kan også defineres som evalueringsprocessen funktionalitet og software korrekthed gennem analyse. De vigtigste metoder til integration og test af softwareprodukter sikrer applikationernes kvalitet og består af kontrol af specifikation, design og kode, vurdering af pålidelighed, validering og verifikation.

Metoder

Hovedformålet med softwaretest er at bekræfte kvaliteten softwarepakke ved systematisk at fejlsøge applikationer under nøje kontrollerede forhold, bestemme deres fuldstændighed og korrekthed og opdage skjulte fejl.

Metoder kan opdeles i statiske og dynamiske.

Førstnævnte omfatter uformel, kontrol og teknisk gennemgang, inspektion, gennemgang, revision og statisk analyse af dataflow og kontrol.

De dynamiske teknikker er som følger:

1. Hvid boks test. Dette er en detaljeret undersøgelse af den interne logik og struktur i et program. Dette kræver viden om kildekoden.
2. Black box test. Denne teknik kræver ikke nogen viden om applikationens interne funktion. Kun de vigtigste aspekter af systemet, som ikke er relaterede eller har ringe forbindelse med dets interne logiske struktur, tages i betragtning.
3. Grå kasse metode. Kombinerer de to foregående tilgange. Fejlretning med begrænset viden om applikationens interne funktion kombineres med viden om de grundlæggende aspekter af systemet.

Gennemsigtig test

White box-metoden bruger testscripts til at kontrollere strukturen af ​​et proceduredesign. Denne teknik giver dig mulighed for at identificere implementeringsfejl, såsom dårlig kodestyring, ved at analysere den interne funktion af et stykke software. Disse testmetoder er anvendelige på integrations-, modul- og systemniveau. Testeren skal have adgang til kildekoden og ved hjælp af den finde ud af, hvilken blok der opfører sig upassende.

White box test af programmer har følgende fordele:

• giver dig mulighed for at identificere fejl i skjult kode, når du fjerner ekstra linjer;
• mulighed for bivirkninger;
• maksimal dækning opnås ved at skrive et testscript.

Fejl:

• en meget bekostelig proces, der kræver en kvalificeret debugger;
• mange stier vil forblive uudforskede, da en grundig kontrol af alle mulige skjulte fejl er meget vanskelig;
• noget af den manglende kode vil forblive ubemærket.

White box test kaldes nogle gange også transparent eller transparent test. åben boks, strukturel, logisk testning, test baseret på kildetekster, arkitektur og logik.

Vigtigste sorter:

1) flowkontrol test - en struktureret strategi, der bruger program kontrol flow som model og prioriterer mere enkle måder før et mindre antal mere komplekse;

2) filialfejlretning har til formål at undersøge hver mulighed (sand eller falsk) for hver kontrolerklæring, som også inkluderer den kombinerede beslutning;

3) grundlæggende stitest, som gør det muligt for testeren at etablere et mål for den logiske kompleksitet af et proceduredesign for at identificere et grundlæggende sæt af eksekveringsstier;

4) dataflowkontrol - en strategi til undersøgelse af kontrolflow ved at annotere grafen med information om erklæringen og brugen af ​​programvariabler;

5) cyklustest - helt fokuseret på den korrekte udførelse af cykliske procedurer.

Behavioural debugging

Black box-test behandler software som en "black box" - information om programmets interne funktion tages ikke i betragtning, og kun de vigtigste aspekter af systemet testes. I dette tilfælde skal testeren kende systemarkitekturen uden adgang til kildekoden.

Fordele ved denne tilgang:

• effektivitet for et stort kodesegment;
• let perception af testeren;
• Brugerens perspektiv er klart adskilt fra udviklerens perspektiv (programmør og tester er uafhængige af hinanden);
• hurtigere testoprettelse.

Test af programmer ved hjælp af black box-metoder har følgende ulemper:

• i virkeligheden udføres et udvalgt antal testsager, hvilket resulterer i begrænset dækning;
• manglen på en klar specifikation gør det vanskeligt at udvikle testcases;
• lav effektivitet.

Andre navne for denne teknik er adfærdstestning, uigennemsigtig test, funktionel testning og lukket boks debugging.

1) ækvivalent partitionering, som kan reducere testdatasættet, da inputdata fra softwaremodulet er opdelt i separate dele;

2) kantanalyse fokuserer på at teste grænser eller ekstreme grænseværdier - minimum, maksimum, fejl og typiske værdier;

3) fuzzing - bruges til at søge efter implementeringsfejl ved at indtaste forvrængede eller semi-forvrængede data i automatisk eller semi-automatisk tilstand;

4) grafer over årsag-virkningsforhold - en teknik baseret på at skabe grafer og etablere en sammenhæng mellem en handling og dens årsager: identitet, negation, logisk ELLER og logisk OG - fire grundlæggende symboler, der udtrykker den indbyrdes afhængighed mellem årsag og virkning;

5) test af ortogonale arrays, anvendt på problemer med et relativt lille inputområde, der overstiger mulighederne for en udtømmende undersøgelse;

6) test af alle par - en teknik, hvis sæt af testværdier inkluderer alle mulige diskrete kombinationer af hvert par af inputparametre;

Black Box-test: Eksempler

Teknikken er baseret på specifikationer, dokumentation og beskrivelser af softwaren eller systemgrænsefladen. Derudover er det muligt at bruge modeller (formelle eller uformelle), der repræsenterer softwarens forventede adfærd.

Denne fejlfindingsmetode bruges typisk til brugergrænseflader og kræver interaktion med applikationen ved at indtaste data og indsamle resultater - fra skærmen, fra rapporter eller udskrifter.

Testeren interagerer således med softwaren gennem input, betjeningskontakter, knapper eller andre grænseflader. Valget af inputdata, rækkefølgen de indtastes i eller rækkefølgen af ​​handlinger kan føre til et gigantisk samlet antal kombinationer, som det kan ses i det følgende eksempel.

Hvor mange tests skal udføres for at kontrollere alle mulige værdier for 4 afkrydsningsfelter og et felt med to positioner, der angiver tiden i sekunder? Ved første øjekast er beregningen enkel: 4 felter med to mulige tilstande - 24 = 16, som skal ganges med antallet af mulige positioner fra 00 til 99, det vil sige 1600 mulige tests.

Denne beregning er imidlertid fejlbehæftet: Vi kan definere, at et felt med to positioner også kan indeholde et mellemrum, dvs. det består af to alfanumeriske positioner og kan indeholde alfabetiske tegn, specialtegn, mellemrum osv. Hvis systemet således er en 16. -bit computer, der er 216 = 65.536 muligheder for hver position, hvilket resulterer i 4.294.967.296 testtilfælde, som skal ganges med 16 kombinationer for flagene, hvilket giver i alt 68.719.476.736. med en hastighed på 1 test pr. sekund, den samlede testvarighed bliver 2.177,5 år. For 32 eller 64-bit systemer er varigheden endnu længere.

Derfor er der behov for at reducere denne periode til en acceptabel værdi. Der skal således anvendes teknikker til at reducere antallet af testtilfælde uden at reducere testdækningen.

Tilsvarende partition

Ækvivalent partitionering er en simpel teknik, der kan anvendes til enhver variabel, der findes i softwaren, hvad enten det er input- eller outputværdier, symbolske, numeriske osv. Den er baseret på princippet om, at alle data fra den samme ækvivalente partition vil blive behandlet på samme måde og efter de samme instruktioner.

Under testning vælges en repræsentant fra hver defineret ækvivalent partition. Dette giver dig mulighed for systematisk at reducere antallet af mulige testsager uden at miste kommando- og funktionsdækning.

En anden konsekvens af denne opdeling er reduktionen af ​​kombinatorisk eksplosion mellem forskellige variable og den tilhørende reduktion af testcases.

For eksempel, i (1/x)1/2 bruges tre datasekvenser, tre ækvivalente partitioner:

1. Alle positive tal vil blive behandlet på samme måde og bør give korrekte resultater.

2. Alle negative tal vil blive behandlet på samme måde, med samme resultat. Dette er forkert, fordi roden af ​​et negativt tal er imaginær.

3. Nul vil blive behandlet separat og vil give en division med nul fejl. Dette er et afsnit med enkelt betydning.

Så vi ser tre forskellige afsnit, hvoraf den ene koger ned til en enkelt betydning. Der er en "korrekt" sektion, som giver pålidelige resultater, og to "forkerte" med forkerte resultater.

Regional analyse

Databehandling ved tilsvarende partitionsgrænser kan udføres anderledes end forventet. Grænseværdistudier er en velkendt måde at analysere softwareadfærd på i sådanne områder. Denne teknik giver dig mulighed for at identificere følgende fejl:

• forkert brug af relationelle operatorer (<,>, =, ≠, ≥, ≤);
• enkelte fejl;
• problemer med loops og iterationer,
• ukorrekte typer eller størrelser af variabler, der bruges til at lagre information;
• kunstige restriktioner forbundet med data og variabeltyper.

Gennemsigtig test

Den grå boks-metode øger dækningen af ​​revisionen, så du kan fokusere på alle niveauer komplekst system ved at kombinere hvide og sorte metoder.

Ved brug af denne teknik skal testeren have kendskab til indre strukturer data og algoritmer. Eksempler på testteknikker i grå boks er:

• arkitektonisk model;
• Unified Modeling Language (UML);
• tilstandsmodel (finite state machine).

I den grå boks-metode studeres modulernes koder ved hjælp af den hvide teknik til at udvikle testcases, og selve testen udføres på programgrænsefladerne ved hjælp af den sorte teknik.

Sådanne testmetoder har følgende fordele:

• at kombinere fordelene ved hvide og sorte boksteknikker;
• testeren er afhængig af grænsefladen og funktionelle specifikationer snarere end på kildekoden;
• debuggeren kan skabe fremragende testscripts;
• verifikation udføres fra brugerens synspunkt, ikke programdesigneren;
• oprettelse af tilpassede testudviklinger;
• objektivitet.

Fejl:

• testdækning er begrænset på grund af manglende adgang til kildekoden;
• vanskeligheder med at opdage defekter i distribuerede applikationer;
• mange stier forbliver uudforskede;
• hvis softwareudvikleren allerede har kørt testen, kan yderligere undersøgelse være overflødig.

Et andet navn for den grå boks-teknikken er gennemsigtig debugging.

1) ortogonalt array - ved hjælp af en delmængde af alle mulige kombinationer;

2) matrix debugging ved hjælp af programtilstandsdata;

3) udføres, når der foretages nye ændringer i softwaren;

4) en skabelontest, der analyserer design og arkitektur af en god applikation.

software test

Brugen af ​​alle dynamiske metoder fører til en kombinatorisk eksplosion i antallet af tests, der skal designes, implementeres og udføres. Hver teknik bør bruges pragmatisk under hensyntagen til dens begrænsninger.

Der er ikke en enkelt korrekt metode, kun dem, der passer bedre til en bestemt kontekst. Strukturelle teknikker kan finde ubrugelig eller ondsindet kode, men de er komplekse og ikke anvendelige til store programmer. Specifikationsbaserede metoder er de eneste, der er i stand til at identificere manglende kode, men de kan ikke identificere outliers. Nogle teknikker er mere egnede til et bestemt testniveau, fejltype eller kontekst end andre.

Nedenfor er de vigtigste forskelle mellem de tre dynamiske testteknikker - en sammenligningstabel mellem de tre former for softwarefejlfinding er givet.

Aspekt	Black box metode	Grå kasse metode	White box metode
Tilgængelighed af information om programmets sammensætning	Kun grundlæggende aspekter analyseres	Delvis viden om indre struktur programmer	Fuld adgang til kildekoden
Grad af programfragmentering
Hvem foretager fejlretningen?	Slutbrugere, testere og udviklere	Slutbrugere, debuggere og udviklere	Udviklere og testere
	Test er baseret på eksterne nødsituationer.	Databasediagrammer, dataflowdiagrammer, interne tilstande, kendskab til algoritme og arkitektur	Den indre struktur er fuldstændig kendt
Dækning	Mindst omfattende og kræver minimal tid		Potentielt den mest omfattende. Tager meget tid
Data og interne grænser	Fejlretning udelukkende ved forsøg og fejl	Datadomæner og interne grænser kan kontrolleres, hvis de er kendt	Bedre test af datadomæner og interne grænser
Egnethed til at teste algoritmen

Automatisering

Automatiserede softwaretestmetoder forenkler i høj grad verifikationsprocessen, uanset det tekniske miljø eller softwarekontekst. De bruges i to tilfælde:

1) at automatisere kedelige, gentagne eller omhyggelige opgaver, såsom at sammenligne filer på flere tusinde linjer, for at frigøre testerens tid til at koncentrere sig om vigtigere punkter;

2) at udføre eller spore opgaver, som ikke let kan udføres af mennesker, såsom præstationstest eller responstidsanalyse, som kan måles i hundrededele af et sekund.

Testinstrumenter kan klassificeres på forskellige måder. Følgende opdeling er baseret på de opgaver, de understøtter:

• teststyring, som omfatter support til projektstyring, versionsstyring, konfigurationsstyring, risikoanalyse, testsporing, fejl, defekter og rapporteringsværktøjer;
• kravstyring, som omfatter lagring af krav og specifikationer, kontrol af dem for fuldstændighed og tvetydighed, deres prioritet og sporbarhed af hver test;
• kritisk gennemgang og statisk analyse, herunder overvågning af flow og opgaver, registrering og lagring af kommentarer, detektering af defekter og planlagte rettelser, håndtering af referencer til tjeklister og regler, sporing af forholdet mellem kildedokumenter og kode, statisk analyse med detektering af defekter, sikring af overholdelse af kodningsstandarder , analyse af strukturer og deres afhængigheder, beregning af metriske parametre for kode og arkitektur. Derudover anvendes compilere, linkanalysatorer og krydsreferencegeneratorer;
• modellering, som omfatter værktøjer til modellering af forretningsadfærd og afprøvning af de skabte modeller;
• testudvikling sikrer generering af forventede data baseret på betingelser og brugergrænseflade, modeller og kode, deres styring til at oprette eller ændre filer og databaser, beskeder, dataverifikation baseret på ledelsesregler, analyse af statistik over forhold og risici;
• kritisk gennemgang ved at indtaste data via GUI, API, kommandolinjer brug af komparatorer til at hjælpe med at bestemme vellykkede og mislykkede tests;
• understøttelse af fejlfindingsmiljøer, der giver dig mulighed for at erstatte manglende hardware eller software, inklusive hardwaresimulatorer baseret på en delmængde af deterministisk output, terminalemulatorer, mobiltelefoner eller netværksudstyr,miljøer til test af sprog, OS og hardware ved at erstatte,manglende komponenter med drivere, dummy-moduler osv., samt værktøjer til at opsnappe og ændre OS-anmodninger, simulere,CPU, RAM, ROM eller netværksbegrænsninger;
• sammenligning af datafiler, databaser, kontrol af forventede resultater under og efter test, herunder dynamisk og batch-sammenligning, automatiske "orakler";
• dækningsmåling for at lokalisere hukommelseslækager og ukorrekt hukommelsesstyring, evaluere systemadfærd under simulerede belastningsforhold, generere applikations-, database-, netværks- eller serverbelastninger under realistiske scenarier for dets vækst, for at måle, analysere, kontrollere og rapportere om systemressourcer;
• sikkerhed;
• ydeevnetest, belastningstest og dynamisk analyse;
• andre værktøjer, inklusive stave- og syntakskontrol, netværkssikkerhed, tilgængelighed af alle webstedssider osv.

Perspektiv

Efterhånden som trends i softwareindustrien ændrer sig, kan fejlretningsprocessen også ændre sig. Eksisterende nye metoder til test af softwareprodukter, såsom serviceorienteret arkitektur (SOA), trådløse teknologier, mobiltjenester osv., har åbnet op for nye måder at teste software på. Nogle af de ændringer, der forventes i denne branche i løbet af de næste par år, er anført nedenfor:

• testere vil levere letvægtsmodeller, som udviklere kan tjekke deres kode med;
• udviklingen af ​​testmetoder, der omfatter visning og simulering af programmer på et tidligt tidspunkt, vil fjerne mange uoverensstemmelser;
• tilstedeværelsen af ​​mange testaflytninger vil reducere tiden til at opdage fejl;
• statiske analysatorer og detektionsværktøjer vil blive brugt mere udbredt;
• anvendelsen af ​​nyttige matricer såsom specifikationsdækning, modeldækning og kodedækning vil guide projektudviklingen;
• kombinatoriske værktøjer vil give testere mulighed for at bestemme prioriterede områder for fejlretning;
• testere vil levere mere synlige og værdifulde tjenester gennem hele softwareudviklingsprocessen;
• debuggere vil være i stand til at skabe softwaretestværktøjer og -teknikker skrevet i og interoperable med forskellige sprog programmering;
• Fejlretningsspecialister vil blive mere professionelt uddannede.

Nye forretningsorienterede metoder til at teste programmer vil komme til at erstatte dem, og ændre den måde, vi interagerer med systemer og den information, de leverer, samtidig med at de reducerer risici og øger fordelene ved forretningsændringer.

• Tutorial

God dag!

Jeg vil samle al den mest nødvendige teori om test, som bliver spurgt til under interviews med praktikanter, juniorer og lidt mellemste. Faktisk har jeg allerede samlet en del. Formålet med dette indlæg er samlet at tilføje det manglede og rette/parafrasere/tilføje/gøre Noget Andet med det der allerede er, så det bliver godt og du kan tage det hele og gentage det inden næste interview, for en sikkerheds skyld . Generelt, kolleger, spørger jeg under snittet, hvem der skal lære noget nyt, hvem der skal systematisere det gamle, og hvem der skal bidrage.

Resultatet skal være et omfattende snydeark, som du skal genlæse på vej til interviewet.

Alt det nedenstående er ikke opfundet af mig personligt, men er hentet fra forskellige kilder, hvor jeg personligt kunne lide formuleringen og definitionen mere. Til sidst er en liste over kilder.

Emne: definition af test, kvalitet, verifikation/validering, mål, stadier, testplan, testplanpunkter, testdesign, testdesignteknikker, sporbarhedsmatrix, tets-case, tjekliste, defekt, fejl/effekt/fejl, fejlrapport, alvorlighed vs prioritet, testniveauer, typer/typer, tilgange til integrationstestning, testprincipper, statisk og dynamisk test, eksplorativ/ad-hoc test, krav, fejllivscyklus, softwareudviklingsstadier, beslutningstabel, qa/qc/testingeniør, tilslutningsdiagram.

Gå!

Software test- kontrol af overensstemmelsen mellem den faktiske og forventede opførsel af programmet, udført på et begrænset sæt af test udvalgt på en bestemt måde. I en bredere forstand er test en af ​​kvalitetskontrolteknikkerne, der omfatter aktiviteterne med arbejdsplanlægning (Test Management), testdesign (Test Design), testudførelse (Test Execution) og analyse af resultaterne (Test Analyse).

Software kvalitet er et sæt af karakteristika ved software relateret til dets evne til at tilfredsstille erklærede og forventede behov.

Verifikation er processen med at evaluere et system eller dets komponenter for at afgøre, om resultaterne af den aktuelle udviklingsfase opfylder de betingelser, der blev dannet i begyndelsen af ​​denne fase. De der. om vores mål, deadlines og projektudviklingsopgaver defineret i begyndelsen af ​​den aktuelle fase bliver overholdt.
Validering- dette er en vurdering af, om den software, der udvikles, lever op til brugerens forventninger og behov samt systemkrav.
Du kan også finde en anden fortolkning:
Processen med at vurdere et produkts overensstemmelse med eksplicitte krav (specifikationer) er verifikation, samtidig med at vurdering af produktets overensstemmelse med brugernes forventninger og krav er validering. Du kan også ofte finde følgende definition af disse begreber:
Validering – ‘er det her den rigtige specifikation?’.
Verifikation - 'er systemet korrekt i henhold til specifikationen?'.

Testmål
Øg sandsynligheden for, at den applikation, der er beregnet til test, vil fungere korrekt under alle omstændigheder.
Øg sandsynligheden for, at den applikation, der testes, opfylder alle de beskrevne krav.
Giver ajourførte oplysninger om produktets aktuelle tilstand.

Teststadier:
1. Analyse
2. Udvikling af en teststrategi
og planlægning af kvalitetskontrolprocedurer
3. Arbejde med krav
4. Oprettelse af testdokumentation
5. Prototypetest
6. Grundlæggende test
7. Stabilisering
8. Betjening

Testplan- dette er et dokument, der beskriver hele omfanget af testarbejdet, startende fra en beskrivelse af objektet, strategien, tidsplanen, kriterierne for start og afslutning af test, til det nødvendige udstyr i arbejdet, særlig viden, samt risikovurderinger med muligheder for deres løsning.
Besvarer spørgsmålene:
Hvad skal testes?
Hvad vil du teste?
Hvordan vil du teste?
Hvornår vil du teste?
Kriterier for start af test.
Kriterier for testgennemførelse.

Hovedpunkter i testplanen
IEEE 829-standarden angiver de punkter, som en testplan bør (kan) bestå af:
a) Identifikation af testplan;
b) Introduktion;
c) Testartikler;
d) Egenskaber, der skal testes;
e) Egenskaber, der ikke skal testes;
f) Tilnærmelse;
g) Element bestået/ikke bestået kriterier;
h) Suspensionskriterier og genoptagelseskrav;
i) Test leverancer;
j) Testopgaver;
k) Miljømæssige behov;
l) Ansvar;
m) Bemanding og uddannelsesbehov;
n) Tidsplan;
o) Risici og uforudsete begivenheder;
p) Godkendelser.

Test design- dette er stadiet i softwaretestprocessen, hvor testcases (testcases) designes og skabes i overensstemmelse med tidligere definerede kvalitetskriterier og testmål.
Roller ansvarlige for testdesign:
Testanalytiker - bestemmer "HVAD skal teste?"
Testdesigner - bestemmer "HVORDAN testes?"

Test designteknikker

Equivalence Partitioning (EP). For eksempel, hvis du har en række gyldige værdier fra 1 til 10, skal du vælge en korrekt værdi inden for intervallet, f.eks. 5, og en forkert værdi uden for intervallet, 0.

Grænseværdianalyse (BVA). Hvis vi tager eksemplet ovenfor, vil vi vælge minimums- og maksimumgrænserne (1 og 10) som værdier for positiv test, og værdier større og mindre end grænserne (0 og 11). Grænseværdianalyse kan anvendes på felter, poster, filer eller enhver form for begrænset enhed.

Årsag/virkning - CE. Dette er som regel at indtaste kombinationer af betingelser (årsager) for at opnå et svar fra systemet (Effekt). For eksempel tester du muligheden for at tilføje en kunde ved hjælp af et specifikt display. For at gøre dette skal du indtaste flere felter såsom "Navn", "Adresse", "Telefonnummer" og derefter klikke på knappen "Tilføj" - dette er "årsagen". Efter at have klikket på knappen "Tilføj", tilføjer systemet klienten til databasen og viser hans nummer på skærmen - dette er "Undersøgelse".

Udtømmende test (ET)- det er et ekstremt tilfælde. Inden for denne teknik bør du teste alle mulige kombinationer af inputværdier, og i princippet skal dette finde alle problemer. I praksis er brugen af ​​denne metode ikke mulig på grund af det store antal inputværdier.

Sporbarhedsmatrix- Kravoverholdelsesmatrixen er en todimensionel tabel, der indeholder overensstemmelsen mellem produktets funktionelle krav og de forberedte testcases. Tabelkolonneoverskrifterne indeholder krav, og rækkeoverskrifterne indeholder testscenarier. I krydset er der et mærke, der angiver, at kravet til den aktuelle kolonne er dækket af den aktuelle rækkes testcase.
Kravoverholdelsesmatrixen bruges af QA-ingeniører til at validere produkttestdækning. MCT er en integreret del af testplanen.

Test sag er en artefakt, der beskriver et sæt trin, specifikke betingelser og parametre, der er nødvendige for at kontrollere implementeringen af ​​den testede funktion eller dens del.
Eksempel:
Handling Forventet resultat Testresultat
(bestået/ikke bestået/blokeret)
Åbn side "login" Login-siden åbnes Bestået

Hver testcase skal have 3 dele:
Forudbetingelser En liste over handlinger, der bringer systemet til en tilstand, der er egnet til grundlæggende test. Eller en liste over betingelser, hvis opfyldelse indikerer, at systemet er i en tilstand, der er egnet til at udføre hovedtesten.
Test Case Beskrivelse En liste over handlinger, der overfører systemet fra en tilstand til en anden for at opnå et resultat, på grundlag af hvilket det kan konkluderes, at implementeringen opfylder kravene
PostConditions Liste over handlinger, der overfører systemet til starttilstanden (tilstand før testen - starttilstand)
Typer af testcases:
Testtilfælde er opdelt efter det forventede resultat i positive og negative:
Et positivt testtilfælde bruger kun korrekte data og verificerer, at applikationen udførte den kaldte funktion korrekt.
Et negativt testtilfælde fungerer med både korrekte og forkerte data (mindst 1 forkert parameter) og har til formål at tjekke for ekstraordinære situationer (validatorer udløses), og også kontrollere, at den funktion, som applikationen kalder, ikke udføres, når validatoren udløses.

Tjekliste er et dokument, der beskriver, hvad der skal testes. I dette tilfælde kan tjeklisten være absolut forskellige niveauer detaljering. Hvor detaljeret tjeklisten vil være afhænger af rapporteringskrav, medarbejdernes produktkendskabsniveau og produktets kompleksitet.
Som regel indeholder en tjekliste kun handlinger (trin), uden det forventede resultat. Tjeklisten er mindre formaliseret end testscriptet. Det er hensigtsmæssigt at bruge det, når testscripts er overflødige. Tjeklister er også forbundet med fleksible tilgange til test.

Defekt (alias fejl)- dette er en uoverensstemmelse mellem det faktiske resultat af programudførelsen og det forventede resultat. Fejl opdages under softwaretestfasen, når testeren sammenligner resultaterne af programmet (komponent eller design) med det forventede resultat beskrevet i kravspecifikationen.

Fejl- brugerfejl, det vil sige, at han forsøger at bruge programmet på en anden måde.
Eksempel - indtaster bogstaver i felter, hvor du skal indtaste tal (alder, varemængde osv.).
I kvalitets program Sådanne situationer er tilvejebragt, og der udsendes en fejlmeddelelse med et rødt kryds.
Fejl (defekt)- en fejl fra programmøren (eller designeren eller enhver anden, der deltager i udviklingen), altså når noget i programmet ikke går som planlagt, og programmet kommer ud af kontrol. For eksempel, når brugerinput ikke kontrolleres på nogen måde, forårsager forkerte data som følge heraf nedbrud eller andre "glæder" i driften af ​​programmet. Eller programmet er internt bygget sådan, at det i første omgang ikke svarer til, hvad der forventes af det.
Fiasko- en fejl (og ikke nødvendigvis en hardware) i driften af ​​en komponent, et helt program eller system. Det vil sige, at der er defekter, der fører til fejl (En defekt forårsagede fejlen), og der er dem, der ikke gør. UI-defekter for eksempel. Men hardwarefejl, som ikke har noget med software at gøre, er også en fiasko.

Fejlrapport er et dokument, der beskriver situationen eller rækkefølgen af ​​handlinger, der førte til den forkerte betjening af testobjektet, med angivelse af årsagerne og det forventede resultat.
en hue
Kort beskrivelse (resumé) En kort beskrivelse af problemet, der tydeligt angiver årsagen og typen af ​​fejlsituation.
Projekt Navn på det projekt, der testes
Application Component (Component) Navnet på den del eller funktion af produktet, der testes
Versionsnummer Den version, hvor fejlen blev fundet
Alvor Det mest almindelige system med fem niveauer til at vurdere sværhedsgraden af ​​en defekt er:
S1 Blocker
S2 Kritisk
S3 Major
S4 mindre
S5 trivielt
Prioritet Defektens prioritet:
P1 Høj
P2 Medium
P3 Lav
Status Status for fejlen. Afhænger af den anvendte procedure og livscyklus fejl arbejdsgang og livscyklus

Forfatter (Forfatter) Skaber af fejlrapport
Tildelt til Navnet på den person, der er tildelt problemet.
Miljø
OS / Service Pack osv. / Browser + version /... Oplysninger om det miljø, hvori fejlen blev fundet: operativsystem, service pack, til WEB-test - browsernavn og version mv.
…
Beskrivelse
Trin til gengivelse Trin, hvormed du nemt kan genskabe den situation, der førte til fejlen.
Faktisk resultat Resultatet opnået efter at have gennemgået trinene for at reproducere
Forventet resultat Forventet korrekt resultat
Tilføjelser
Vedhæftet fil En logfil, et skærmbillede eller ethvert andet dokument, der kan hjælpe med at afklare årsagen til fejlen eller angive en måde at løse problemet på.

Sværhedsgrad vs prioritet
Alvorlighed er en egenskab, der karakteriserer virkningen af ​​en defekt på en applikations ydeevne.
Prioritet er en egenskab, der angiver prioritet for at udføre en opgave eller eliminere en defekt. Vi kan sige, at dette er et arbejdsplanlægningsleders værktøj. Jo højere prioritet, jo hurtigere skal fejlen rettes.
Sværhedsgraden afsløres af testeren
Prioritet - leder, teamleder eller kunde

Gradering af defekts sværhedsgrad (alvorlighed)

S1 Blocker
En blokeringsfejl, der gør applikationen ude af drift, hvilket gør yderligere arbejde med systemet under test eller dets nøglefunktioner umuligt. Løsning af problemet er nødvendig for den videre funktion af systemet.

S2 Kritisk
En kritisk fejl, en defekt nøgleforretningslogik, et hul i sikkerhedssystemet, et problem, der førte til et midlertidigt nedbrud af serveren eller gjorde en del af systemet ude af drift, uden mulighed for at løse problemet ved hjælp af andre indgangspunkter. Løsning af problemet er nødvendig for yderligere arbejde med nøglefunktioner i det system, der testes.

S3 Major
En væsentlig fejl, en del af hovedforretningslogikken fungerer ikke korrekt. Fejlen er ikke kritisk, eller det er muligt at arbejde med funktionen under test ved hjælp af andre inputpunkter.

S4 mindre
En mindre fejl, der ikke krænker forretningslogikken i den del af applikationen, der testes, et åbenlyst problem med brugergrænsefladen.

S5 trivielt
En triviel fejl, der ikke påvirker applikationens forretningslogik, et dårligt reproducerbart problem, der næppe er mærkbart gennem brugergrænsefladen, et problem med tredjeparts biblioteker eller tjenester, et problem, der ikke har nogen indflydelse på den overordnede kvalitet af produktet.

Gradering af defektprioritet (Prioritet)
P1 Høj
Fejlen skal rettes hurtigst muligt, fordi... dens tilstedeværelse er afgørende for projektet.
P2 Medium
Fejlen skal rettes, dens tilstedeværelse er ikke kritisk, men kræver en obligatorisk løsning.
P3 Lav
Fejlen skal rettes, dens tilstedeværelse er ikke kritisk og kræver ikke en hasteløsning.

Test niveauer

1. Enhedstest
Komponent-(enheds-)testning kontrollerer funktionaliteten og leder efter defekter i dele af applikationen, som er tilgængelige og kan testes separat (programmoduler, objekter, klasser, funktioner osv.).

2. Integrationstest
Samspillet mellem systemkomponenter kontrolleres efter komponenttest.

3. Systemtest
Hovedformålet med systemtest er at verificere både funktionelle og ikke-funktionelle krav i systemet som helhed. Dette identificerer defekter såsom forkert brug af systemressourcer, utilsigtede kombinationer af data på brugerniveau, inkompatibilitet med miljøet, utilsigtede brugstilfælde, manglende eller forkert funktionalitet, besvær ved brug osv.

4. Operationel test (Release Testing).
Selvom et system opfylder alle krav, er det vigtigt at sikre, at det opfylder brugerens behov og opfylder sin rolle i dets driftsmiljø som defineret i systemets forretningsmodel. Det skal tages i betragtning, at forretningsmodellen kan indeholde fejl. Derfor er det så vigtigt at driftstest som det sidste valideringstrin. Derudover giver test i driftsmiljøet os mulighed for at identificere ikke-funktionelle problemer, såsom: konflikter med andre systemer relateret til forretningsområdet eller i software og elektroniske miljøer; utilstrækkelig systemydelse i driftsmiljøet osv. Det er klart, at det er et kritisk og dyrt problem at finde sådanne ting på implementeringsstadiet. Derfor er det så vigtigt at udføre ikke kun verifikation, men også validering, fra de tidligste stadier af softwareudvikling.

5. Accepttest
En formel testproces, der verificerer, at et system opfylder kravene og udføres for at:
at bestemme, om systemet opfylder acceptkriterier;
træffe afgørelse af kunden eller anden autoriseret person, om ansøgningen accepteres eller ej.

Typer/typer af test

Funktionelle typer af test
Funktionstest
Test af sikkerhed og adgangskontrol
Interoperabilitetstest

Ikke-funktionelle typer af test
Alle typer præstationstest:
o belastningstest (ydeevne og belastningstest)
o Stresstest
o Stabilitets-/pålidelighedstest
o Volumentestning
Installationstest
Usability test
Failover og gendannelsestest
Konfigurationstest

Ændringsrelaterede testtyper
Røgtestning
Regressionstest
Gentestning
Build Verification Test
Sanitetstest

Funktionstest overvejer forudbestemt adfærd og er baseret på en analyse af specifikationerne for funktionaliteten af ​​komponenten eller systemet som helhed.

Sikkerhedstest er en teststrategi, der bruges til at kontrollere systemets sikkerhed, samt til at analysere de risici, der er forbundet med at levere en holistisk tilgang til beskyttelse af applikationen, angreb fra hackere, vira, uautoriseret adgang til fortrolige data.

Interoperabilitetstest er funktionel test, der tester en applikations evne til at interagere med en eller flere komponenter eller systemer og inkluderer kompatibilitetstest og integrationstest

Stresstest- dette er automatiseret test, der simulerer arbejde et vist beløb brugernes virksomhed på enhver fælles (delt) ressource.

Stresstest giver dig mulighed for at kontrollere, hvor effektiv applikationen og systemet som helhed er under stress og også evaluere systemets evne til at regenerere, dvs. at vende tilbage til normal efter ophør af stress. Stress i denne sammenhæng kan være en stigning i intensiteten af ​​operationer til meget høje værdier eller en nødsituation ændring i serverkonfigurationen. En af stresstestens opgaver kan også være at vurdere præstationsforringelse, så målene for stresstest kan overlappe med målene for præstationstestning.

Volumentestning. Formålet med volumentest er at opnå en vurdering af ydeevnen, efterhånden som mængden af ​​data i applikationsdatabasen stiger

Stabilitets-/pålidelighedstest. Opgaven med stabilitet (pålidelighed) test er at kontrollere funktionaliteten af ​​applikationen under langsigtede (mange timer) test med et gennemsnitligt belastningsniveau.

Test af installationen rettet mod at verificere vellykket installation og konfiguration samt at opdatere eller afinstallere software.

Usability test er en testmetode, der har til formål at fastslå graden af ​​brugervenlighed, indlæringsevne, forståelighed og attraktivitet for brugere af det produkt, der udvikles i sammenhængen. givne forhold. Dette omfatter også:
UI-testning er en type forskningstest, der udføres for at afgøre, om et kunstigt objekt (såsom en webside, brugergrænseflade eller enhed) er egnet til dets tilsigtede brug.
User eXperience (UX) er følelsen, som en bruger oplever, mens han bruger et digitalt produkt brugergrænseflade er et værktøj, der tillader interaktion mellem brugeren og webressourcen.

Failover og gendannelsestest validerer produktet, der testes, med hensyn til dets evne til at modstå og med succes komme sig efter mulige fejl forårsaget af softwarefejl, hardwarefejl eller kommunikationsproblemer (for eksempel netværksfejl). Formålet med denne type test er at teste gendannelsessystemer (eller systemer, der duplikerer hovedfunktionaliteten), som i tilfælde af fejl vil sikre sikkerheden og integriteten af ​​dataene for det produkt, der testes.

Konfigurationstest- speciel type test, der sigter på at kontrollere driften af ​​softwaren under forskellige systemkonfigurationer (erklærede platforme, understøttede drivere, forskellige computerkonfigurationer osv.)

Røg test betragtes som en kort cyklus af test udført for at bekræfte, at efter opbygning af koden (ny eller fast), starter den installerede applikation og udfører grundlæggende funktioner.

Regressionstest- dette er en type test, der har til formål at kontrollere ændringer foretaget i en applikation eller miljø(ret en defekt, fletning af kode, migrering til et andet operativsystem, database, webserver eller applikationsserver), for at bekræfte det faktum, at allerede eksisterende funktionalitet fungerer som før. Regressionstest kan være både funktionelle og ikke-funktionelle test.

Gentestning- test, hvor testscripts, der identificerede fejl under den sidste kørsel, udføres for at bekræfte succesen med at rette disse fejl.
Hvad er forskellen mellem regressionstest og re-testing?
Gentestning - fejlrettelser kontrolleres
Regressionstest - kontrollerer, at fejlrettelser ikke påvirkede andre softwaremoduler og ikke forårsagede nye fejl.

Samlingstest eller bygningsverifikationstest- test, der sigter mod at fastslå, om den frigivne version er i overensstemmelse med kvalitetskriterier for at begynde test. Med hensyn til dets mål er det analogt med røgtestning, der sigter mod at acceptere en ny version til yderligere test eller drift. Det kan trænge dybere ind, afhængigt af kvalitetskravene i den frigivne version.

Sanitær test- dette er en snævert fokuseret test, der er tilstrækkelig til at bevise, at en specifik funktion fungerer i overensstemmelse med kravene i specifikationen. Det er en delmængde af regressionstest. Bruges til at bestemme ydeevnen af ​​en bestemt del af applikationen efter ændringer foretaget i den eller miljøet. Gøres normalt manuelt.

Gætte fejl - EG. Det er, når testanalytikeren bruger sin viden om systemet og evne til at fortolke specifikationen til at "forudsige" under hvilke inputbetingelser systemet kan fejle. For eksempel siger specifikationen "brugeren skal indtaste en kode." Testanalytikeren vil tænke: "Hvad hvis jeg ikke indtaster koden?", "Hvad hvis jeg indtaster forkert kode? ", og så videre. Dette er forudsigelsen af ​​fejl.

Integrationstestmetoder:

Bottom Up Integration
Alle moduler, procedurer eller funktioner på lavt niveau samles og testes derefter. Hvorefter det samler sig næste niveau moduler til udførelse af integrationstest. Denne tilgang anses for nyttig, hvis alle eller næsten alle moduler på det niveau, der udvikles, er klar. Denne tilgang hjælper også med at bestemme niveauet af applikationsparathed baseret på testresultater.

Top Down Integration
Først testes alle højniveaumoduler, og gradvist tilføjes lavniveaumoduler en efter en. Alle moduler på lavere niveau simuleres som stubbe med lignende funktionalitet, og når de er klar, erstattes de med rigtige aktive komponenter. På denne måde tester vi fra top til bund.

Big Bang ("Big Bang"-integration)
Alle eller næsten alle de udviklede moduler er samlet som et komplet system eller dets hoveddel, og derefter udføres integrationstest. Denne tilgang er meget god til at spare tid. Men hvis testcaserne og deres resultater ikke registreres korrekt, så vil selve integrationsprocessen være meget kompliceret, hvilket vil blive en hindring for testteamet i at nå hovedmålet med integrationstest.

Testprincipper

Princip 1- Test viser tilstedeværelse af defekter
Test kan vise, at defekter er til stede, men kan ikke bevise, at de ikke er til stede. Test reducerer sandsynligheden for defekter i softwaren, men selvom der ikke findes nogen defekter, beviser dette ikke dens rigtighed.

Princip 2- Udtømmende test er umuligt
Fuldstændig test med alle kombinationer af input og forudsætninger er fysisk umuligt, undtagen i trivielle tilfælde. I stedet for udtømmende test bør risikoanalyse og prioritering bruges til bedre at fokusere testindsatsen.

Princip 3- Tidlig test
For at finde defekter så tidligt som muligt, bør testaktiviteter startes så tidligt som muligt i software- eller systemudviklingens livscyklus og bør fokuseres på specifikke mål.

Princip 4- Klynger af defekter
Testindsatsen bør koncentreres i forhold til den forventede, og senere den faktiske, moduldefekttæthed. Som regel er de fleste af de fejl, der er opdaget under test, eller som forårsagede størstedelen af ​​systemfejl, indeholdt i et lille antal moduler.

Princip 5- Pesticidparadoks
Hvis de samme tests køres igen og igen, vil dette sæt af testcases ikke længere finde nye defekter. For at overvinde dette "pesticidparadoks" skal testcases regelmæssigt gennemgås og revideres, og nye test skal være omfattende for at dække alle komponenter i softwaren eller systemet og finde så mange defekter som muligt.

Princip 6- Test er konceptafhængigt
Test udføres forskelligt afhængigt af konteksten. For eksempel testes sikkerhedskritisk software anderledes end en e-handelsside.

Princip 7- Fravær-af-fejl fejlslutning
Det hjælper ikke at finde og rette fejl, hvis det oprettede system ikke passer til brugeren og ikke lever op til dennes forventninger og behov.

Statisk og dynamisk test
Statisk test adskiller sig fra dynamisk test ved, at den udføres uden lancering programkode produkt. Test udføres ved at analysere programkoden (kodegennemgang) eller den kompilerede kode. Analysen kan udføres enten manuelt eller ved hjælp af special værktøjer. Formålet med analysen er tidligt at identificere fejl og potentielle problemer i produktet. Statisk test omfatter også testspecifikationer og anden dokumentation.

Udforskende/ad-hoc test
Den enkleste definition af eksplorativ test er at designe og køre test på samme tid. Hvilket er det modsatte af scenarietilgangen (med dens foruddefinerede testprocedurer, enten manuel eller automatiseret). Udforskende tests er, i modsætning til scenarietests, ikke forudbestemte og udføres ikke nøjagtigt som planlagt.

Forskellen mellem ad hoc og eksplorativ test er, at teoretisk set kan ad hoc test udføres af enhver, mens eksplorativ test kræver færdighed og viden om visse teknikker. Bemærk venligst, at visse teknikker ikke kun er testteknikker.

Krav er en specifikation (beskrivelse) af hvad der skal implementeres.
Krav beskriver, hvad der skal implementeres, uden at detaljere den tekniske side af løsningen. Hvad, ikke hvordan.

Krav Krav:
Rigtigheden
Entydighed
Fuldstændigheden af ​​kravsættet
Konsistens af et sæt krav
Verificerbarhed (testbarhed)
Sporbarhed
Forståelighed

Bug livscyklus

Softwareudviklingsstadier- det er de stadier, som softwareudviklingsteams gennemgår, før programmet bliver tilgængeligt for en bred vifte af brugere. Softwareudvikling begynder med den indledende udviklingsfase (præ-alfastadiet) og fortsætter med stadier, hvor produktet forfines og moderniseres. Den sidste fase af denne proces er frigivelsen af ​​den endelige version af softwaren til markedet ("generelt tilgængelig udgivelse").

Softwareproduktet gennemgår følgende trin:
analyse af projektkrav;
design;
implementering;
produkt test;
implementering og support.

Hvert trin i softwareudviklingen er tildelt en bestemt serienummer. Hver fase har også sit eget navn, som kendetegner produktets klarhed på dette stadium.

Softwareudviklings livscyklus:
Præ-alfa
Alfa
Beta
Frigivelseskandidat
Frigøre
Efter udgivelse

Beslutningstabel- et fremragende værktøj til at organisere komplekse forretningskrav, der skal implementeres i et produkt. Beslutningstabeller præsenterer et sæt betingelser, hvis samtidige opfyldelse bør føre til en specifik handling.

QA/QC/Testingeniør


Således kan vi opbygge en model for hierarkiet af kvalitetssikringsprocesser: Test er en del af QC. QC er en del af QA.

Tilslutningsdiagram er et kvalitetsstyringsværktøj baseret på at identificere logiske sammenhænge mellem forskellige data. Dette værktøj bruges til at sammenligne årsager og virkninger på det undersøgte problem.

Test model- Det her logisk struktur, der beskriver systemets funktionalitet og/eller brugeradfærd, baseret på hvilke testcases genereres. Konstruktion test model begynder med at bygge en struktur, og derefter er den godkendte struktur fyldt med testcases.

Modeller bygges normalt ud fra systemets krav og/eller forventede opførsel. Test model konstruktion og ledelse er velegnet til store systemer med kompleks forretningslogik og er svære at anvende på projekter ved hjælp af fleksible metoder, fordi omkostningerne ved at vedligeholde testmodelstyringen og kvalitetssikringsprocessen vil være for høje.

Testmodelstyring refererer til den proces, der kontrollerer dækningen af ​​testmodellen, kvaliteten af ​​de scripts, der beskriver testmodellen og dens opdatering.

Testmodelstyring er en løbende proces gennem hele produktets livscyklus.

Testmodeldækning

For at kontrollere dækningen af ​​alle krav kan du bruge sporingsmatricer, som bestemmer dækningen af ​​krav ved testcases (se eksempel).
Inden testcases beskrives, skal opbygningen af ​​testmodellen godkendes med kunden.

Script kvalitet

For at styre kvaliteten af ​​scripts er det nødvendigt at kontrollere ikke kun niveauet for beskrivelse af testcases, men også deres kvalitet.

Før man begynder at beskrive testcases, er det nødvendigt at fastlægge kravene til hvert beskrivelsesniveau og kvalitetskriterier for beskrivelse af testcases.

Mulige niveauer af testcasebeskrivelse:

På niveau 4 kan koordinering med kunden erstattes af godkendelse.

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

• Testcases skal skrives efter kravene

Test er processen med at verificere, at et produkt opfylder dets krav. Derfor til dels generel beskrivelse testcase (i testsporingssystemer bruges normalt udtrykket "resumé") er det nødvendigt at henvise til et specifikt krav i forbindelse med fragmenter af kravteksten. Det vil således være klart for alle projektdeltagere, på grundlag af hvilken denne testcase er skrevet.

• Brug detaljerede forudsætninger

Hvordan sparer man tid på testcases?

Indstil formateringsregler for alle testcases. På denne måde bliver testcasen let at forstå og læse for enhver projektdeltager. For eksempel kan du på et projekt indtaste følgende regler:

• Alle inputparametre skal markeres med rødt.
• Alle scripts skal fremhæves med blåt,
• Alle navne på knapper, felter, blokke er fremhævet i kursiv og fed.
• Vigtige steder er fremhævet med understregning.
• Hvert trin, der udføres, skal have et forventet resultat.
• Hvert trin i testcases bør kun beskrive én handling og det forventede resultat for den. De der. Når du modtager en mislykket testsag i et specifikt trin, skal det klart fremgå, ved hvilken handling fejlen opstår.
• Det forventede resultat bør være entydigt.

Testcases skal være entydige, dvs. skal være affattet og formuleret på en sådan måde, at de ikke giver mulighed for tvetydig fortolkning, men klart forstås af alle deltagere.

Hvis det tager lang tid at skrive testcases, kan der opstå en situation, hvor en specialist holder op med at se sine fejl. Dette kræver et udefrakommende perspektiv – her vil det hjælpe gennemføre krydsrevisioner. Denne fase anbefales at blive udført i tilfælde, hvor udviklingen af ​​en testmodel forlænges og tager lang tid. For eksempel når udviklingen af ​​testscenarier tager mere end 1 måned.

Scriptkvalitetskontrolprocessen kan udføres Med ved hjælp af Test Model kontrol– en specielt udarbejdet skabelon.

Test model opdatering

Det er nødvendigt løbende at opdatere testmodellen og selve testcaserne for overholdelse af kravene, samt gennemgå testcases prioriteter.

At opdatere du kan opretholde en "kravmatrix"(Requirement Traceability Matrix): efter hver ændring i et specifikt krav, udvælges alle testcases forbundet med dette krav fra testsporingssystemet og opdateres.

Testmodelkontrol:

• TestRail
• TestLink
• Jira+Zephyr
• Microsoft Test Manager (MTM)
• Excel

Kapitlet introducerer begrebet kvalitet, beskriver testprocessen og diskuterer, hvordan kvalitet og test relaterer sig til forskellige fremstillingsprocesser. Det traditionelle syn på test som en mekanisme til at vurdere kvaliteten af ​​et produkt præsenteres, og det beskriver også, hvordan test er med til at styrke og styrke arkitekturen tidligt i udviklingscyklussen.

Mål

Formålet med test er at vurdere kvaliteten af ​​produktet. Det betyder ikke kun at evaluere det endelige produkt, men også at evaluere arkitekturen fra de tidlige stadier af processen til den endelige levering af produktet til kunderne. omfatter følgende.

Kontrol af komponentinteraktioner

Kontrol af korrekt integration af komponenter

Kontrol af nøjagtigheden af ​​implementeringen af ​​alle krav

Identifikation af defekter og træffe de nødvendige foranstaltninger for at fjerne dem før
softwareimplementering

Kvalitet

Standardbrug af udtrykket kvalitet omfatter mange ting: som regel betegner dette ord fraværet af defekter og (hvad er meget vigtigere!) overholdelse af det tilsigtede formål; Med kvalitetsbegrebet forbinder vi det, vi har brug for af et produkt. Et produkt (eller en komponent af det) er muligvis ikke defekt, men hvis det ikke gør, hvad vi har brug for det, er det lige så ubrugeligt som et produkt med fejl. Hovedformålet med test er at evaluere kvaliteten af ​​det endelige produkt, samt at evaluere kvaliteten af ​​de komponenter, der udgør det, og den arkitektur, der bestemmer formen af ​​disse komponenter. Dette er for at sikre, at produktet er

Kapitel 12. G67

opfylder eller overstiger visse krav (vurderet efter foranstaltninger og acceptkriterier).

Kvaliteten af ​​et produkt kan ikke vurderes fuldt ud alene; software er udviklet af en organisation ved hjælp af en proces, så dårlig kvalitet kan skyldes en dårlig proces eller en proces, der er svær at overholde. Som en konsekvens heraf tager kvalitetsvurdering ofte ikke kun selve produktets kvalitet i betragtning, men også organisatoriske faktorer og proceskvalitet.

Hvem er ansvarlig for kvaliteten af ​​produktet

Alle medlemmer af projektgruppen er ansvarlige for at producere et kvalitetsprodukt. Hvis kvalitet ikke oprindeligt var indbygget i produktet, så kan det ikke længere "tilføjes senere" ved at udføre nogle aktive handlinger for at garantere kvaliteten.

Opgaven med at teste er ikke garanti kvalitet og skøn og samtidig give feedback for at løse kvalitetsproblemer til en rimelig pris og tid. Testerens opgave er at evaluere kvalitet og give feedback, og projektgruppens opgave er at skabe artefakter, der opfylder kravene og kvalitetsparametrene.

Test i en iterativ livscyklus

Test er ikke en separat aktivitet eller en fase af et projekt, hvor der udføres kvalitetsvurdering. Hvis udviklere har brug for rettidig feedback om produktkvalitetsproblemer, bør testning udføres gennem hele livscyklussen: funktionaliteten af ​​tidlige prototyper kan testes; stabilitet, dækning og ydeevne af arkitekturen (samtidig kan mislykkede beslutninger altid korrigeres); Derudover kan du teste det endelige produkt og vurdere dets klarhed til overførsel til kunderne. Der er en almindelig opfattelse af, at test er den sidste kontrol af den globale ydeevne; Men denne situation går glip af den største fordel ved test: muligheden for at give feedback, mens der stadig er tid (og ressourcer) til at tage de nødvendige handlinger.

Klassificering af prøver

For at vurdere kvaliteten af ​​et produkt kræves der forskellige typer test. Følgende egenskaber kan bruges til at klassificere tests.

Testet kvalitetsparameter - hvilken kvalitetsparameter testes?

Testfase- punkt i livscyklussen, hvor det udføres
afprøvning

Testtype- en specifik opgave i en individuel test, normalt forbundet med en
kvalitetsparameter

Kvalitetsparametre

Der er mønstre, der giver dig mulighed for at identificere problemer relateret til kvalitet (som regel har næsten alle systemer den samme type problemer). Som følge heraf bør følgende vurderes for hvert produkt.

Pålidelighed

Softwaren "modstår" forekomsten af ​​fejl under udførelsen: der er ingen nedbrud, fryser, hukommelseslækager osv.

Funktionalitet

Softwaren implementerer de nødvendige use cases eller har den forventede adfærd.

I Produktivitet

Softwaren og systemet fungerer, reagerer hurtigt på forudbestemte hændelser og fortsætter med at fungere acceptabelt under virkelige driftsforhold (f.eks. tung belastning, længere driftsperioder osv.). Ydelsestest fokuserer på at levere den nødvendige funktionalitet og samtidig opfylde de ikke-funktionelle krav til systemet.

Hver af de specificerede kvalitetsparametre kræver, at en eller flere tests udføres på et eller flere teststadier. Derudover er der andre kvalitetsparametre, hvis vurdering kan være mere subjektiv: brugervenlighed, udvidelsesmuligheder, fleksibilitet mv. En kvalitativ vurdering af disse kvalitetsparametre bør foretages ved enhver lejlighed.

Test stadier

Test bør ikke betragtes som en separat aktivitet, der udføres helt på én gang. Test udføres på forskellige stadier af softwareudvikling og har til formål at kontrollere forskellige objekter (testmål). Teststadierne går fra test af små elementer af systemet, såsom komponenter (enhedstest) til test. test af færdige systemer (systemtest). Lad os liste de eksisterende teststadier og deres opgaver.

Enhedstest

Minimumselementerne i systemet testes. Testtiden falder som regel sammen med implementeringstiden for elementerne.

Integral test

Integrerede enheder (eller komponenter eller undersystemer) testes.

System test

Gennemførte applikationer og systemer (bestående af en eller flere applikationer) testes.

Accept test

Den færdige applikation (eller systemet) testes af slutbrugere (eller repræsentanter for slutbrugere). Mål med test: Bestem produktets klarhed til implementering.

Det skal huskes, at på forskellige tidspunkter i livscyklussen finder teststadier sted med forskellig vægt. Den tidlige konceptprototype, der blev brugt i forskningsfasen til at evaluere levedygtigheden af ​​produktvisionen, vil blive genstand for forskellige accepttests. Den arkitektoniske prototype, der er udviklet under planforfiningsfasen, vil blive genstand for integral- og systemtests med det formål at verificere den arkitektoniske integritet og ydeevne af nøglearkitektoniske elementer, selvom meget af systemkoden på nuværende tidspunkt er i form af surrogatprogrammer. Teststadier er ikke foruddefinerede "faser", som udføres sekventielt tættere på ende projekt; i modsætning hertil, i en iterativ livscyklus, starter test tidligt og forekommer ofte.

Typer af tests

Der er mange typer test, som hver især fokuserer på et specifikt testmål og kun tester ét aspekt af softwarekvalitet. Fordi test finder sted gennem hele livscyklussen, kan softwaren, der testes, være et enkelt stykke kode, en integreret enhed eller et komplet program (eller system). Lad os nævne de mest almindelige typer test.

Certificeringstest

Sammenligner ydeevnen af ​​et testmål og et standardobjekt, såsom eksisterende software, eller evaluerer ydeevnen i henhold til et system af foranstaltninger.

Konfigurationstest

Kontrollerer den acceptable funktion af testmålet under forskellige konfigurationer (software eller hardware).

Funktionstest

Funktionen af ​​måltestobjektet generelt kontrolleres, dvs. korrekt implementering af de nødvendige præcedenser.

Installationstest

Kontrollerer den korrekte installation af testmålet, muligheden for vellykket installation under forskellige konfigurationer eller i forskellige forhold(f.eks. hvis der ikke er tilstrækkelig diskplads).

Integritetstest

Pålideligheden af ​​måltestobjektet, dets stabilitet og modstandsdygtighed over for fejl under udførelsen kontrolleres.

Belastningstest

Verificerer, at testmålets ydeevne er acceptabel under en række forskellige driftsforhold (inklusive andet nummer brugere, transaktioner osv.) med en uforanderlig konfiguration.

Præstationstests

Verificerer den acceptable ydeevne af testmålet i forskellige konfigurationer, samtidig med at konstante driftskarakteristika opretholdes.

Hard mode test

Verificerer testmålets acceptable ydeevne under nødsituationer eller kritiske forhold, såsom begrænsede ressourcer eller et ekstremt stort antal brugere.

Regressionstest

Regressionstest er en testteknik, hvor tidligere udførte test genudføres på en ny version af målobjektet. Målet med denne type test er at sikre, at kvaliteten af ​​målobjektet ikke forringes (regress), når nye funktioner tilføjes til det pågældende objekt. Regressionstest er nødvendig for

Maksimal tidlig opdagelse af defekter;

Tjek at kodeændringer ikke introducerer nye defekter eller
genoprette gamle.

Regressionstest kan involvere at køre enhver form for test igen og igen. Typisk udføres en sådan test i hver iteration og består af genkørende test udført i tidligere iterationer.

Test model

Test model- det er en repræsentation af, hvad der vil blive testet, og hvordan testen vil blive udført. Denne model er en repræsentation af design- og implementeringsmodellerne, der viser de faktiske tests og testrelaterede målparametre. Testmodellen omfatter et sæt kontrolopgaver, testprocedurer, testscenarier og forventede testresultater, samt en beskrivelse af deres sammenhæng.

Lad os se nærmere på komponenterne i testmodellen.

Kontrolopgaver

Et sæt testdata, testudførelsesbetingelser og forventede resultater designet til specifik opgave afprøvning. Kontrolopgaver kan bestemmes ud fra præcedenser, designdokumentation eller programkode. Kontrolopgaven kan implementeres ved hjælp af en eller flere testmetoder.

Testmetoder

Et sæt detaljerede instruktioner til opsætning og udførelse af kontrolopgaver og evaluering af de opnåede resultater. Ved hjælp af én testmetode kan en eller flere kontrolopgaver implementeres. En testmetodologi kan også bruges til kun at implementere en del af en testopgave, såsom et alternativt use case flow.

Test scenarier

Instruktioner, der automatiserer implementeringen af ​​en del af eller hele en testprocedure (eller testprocedurer).

Test klasser og komponenter

Klasser og komponenter, der implementerer testprojekter, herunder drivere og surrogatprogrammer.

Test interaktioner

Interaktioner er repræsenteret i form af et interaktionsdiagram eller sekvensdiagram og afspejler det tidsordnede flow af meddelelser mellem testkomponenter og testmålet, der opstår under testprocessen.

Noter

Tekstoplysninger, der beskriver begrænsningerne, eller Yderligere Information, brugt i testmodellen. Noter kan knyttes til ethvert element i testmodellen.

Hovedelementerne i testmodellen og deres sammenhænge er vist i fig. 12.1.

Ris. 12.1. Testopgaver, testmetoder og testscenarier for en pengeautomat

Performere og artefakter

To hovedaktører er involveret i testprocessen.

Testudvikler ansvarlig for planlægning, udvikling, implementering af tests og
testvurdering. Hans ansvar omfatter at lave en testplan og model
udvikling, implementering af testmetoder og evaluering af testdækning, resultater
tats og test effektivitet.

Tester Ansvarlig for udførelse af systemtest. I sin forpligtelse
omfatter opsætning og afvikling af test, vurdering af testydelse,
retablering af fejl, evaluering af testresultater og registrering
identificerede defekter.

Hvis specifik kode er nødvendig for at understøtte test (for eksempel skal der udvikles drivere eller surrogater), så skal processen også involvere en udvikler og designer i roller svarende til dem, der er defineret i kapitel 10 og 11.

Udøvere og artefakter af testprocessen er præsenteret i fig. 12.2. Lad os se på de vigtigste artefakter i denne proces.

Testplan, indeholdende information om målene og formålene med testen.
Testplanen bestemmer hvilke strategier der vil blive brugt og hvilke
der kræves ressourcer til at udføre test.

Test model beskrevet tidligere.

Test resultater og data indsamlet under testudførelsen.

Arbejdsbelastningsmodel til præstationstests; det definerer
variabler og deres værdier brugt i forskellige operationelle
tests til at modellere eller simulere karakteristika for eksterne
udøvere, udførte funktioner slutbrugere, volumen
disse funktioner og belastningen skabt af disse funktioner.

defekter, opnået som følge af "ikke beståede tests" er en af
typer af ændringsanmodninger (se kapitel 13).

Ud over de anførte artefakter skal følgende artefakter oprettes ved udvikling af softwareunderstøttelse til en test.

Testpakker og klasser

Delsystemer og testkomponenter

Den endelige testevaluering bruges som en del af design-iterationsevalueringen og den periodiske statusevaluering (se kapitel 7, " Teknologisk proces projektledelse").

Teknologisk proces

En typisk testproces, dens hovedelementer og afhængigheder mellem dem er vist i fig. 12.3.

Forberedelse til test

Formålet med dette workflow-element er at definere og beskrive den test, der skal udføres. For at gøre dette oprettes en testplan, der indeholder testkrav og teststrategier. Der kan udvikles en enkelt testplan, der beskriver alle typer test, der skal udføres, eller der kan oprettes en separat plan for hver type test. Testforberedelse udføres på en sådan måde, at testaktiviteter er målbare og overskuelige.

Test udvikling

Formålet med dette workflow-element er at definere, beskrive og skabe testmodellen og dens tilknyttede artefakter. Et testprojekt oprettes for at sikre, at den software, der bruges til test, er ordentligt organiseret og opfylder de specificerede krav. Under dette element i arbejdsgangen analyserer testdesigneren testmålet, udvikler en testmodel og (i tilfælde af præstationstest) en arbejdsbelastningsmodel. Testdesign transformerer use cases til accept- og systemkontrolopgaver, som derefter guider designet af de softwareelementer, der udfører test.

Test implementering

Formålet med dette proceselement er at implementere testprocedurerne defineret i afsnit Forberedelse til test. Testmetoder skabes som regel i et testautomatiseringsmiljø eller i et programmeringsmiljø. Den resulterende artefakt er en elektronisk version af testproceduren, kaldet et testscript.

Hvis der er behov for specifik kode for at understøtte eller udføre test (for eksempel skal der udvikles testværktøjer, drivere eller surrogatprogrammer), så er udvikleren, designeren og testudvikleren involveret i arbejdet med dens oprettelse.

Udførelse af test på den integrerede teststadie

Formålet med dette workflow-element er at sikre, at systemkomponenter kombineres korrekt og at sikre, at kombinationen opfører sig korrekt. Systemintegratoren er ansvarlig for at kompilere og kombinere systemet til stigende funktionelle blokke. For hver sådan blok testes de tilføjede funktioner, regressionstests udføres, og testresultater hentes.

I løbet af en iteration udføres integral test flere gange, indtil hele systemet er vellykket integreret (bestemt af målet med iterationen).

Udførelse af test under systemtestfasen

Formål af dette element teknologisk proces er at sikre, at hele systemet fungerer korrekt. Systemintegratoren kompilerer og integrerer systemer i stigende funktionelle enheder. Hvert element tilføjet

skal bestå funktionalitetstest; desuden udføres alle tidligere udførte test på hvert design (regressionstest).

Under en enkelt iteration udføres systemtestning flere gange, indtil hele systemet er integreret med succes (bestemt af iterationsmålet), og testsucces- eller systemafslutningskriterierne er opfyldt.

Test vurdering

Formålet med dette element i den teknologiske proces er at udvikle og evaluere kvantitative testtiltag, der gør det muligt at bestemme kvaliteten af ​​måltestobjektet og testprocessen. Dette opnås ved at gennemgå og evaluere testresultater, identificere og registrere ændringsanmodninger og beregne nøgletestmål.

Værktøjsstøtte

Fordi test er en iterativ indsats, der udføres gennem hele udviklingscyklussen, er værktøjsstøtte nødvendig for at sikre, at test starter tidligt og forekommer ofte; Manuel test er ikke effektivt nok og giver dig ikke mulighed for grundigt at evaluere den software, der udvikles. Dette sidste punkt gælder især for præstations- og belastningstestning, hvor arbejdsbelastningen skal simuleres og en betydelig mængde data skal indsamles.

Rational Software Corporation tilbyder følgende værktøjer til at understøtte testautomatisering og testprocessen generelt.

TestStudio er et sæt værktøjer, der understøtter udførelsen af
udførelse af test og evaluering af testresultater. TestStudio værktøjer tillader
tester til at lave testscripts med grafisk grænseflade
brugerens ansigt. Disse scenarier fokuserer på sådanne parametre
kvaliteter som pålidelighed, funktion og ydeevne. Inkluderet i sættet
TestStudio indeholder følgende værktøjer.

Robot understøtter testudførelse, hvilket giver testere mulighed for at oprette og reproducere testscripts med en grafisk brugergrænseflade og sammenligne de opnåede resultater og forventede resultater.

LogViewer fanger testresultater og giver en rapport til at evaluere testydelsen.

TestManager understøtter testplanlægning, -design og -evaluering, giver dig mulighed for at bestemme testdækning og genererer teststatusrapporter.

TestFactory understøtter pålidelighedstest af automatisk oprettelse og udførelse af testscripts. Derudover rapporterer dette værktøj programmæssigt testdækning.

PerformanceStudio kører virtuelle brugertestscripts
krop, ved hjælp af præstationstest og nogle funktioner
onale tests.

DevelopmentStudio understøtter test workflow og
omfatter følgende værktøjer.

Rational Purify for at isolere svære at finde runtime-fejl.

Rational PureCoverage* til at identificere kodeområder, der ikke testes, og udføre analyse af kodedækning.

Rational Quantify* for at identificere ydeevnebegrænsende kodestykker.

Derudover tilbyder Rational Unified Process værktøjsmentorer til de fleste af disse værktøjer.

Resumé

Test giver dig mulighed for at evaluere kvaliteten af ​​det fremstillede produkt.

Test er en iterativ proces, der udføres i alle faser af livet.
lang cyklus; det giver dig mulighed for at organisere tidligt baglæns kommunikation om kvalitetsspørgsmål
va, bruges til at forbedre produktet under dets udvikling og konstruktion
nia. Test bør ikke kun udføres i slutningen af ​​livscyklussen
(at acceptere eller afvise det endelige produkt); det skal være uadskilleligt
en integreret del af den konstante feedback-mekanisme.

Alle er ansvarlige for kvaliteten. Kvalitet kan ikke indføres af testorganet
tion. Test er kun rettet mod at vurdere kvalitet og organisering
rettidig feedback for at forbedre kvaliteten af ​​systemet.

Tilbyder en feedback-mekanisme,
gør det muligt at måle kvaliteten og identificere defekter. Test udført
foregår i de tidlige faser af projektet - starter med planlægningstest og nogle
anden vurdering (nogle gange udført selv i forskningsfasen) og fortsatte
vokser som projektet skrider frem.

Test af webtjenester

Den bedste måde at vurdere, om vi har testet et produkt godt, er at analysere de fejl, vi gik glip af. Dem, som vores brugere, implementere og virksomheder er stødt på. Baseret på dem kan du evaluere en masse: hvad vi ikke har kontrolleret grundigt nok, hvilke områder af produktet der skal gives mere opmærksomhed, hvad den samlede procentdel af udeladelser er, og hvad dynamikken i dets ændringer er. Med denne metrik (måske den mest almindelige i test) er alt fint, men... Da vi udgav produktet og lærte om de glemte fejl, er det måske allerede for sent: en vred artikel om os dukkede op på Habré, konkurrenterne er hurtigt spredte kritik, vi mistede kundernes tillid til os, ledelsen er utilfreds.

For at forhindre dette i at ske, forsøger vi normalt at vurdere kvaliteten af ​​testene på forhånd, inden frigivelse: Hvor godt og grundigt tester vi produktet? Hvilke områder mangler opmærksomhed, hvor er de største risici, hvad er fremskridtene? Og for at besvare alle disse spørgsmål, evaluerer vi testdækning.

Hvorfor evaluere?

Enhver evalueringsmåling er spild af tid. På dette tidspunkt kan du teste, oprette fejl og forberede autotest. Hvilken slags magisk fordel får vi af testdækningsmålinger for at ofre testtid?

1. Find dine svage områder. Behøver vi naturligvis dette? ikke bare for at sørge, men for at vide, hvor der er behov for forbedringer. Hvilke funktionsområder er ikke omfattet af tests? Hvad har vi ikke tjekket? Hvor er den største risiko for manglende fejl?
2. Sjældent får vi 100 % baseret på vores dækningsvurderingsresultater. Hvad skal forbedres? Hvor skal vi hen? Hvad er procentdelen nu? Hvordan kan vi øge det med enhver opgave? Hvor hurtigt kan vi nå 100? Alle disse spørgsmål bringer gennemsigtighed og klarhed til vores proces., og svarene på dem er givet af dækningsvurderingen.
3. Fokus for opmærksomhed. Lad os sige, at vores produkt har omkring 50 forskellige funktionsområder. En ny version udkommer, og vi begynder at teste 1 af dem, og vi finder tastefejl, og knapper, der har flyttet sig et par pixels, og andre småting... Og nu er testtiden forbi, og denne funktionalitet er testet i detalje... Og de andre 50? Dækningsvurdering giver os mulighed for at prioritere opgaver baseret på aktuelle realiteter og deadlines.

Hvordan evaluerer man?

Før du implementerer nogen metrik, er det vigtigt at beslutte, hvordan du vil bruge det. Start med at svare på præcis dette spørgsmål – højst sandsynligt vil du straks forstå, hvordan du bedst beregner det. Og i denne artikel vil jeg lige dele nogle eksempler og min erfaring med, hvordan dette kan lade sig gøre. Ikke for blindt at kopiere løsninger - men for at din fantasi er baseret på denne erfaring, gennemtænke en løsning, der er ideel for dig.

Vi vurderer dækningen af ​​krav ved test

Lad os sige, at du har analytikere på dit hold, og de spilder ikke deres tid. arbejdstid. Baseret på resultaterne af deres arbejde blev der oprettet krav i RMS (Requirements Management System) - HP QC, MS TFS, IBM Doors, Jira (med ekstra plugins) osv. De indfører krav i dette system, der opfylder kravene (undskyld tautologien). Disse krav er atomare, sporbare, specifikke... Generelt ideelle betingelser for test. Hvad kan vi gøre i dette tilfælde? Når du bruger en scriptet tilgang, skal du linke krav og test. Vi kører test i samme system, laver en krav-test forbindelse, og vi kan til enhver tid se en rapport om hvilke krav der har test, hvilke der ikke gør, hvornår disse test er bestået, og med hvilket resultat.
Vi får et dækningskort, vi dækker alle udækkede krav, alle er glade og tilfredse, vi går ikke glip af nogen fejl...

Okay, lad os vende tilbage fra himlen til jorden. Du har højst sandsynligt ikke detaljerede krav, de er ikke atomare, nogle af kravene er helt tabt, og du har ikke tid til at dokumentere hver test, eller i det mindste hver anden. Du kan fortvivle og græde, eller du kan indrømme, at test er en kompenserende proces, og jo værre det går med analyser og udvikling på projektet, jo mere må vi prøve os og kompensere for andre deltageres problemer i processen. Lad os se på problemerne separat.

Problem: Kravene er ikke atomare.

Analytikere laver også nogle gange fejl i deres hoveder, og som regel er det fyldt med problemer med hele projektet. For eksempel udvikler du dig tekst editor, og du kan have to krav i dit system (blandt andre): "html-formatering skal understøttes" og "når du åbner en fil i et ikke-understøttet format, skulle et pop op-vindue med et spørgsmål vises." Hvor mange tests er nødvendige for den grundlæggende verifikation af det 1. krav? Og til 2.? Forskellen i svar er højst sandsynligt omkring hundrede gange!!! Vi kan ikke sige, at hvis der er mindst 1 test til 1. krav, er dette nok - men for 2. er det højst sandsynligt.

Tilstedeværelsen af ​​en test for et krav garanterer os således ikke noget som helst! Hvad betyder vores dækningsstatistikker i dette tilfælde? Næsten ingenting! Vi bliver nødt til at beslutte os!

1. I dette tilfælde kan den automatiske beregning af kravdækning ved test fjernes - den bærer stadig ingen semantisk belastning.
2. For hvert krav, begyndende med højeste prioritet, udarbejder vi tests. Når vi forbereder os, analyserer vi, hvilke tests dette krav vil kræve, hvor mange vil være nok? Vi udfører en fuldgyldig testanalyse og børster den ikke af "der er én test, ja, okay."
3. Afhængigt af det anvendte system, eksporterer/uploader vi tests on demand og... tester disse tests! Er der nok af dem? Ideelt set bør en sådan test naturligvis udføres med en analytiker og udvikler af denne funktionalitet. Print testene ud, lås dine kolleger inde i et mødelokale, og lad dem ikke gå, før de siger "ja, disse test er nok" (det sker kun med skriftlig aftale, når disse ord siges at kvittere, også uden analysere testene. Under en mundtlig diskussion vil dine kolleger udgyde kritik, missede tests, misforståede krav osv. - det er ikke altid behageligt, men det er meget nyttigt til test!)
4. Efter at have afsluttet testene efter behov og aftalt deres fuldstændighed, kan dette krav tildeles status "dækket af test" i systemet. Disse oplysninger vil betyde meget mere end "der er mindst 1 test her."

Selvfølgelig kræver en sådan godkendelsesproces mange ressourcer og tid, især i starten, før man får praksis. Udfør derfor kun højt prioriterede krav og nye forbedringer. Med tiden vil du skærpe de resterende krav, og alle bliver glade! Men... hvad nu hvis der slet ikke er nogen krav?

Problem: Der er ingen krav overhovedet.

De er fraværende i projektet, diskuteres mundtligt, alle gør hvad de vil/kan og som han forstår. Vi tester det på samme måde. Som et resultat får vi stor mængde problemer ikke kun i test og udvikling, men også i den oprindeligt forkerte implementering af funktioner - de ville noget helt andet! Her kan jeg anbefale muligheden "definer og dokumenter kravene selv," og jeg brugte endda denne strategi et par gange i min praksis, men i 99% af tilfældene er der ikke sådanne ressourcer i testteamet - så lad os tage meget mindre ressourcekrævende vej:

1. Opret en funktionsliste. Sami! I form af et Google-tegn, i PBI-format i TFS - vælg et hvilket som helst, så længe du ikke gør det tekstformat. Vi mangler stadig at indsamle statusser! Vi tilføjer alle de funktionelle områder af produktet til denne liste og prøver at vælge et generelt niveau nedbrydning (du kan udskrive softwareobjekter eller brugerscripts eller moduler eller websider eller API-metoder eller skærmformularer...) – men ikke det hele på én gang! ET nedbrydningsformat, som er nemmere og mere visuelt for dig, giver dig mulighed for ikke at gå glip af vigtige ting.
2. Vi er enige om FULDSTÆNDIGHEDEN af denne liste med analytikere, udviklere, business, inden for vores team... Prøv at gøre alt for ikke at miste vigtige dele af produktet! Hvor dybt du skal analysere er op til dig. I min praksis har der kun været få produkter, som vi har lavet mere end 100 sider til i tabellen, og det var kæmpeprodukter. Oftest er 30-50 linjer et opnåeligt resultat for efterfølgende omhyggelig bearbejdning. I et lille team uden dedikerede testanalytikere større antal featurelist-elementer vil være for svære at vedligeholde.
3. Derefter går vi efter prioriteter og behandler hver linje på funktionslisten som i kravafsnittet beskrevet ovenfor. Vi skriver prøver, diskuterer, aftaler tilstrækkelighed. Vi markerer statusserne for, hvilken funktion der er test nok. Vi får status, fremskridt og udvidelse af tests gennem kommunikation med teamet. Alle er glade!

Men... Hvad hvis kravene opretholdes, men ikke i et sporbart format?

Problem: Kravene kan ikke spores.

Der er en enorm mængde dokumentation om projektet, analytikere skriver med en hastighed på 400 tegn i minuttet, du har specifikationer, tekniske specifikationer, instruktioner, certifikater (oftest sker dette på kundens anmodning), og alt dette virker som krav, og alt har været på projektet i lang tid. Forvirret over, hvor man skal lede efter hvilken information?
Vi gentager det foregående afsnit og hjælper hele holdet med at blive organiseret!

1. Vi opretter en funktionsliste (se ovenfor), men uden en detaljeret beskrivelse af kravene.
2. For hver funktion indsamler vi links til tekniske specifikationer, specifikationer, instruktioner og andre dokumenter.
3. Vi prioriterer, forbereder tests, er enige om deres fuldstændighed. Alt er det samme, kun ved at kombinere alle dokumenter i én tabel øger vi let adgang til dem, gennemsigtige statusser og konsistens i testene. I sidste ende er alt godt med os, og alle er glade!

Men... Ikke så længe... Det ser ud til, at analytikere i løbet af den seneste uge har opdateret 4 forskellige specifikationer baseret på kundeønsker!!!

Problem: kravene ændrer sig hele tiden.

Selvfølgelig ville det være rart at teste en form for fast system, men vores produkter lever normalt. Kunden bad om noget, noget ændret i lovgivningen eksternt i forhold til vores produkt, og et eller andet sted fandt analytikere en fejl i analysen af ​​året før... Krav lever deres eget liv! Hvad skal man gøre?

1. Lad os sige, at du allerede har samlet links til tekniske specifikationer og specifikationer i form af en funktionslistetabel, PBI, krav, Wiki-noter osv. Lad os sige, at du allerede har test til disse krav. Og nu ændrer kravet sig! Det kan betyde en ændring i RMS eller en opgave i TMS (Task Management System) eller et brev med posten. Under alle omstændigheder fører dette til samme konsekvens: dine tests er irrelevante! Eller de er måske ikke relevante. Dette betyder, at de kræver opdatering (at dække den gamle version af produktet med tests tæller på en eller anden måde ikke rigtig, vel?)
2. I featurelist, i RMS, i TMS (Test Management System – testrails, sitechco, osv.) skal tests nødvendigvis og straks markeres som irrelevante! I HP QC eller MS TFS kan dette gøres automatisk ved opdatering af krav, men i en Google-plade eller wiki bliver du nødt til at indtaste det manuelt. Men du bør se med det samme: test er irrelevant! Det betyder, at vi står over for en komplet gentagelsessti: Opdater, kør testanalysen igen, omskriv testene, aftale ændringerne, og først derefter markere funktionen/kravet igen som "dækket af tests."

I dette tilfælde får vi alle fordelene ved testdækningsevaluering, og i dynamik! Alle er glade!!! Men…
Men du har brugt så meget tid på at arbejde med krav, at du nu ikke har tid nok til hverken at teste eller dokumentere test. Efter min mening (og der er plads til en religiøs strid her!) er krav vigtigere end prøver, og det er bedre på den måde! De er i hvert fald ok, og hele teamet er klar over, og udviklerne gør præcis, hvad der er brug for. MEN DER ER IKKE TID TILBAGE TIL DOKUMENTERING AF TEST!

Problem: Der er ikke tid nok til at dokumentere tests.

Faktisk kan kilden til dette problem ikke kun være mangel på tid, men også dit meget bevidste valg om ikke at dokumentere dem (vi bryder os ikke om dem, vi undgår effekten af ​​et pesticid, produktet skifter for ofte osv.) .). Men hvordan vurderer man testdækning i dette tilfælde?

1. Du har stadig brug for kravene, enten som fulde krav eller som en feature-liste, så nogle af afsnittene beskrevet ovenfor, afhængigt af analytikernes arbejde på projektet, vil stadig være nødvendige. Har du kravene/funktionslisten?
2. Vi beskriver og bliver mundtligt enige om teststrategien, uden at dokumentere specifikke tests! Denne strategi kan angives i en tabelkolonne, på en wiki-side eller i et krav i RMS og skal igen aftales. Denne strategi vil teste anderledes, men du vil vide: Hvornår blev denne sidst testet og med hvilken strategi? Og dette, ser du, er heller ikke dårligt! Og alle vil være glade.

Men… Hvilket andet "men"? Hvilken???

Lad os sige, vi kommer rundt om alt, og må kvalitetsprodukter være med os!