Phenquestions
Enhetstestning
Enhetstestning testas på en enskild funktion, klass eller modul oberoende än att testa en fullt fungerande programvara. Med hjälp av ett ramverk för enhetstestning kan programmeraren skapa testfall med input och förväntad output. När du har hundratals, tusentals eller tiotusentals enhetstestfall för ett stort programvaruprojekt säkerställer du att alla enskilda enheter fungerar som förväntat när du fortsätter att ändra koden. När du byter en enhet som har testfall bör testfallet för den modulen studeras och avgöra om nya testfall är nödvändiga, utdata har ändrats eller de nuvarande testfall kan tas bort eftersom de inte längre är relevanta. Att skapa en stor volym enhetstest är det enklaste sättet att uppnå hög testtäckning för en programvarukodbas, men kommer inte att säkerställa att slutprodukten fungerar som ett system som förväntat.
Funktionell testning
Funktionell testning är den vanligaste formen av testning. När människor hänvisar till programvarutestning utan mycket detaljer, menar de ofta funktionstestning. Funktionstestning kontrollerar programvarans primära funktioner som förväntat. En testplan kan skrivas för att beskriva alla funktionella testfall som kommer att testas, vilket motsvarar de viktigaste funktionerna och funktionerna i programvaran. Primär funktionstestning kommer att vara “lycklig väg ” testning, som inte försöker bryta programvaran eller använda den i några utmanande scenarier. Detta borde vara det absolut minimala testet för alla programvaruprojekt.
Integrationstestning
Efter enhetstestning och funktionstestning kan det finnas flera moduler eller hela systemet som ännu inte har testats som en helhet. Eller så kan det finnas komponenter som till stor del är oberoende men ibland används tillsammans. Varje gång komponenter eller moduler testas oberoende men inte som ett helt system, ska integreringstester utföras för att validera komponenterna tillsammans som ett fungerande system enligt användarens krav och förväntningar.
Stresstestning
Tänk på stresstest som om du testar en rymdfärja eller ett flygplan. Vad betyder det att sätta din programvara eller ditt system under "STRESS"? Stress är inget annat än en intensiv belastning av en specifik typ som sannolikt kommer att bryta ditt system. Detta kan likna "Load Testing" i betydelsen att sätta ditt system under hög samtidighet med många användare som har åtkomst till systemet. Men att betona ett system kan också hända på andra vektorer. Till exempel körning av firmware på en hårdvarukomponent när hårdvaran har försämrats fysiskt och fungerar i försämrat läge. Stress är unik för alla typer av programvara, och system och utformning av stresstester bör övervägas av vilka naturliga eller onaturliga orsaker som mest sannolikt kommer att stressa din programvara eller ditt system.
Lasttestning
Belastningstestning är en specifik typ av stresstestning, som diskuterats ovan, där ett stort antal samtidiga användaranslutningar och åtkomst automatiseras för att generera simuleringen av effekten av ett stort antal autentiska användare som får åtkomst till ditt mjukvarusystem samtidigt. Målet är att ta reda på hur många användare som kan komma åt ditt system samtidigt utan att ditt programvarusystem går sönder. Om ditt system enkelt kan hantera normal trafik på 10 000 användare, vad händer om din webbplats eller programvara blir viral och får 1 miljon användare? Kommer detta oväntat "LADDA" bryta din webbplats eller ditt system? Lasttestning kommer att simulera detta, så du är bekväm med den framtida ökningen av användare eftersom du vet att ditt system klarar av den ökade belastningen.
Prestandatester
Människor kan bli helt frustrerade och förtvivlade när programvaran inte uppfyller deras prestandakrav. Prestanda betyder i allmänhet hur snabbt viktiga funktioner kan slutföras. Ju mer komplexa och dynamiska funktionerna finns i ett system, desto viktigare och mer självklart blir det att testa dess prestanda, låt oss ta ett grundläggande exempel, Windows eller Linux operativsystem. Ett operativsystem är en mycket komplex programvaruprodukt, och att göra prestandatestning av dess system kan innebära hastighet och tidpunkt för funktioner som Bootup, installation av en app, sökning efter en fil, körning av beräkningar på en GPU och / eller någon annan av de miljontals åtgärder som kan utföras. Försiktighet bör iakttas vid val av prestanda testfall för att säkerställa de viktiga och troliga funktionsfunktionerna som testats.
Test av skalbarhet
Att testa på din bärbara dator är bra men inte riktigt bra när du bygger ett socialt nätverk, ett e-postsystem eller superdatorprogramvara. När din programvara är avsedd att distribueras på 1000 servrar, som alla fungerar tillsammans, kommer de tester du gör lokalt på ett system inte att avslöja de fel som uppstår när programvaran distribueras "I skala" i hundratusentals instanser. I verkligheten kommer dina tester sannolikt aldrig att kunna köras i full skala innan de släpps till produktion eftersom det skulle vara alldeles för dyrt och inte praktiskt att bygga ett testsystem med 1000 servrar som kostar miljoner dollar. Därför görs skalbarhetstestning på flera servrar, men vanligtvis inte hela antalet produktionsservrar för att försöka avslöja några av de fel som kan hittas när dina system används på större infrastruktur.
Statisk analystestning
Statisk analys är testning som görs genom att inspektera programvarukoden utan att faktiskt köra den. För att göra statisk analys, i allmänhet skulle du använda ett verktyg, det finns många, ett känt verktyg är Coverity. Statisk analys är lätt att köra innan du släpper din programvara och kan hitta många kvalitetsproblem i din kod som kan åtgärdas innan du släpper. Minnesfel, datatypshanteringsfel, nollpekare-avferenser, oinitialiserade variabler och många fler fel kan hittas. Språk som C och C ++ drar stor nytta av statisk analys eftersom språken ger stor frihet för programmerare i utbyte mot stor kraft, men detta kan också skapa stora buggar och misstag som kan hittas med hjälp av statisk analystestning.
Test av felinsprutning
Vissa felförhållanden är mycket svåra att simulera eller utlösa, därför kan programvaran utformas för att artificiellt injicera ett problem eller fel i systemet utan att defekten naturligt uppstår. Syftet med felinsprutningstest är att se hur programvaran hanterar dessa oväntade fel. Svarar det på ett graciöst sätt på situationen, kraschar det eller ger det oväntade och oförutsägbara problematiska resultat? Låt oss till exempel säga att vi har ett banksystem och det finns en modul för att överföra pengar internt från KONTO A till KONTO B. Denna överföringsåtgärd anropas dock bara efter att systemet redan har verifierat att dessa konton fanns innan de anropade överföringen. Även om vi antar att båda kontona finns, har överföringsoperationen ett felfall där ett mål- eller källkonto inte existerar och att det kan orsaka ett fel. Eftersom vi under normala omständigheter aldrig får detta fel på grund av förtestning av ingångar, så för att verifiera systemets beteende när överföringen misslyckas på grund av ett obefintligt konto, injicerar vi ett falskt fel i systemet som returnerar ett obefintligt konto för en överföring och testa hur resten av systemet reagerar i så fall. Det är mycket viktigt att felinsprutningskoden endast är tillgänglig i testscenarier och inte släpps till produktion, där det kan skapa förödelse.
Test av minnesöverskridande
När man använder språk som C eller C ++ har programmeraren ett stort ansvar för att direkt adressera minne, och detta kan orsaka dödliga buggar i programvaran om misstag görs. Till exempel, om en pekare är noll och härleds kommer programvaran att krascha. Om minne tilldelas ett objekt och sedan en sträng kopieras över objektets minnesutrymme kan referens till objektet orsaka en krasch eller till och med ospecificerat felbeteende. Därför är det viktigt att använda ett verktyg för att försöka fånga minnesåtkomstfel i programvara som använder språk som C eller C ++, vilket kan ha dessa potentiella problem. Verktyg som kan göra denna typ av test inkluderar Open Source Valgrind eller proprietära verktyg som PurifyPlus. Dessa verktyg kan rädda dagen när det inte är klart varför programvaran kraschar eller uppför sig och pekar direkt på platsen i koden som har felet. Fantastiskt, rätt?
Gränsfallstestning
Det är lätt att göra fel i kodningen när du befinner dig på vad som kallas en gräns. Till exempel säger en bankautomatisk kassamaskin att du kan ta ut högst 300 $. Så tänk dig att kodaren skrev följande kod på ett naturligt sätt när du skapade detta krav:
Om (amt < 300)startWithdrawl ()
annan
fel ("Du kan ta ut% s", amt);
Kan du upptäcka felet? Användaren som försöker ta ut $ 300 får ett fel eftersom det inte är mindre än $ 300. Det här är ett fel. Därför görs gränstester naturligt. Kravsgränser säkerställer att programvaran fungerar på båda sidor av gränsen och gränsen.
Fuzz-testning
Höghastighetsgenerering av ingång till programvara kan producera så många möjliga ingångskombinationer, även om dessa ingångskombinationer är totalt nonsens och aldrig skulle levereras av en riktig användare. Denna typ av fuzz-test kan hitta buggar och säkerhetsproblem som inte hittas på andra sätt på grund av den höga volymen ingångar och scenarier som testas snabbt utan manuell testfallgenerering.
Exploratory Testing
Stäng ögonen och visualisera vad ordet ”Utforska” betyder. Du observerar och undersöker ett system för att ta reda på hur det verkligen fungerar. Tänk dig att du får en ny skrivbordsstol i postorder och den har 28 delar i separata plastpåsar utan instruktioner. Du måste utforska din nya ankomst för att ta reda på hur den fungerar och hur den är sammanställd. Med denna anda kan du bli en utforskande testare. Du kommer inte att ha en väldefinierad testplan för testfall. Du kommer att utforska och undersöka din programvara och leta efter saker som får dig att säga det underbara ordet: ”intressant!”. När du lär dig söker du vidare och hittar sätt att bryta programvaran som designarna aldrig tänkt på, och sedan leverera en rapport som beskriver många dåliga antaganden, fel och risker i programvaran. Läs mer om detta i boken som heter Explore It.
Penetrationstestning
I världen av mjukvarusäkerhet är penetrationstest ett av de främsta testmetoderna. Alla system, vare sig biologiska, fysiska eller programvara har gränser och gränser. Dessa gränser är avsedda att endast tillåta specifika meddelanden, personer eller komponenter att komma in i systemet. Mer konkret, låt oss överväga ett online-banksystem som använder användarautentisering för att komma in på webbplatsen. Om webbplatsen kan hackas och skrivas in i backend utan korrekt autentisering skulle det vara en penetration, som måste skyddas mot. Målet med penetrationstestning är att använda kända och experimentella tekniker för att kringgå den normala säkerhetsgränsen för ett programsystem eller en webbplats. Genomträngningstestning innebär ofta att alla portar som lyssnar kontrolleras och försöker komma in i ett system via en öppen port. Andra vanliga tekniker inkluderar SQL-injektion eller lösenordssprickning.
Regressionstestning
När du har fungerande programvara som är distribuerad i fältet är det viktigt att förhindra att buggar införs i funktionalitet som redan fungerade. Syftet med mjukvaruutveckling är att öka produktens kapacitet, införa buggar eller få gamla funktioner att sluta fungera, vilket kallas en REGRESSION. Regression är ett fel eller en defekt som introducerades när funktionen tidigare fungerade som förväntat. Ingenting kan förstöra ditt programvaras eller varumärkes rykte snabbare än att införa regressionsfel i din programvara och få riktiga användare att hitta dessa buggar efter en release.
Regressionstestfall och testplaner bör byggas kring kärnfunktionaliteten som behöver fortsätta arbeta för att säkerställa att användare har en bra upplevelse med din applikation. Alla kärnfunktioner i din programvara som användarna förväntar sig att fungera på ett visst sätt bör ha ett regressionstestfall som kan köras för att förhindra att funktionaliteten går sönder vid en ny version. Det kan vara allt från 50 till 50 000 testfall som täcker kärnfunktionaliteten i din programvara eller applikation.
Testning av källkodsdelning
Ett fel introducerades i programvaran, men det är inte uppenbart vilken version av versionen som introducerade det nya felet. Tänk dig att det fanns 50 programvaruförpliktelser från den senaste kända gången programvaran fungerade utan felet, tills nu när ..
Lokaliseringstestning
Föreställ dig en väderapplikation som visar det aktuella och beräknade vädret på din plats, samt en beskrivning av väderförhållandena. Den första delen av lokaliseringstestningen är att säkerställa att rätt språk, alfabet och tecken visas korrekt, beroende på användarens geolokalisering. Appen i Storbritannien ska visas på engelska med latinska tecken. samma app i Kina ska visas i kinesiska tecken på kinesiska. Mer detaljerad lokaliseringstest gjort, det bredare utbudet av människor från olika geolokaler kommer att gränssnitt med applikationen.
Testning av tillgänglighet
Några av medborgarna i vårt samhälle har funktionshinder och kan därför ha problem med att använda programvaran som skapas, så tillgänglighetstestning görs för att säkerställa att befolkningar med funktionsnedsättning fortfarande kan komma åt systemets funktionalitet. Om vi till exempel antar att 1% av befolkningen är färgblind och vårt mjukvarugränssnitt förutsätter att användare kan skilja mellan rött och grönt men de färgblinda individerna KAN INTE säga skillnaden. Därför kommer ett mjukvarugränssnitt att ha ytterligare ledtrådar utöver färgen för att indikera betydelse. Andra scenarier förutom test för färgblindhet skulle också inkluderas i programvarutillgänglighetstestning, såsom full synblindhet, dövhet och många andra scenarier. En bra mjukvaruprodukt bör vara tillgänglig för en maximal procentandel av potentiella användare.
Uppgraderingstestning
Enkla appar på en telefon, operativsystem som Ubuntu, Windows eller Linux Mint och programvara som kör kärnbåtar behöver frekventa uppgraderingar. Processen för uppgraderingen i sig kunde introducera buggar och defekter som inte skulle existera vid en ny installation eftersom miljöns tillstånd var annorlunda och processen att introducera den nya programvaran ovanpå den gamla kunde ha introducerat buggar. Låt oss ta ett enkelt exempel, vi har en bärbar dator som kör Ubuntu 18.04, och vi vill uppgradera till Ubuntu 20.04. Detta är en annan process för att installera operativsystemet än att rengöra hårddisken direkt och installera Ubuntu 20.04. Efter det att programvaran har installerats eller någon av dess derivatfunktioner fungerar den kanske inte 100% som förväntat eller samma som när programvaran nyligen installerades. Så vi bör först överväga att testa själva uppgraderingen i många olika fall och scenarier för att säkerställa att uppgraderingen fungerar till slut. Och sedan måste vi också överväga att testa den faktiska systemuppgraderingen för att säkerställa att programvaran har lagts ned och fungerar som förväntat. Vi skulle inte upprepa alla testfall av ett nyligen installerat system, vilket skulle vara slöseri med tid, men vi kommer att tänka noga med vår kunskap om systemet om vad KAN gå sönder under en uppgradering och strategiskt lägga till testfall för dessa funktioner.
Black Box & White Box Testing
Svart ruta och vit ruta är mindre specifika testmetoder och mer av kategoriseringstyper av testning. I huvudsak testar den svarta lådan, vilket förutsätter att testaren inte vet något om programvarans inre funktion och bygger en testplan och testfall som bara tittar på systemet från utsidan för att verifiera dess funktion. Testning av vitlåda utförs av programvaruarkitekter som förstår de interna funktionerna i ett mjukvarusystem och utformar ärenden med kunskap om vad som kan, skulle, borde och sannolikt skulle bryta. Både svarta och vita lådtester kommer sannolikt att hitta olika typer av defekter.
Bloggar och artiklar om programvarutestning
Programvarutestning är ett dynamiskt fält och många intressanta publikationer och artiklar som uppdaterar samhället om toppmodern tänkande om programvarutestning. Vi kan alla dra nytta av denna kunskap. Här är ett urval av intressanta artiklar från olika bloggkällor som du kanske vill följa:
- 7 tips att följa innan du testar utan krav; http: // www.testa tidskrifter.com /
- 60 bästa verktyg för automatiseringstest: Den ultimata listguiden; https: // testguild.com /
- Open Source Databas Testverktyg; https: // www.mjukvarutestningstidskrift.com /
- 100 procents enhetstäckning är inte tillräckligt; https: // www.stickyminds.com /
- Fläckiga tester på Google och hur vi mildrar dem; https: // testning.googleblog.com /
- Vad är regressionstestning? ; https: // test.io / blogg /
- 27 bästa Chrome-tillägg för utvecklare 2020; https: // www.lambdatest.com /
- 5 viktiga steg för programvarutestning som varje ingenjör ska utföra; https: // techbeacon.com /
Produkter för programvarutestning
Majoriteten av värdefulla testuppgifter kan automatiseras, så det borde inte vara någon överraskning att det är en bra idé att använda verktyg och produkter för att utföra de otaliga uppgifterna för programvarukvalitetssäkring. Nedan listar vi några viktiga och mycket värdefulla programvaruverktyg för programvarutestning som du kan utforska och se om de kan hjälpa till.
JUnit
För att testa Java-baserad programvara tillhandahåller JUnit en omfattande testsvit för enhets- och funktionstestning av koden som är vänlig för Java-miljön.
Selen
För att testa webbapplikationer ger Selenium möjligheten att automatisera interaktioner med webbläsare, inklusive testning av kompatibilitet mellan webbläsare. Detta är en främsta testinfrastruktur för automatisering av webbtestning.
Gurka
En beteendestyrd testram gör det möjligt för företagsanvändare, produktchefer och utvecklare att förklara den förväntade funktionaliteten på naturligt språk och sedan definiera detta beteende i testfall. Detta gör mer läsbara testfall och tydlig mappning till förväntad användarfunktionalitet.
Rena
Hitta minnesläckor och minneskorruptioner under körning genom att köra din programvara med Purify Plus-instrumenteringen inbäddad som spårar din minnesanvändning och pekar på fel i din kod som inte är lätta att hitta utan instrumentering.
Valgrind
Öppna källkodsverktyg som kommer att köra din programvara och låta dig interagera med den medan du pekar på en felrapport om kodfel som minnesläckor och korruption. Inget behov av att kompilera om eller lägga till instrumentering i kompileringsprocessen eftersom Valgrind har intelligensen för att dynamiskt förstå din maskinkod och injicera instrumentering sömlöst för att hitta kodfel och hjälpa dig att förbättra din kod.
Täckning
Statiskt analysverktyg som hittar kodningsfel i din programvara innan du ens kompilerar och kör din kod. Coverity kan hitta säkerhetssårbarheter, kränkningar av kodkonventioner, samt fel och defekter som din kompilator inte hittar. Död kod kan hittas, oinitialiserade variabler och tusentals andra defekttyper. Det är viktigt att rengöra din kod med statisk analys innan du släpper den till produktion.
JMeter
En öppen källkodsram för prestandatestning inriktad på Java-baserade utvecklare, därav J i namnet. Webbplatstestning är ett av de viktigaste användningsfallet för JMeter förutom prestandatestning av databaser, e-postsystem och många andra serverbaserade applikationer.
Metasploit
För säkerhet och penetrationstestning är Metasploit ett generiskt ramverk med tusentals funktioner och funktioner. Använd interaktionskonsolen för att få åtkomst till förkodade exploater och försök verifiera säkerheten för din applikation.
Akademisk forskning om programvarutestning
- University of Sheffield Testing Research Group
- University of Kentucky Software Verification and Validation Lab
- North Dakota State University Software Testing Research Group
- Systemtest Intelligent Lab; Tjeckiska tekniska universitetet Prag
- NASA: Jon McBride Software Testing and Research (JSTAR)
- McMaster University; Forskningslaboratorium för programvarukvalitet
- Ontario Tech University; Software Quality Research Lab
- University of Texas @ Dallas; STQA
Slutsats
Programvarans roll i samhället fortsätter att växa, och samtidigt blir världens programvara mer komplex. För att världen ska fungera måste vi ha metoder och strategier för att testa och validera programvaran vi skapar genom att utföra de funktioner den är avsedd att utföra. För varje komplext mjukvarusystem bör en teststrategi och testplan finnas för att fortsätta att validera programvarans funktionalitet eftersom de fortsätter att bli bättre och tillhandahålla dess funktion.
