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

Testning av mjukvaruprodukt. Hur kontrollerar 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 ett fel inom en halvtimme och först efter det kasta monitorn exakt 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 gjorde det " falla”.

Hur gör man det så att fall av fallande, frysning, underlåtenhet att utföra de nödvändiga åtgärderna i programmet som utvecklats av dig blir mycket sällsynta?

Det finns inget exakt svar på denna fråga. Men i århundraden har de klokaste vetenskapsmännen tänkt på detta i åratal och ändå kunnat hitta ett botemedel som, om inte eliminerar alla programfel, så åtminstone skapar en illusion av aktivitet för att eliminera dem.

Och detta verktyg kallas Testning av 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 en uppsättning effektiva verktyg modernt system kvalitetssäkring av mjukvaruprodukter.

Kvaliteten på en mjukvaruprodukt kännetecknas av en uppsättning egenskaper som bestämmer hur "bra" produkten är ur intresserade parters synvinkel, såsom kunden av produkten, sponsor, slutanvändare, produktutvecklare och testare, support ingenjö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. Utformningen av problemet med att säkerställa produktens kvalitet 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 verksamhet. Specialutbildade anställda, så kallade testare, bör testa mjukvaruprodukten, eftersom inte ens den mest erfarna utvecklaren kommer att kunna se sitt misstag, ens med de senaste optiska instrumenten.

Ändå är alla utvecklare överens om att testning av en mjukvaruprodukt när det gäller klassificering efter mål bör delas in i två klasser:

Funktionstestning
Icke-funktionell testning

Funktionstestning

Funktionstestning förstås som kontroll av en mjukvaruprodukts överensstämmelse med de funktionskrav som anges i referensvillkoren för att skapa denna produkt. Enkelt uttryckt, funktionstestning kontrollerar om mjukvaruprodukten utför alla funktioner som den borde.

Så du bestämde dig för att utföra funktionstestning. Du tittar på uppdragsbeskrivningen, läser funktionskraven och förstår att de åtminstone inte är i den ordning du kan testa. Du kommer att bli förvånad över att för länge sedan har andra redan 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 en metod för att testa applikationsfunktionaliteten (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. Programmet och testmetoden måste simulera driften av mjukvaruprodukten i verkligt läge. Detta innebär att testskriptet ska byggas på basis 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 är begripliga endast för utvecklaren.

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

Komponent (enhet) 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 sådana egenskaper hos en mjukvaruprodukt som till exempel 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 systemets prestanda inte är tillräcklig, måste användarna vänta en halv dag på ett svar på sina handlingar, vilket kan leda till deras massiva viloläge.

Som namnet antyder kontrollerar icke-funktionell testning att mjukvaruprodukten uppfyller de icke-funktionella kraven i mandat till dess skapelse. Och, som i fallet med funktionstestning, utvecklas ett program och testmetodik för icke-funktionell testning.

Inbyggd mjukvarutestning och efterlevnad i Agiles tidsålder

Att följa branschstandarder är inget du kan försumma eller göra senare; det är en integrerad del av utvecklingsprocessen för inbyggd programvara (SW). För vissa branscher – såsom flygelektronik, fordonsindustrin och hälsovård – håller strikt efterlevnad av kvalitetsstandarder i utvecklingen av komplexa och problemfria inbyggda system att bli en viktig förutsättning för att få ut en produkt på marknaden. Traditionellt har testning spelat en viktig roll i utvecklingen av inbyggda system för standarddrivna industrier. Men under de senaste åren har etablerade metoder och testprocesser, deras plats och roll i sådana projekt förändrats avsevärt. Det har dramatiskt förändrat alla spelets regler, och när spelreglerna ändras måste du ändra med dem för att vinna.

Med ny, toppmodern teknik som ständigt utvecklas, måste företag snabbt få ut produkter på marknaden som är pålitliga, säkra, lätta att använda och interoperabla – bara så att de inte går vilse i det snabba tempot. teknikvärlden. I en sådan situation håller den traditionella vattenfallsmodellen, där mjukvaruutvecklingsprocessen är strikt sekventiell och testning utförs i slutet av den, att bli ett minne blott. DevOps och agila metoder blir allt populärare eftersom de tillåter ingenjörer att utföra uppgifter som brukade följa varandra samtidigt.

Prestandatester

Under prestandatestfasen utförs först och främst belastningstestning, vars syfte är att kontrollera om systemet kommer att reagera adekvat på yttre påverkan i ett läge nära det verkliga driftläget.

Förutom belastningstestning utförs tester under förhållanden med minimal hårdvara och maximal belastning - stresstestning, samt tester under förhållanden med maximala volymer bearbetad information - volymtestning.

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

Dokumentation för testning

Som nämnts ovan utförs testning i enlighet med testprogrammet och metodiken, som utvecklas i enlighet med GOST 34.603-92.

Utvecklad för testning testfall, som bör innehålla tillräckligt med data för att kontrollera alla funktionssätt för mjukvaruprodukten. Vanligtvis skapas ett testfall gemensamt av beställaren och entreprenören baserat på verkliga data.

För att genomföra alla typer av prestandatester skapas oftast en så kallad datagenerator som gör att du kan automatiskt läge skapa tillräckligt med data för att uppnå ett objektivt resultat vid utvärdering av prestanda.

Under provningen upprättas ett testprotokoll, där information läggs in om genomgången av alla steg och steg i testningen och de kommentarer som inkommit under testerna.

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

Utforskande testning

Utforskande testning (ad hoc-testning är en underart av funktionstestning. Det används i snabbväxande projekt med flexibla utvecklingsmetoder, där det inte finns någon tydlig dokumentation och krav. Utforskande testning är toppen av mjukvarutestning. Testning av hög kvalitet finns tillgänglig till högt kvalificerade specialister och nästan helt beroende av utförare, hans erfarenhet, kunskap (både inom ämnesområdet och i testmetoder), förmågan att snabbt penetrera essensen.

Stresstestning

Lasttestning är processen för att analysera prestandan hos systemet som testas under påverkan av belastningar. Målet med lasttestning är att bestämma en applikations förmåga att motstå externa belastningar. Vanligtvis utförs tester i flera steg.

1. Generering av testskript

För effektiv analys bör scenarier vara så nära verkliga 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 en framgångsrik analys är det nödvändigt att lyfta fram kriterierna för att utvärdera prestanda (svarshastighet, bearbetningstid för begäran etc.).

3. Genomföra ett testtest

När du utför tester är det viktigt att övervaka exekveringen av skript och responsen från systemet som testas i tid. För att efterlikna höga belastningar krävs en seriös hård- och mjukvaruinfrastruktur. I vissa fall används matematiska modelleringsmetoder för att minska kostnaderna för arbetet. De data som erhålls 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 Worksoft-rapporten) ä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 de höga kostnaderna för att implementera och underhålla testautomatisering använder fortfarande cirka 50 % av företagen oftast manuell testning.

Användbarhetstestning

Varje app är byggd för att användas. Användarvänlighet är en viktig kvalitetsindikator för programmet. 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 en 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, vilket innebär för maximalt antal användare. För WEB-applikationer väljs vanligtvis testning av kompatibilitet över webbläsare. För Windows-applikationer - testning på olika operativsystem och bithet (x86, x64). En viktig komponent i konfigurationstestning är testinfrastrukturen: för testning 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 interaktion mellan delar av programmet. Testning uppnås genom att utveckla och genomföra "genom" 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ärsorientering.

stresstestning

Varje system har en gräns normal funktion. När gränsen överskrids går systemet in i ett stresstillstånd och ändrar avsevärt sitt beteende. Stresstestning kontrollerar applikationens prestanda under förhållanden där gränserna för normal drift överskrids. Detta är särskilt viktigt för "kritiska" program: bankprogramvara, flygindustrins program och medicin. Stresstester utförs inte bara i utvecklingsstadiet utan även under hela driftcykeln för att erhålla och bearbeta data om systemets beteende under lång tid.

Anta att det finns en get-data-funktion, som returnerar en karta med information om användar-id:t som passerade. Nu använder den här funktionen de 3 funktionerna source-a , source-b och source-c för att få 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-data, ska jag kontrollera om det finns data 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 denna funktions uppgift är att sammanfoga data, och det gör den, borde det vara tillräckligt, eller hur?

2 svar

Anta att det finns en get-data-funktion som returnerar en karta med information om användar-id som skickats in.

Bra. Då bör du kolla upp det. För det angivna ID:t, returnerar du rätt data?

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

Vilken implementeringsdetalj ska du ignorera i ett test. 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 implementeringen av metoden och testet kommer att verifiera att du gjorde det rätt.

Men du kommer förmodligen att behöva håna datakällor, 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), göra testet fokuserat på krav och pragmatism.

Detta är trots allt viktig kod. Det finns tester för att säkerhetskopiera den faktiska koden, att spendera mycket tid och krångel 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 för 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, vilket innebär 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 sammanfogade).

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

Hur gör man det så att fall av fallande, frysning, underlåtenhet att utföra de nödvändiga åtgärderna i programmet som utvecklats av dig blir mycket sällsynta?

Och detta verktyg kallas Testning av mjukvaruprodukt.

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 mjukvara.

När och vem?

Ändå är alla utvecklare överens om att testning av en mjukvaruprodukt när det gäller klassificering efter mål 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 en metod för att testa applikationsfunktionaliteten (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. Programmet och testmetoden måste simulera driften av mjukvaruprodukten i verkligt läge. Detta innebär att testskriptet ska byggas på basis 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 är begripliga endast för utvecklaren.

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

Komponent (enhet) 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 sådana egenskaper hos en mjukvaruprodukt som till exempel ergonomi eller prestanda.

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

Inbyggd mjukvarutestning och efterlevnad i Agiles tidsålder

Prestandatester

Dokumentation för testning

Som nämnts ovan utförs testning i enlighet med testprogrammet och metodiken, som utvecklas i enlighet med GOST 34.603-92.

För testning utvecklas ett testfall som bör innehålla tillräckligt med data för att testa alla funktionssätt för mjukvaruprodukten. Vanligtvis skapas ett testfall gemensamt av beställaren och entreprenören baserat på verkliga data.

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 utvärdering av prestanda.

Under provningen upprättas ett testprotokoll, där information läggs in om genomgången av alla steg och steg i testningen och de kommentarer som inkommit under testerna.

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

Utforskande testning

Stresstestning

1. Generering av 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 Worksofts företagsrapport) ä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 de höga kostnaderna för att implementera och underhålla testautomatisering använder fortfarande cirka 50 % av företagen oftast manuell testning.

Användbarhetstestning

Konfigurationstestning

Konfigurationstestning ger förtroende för att applikationen kommer att fungera på olika plattformar, vilket innebär för maximalt antal användare. För WEB-applikationer väljs vanligtvis testning av kompatibilitet över webbläsare. För Windows-applikationer - testning på olika operativsystem och bitness (x86, x64). En viktig komponent i konfigurationstestning är testinfrastrukturen: för testning 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 normal funktion. När gränsen överskrids går systemet in i ett stresstillstånd och ändrar avsevärt sitt beteende. Stresstestning kontrollerar applikationens prestanda under förhållanden där gränserna för normal drift överskrids. Detta är särskilt viktigt för "kritiska" program: bankprogramvara, flygindustrins program och medicin. Stresstester utförs inte bara i utvecklingsstadiet utan även under hela driftcykeln för att erhålla och bearbeta data om systemets beteende under lång tid.

Bland alla typer av funktionstestning intar det med rätta en ledande position, eftersom programmet måste fungera korrekt i första hand, annars kommer det att vara absolut ingen känsla av användarvänlighet, säkerhet och tillräcklig hastighet. Förutom att behärska olika testtekniker måste varje specialist förstå hur man testar 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 ;

På "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 insatserna och utnyttja fördelarna med vart och ett av områdena maximalt.

Programvaruverifiering utförs olika sätt, varav en är black-box eller datadriven testning.

Programmet i det här fallet presenteras ur den "svarta lådan", och testet utförs för att ta reda på de omständigheter under vilka programmets beteende inte kommer att överensstämma med specifikationen. Alla fel fastställs av datahantering som utförs med hjälp av uttömmande tester, det vill säga med alla tänkbara

Om exekveringen av ett kommando för ett program beror på händelserna som föregår det, kommer en kontroll av alla möjliga sekvenser att krävas. 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 frånvaron av avvikelser från specifikationerna.

Funktionstestning innebär rätt val av test. Samtidigt är det vanligt att skilja mellan sådana metoder för att forma uppsättningar för dem:

Gränsvärdesanalys;

Motsvarande partition;

Gissa fel;

Analys av samband mellan orsaker och effekter.

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

Analys av gränsvärden. 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 enligt principen att upptäcka liknande fel. Det är allmänt accepterat att om en uppsättning av en klass upptäcker ett fel, kommer likvärdiga sådana också att indikera det. Funktionstest av den här metoden utförs i två steg: i det första väljs ekvivalensklasser och i det andra bildas redan speciella tester.

Analys av sambanden mellan orsak och verkan. Systemet kan välja tester med hög prestanda på grund av sådana kontroller. I detta fall tas ett separat ingångstillstånd som en orsak, och ett utmatningsvillkor ses som en konsekvens. 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 konsekvenser.

oavsiktlig avvikelse från utvecklare från arbetsstandarder eller implementeringsplaner;
specifikationer av funktions- och gränssnittskrav exekveras utan att utvecklingsstandarderna följs, vilket leder till avbrott i programmens funktion;
organisation av utvecklingsprocessen - ofullständig eller otillräcklig hantering av projektledaren av resurser (mänskliga, tekniska, mjukvara, etc.) och frågor om testning och integration av projektelement.

Låt oss överväga testprocessen baserat på rekommendationerna i ISO/IEC 12207-standarden och lista de typer av fel som finns i varje livscykelprocess.

Kravutvecklingsprocess. Vid fastställande av systemets initiala koncept och de initiala kraven för systemet uppstår analytikerfel under specifikationen 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;
diskrepans mellan kundkrav för individuella och allmänna programvaruegenskaper;
felaktig beskrivning av funktionella egenskaper;
brist på verktyg för alla aspekter av implementering av kundkrav m.m.

Designprocessen.Fel i design av komponenter kan uppstå vid beskrivning av algoritmer, styrlogik, datastrukturer, gränssnitt, logik för modellering av dataflöden, input-output format etc. Dessa fel är baserade på defekter i analytikers specifikationer och brister hos designers. 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 komplexet av komponenter);
med definitionen av och interaktionen mellan processer (resultatet av en felaktig definition av relationerna mellan komponenter och processer);
med felaktig tilldelning av data och deras strukturer i beskrivningen av enskilda komponenter och PS som helhet;
med felaktig beskrivning av modulalgoritmer;
med definitionen av villkoren för förekomsten av möjliga fel i programmet;
i strid med de standarder och tekniker som antagits för projektet.

Kodningsstadiet.I detta skede uppstår fel som är resultatet av designdefekter, fel hos programmerare och chefer i processen att utveckla och felsöka 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 samma namn för att beteckna olika objekt eller olika namn på samma objekt, dåliga namnmnemonics; - 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 testsviter och testscenarier etc. Programvarufel som orsakas av sådana fel bör upptäckas, elimineras och inte återspeglas i felstatistiken för komponenter och programvara 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 de tidigare stegen 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;
I/O- och datamanipulationsfel;
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 resultatet av felaktigt definierade funktioner, överträdelse av ordningen för deras tillämpning eller bristande fullständighet av 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 relaterade till misslyckandet med att tillhandahålla den nödvändiga frågebehandlingshastigheten eller programåterställningstid.

I/O-fel och manipulering av data är resultatet av förberedelser av dålig kvalitet på data för körning av programmet, misslyckanden när de skrivs in i databasen eller när de hämtas från den.

Gränssnittsfel relatera till fel i sammankopplingen av enskilda element med varandra, vilket visar sig vid överföring av data mellan dem, såväl som vid interaktion med den fungerande miljö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å när man arbetar med en databas finns det fel i presentationen och manipuleringen av data, logiska fel i uppgiften att tillämpa databehandlingsprocedurer etc. Beräkningsfel dominerar i program av beräkningskaraktär och logiska och funktionella fel i styr- och bearbetningsprogram. Programvaran, som består av många olika program som implementerar olika funktioner, kan innehålla fel. olika typer. Gränssnittsfel och räckviddsöverträdelser är vanliga 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 att programvaran är korrekt.

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

Att koppla ett fel till ett fel.Närvaron av ett fel i programmet leder som regel till att programvaran misslyckas under dess drift. För att analysera orsak-och-verkan-sambanden "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 ett resultat av fel i projektspecifikationen, programmodeller;
verifiering och skydd mot fel i alla stadier av livscykeln, såväl som 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 mjukvarudokumentation och testprocesser.

Det slutliga målet med fel-fel-kausalitet är att definiera metoder och verktyg för att testa och upptäcka fel i vissa klasser, såväl som kriterier för att testa komplettering på en uppsättning datamängder; att fastställa sätt att förbättra organisationen av mjukvaruutveckling, testning och underhållsprocessen.

Vi ger följande klassificering av feltyper:

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

Vissa fel kan bero på brister i kravdefinition, design, generering av utdatakod eller dokumentation. Å andra sidan genereras de under utvecklingen av programmet eller under utvecklingen av gränssnitt för enskilda delar av programmet (ö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 i den.

Vissa fel i programmet kan vara resultatet av brister i definitionen av krav, design, kodgenerering eller dokumentation. Å andra sidan genereras fel under utvecklingen av ett program eller gränssnitt 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 uppkomsten av fel är ett missförstånd av kundens krav; felaktig kravspecifikation i projektdokument etc. Detta leder till att vissa systemfunktioner implementeras som inte kommer att fungera som kunden föreslår. I detta avseende hålls en gemensam diskussion mellan kunden och utvecklaren av vissa detaljer om kraven för deras förtydligande.

Systemdesignteamet kan också ändra syntax och semantik för systembeskrivningen. Vissa fel kanske inte upptäcks (till exempel är index eller variabelvärden för dessa operatörer felaktigt inställda).

Populär i kategorin: