Hem › Installation och konfiguration › Testning av mjukvaruprodukt. Hur testar man funktionen hos en funktion som använder andra funktioner i den? Ändringsrelaterad testning

Testning av mjukvaruprodukt. Hur testar man funktionen hos en funktion som använder andra funktioner i den? Ändringsrelaterad testning

Även om du är så tolerant att du kan starta om programmet 18 gånger efter en krasch inom en halvtimme och först då kasta bildskärmen direkt mot fönstret, kommer du att hålla med om att det skulle vara bekvämare att arbeta med det här programmet om det inte "kraschade ”.

Hur kan du säkerställa att fall av krascher, frysning eller underlåtenhet att utföra de nödvändiga åtgärderna i programmet du har utvecklat blir mycket sällsynta?

Det exakta svaret på den här frågan Nej. Men genom århundradena har de klokaste forskarna tänkt på detta ämne i flera år och kunnat hitta ett botemedel som, om det inte eliminerar alla programfel, åtminstone skapar en illusion av handling för att eliminera dem.

Och detta botemedel kallas TESTNING mjukvaruprodukt .

Enligt kloka människor är testning ett av de mest etablerade sätten att säkerställa kvaliteten på utvecklingen programvara och ingår i setet effektiva medel modernt system säkerställa kvaliteten på mjukvaruprodukten.

Kvaliteten på en mjukvaruprodukt kännetecknas av en uppsättning egenskaper som avgör hur "bra" produkten är ur intressenternas synvinkel, såsom produktkund, sponsor, slutanvändare, produktutvecklare och testare, supportingenjörer, marknadsföring , utbildning och säljare. Var och en av deltagarna kan ha olika uppfattningar om produkten och hur bra eller dålig den är, det vill säga hur hög kvaliteten på produkten är. Att sätta problemet med att säkerställa produktkvalitet resulterar alltså i uppgiften att identifiera intressenter, deras kvalitetskriterier och sedan hitta den optimala lösningen som uppfyller dessa kriterier.

När och vem?

Enligt erfarna utvecklare bör testning av en mjukvaruprodukt utföras redan från början av skapandet. Men samtidigt bör erfarna utvecklare själva inte delta i testning, eftersom detta inte är en kunglig fråga. Mjukvaruprodukten måste testas av specialutbildade medarbetare som kallas testare, eftersom inte ens den mest erfarna utvecklaren kommer att kunna se sitt misstag, ens med de senaste optiska instrumenten.

Alla utvecklare är dock överens om att testning av en mjukvaruprodukt utifrån klassificering efter syfte bör delas in i två klasser:

Funktionstestning
Icke-funktionell testning

Funktionstestning

Funktionstestning innebär att kontrollera att en mjukvaruprodukt överensstämmer med de funktionskrav som anges i de tekniska specifikationerna för att skapa denna produkt. Enkelt uttryckt, funktionstestning kontrollerar om mjukvaruprodukten utför alla funktioner den ska.

Så du bestämde dig till slut för att utföra funktionstestning. Du tittar på den tekniska specifikationen, läser funktionskraven och inser att de åtminstone inte är i den ordning som testning kan göras. Du kommer att bli förvånad över att andra redan för ganska länge sedan har märkt denna avvikelse och kommit på hur man kan övervinna den.

För att genomföra funktionstestning utvecklar personalen på den tekniska kontrollavdelningen ett dokumentprogram och metodik för att testa applikationens funktionalitet (API). PMI-dokumentet innehåller en lista över scenarier för testning av programvaruprodukter (testfall) med detaljerad beskrivning steg. Varje steg i testscenariot kännetecknas av användarens (testspecialistens) åtgärder och de förväntade resultaten - programmets svar på dessa åtgärder. Testprogrammet och metodiken måste simulera driften av mjukvaruprodukten i verkligt läge. Detta innebär att testscenariot bör byggas på grundval av en analys av de operationer som framtida användare av systemet kommer att utföra, och inte vara en artificiellt sammanställd sekvens av manipulationer som bara är förståelig för utvecklaren.

Typiskt utförs funktionstestning på två nivåer:

Komponent (enhets) testning. Testning av individuella komponenter i en mjukvaruprodukt, med fokus på deras specifikationer, syfte och funktionella egenskaper.
Integrationstestning. Den här typen testning utförs efter komponenttestning och syftar till att identifiera defekter i samverkan mellan olika delsystem på nivån för styrflöden och datautbyte.

Icke-funktionell testning

Icke-funktionell testning utvärderar egenskaperna hos en mjukvaruprodukt, såsom ergonomi eller prestanda.

Jag tror att vikten av denna typ av testning är tydlig och inte kräver motivering. När allt kommer omkring förstår alla att om till exempel systemprestandan inte är tillräcklig, måste användarna vänta en halv dag på ett svar på sina handlingar, vilket kan leda till deras massdvala.

Som namnet antyder, verifierar icke-funktionell testning att en mjukvaruprodukt uppfyller de icke-funktionella kraven för mandat för dess skapelse. Och, som i fallet med funktionstestning, utvecklas ett testprogram och metodik för icke-funktionell testning.

Inbäddad mjukvarutestning och efterlevnad i den agila eran

Att följa branschstandarder är inget du kan försumma eller göra senare; det är en integrerad del av utvecklingsprocessen för inbäddad programvara (mjukvara). För vissa branscher - såsom flygelektronik, fordonsindustri och hälsovård - är strikt efterlevnad av kvalitetsstandarder vid utveckling av komplexa och problemfria inbyggda system avgörande för att få ut en produkt på marknaden. Traditionellt har testning spelat en viktig roll i utvecklingen av inbyggda system för standardreglerade industrier. Men på senare år har etablerade testpraxis och processer, deras plats och roll i sådana projekt, förändrats avsevärt. Det var en game changer, och när spelreglerna ändras måste du ändra med dem för att vinna.

Med den ständiga utvecklingen av nya, banbrytande teknologier måste företag snabbt erbjuda produkter till marknaden som är pålitliga, säkra, lätta att använda och kompatibla med andra system – bara för att undvika att gå vilse i den snabbt föränderliga teknologiska världen. I en sådan situation blir den traditionella vattenfallsmodellen, där mjukvaruutvecklingsprocessen är strikt sekventiell och testning utförs i slutet, ett minne blott. DevOps och agila metoder blir allt mer populära eftersom de tillåter ingenjörer att utföra uppgifter som tidigare följde varandra samtidigt.

Prestandatester

Under prestandatestfasen är det första steget belastningstestning, vars syfte är att kontrollera om systemet kommer att reagera på ett adekvat sätt på yttre påverkan i ett läge nära verklig drift.

Förutom belastningstestning utförs tester under förhållanden med minimal hårdvara och maximal belastning - stresstestning, såväl som tester under förhållanden med maximala volymer bearbetad information - volymetrisk testning.

Det finns en annan typ av testning: stabilitets- och tillförlitlighetstestning, som inte bara inkluderar långtidstestning av en mjukvaruprodukt under normala förhållanden, utan också dess förmåga att återgå till normal drift efter korta perioder av stressande belastningar.

Dokumentation för testning

Som nämnts ovan utförs testning i enlighet med programmet och testmetoden, som är utvecklad i enlighet med GOST 34.603-92.

För att utföra testning utvecklas ett testfall, som måste innehålla tillräckligt med data för att testa alla funktionssätt för mjukvaruprodukten. Vanligtvis skapas ett testfall gemensamt av kunden och entreprenören baserat på verkliga data.

För att genomföra alla typer av prestandatester skapas oftast en så kallad datagenerator som tillåter automatiskt läge skapa en tillräcklig mängd data för att uppnå ett objektivt resultat vid bedömning av prestanda.

Under testningen upprättas ett testprotokoll som innehåller information om slutförandet av alla teststeg och steg samt kommentarer som inkommit under testningen.

Om testresultatet är negativt korrigeras bristerna och testas på nytt.

Utforskande testning

Exploratory testing (ad hoc-testning är en undertyp av funktionstestning. Den används i snabbväxande projekt med flexibla utvecklingsmetoder, där det saknas tydlig dokumentation och krav. Exploratory testing är den högsta aerobatiken inom mjukvarutestning. Kvalitativ testning finns tillgänglig för högt kvalificerade specialister och är nästan helt beroende av utföraren, hans erfarenhet, kunskap (både inom ämnesområdet och i testmetoder), och förmågan att snabbt komma till essensen.

Stresstestning

Belastningstestning är processen för att analysera prestandan hos systemet som testas under belastning. Syftet med lasttestning är att fastställa applikationens förmåga att motstå externa belastningar. Vanligtvis utförs tester i flera steg.

1. Generera testskript

För effektiv analys måste scenarier ligga så nära faktiska användningsfall som möjligt. Det är viktigt att förstå att undantag alltid är möjliga, och även den mest detaljerade testplanen kanske inte täcker ett enda fall.

2. Utveckling av en testkonfiguration

Med testscenarier är det viktigt att fördela ordningen för ökande belastning. För framgångsrik analys är det nödvändigt att identifiera kriterier för prestationsutvärdering (svarshastighet, bearbetningstid för begäran, etc.).

3. Genomföra ett testtest

När du utför tester är det viktigt att i tid övervaka exekveringen av scenarier och responsen från systemet som testas. Att emulera höga belastningar kräver seriös hård- och mjukvaruinfrastruktur. I vissa fall används matematiska modelleringsmetoder för att minska kostnaderna för arbetet. Data erhållna vid låga belastningar tas som bas och approximeras. Ju högre nivå av simulerad belastning, desto lägre är noggrannheten för uppskattningen. Denna metod minskar dock kostnaderna avsevärt.

Testa automatisering

Huvudfunktionen i automatiserade tester är möjligheten att snabbt utföra regressionstester. De främsta fördelarna med automatisering (enligt en rapport från Worksoft) är ökad personaleffektivitet, tidigare upptäckt av defekter med mera hög kvalitet affärsprocesser. Dessa fördelar uppvägs av en betydande nackdel: hög kostnad - på grund av den höga kostnaden för att implementera och stödja testautomatisering använder fortfarande cirka 50 % av företagen huvudsakligen manuell testning.

Användbarhetstestning

Alla program skapas för att kunna användas. Användarvänlighet är en viktig kvalitetsindikator för ett program. IT-branschen känner till många exempel på projekt som tar fart efter en lyckad användbarhetsfix. Ju bredare publik, desto viktigare är användbarhetsfaktorn. Användbarhetstester innebär detaljerad analys av användarbeteende. För att bedöma ergonomin är det viktigt att ha data inte bara om hastigheten för att slutföra en affärsuppgift, utan också om användarens känslor, ansiktsuttryck och röstklang.

Konfigurationstestning

Konfigurationstestning ger förtroende för att applikationen kommer att fungera på olika plattformar och därför för maximalt antal användare. För WEB-applikationer väljs vanligtvis testning över webbläsare. För Windows-applikationer - testning på olika operativsystem och bitstorlekar (x86, x64). En viktig komponent i konfigurationstestning är testinfrastrukturen: för att utföra tester måste du ständigt underhålla en flotta av testmaskiner. Deras antal varierar från 5 till flera dussin.

Integrationstestning

Om ditt projekt har mer än en komponent behöver det integrationstestning. Med en komplex applikationsarkitektur är en nödvändig förutsättning för kvalitetssäkring att kontrollera samspelet mellan programdelar. Testning sker genom att utveckla och genomföra "end-to-end"-fall. Integrationstestning utförs efter komponenttestning. Därför är det mycket viktigt att ta hänsyn till erfarenheten av komponenttestning, samtidigt som man respekterar testfallens affärsinriktning.

Stresstestning

Varje system har en gräns normal funktion. När gränsen överskrids går systemet in i ett tillstånd av stress och ändrar sitt beteende avsevärt. Stresstestning testar driften av en applikation under förhållanden som överskrider normala funktionsgränser. Detta är särskilt viktigt för "kritiska" program: bankprogramvara, flygindustriprogram, medicin. Stresstester utförs inte bara i programvaruutvecklingsstadiet utan även under hela driftcykeln för att erhålla och bearbeta systembeteendedata över en lång tidsperiod.

Låt oss anta att det finns en get-data-funktion, som returnerar en karta med information om det användar-ID som passerade. Nu använder den här funktionen 3 funktioner source-a , source-b och source-c för att producera tre olika typer av kartor. Nu kommer vi att kombinera alla dessa kartor till en karta och återvända från get-data.

När jag testar get-dataska jag söka efter datatillgänglighet för nycklar? Är det vettigt att den här funktionen misslyckas med enhetstester om en av source-a, source-b och source-c misslyckas? Om uppgiften för den funktionen är att sammanfoga data, och det gör den, borde det vara tillräckligt, eller hur?

2 svar

Låt oss anta att det finns en get-data-funktion som returnerar en karta med information om det användar-ID som skickas till.

Bra. Då bör du kolla upp det. För ett givet ID, returnerar du rätt data?

nu använder den här funktionen 3 funktioner source-a, source-b och source-c för att producera tre olika typer av kartor.

Vilken implementeringsdetalj ska du ignorera i testet. Allt du testar är att din arbetsenhet (denna metod) gör vad den ska göra (ta ett ID och returnera XYZ-data för det ID). Hur den här metoden spelar egentligen ingen roll - trots allt är den viktigaste fördelen med detta enhetsteste att du kan refaktorera metodens implementering och testet kommer att kontrollera att du gjorde det korrekt.

Men du måste förmodligen håna datakällorna, så någon gång kommer testet förmodligen att behöva veta hur den här koden fungerar. Du måste balansera tre konkurrerande mål här: göra testet isolerat (genom att håna data), samtidigt som testet fokuserar på krav och pragmatism.

Detta är trots allt viktig kod. Det finns tester för att stödja den faktiska koden, att spendera mycket tid och besväret med att kontrollera polish är inte lika användbart som tester tillverkning .

I enhetstestning bör du bara testa funktionaliteten för en klass, om dina metoder source-a, source-b och source-c anropar andra klasser bör du håna dem (de bör enhetstestades i sina klasser).

I integrationstestning testar du beteendet hos flera klasser som interagerar mellan dem, detta betyder att din get-data-funktion måste kontrollera att den data som hämtas är korrekt (källa-a, källa-b och källa-c är korrekta och data är korrekt ansluten).

Enhetstest är enklare och mer fokuserade och bör skrivas av utvecklare. Integrationstest blir vanligtvis föråldrade relativt snabbt (om några intern komponent har ändrats), vilket gör dem svårare att utföra. Måste skapas av en QA-profil.

Hur kan du säkerställa att fall av krascher, frysning eller underlåtenhet att utföra de nödvändiga åtgärderna i programmet du har utvecklat blir mycket sällsynta?

Det finns inget exakt svar på denna fråga. Men genom århundradena har de klokaste forskarna tänkt på detta ämne i flera år och kunnat hitta ett botemedel som, om det inte eliminerar alla programfel, åtminstone skapar en illusion av handling för att eliminera dem.

Och detta botemedel kallas TESTA programvaran.

Enligt kloka människor är testning ett av de mest etablerade sätten att säkerställa kvaliteten på mjukvaruutveckling och ingår i uppsättningen av effektiva verktyg i ett modernt kvalitetssäkringssystem för mjukvaruprodukter.

När och vem?

Alla utvecklare är dock överens om att testning av en mjukvaruprodukt utifrån klassificering efter syfte bör delas in i två klasser:

Funktionstestning
Icke-funktionell testning

Funktionstestning

För att genomföra funktionstestning utvecklar personalen på den tekniska kontrollavdelningen ett dokumentprogram och metodik för att testa applikationens funktionalitet (API). PMI-dokumentet innehåller en lista över scenarier för testning av programvaruprodukter (testfall) med en detaljerad beskrivning av stegen. Varje steg i testscenariot kännetecknas av användarens (testspecialistens) åtgärder och de förväntade resultaten - programmets svar på dessa åtgärder. Testprogrammet och metodiken måste simulera driften av mjukvaruprodukten i verkligt läge. Detta innebär att testscenariot bör byggas på grundval av en analys av de operationer som framtida användare av systemet kommer att utföra, och inte vara en artificiellt sammanställd sekvens av manipulationer som bara är förståelig för utvecklaren.

Typiskt utförs funktionstestning på två nivåer:

Komponent (enhets) testning. Testning av individuella komponenter i en mjukvaruprodukt, med fokus på deras specifikationer, syfte och funktionella egenskaper.
Integrationstestning. Denna typ av testning utförs efter komponenttestning och syftar till att identifiera defekter i samverkan mellan olika delsystem på nivån för styrflöden och datautbyte.

Icke-funktionell testning

Icke-funktionell testning utvärderar egenskaperna hos en mjukvaruprodukt, såsom ergonomi eller prestanda.

Som namnet antyder kontrollerar icke-funktionell testning att en mjukvaruprodukt överensstämmer med icke-funktionella krav från de tekniska specifikationerna för dess skapande. Och, som i fallet med funktionstestning, utvecklas ett testprogram och metodik för icke-funktionell testning.

Inbäddad mjukvarutestning och efterlevnad i den agila eran

Prestandatester

Dokumentation för testning

Som nämnts ovan utförs testning i enlighet med programmet och testmetoden, som är utvecklad i enlighet med GOST 34.603-92.

För att genomföra alla typer av prestandatester skapas oftast en så kallad datagenerator, som gör att man automatiskt kan skapa en tillräcklig mängd data för att uppnå ett objektivt resultat vid bedömning av prestanda.

Under testningen upprättas ett testprotokoll som innehåller information om slutförandet av alla teststeg och steg samt kommentarer som inkommit under testningen.

Om testresultatet är negativt korrigeras bristerna och testas på nytt.

Utforskande testning

Stresstestning

1. Generera testskript

2. Utveckling av en testkonfiguration

3. Genomföra ett testtest

Testa automatisering

Huvudfunktionen i automatiserade tester är möjligheten att snabbt utföra regressionstester. De främsta fördelarna med automatisering (enligt en rapport från Worksoft) är ökad personaleffektivitet, tidigare upptäckt av defekter och högre kvalitet på affärsprocesser. Dessa fördelar uppvägs av en betydande nackdel: hög kostnad - på grund av den höga kostnaden för att implementera och stödja testautomatisering använder fortfarande cirka 50 % av företagen huvudsakligen manuell testning.

Användbarhetstestning

Konfigurationstestning

Konfigurationstestning ger förtroende för att applikationen kommer att fungera på olika plattformar och därför för maximalt antal användare. För WEB-applikationer väljs vanligtvis testning över webbläsare. För Windows-applikationer - testning på olika operativsystem och bithastigheter (x86, x64). En viktig komponent i konfigurationstestning är testinfrastrukturen: för att utföra tester måste du ständigt underhålla en flotta av testmaskiner. Deras antal varierar från 5 till flera dussin.

Integrationstestning

Stresstestning

Alla system har en gräns för dess normala funktion. När gränsen överskrids går systemet in i ett tillstånd av stress och ändrar sitt beteende avsevärt. Stresstestning testar driften av en applikation under förhållanden som överskrider normala funktionsgränser. Detta är särskilt viktigt för "kritiska" program: bankprogramvara, flygindustriprogram, medicin. Stresstester utförs inte bara i utvecklingsstadiet utan även under hela driftcykeln för att erhålla och bearbeta systembeteendedata över en lång tidsperiod.

Bland alla typer intar funktionstestning med rätta en ledande position, eftersom programmet först och främst måste fungera korrekt, annars kommer användarvänlighet, säkerhet och tillräcklig hastighet att vara till ingen nytta. Förutom att behärska olika testtekniker måste varje specialist förstå hur man utför ett test korrekt för att få det mest effektiva resultatet.

Funktionstestning: vart ska man rikta huvudinsatserna?

För enhets- och systemtestning;

För att markera den "vita" eller "svarta" rutan;

För manuell testning och automatisering;

För att testa ny funktionalitet eller;

För "negativa" eller "positiva" tester.

Mellan alla dessa verksamhetsområden är det viktigt att hitta den rätta vägen, som kommer att vara "mitten", för att balansera ansträngningarna och utnyttja fördelarna med vart och ett av områdena maximalt.

Mjukvaruverifiering utförs olika sätt, varav en är svart låda eller datadriven testning.

Programmet i det här fallet presenteras utifrån en "svart låda", och testet utförs för att fastställa under vilka omständigheter programmets beteende inte kommer att överensstämma med specifikationen. Alla fel identifieras genom datahantering, som utförs genom uttömmande tester, det vill säga med hjälp av alla möjliga

Om exekveringen av ett kommando för ett program beror på händelserna som föregår det, kommer det att kräva att alla möjliga sekvenser kontrolleras. Det är ganska uppenbart att det i de flesta fall helt enkelt är omöjligt att utföra uttömmande tester, så oftare väljer de ett acceptabelt eller rimligt alternativ som är begränsat till att köra programmet på en liten delmängd av all indata. Detta alternativ garanterar helt att inga avvikelser från specifikationer.

Funktionstestning innebär att man väljer rätt test. Samtidigt är det vanligt att skilja mellan följande metoder för att generera uppsättningar för dem:

Gränsvärdesanalys;

Motsvarande partition;

Felantagande;

Analys av samband mellan orsaker och effekter.

Du kan överväga var och en av dem separat.

Gränsvärdesanalys. Gränsvärden förstås vanligtvis som de som ligger på gränserna för ekvivalensklasser. På sådana platser är det mest sannolikt att hitta ett fel. Användningen av en sådan metod kräver en viss kreativitet från specialisten, såväl som specialisering i detta specifika problem som övervägs.

Motsvarande partition. Alla möjliga uppsättningar av ingångsparametrar är uppdelade i flera ekvivalensklasser. Data kombineras utifrån principen att upptäcka liknande fel. Det är allmänt accepterat att om en uppsättning av en klass visar ett fel, så kommer de motsvarande också att indikera det. Funktionstest av den här metoden utförs i två steg: i det första identifieras ekvivalensklasser, och i det andra bildas redan speciella tester.

Analys av orsak och verkan samband. Systemet kan välja tester med hög prestanda genom att utföra sådana kontroller. I detta fall tas ett separat ingångstillstånd som orsak, och utmatningsvillkoret ses som effekten. Metoden bygger på idén att tillskriva alla typer av orsaker till vissa konsekvenser, det vill säga att klargöra samma orsak-och-verkan-samband. Testning av en mjukvaruprodukt utförs i flera steg, vilket resulterar i en lista över orsaker och efterföljande konsekvenser.

oavsiktliga avvikelser från utvecklare från arbetsstandarder eller implementeringsplaner;
specifikationer av funktions- och gränssnittskrav görs utan att följa utvecklingsstandarder, vilket leder till avbrott i programmens funktion;
organisation av utvecklingsprocessen - ofullständig eller otillräcklig hantering av projektledarens resurser (mänskliga, tekniska, mjukvara, etc.) och frågor om testning och integration av projektelement.

Låt oss titta på testprocessen baserat på rekommendationerna i ISO/IEC 12207-standarden och ange vilka typer av fel som upptäcks i varje livscykelprocess.

Utvecklingsprocess för krav. När man bestämmer systemets initiala koncept och de initiala kraven för systemet gör analytiker specifikationsfel högsta nivån system och bygga en konceptuell modell av ämnesområdet.

Typiska fel i denna process är:

otillräcklighet i kravspecifikationen för slutanvändare, - felaktig specifikation av programvarans interaktion med operativmiljön eller med användare;
bristande efterlevnad av kundkrav för individuella och allmänna programvaruegenskaper;
felaktig beskrivning av funktionella egenskaper;
brist på tillgång till verktyg för alla aspekter av att implementera kundkrav osv.

Designprocessen.Fel i konstruktionen av komponenter kan uppstå vid beskrivning av algoritmer, styrlogik, datastrukturer, gränssnitt, dataflödesmodelleringslogik, input/output-format etc. Dessa fel är baserade på defekter i analytikerspecifikationer och designfel. Dessa inkluderar fel relaterade till:

med definitionen av användargränssnittet med miljön;
med en beskrivning av funktionerna (otillräcklighet i målen och målen för komponenterna som upptäcks vid kontroll av en uppsättning komponenter);
med definitionen av och interaktionen mellan processer (resultatet av felaktig bestämning av förhållandena mellan komponenter och processer);
med felaktig specifikation av data och deras strukturer vid beskrivning av enskilda komponenter och programvaran som helhet;
med felaktig beskrivning av modulalgoritmer;
med fastställande av villkoren för förekomsten möjliga fel i ett program;
i strid med de standarder och tekniker som antagits för projektet.

Kodningsstadiet.I detta skede uppstår fel som är resultatet av konstruktionsfel, fel hos programmerare och chefer under utveckling och felsökning av systemet. Orsakerna till fel är:

brist på kontroll över värdena på ingångsparametrar, arrayindex, loopparametrar, utdata, division med 0, etc.;
felaktig hantering av oregelbundna situationer vid analys av returkoder från anropade subrutiner, funktioner etc.;
brott mot kodningsstandarder (dåliga kommentarer, irrationella tilldelning av moduler och komponent, etc.);
användningen av ett namn för att beteckna olika objekt eller olika namn på ett objekt, dåliga namnminnen; - inkonsekventa ändringar av programmet av olika utvecklare, etc.

Testprocess.I denna process görs fel av programmerare och testare när de utför monterings- och testteknik, väljer testset och testscenarier, etc. Fel i programvara som orsakas av denna typ av fel måste identifieras, elimineras och inte påverka statistiken för komponent och programvarufel i allmänhet.

Underhållsprocess.Under underhållsprocessen upptäcks fel som orsakas av brister och defekter i driftdokumentationen, otillräckliga indikatorer på modifierbarhet och läsbarhet, samt inkompetens hos personer som ansvarar för underhåll och/eller förbättring av programvaran. Beroende på vilken typ av ändringar som görs kan nästan alla fel som liknar de tidigare listade felen i tidigare skeden uppstå i detta skede.

Alla fel som uppstår i program delas vanligtvis in i följande klasser [7.12]:

logiska och funktionella fel;
beräknings- och körtidsfel;
in-/utdata- och datamanipuleringsfel;
gränssnittsfel;
datavolymfel etc.

Logiska felär orsaken till brott mot algoritmens logik, intern inkonsekvens av variabler och operatörer, såväl som programmeringsregler. Funktionella fel är en konsekvens av felaktigt definierade funktioner, brott mot ordningen för deras tillämpning eller bristande fullständighet i deras implementering, etc.

Beräkningsfel uppstår på grund av felaktigheter i källdata och implementerade formler, metodfel, felaktig tillämpning av beräkningsoperationer eller operander. Körtidsfel är förknippade med misslyckande med att tillhandahålla den begärda bearbetningshastigheten eller programåterställningstid.

I/O-fel och datamanipulation är en konsekvens av dålig kvalitet på förberedelser av data för programkörning, misslyckanden när de läggs in i databaser eller när de hämtas från dem.

Gränssnittsfel hänvisar till fel i förhållandet mellan enskilda element med varandra, vilket visar sig under överföringen av data mellan dem, såväl som under interaktion med driftsmiljön.

Volymfel relaterar till data och är en konsekvens av att de implementerade åtkomstmetoderna och databasstorlekarna inte tillfredsställer de verkliga volymerna av systeminformation eller intensiteten i deras bearbetning.

De givna huvudklasserna av fel är karakteristiska för olika typer av programvarukomponenter och de manifesterar sig i program på olika sätt. Sålunda, när man arbetar med en databas, uppstår fel i datapresentation och manipulation, logiska fel i att specificera tillämpade databehandlingsprocedurer etc. I beräkningsprogram dominerar beräkningsfel och i styr- och bearbetningsprogram dominerar logiska och funktionella fel. Programvara, som består av många olika program som implementerar olika funktioner, kan innehålla fel olika typer. Gränssnittsfel och volymöverträdelser är typiska för alla typer av system.

Att analysera typerna av fel i program är en förutsättning för att skapa testplaner och testmetoder för att säkerställa programvarans korrekthet.

I det nuvarande utvecklingsstadiet av stödverktyg för mjukvaruutveckling (CASE-teknologier, objektorienterade metoder och verktyg för design av modeller och program) genomförs en design där mjukvaran skyddas från de vanligaste felen och därigenom förhindrar uppkomsten av programvarufel.

Samband mellan fel och misslyckande.Förekomsten av ett fel i ett program leder som regel till ett fel i programvaran under dess drift. För att analysera orsak-och-verkan-förhållandena för "fel-fel" utförs följande åtgärder:

identifiering av brister i design- och programmeringsteknik;
förhållandet mellan brister i designprocessen och mänskliga fel;
klassificering av fel, brister och möjliga fel, såväl som defekter i varje utvecklingsstadium - jämförelse av mänskliga fel som gjorts i en viss utvecklingsprocess och defekter i objektet, som en konsekvens av fel i projektspecifikationen, programmodeller;
verifiering och felskydd i alla skeden av livscykeln, samt upptäckt av defekter i varje utvecklingsstadium;
jämförelse av defekter och fel i programvara för att utveckla ett system av sammankopplingar och metoder för lokalisering, insamling och analys av information om fel och defekter;
utveckling av metoder för processer för att dokumentera och testa programvara.

Det slutliga målet med fel-fel-orsak är att definiera metoder och medel för att testa och upptäcka fel i vissa klasser, såväl som kriterier för att slutföra testning på flera datamängder; att identifiera sätt att förbättra organisationen av processen för mjukvaruutveckling, testning och underhåll.

Här är följande klassificering av feltyper:

hårdvara, där den systemomfattande programvaran inte fungerar;
information, orsakad av fel i indata och dataöverföring via kommunikationskanaler, såväl som fel på inmatningsenheter (en följd av hårdvarufel);
ergonomisk, orsakad av operatörsfel under hans interaktion med maskinen (detta fel är ett sekundärt fel och kan leda till informations- eller funktionsfel);
programvara, om det finns fel i komponenter osv.

Vissa fel kan vara resultatet av brister i kravdefinition, design, generering av utdatakod eller dokumentation. Å andra sidan genereras de under utvecklingen av ett program eller under utvecklingen av gränssnitt för enskilda programelement (överträdelse av parametrarnas ordning, färre eller fler parametrar, etc.).

Källor till fel.Fel kan genereras under utvecklingen av projektet, komponenter, kod och dokumentation. Som regel upptäcks de under körning eller underhåll av programvara på de mest oväntade och olika punkter.

Vissa fel i ett program kan vara resultatet av brister i kravdefinition, design, kodgenerering eller dokumentation. Å andra sidan genereras fel under utvecklingen av ett program eller gränssnitten för dess element (till exempel när ordningen för inställning av kommunikationsparametrar överträds - mindre eller mer än vad som krävs, etc.).

Orsaken till felen är bristande förståelse för kundens krav; felaktig kravspecifikation i projektdokument etc. Detta leder till att vissa systemfunktioner implementeras som inte kommer att fungera som kunden föreslagit. I detta avseende genomförs en gemensam diskussion mellan kunden och utvecklaren av vissa detaljer i kraven för att klargöra dem.

Systemutvecklingsteamet kan också ändra syntax och semantik för systembeskrivningen. Vissa fel kanske inte upptäcks (till exempel är indexen eller variabelvärdena för dessa uttalanden felaktigt inställda).

Populär i kategorin: