Typer programvaretesting
Enhetstesting
Enhetstesting er testing utført på en individuell funksjon, klasse eller modul uavhengig enn å teste en fullt fungerende programvare. Ved hjelp av et rammeverk for enhetstesting kan programmereren opprette testtilfeller med inngang og forventet utgang. Når du har hundrevis, tusenvis eller titusenvis av enhetstestsaker for et stort programvareprosjekt sikrer at alle de enkelte enhetene fungerer som forventet når du fortsetter å endre koden. Når du endrer en enhet som har testtilfeller, bør testtilfellene for den modulen studeres og bestemme om nye testtilfeller er nødvendige, utgangen har endret seg, eller de aktuelle testtilfellene kan fjernes som ikke lenger relevant. Å lage et stort volum av enhetstester er den enkleste måten å oppnå dekning av høy test for en programvarekodebase, men vil ikke sikre at sluttproduktet fungerer som et system som forventet.
Funksjonell testing
Funksjonell testing er den vanligste formen for testing. Når folk refererer til programvaretesting uten mye detaljer, betyr de ofte funksjonell testing. Funksjonstesting vil sjekke de primære funksjonene til programvarearbeidet som forventet. En testplan kan skrives for å beskrive alle funksjonelle testtilfeller som vil bli testet, som tilsvarer de viktigste funksjonene og egenskapene til programvaren. Primær funksjonalitetstesting vil være “Happy Path ” Testing, som ikke prøver å bryte programvaren eller bruke den i noen utfordrende scenarier. Dette skal være det absolutte bare minimum av testing for ethvert programvareprosjekt.
Integrasjonstesting
Etter enhetstesting og funksjonell testing kan det være flere moduler eller hele systemet som ennå ikke er testet som en helhet. Eller det kan være komponenter som stort sett er uavhengige, men som av og til brukes sammen. Hver tidskomponenter eller moduler testes uavhengig, men ikke som et helt system, bør integrasjonstesting utføres for å validere komponentene fungerer sammen som et arbeidssystem i henhold til brukerkrav og forventninger.
Stresstesting
Tenk på stresstesting som om du tester en romferge eller fly. Hva betyr det å sette programvaren eller systemet ditt under "Stress"? Stress er ikke annet enn en intens belastning av en bestemt type som mest sannsynlig vil bryte systemet ditt. Dette kan være likt "belastningstesting" i betydningen å sette systemet ditt under høy samtidighet med mange brukere som får tilgang til systemet. Men å understreke et system kan også skje på andre vektorer. For eksempel å kjøre firmware på en maskinvarekomponent når maskinvaren har hatt fysisk forverring og opererer i degradert modus. Stress er unik for alle typer programvare, og systemer, og utforming av stresstester bør være under vurdering av hvilke naturlige eller unaturlige årsaker som mest sannsynlig stresser programvaren eller systemet ditt.
Lasttesting
Lasttesting er en spesifikk type stresstesting, som diskutert ovenfor, hvor stort antall samtidige brukerforbindelser og tilganger automatiseres for å generere simuleringen av effekten av et stort antall autentiske brukere som får tilgang til programvaresystemet ditt samtidig. Målet er å finne ut hvor mange brukere som kan få tilgang til systemet ditt samtidig uten at programvaresystemet ditt bryter. Hvis systemet ditt enkelt kan håndtere normal trafikk på 10.000 brukere, hva som vil skje hvis nettstedet eller programvaren din blir viralt og oppnår 1 million brukere? Vil dette uventet "LASTE" Bryt nettstedet eller systemet ditt? Lastetesting vil simulere dette, slik at du er komfortabel med den fremtidige økningen hos brukere fordi du vet at systemet ditt kan håndtere den økte belastningen.
Ytelsestesting
Folk kan bli helt frustrerte og fortvilte når programvaren ikke oppfyller sine ytelseskrav. Ytelsen betyr generelt hvor raskt viktige funksjoner kan fullføres. Jo mer komplekse og dynamiske funksjonene er tilgjengelige i et system, jo viktigere og ikke-åpenbart blir det å teste ytelsen, la oss ta et grunnleggende eksempel, Windows eller Linux-operativsystem. Et operativsystem er et svært komplekst programvareprodukt, og å gjøre ytelsestesting på systemet kan innebære hastighet og tidspunkt for funksjoner som oppstart, installere en app, søke etter en fil, kjøre beregninger på en GPU og/eller noen annen av av de millioner av handlingene som kan utføres. Det bør utvises forsiktighet når du velger ytelsestesttilfeller, for å sikre at de viktige og sannsynligvis funksjonsfeil ytelsesfunksjonene testes.
Skalerbarhetstesting
Testing på den bærbare datamaskinen er bra, men ikke veldig bra nok når du bygger et sosialt nettverk, et e -postsystem eller Supercomputer -programvare. Når programvaren din er ment å bli distribuert på 1000 servere, vil ikke alle funksjoner unisont, da testingen du gjør lokalt på ett system vil ikke avdekke feilene som oppstår når programvaren er distribuert "i skala" på hundretusenvis av forekomster. I virkeligheten vil testingen din sannsynligvis aldri kunne kjøre i full skala før du slipper til produksjon, fordi det ville være altfor dyrt og ikke praktisk å bygge et testsystem med 1000 servere som koster millioner av dollar. Derfor gjøres skalerbarhetstesting på flere servere, men vanligvis ikke det fulle antall produksjonsservere for å prøve å avdekke noen av manglene som kan bli funnet da systemene dine brukes på større infrastruktur.
Statisk analysetesting
Statisk analyse er tester som gjøres ved å inspisere programvarekoden uten å faktisk kjøre den. For å gjøre statisk analyse, vanligvis vil du bruke et verktøy, det er mange, ett kjent verktøy er dekning. Statisk analyse er enkel å kjøre før du slipper programvaren din og kan finne mange kvalitetsproblemer i koden din som kan løses før du slipper. Minnefeil, håndteringsfeil for datatype, nullpeker -dereferanser, uinitialiserte variabler og mange flere defekter kan bli funnet. Språk som C og C ++ drar stor nytte av statisk analyse fordi språkene gir stor frihet til programmerere i bytte mot stormakt, men dette kan også skape gode feil og feil som kan bli funnet ved hjelp av statisk analysetesting.
Feilinjeksjonstesting
Noen feilforhold er veldig vanskelige å simulere eller utløse, derfor kan programvaren utformes for å kunstig injisere et problem eller feil i systemet uten at defekten naturlig forekommer. Hensikten med feilinjeksjonstesting er å se hvordan programvaren håndterer disse uventede feilene. Reagerer det grasiøst på situasjonen, krasjer det, eller gir det uventede og uforutsigbare problematiske resultater? La oss for eksempel si at vi har et banksystem, og det er en modul for å overføre midler internt fra konto A til konto B. Imidlertid kalles denne overføringsoperasjonen bare etter at systemet allerede har bekreftet at disse kontoene eksisterte før de kalte overføringsoperasjonen. Selv om vi antar at begge kontoene eksisterer, har overføringsoperasjonen en feilsak der ett mål- eller kildekonto ikke eksisterer, og at den kan kaste en feil. For under normale omstendigheter får vi aldri denne feilen på grunn av forhåndstesting av innganger, så for å bekrefte systematferden når overføringen mislykkes på grunn av en ikke-eksisterende konto, injiserer vi en falsk feil i systemet som returnerer en ikke-eksisterende konto for en overføring og teste hvordan resten av systemet reagerer i så fall. Det er veldig viktig at feilinjeksjonskoden bare er tilgjengelig i testscenarier og ikke frigjøres til produksjon, der den kan skape ødeleggelser.
Memory overkjørstesting
Når du bruker språk som C eller C ++, har programmereren et stort ansvar for å direkte adressere minne, og dette kan forårsake dødelige feil i programvare hvis det blir gjort feil. For eksempel, hvis en peker er null og derferert, vil programvaren krasje. Hvis minnet blir tildelt et objekt og deretter blir en streng kopiert over objektets minneområde, kan referere til objektet forårsake et krasj eller til og med uspesifisert feil oppførsel. Derfor er det viktig å bruke et verktøy for å prøve å fange minnetilgangsfeil i programvare som bruker språk som C eller C ++, noe som kan ha disse potensielle problemene. Verktøy som kan gjøre denne typen testing inkluderer open source valgrind eller proprietære verktøy som PurifyPlus. Disse verktøyene kan lagre dagen når det ikke er klart hvorfor programvaren krasjer eller oppfører seg feil og peker direkte på stedet i koden som har feilen. Fantastisk, ikke sant?
Grensesakstesting
Det er lett å gjøre feil i koding når du er på det som kalles en grense. For eksempel sier en bankautomatisert tellermaskin at du kan trekke maksimalt $ 300. Så forestill deg at koderen skrev følgende kode naturlig når han bygde dette kravet:
Hvis (amt < 300)
startwithdrawl ()
ellers
Feil (“Du kan ta ut %s”, AMT);
Kan du oppdage feilen? Brukeren som prøver å trekke $ 300 vil motta en feil fordi den ikke er mindre enn $ 300. Dette er en feil. Derfor gjøres grensetesting naturlig. Kravsgrenser sørger deretter for at programvaren fungerer på begge sider av grensen og grensen.
Fuzz -testing
Høyhastighetsgenerering av innspill til programvare kan produsere så mange mulige inngangskombinasjoner, selv om disse inngangskombinasjonene er total tull og aldri vil bli levert av en ekte bruker. Denne typen Fuzz -testing kan finne feil og sikkerhetsproblemer som ikke er funnet på andre måter på grunn av det høye volumet av innganger og scenarier som er testet raskt uten manuell test case -generering.
Utforskende testing
Lukk øynene og visualiser hva ordet "utforske" betyr. Du observerer og sonderer et system for å finne ut hvordan det virkelig fungerer. Se for deg at du mottar en ny skrivebordsstol i postordre, og den har 28 deler i separate plastposer uten instruksjoner. Du må utforske din nye ankomst for å finne ut hvordan den fungerer og hvordan den er satt sammen. Med denne ånden kan du bli en utforskende tester. Du vil ikke ha en veldefinert testplan for testtilfeller. Du vil utforske og undersøke programvaren din på jakt etter ting som får deg til å si det fantastiske ordet: “Interessant!”. Når du lærer, undersøker du videre og finner måter å bryte programvaren som designerne aldri tenkte på, og deretter levere en rapport som beskriver mange dårlige forutsetninger, feil og risiko i programvaren. Lær mer om dette i boken som heter Explore It.
Penetrasjonstesting
I verden av programvaresikkerhet er penetrasjonstesting et av de viktigste testingsmidlene. Alle systemer, enten biologiske, fysiske eller programvare har grenser og grenser. Disse grensene er ment å tillate bare spesifikke meldinger, mennesker eller komponenter å gå inn i systemet. Mer konkret, la oss vurdere et nettbanksystem som bruker brukergodkjenning for å komme inn på nettstedet. Hvis nettstedet kan hackeres og legges inn i backend uten riktig autentisering, vil det være en penetrasjon, som må beskyttes mot. Målet med penetrasjonstesting er å bruke kjente og eksperimentelle teknikker for å omgå den normale sikkerhetsgrensen til et programvaresystem eller nettsted. Inntrengningstesting innebærer ofte å sjekke alle portene som lytter og prøver å gå inn i et system via en åpen port. Andre vanlige teknikker inkluderer SQL -injeksjon eller passordsprekker.
Regresjonstesting
Etter at du har arbeidsprogramvare som er distribuert i feltet, er det viktig å forhindre å introdusere feil i funksjonalitet som allerede fungerte. Hensikten med programvareutvikling er å øke muligheten til produktet ditt, introdusere feil eller føre til at gammel funksjonalitet slutter å fungere, noe som kalles en regresjon. Regresjon er en feil eller feil som ble introdusert da evnen tidligere fungerte som forventet. Ingenting kan ødelegge omdømmet til programvaren din eller merket raskere enn å introdusere regresjonsfeil i programvaren din og få ekte brukere til å finne disse feilene etter en utgivelse.
Regresjonstestingssaker og testplaner bør bygges rundt kjernefunksjonaliteten som må fortsette å jobbe for å sikre at brukerne har en god opplevelse med applikasjonen din. Alle kjernefunksjonene til programvaren din som brukerne forventer å fungere på en bestemt måte, bør ha en regresjonstest -sak som kan utføres for å forhindre at funksjonaliteten bryter på en ny utgivelse. Dette kan være alt fra 50 til 50 000 testsaker som dekker kjernefunksjonaliteten til programvaren eller applikasjonen din.
Testing av kildekode Bisection
En feil ble introdusert i programvaren, men det er ikke åpenbart hvilken versjon av utgivelsen som ble introdusert den nye feilen. Se for deg at det var 50 programvareforpliktelser fra den siste kjente tiden programvaren fungerte uten feilen, til nå da ..
Lokaliseringstesting
Se for deg en værprogram som viser det nåværende og anslåtte været på ditt sted, samt en beskrivelse av værforholdene. Den første delen av lokaliseringstesting er å sikre at riktig språk, alfabet og tegn vises riktig, avhengig av brukerens geolokasjon. Appen i Storbritannia skal vises på engelsk med latinske karakterer; Den samme appen i Kina skal vises i kinesiske tegn på kinesisk språk. Mer forseggjort lokaliseringstesting utført, det bredere spekteret av mennesker fra forskjellige geolokasjoner vil grensesnitt mot applikasjonen.
Tilgjengelighetstesting
Noen av innbyggerne i samfunnet vårt har funksjonshemninger, og kan derfor ha problemer med å bruke programvaren som opprettes, så tilgjengelighetstesting blir gjort for å sikre at populasjoner med funksjonshemminger fremdeles kan få tilgang til funksjonaliteten til systemet. For eksempel, hvis vi antar at 1% av befolkningen er fargeblind, og programvaregrensesnittet vårt forutsetter at brukere kan skille mellom rødt og grønt, men de fargeblinde individer kan ikke fortelle forskjellen. Derfor vil et godt programvare-grensesnitt ha flere signaler utover fargen for å indikere mening. Andre scenarier foruten fargeblindhetstesting vil også bli inkludert i programvaretilgjengelighetstesting, for eksempel full visuell blindhet, døvhet og mange andre scenarier. Et godt programvareprodukt skal være tilgjengelig med en maksimal prosentandel av potensielle brukere.
Oppgraderingstesting
Enkle apper på en telefon, operativsystemer som Ubuntu, Windows eller Linux Mint og programvare som kjører atomubåter trenger hyppige oppgraderinger. Prosessen med selve oppgraderingen kunne introdusere feil og mangler som ikke ville eksistere på en ny installasjon fordi miljøet var annerledes og prosessen med å introdusere den nye programvaren på toppen av den gamle kunne ha introdusert feil. La oss ta et enkelt eksempel, vi har en bærbar PC som kjører Ubuntu 18.04, og vi vil oppgradere til Ubuntu 20.04. Dette er en annen prosess med å installere operativsystemet enn å rengjøre harddisken direkte og installere Ubuntu 20.04. Derfor, etter at programvaren er installert eller noen av dens derivatfunksjoner, kan det hende at den ikke fungerer 100% som forventet eller det samme som når programvaren var nyinstallert. Så vi bør først vurdere å teste oppgraderingen selv under mange forskjellige tilfeller og scenarier for å sikre at oppgraderingen fungerer til fullføring. Og da må vi også vurdere å teste den faktiske oppgraderingen av systemet for å sikre at programvaren ble lagt ned og fungerer som forventet. Vi vil ikke gjenta alle testtilfeller av et nylistinstallert system, noe som vil være bortkastet tid, men vi vil tenke nøye med vår kunnskap om systemet om hva som kan bryte under en oppgradering og strategisk legge til testtilfeller for disse funksjonene.
Black Box & White Box Testing
Black Box and White Box er mindre spesifikke testmetodologier og flere av kategoriseringsstyper av testing. I hovedsak tester svart boks, som antar at testeren ikke vet noe om programvarenes indre arbeid og bygger en testplan og testtilfeller som bare ser på systemet utenfra for å bekrefte funksjonen. Testing av hvit boks gjøres av programvarearkitekter som forstår den interne virkningen av et programvaresystem og designer sakene med kunnskap om hva. Både testing av svart og hvitt boks vil sannsynligvis finne forskjellige typer defekter.
Blogger og artikler om programvaretesting
Programvaretesting er et dynamisk felt, og mange interessante publikasjoner og artikler som oppdaterer samfunnet om topp moderne tenker om programvaretesting. Vi kan alle dra nytte av denne kunnskapen. Her er et utvalg av interessante artikler fra forskjellige bloggkilder du kanskje vil følge:
- 7 tips som skal følges før testing uten krav; http: // www.Testingjournaler.com/
- 60 Beste automatiseringstestingsverktøy: The Ultimate List Guide; https: // testguild.com/
- Open Source Database Testing Tools; https: // www.softwaretestingmagazine.com/
- 100 prosent enhetstestdekning er ikke nok; https: // www.Stickyminds.com/
- Flaky tester på Google og hvordan vi demper dem; https: // testing.Googleblog.com/
- Hva er regresjonstesting? ; https: // test.io/blogg/
- 5 nøkkelprogramtestingstrinn hver ingeniør skal utføre; https: // techbeacon.com/
Produkter for programvaretesting
Flertallet av verdifulle testoppgaver kan automatiseres, så det skal ikke være noen overraskelse at bruk av verktøy og produkter for å utføre de mange oppgavene med programvarekvalitetssikring er en god idé. Nedenfor vil vi liste opp noen viktige og svært verdifulle programvareverktøy for programvaretesting som du kan utforske og se om de kan hjelpe.
Junit
For testing av Java-basert programvare gir Junit en omfattende testsuite for enhet og funksjonell testing av koden som er vennlig mot Java-miljøet.
Selen
For testing av webapplikasjoner gir Selenium muligheten til å automatisere interaksjoner med nettlesere, inkludert testing av nettleserkompatibilitet. Dette er en fremste testinfrastruktur for automatisering av netttesting.
Agurk
Et atferdsdrevet testrammeverk gjør at forretningsbrukere, produktledere og utviklere kan forklare den forventede funksjonaliteten i naturlig språk og deretter definere den atferden i testtilfeller. Dette gjør mer lesbare testtilfeller og tydelig kartlegging for forventet brukerfunksjonalitet.
Rense
Finn minnelekkasjer og minnekorrupsjoner på kjøretid ved å utføre programvaren din med Purify Plus Instrumentation innebygd som sporer din minnebruk og påpeker feil i koden din som ikke er enkle å finne uten instrumentering.
VALGRIND
Open source-verktøy som vil utføre programvaren din og lar deg samhandle med den mens du påpeker en feilrapport om kodingsfeil som minnelekkasjer og korrupsjoner. Ingen grunn til å kompilere eller legge til instrumentering i kompilasjonsprosessen, da Valgrind har intelligensen til å forstå din maskinkode dynamisk og injisere instrumentering sømløst for å finne kodingsfeil og hjelpe deg med å forbedre koden din.
Coverity
Statisk analyseverktøy som finner kodingsfeil i programvaren din før du selv samler og kjører koden din. Coverity kan finne sikkerhetssårbarheter, brudd på kodingskonvensjoner, samt feil og mangler som kompilatoren din ikke vil finne. Død kode finner du, uinitialiserte variabler og tusenvis av andre defekttyper. Det er viktig å rense koden din med statisk analyse før du slipper den til produksjon.
JMeter
Et rammeverk for åpen kildekode for ytelsestesting orientert til Java-baserte utviklere, derav j i navnet. Nettstedstesting er en av de viktigste brukssakene for JMeter i tillegg til ytelsestesting av databaser, postsystemer og mange andre serverbaserte applikasjoner.
Metasploit
For sikkerhets- og penetrasjonstesting er Metasploit en generisk ramme med tusenvis av funksjoner og evner. Bruk interaksjonskonsollen for å få tilgang til forhåndskodede utnyttelser og prøv å bekrefte sikkerheten til søknaden din.
Akademisk forskning på programvaretesting
- University of Sheffield Testing Research Group
- University of Kentucky programvareverifisering og valideringslaboratorium
- North Dakota State University Software Testing Research Group
- Systemtesting intelligent lab; Tsjekkisk teknisk universitet Praha
- NASA: Jon McBride Software Testing and Research (JSTAR)
- McMaster University; Programvarekvalitetsforskningslaboratorium
- Ontario Tech University; Programvarekvalitetsforskningslaboratorium
- University of Texas @ Dallas; Stqa
Konklusjon
Programvarens rolle i samfunnet fortsetter å vokse, og samtidig blir verdens programvare mer kompleks. For at verden skal fungere, må vi ha metoder og strategier for testing og validering av programvaren vi lager ved å utføre funksjonene den er ment å utføre. For hvert komplekse programvaresystem bør en teststrategi og testplan være på plass for å fortsette å validere funksjonaliteten til programvaren når de fortsetter å bli bedre og gi dens funksjon.