En komplett ikke-funksjonell testveiledning for nybegynnere

complete non functional testing guide

En komplett guide til ikke-funksjonell testing: Formål, typer, verktøy, testtilfeller med eksempler

Hva er ikke-funksjonell testing?

Ikke-funksjonell testing gjøres for å verifisere det ikke-funksjonelle kravet til applikasjonen som ytelse, brukervennlighet, etc.

Det verifiserer om oppførselen til systemet er i samsvar med kravet eller ikke. Den dekker alle aspektene som ikke er dekket av funksjonstesting . I vår daglige testing blir det lagt stor vekt på funksjonstesting og funksjonelle krav.

Kundene er også interessert i å oppfylle funksjonelle krav som er direkte relatert til funksjonaliteten til en applikasjon. Men i den faktiske fasen, dvs. når du er funksjonstestet, kommer programvaren ut på markedet og brukes av de virkelige sluttbrukerne, og det er sjanser for at den møter noen problemer knyttet til ytelsen.

Disse problemene er ikke relatert til funksjonaliteten til systemet, men de kan påvirke brukeropplevelsen på en negativ måte. Derfor er det viktig at programvaren eller applikasjonen også testes for ikke-funksjonelle krav for å unngå negativ kundeopplevelse.

Testing er stort sett klassifisert i to typer:

• Funksjonell testing
• Ikke-funksjonell testing

Hva du vil lære:

• Betydning
• Hensikt
• Eksempel
• Fordeler
• Hvordan fange opp ikke-funksjonelle krav?
  • # 1) Bruker / tekniske historier
  • # 2) Akseptkriterier
  • # 3) I gjenstander
• Forskjell i funksjonelle og ikke-funksjonelle krav
• Testes denne Black Box eller White Box?
• Ikke-funksjonell testsaker Sjekkliste
  • Sjekkliste for ytelsestesting
  • Sjekkliste for sikkerhetstesting
  • Sjekkliste for dokumentasjonstesting
• Tilnærmingsdokument
  • Testomfang
  • Test beregninger
  • Test verktøy
  • Viktige datoer og leveranser
• Ikke-funksjonelle testtyper
• Ikke-funksjonelle testverktøy
  • # 1) Usability Testing Test cases
  • # 2) Prestasjonstesting Testtilfeller
  • # 3) Sikkerhetstesting av testtilfeller
• Konklusjon
• Anbefalt lesing

Betydning

Denne testingen manglet på grunn av oppmerksomhet med tanke på at den ikke påvirker systemets funksjonalitet.

De ikke-funksjonelle kravene ble heller ikke gitt tilstrekkelig oppmerksomhet i de tidligere testsyklusene. Dette har imidlertid endret seg nå. Ikke-funksjonelle tester er nå viktigst ettersom de vurderer alle applikasjonsytelses- og sikkerhetsproblemer i disse dager.

Denne testingen har større innvirkning på applikasjoner når det gjelder ytelsen til applikasjonen under høy brukertrafikk. Denne testingen sikrer at applikasjonen din er stabil og er i stand til å håndtere belastning under ekstreme forhold.

Som selve navnet skildrer, konsentrerer denne testen seg om det ikke-funksjonelle aspektet ved applikasjonen. Så hva er de ikke-funksjonelle aspektene? Eller skal jeg si hvilke funksjoner som ikke er relatert til funksjonaliteten til applikasjonen?

Her er svarene på disse:

• Hvordan fungerer applikasjonen under normale omstendigheter?
• Hvordan oppfører applikasjonen seg når for mange brukere logger inn samtidig?
• Kan applikasjonen takle stress?
• Hvor sikker er applikasjonen?
• Kan applikasjonen komme seg etter en katastrofe?
• Kan applikasjonen oppføre seg på samme måte i et annet miljø eller operativsystem?
• Hvor enkelt er det å portere applikasjonen i et annet system?
• Er dokumentene / brukerhåndboken som følger med applikasjonen enkle å forstå?

Listen fortsetter. Men poenget her er at - er ikke disse funksjonene bidratt til kvaliteten på applikasjonen? Svaret er JA. Disse funksjonene er like viktige.

Tenk deg at et program oppfyller alle brukerens krav perfekt, men noen uautoriserte brukere går lett og sprekker dataene som er angitt av brukeren i applikasjonen, eller applikasjonen dør når mer enn 5BB av en hvilken som helst fil lastes opp. Så vil du si at applikasjonen er av god kvalitet? Åpenbart ikke riktig !!

Hensikt

Det eneste formålet med denne typen testing er å sikre at de ikke-funksjonelle aspektene ved applikasjonen blir testet og applikasjonen fungerer godt i sammenheng med det samme.

Hensikten er å dekke testing av alle egenskapene til applikasjonen som hjelper til med å gi en applikasjon som oppfyller forretningsforventningene.

Eksempel

Dette er en viktig testtype.

Funksjonstesting tester applikasjonens funksjonalitet og sikrer at den fungerer som forventet, men ikke-funksjonell testing sørger for at applikasjonen fungerer bra nok til å oppfylle forretningsforventningene.

For å forstå dens betydning, la oss ta et enkelt eksempel:

En applikasjon er utviklet og er fullstendig testet for funksjonalitet, men ikke-funksjonell testing utføres ikke på det samme.

I mellomtiden, når applikasjonen går live, kan det resultere i kritiske eller store problemer som når belastningen økes på applikasjonen, det blir for sakte og tar mye tid å åpne.

Svartiden kan øke, eller når belastningen økes til en viss grad, kan applikasjonen krasje. Dette viser hvor viktig det er å teste applikasjonens ikke-funksjonelle aspekter.

Fordeler

Nedenfor er noen av fordelene med en ikke-funksjonell test gitt:

• Den dekker testingen som ikke kan dekkes ved funksjonstesting.
• Det sikrer at applikasjonen kjører effektivt og er pålitelig nok.
• Det sikrer sikkerheten til applikasjonen.

Hvordan fange opp ikke-funksjonelle krav?

Mens vi utfører testing, er fokus hovedsakelig på funksjonstesting som tester produktets funksjonalitet. Men ikke-funksjonell testing er like viktig som funksjonstesting, og kravet til dette bør tas i betraktning fra begynnelsen av produktet.

Ikke-funksjonelle krav brukes til å utføre ikke-funksjonell testing. Disse kravene inkluderer ytelse som forventes fra applikasjonen eller programvaren som testes. Dette inkluderer i utgangspunktet den tiden programvaren tar for å betjene et bestemt system.

Ikke-funksjonelle krav fanger også oppførselen når et stort antall mennesker bruker programvaren samtidig. Mesteparten av tiden oppleves det at serverne er opptatt eller utilgjengelige på grunn av tung belastning (dvs. at flere bruker den samtidig). Å bestille jernbanebilletter på nettet kan være best eksempel av en slik situasjon.

Derfor vil dokumentasjon av det ikke-funksjonelle kravet riktig og utførelse av testene sikre høy tilfredshet med hensyn til brukervennlighet av potensielle kunder.

Selv om denne testingen ikke har en direkte forretningspåvirkning på systemets funksjonalitet, kan den øke brukeropplevelsen og brukervennligheten i høyere grad, noe som igjen vil ha større innvirkning på kvaliteten på programvaren.

Eksempel:

Tenk på det samme eksemplet på Facebook-påloggingssiden. I dette tilfellet er omfanget av ikke-funksjonell testing å notere tiden det tar for systemet å logge på Facebook etter å ha oppgitt gyldig legitimasjon.

Det kan også testes som når (la oss si 100) brukerne logger inn samtidig, hvor lang tid det tar å logge inn brukeren på Facebook.

Dette sikrer at systemet kan takle belastning og trafikk som igjen har en god brukeropplevelse.

På smidig, bør ikke-funksjonelle krav fanges ved hjelp av innganger.

Et ikke-funksjonelt krav bør fanges opp som:

• Bruker / tekniske historier
• I akseptkriterier
• I Artefakt

9

# 1) Bruker / tekniske historier

Et ikke-funksjonelt krav kan fanges opp ved hjelp av brukerhistorier eller tekniske historier. Å fange ikke-funksjonelle krav som en brukerhistorie er det samme som å fange opp andre krav. Den eneste forskjellen i brukeren og en teknisk historie er at brukerhistorien krever diskusjon og har synlighet.

# 2) Akseptkriterier

Akseptkriterier er poenget som er definert for å akseptere produktet av kunden, dvs. å få produktet akseptert til de definerte punktene, bør være i godkjent tilstand.

Et ikke-funksjonelt krav bør inkluderes i akseptkriteriene, men noen ganger er det ikke mulig å teste de ikke-funksjonelle kravene med hver historie, dvs. med hver iterasjon. Derfor bør kravene bare legges til eller testes med relevant iterasjon.

# 3) I gjenstander

Det bør utarbeides en egen gjenstand for de ikke-funksjonelle kravene. Dette vil igjen bidra til å få en bedre ide om hva som må testes og hvordan det kan gjøres i iterasjoner.

Forskjell i funksjonelle og ikke-funksjonelle krav

Det er flere forskjeller mellom funksjonelle og ikke-funksjonelle krav, og få av dem er angitt nedenfor:

Videre lesing => Forskjeller mellom funksjonell og ikke-funksjonell testing

Testes denne Black Box eller White Box?

Den ikke-funksjonelle testen kommer under en black box testing teknikk.

Denne teknikken er ikke bare begrenset til å teste funksjonalitetene, men kan også brukes til å teste de ikke-funksjonelle kravene, så vel som ytelse, brukervennlighet osv. Testteknikk for svart boks krever ikke kunnskap om det interne systemet, dvs. det krever ikke kunnskapen om kode til testeren.

Ikke-funksjonell testsaker Sjekkliste

En sjekkliste brukes for å sikre at ingen viktige aspekter blir igjen uten testing.

En sjekkliste brukes vanligvis når det ikke er tid for dokumentasjon og produktet må testes, eller når det er tidsbegrensning, kan en sjekkliste brukes for å sikre at alle viktige aspekter er dekket.

La oss se eneksempelav sjekkliste for testing, sikkerhet og dokumentasjon.

Sjekkliste for ytelsestesting

• Svartiden av applikasjonen skal verifiseres, dvs. hvor lang tid tar det å laste inn applikasjonen, alle innganger gitt til applikasjonen gir utdata på hvor lang tid, oppdaterer nettleseren osv.
• Gjennomstrømning bør verifiseres for antall transaksjoner som er gjennomført under en belastningstest.
• Miljø oppsett skal være det samme som det levende miljøet, ellers vil ikke resultatene være de samme.
• Prosesstid - Behandle aktiviteter som import og eksport av excel, alle beregninger i applikasjonen bør testes.
• Interoperabilitet skal verifiseres, dvs. at en programvare skal kunne samarbeide med den andre programvaren eller systemene.
• ETL tiden bør verifiseres, dvs. tiden det tar å trekke ut, transformere og laste dataene fra en database til en annen.
• Økende belastning på søknaden skal verifiseres.

Sjekkliste for sikkerhetstesting

• Godkjenning: Bare en autentisk bruker skal kunne logge på.
• Autorisert: Brukeren skal kunne logge på de modulene som han er autorisert for eller som brukeren har fått tilgang til.
• Passord: Passordkrav bør verifiseres, dvs. passord skal være i henhold til hvordan kravet definerer dvs. lengde, spesialtegn, tall osv.
• Pause: Hvis applikasjonen er inaktiv, bør den timeout i en spesifisert tid.
• Data backup: Sikkerhetskopiering av data skal tas til et bestemt tidspunkt og skal kopieres til et sikret sted.
• Interne lenker til webapplikasjonen skal ikke være tilgjengelig hvis den plasseres direkte i nettleseren.
• All kommunikasjon skal være kryptert.

Sjekkliste for dokumentasjonstesting

• Bruker- og systemdokumentasjon.
• Dokumenter for treningsformål.

Tilnærmingsdokument

Utvikle et spesifikt tilnærmingsdokument for Performance Test-trinnet ved å foredle den overordnede teststrategien. Denne testtilnærmingen veileder i planlegging og gjennomføring av alle ytelsestestoppgavene.

hva er en god mp3 downloader app for android

• Testomfang
• Test beregninger
• Test verktøy
• Viktige datoer og leveranser

Testomfang

Utfør ytelsestesting fra forskjellige perspektiver, for eksempel brukerytelse, forretningsprosesser, systemstabilitet, ressursforbruk og så videre. Typer ytelsestesting som skal utføres er diskutert i avsnittet ovenfor i artikkelen (som belastningstest, stresstest osv.)

Test beregninger

Testtilnærmingen forbedrer beregningene som måles og rapporteres under testing, for eksempel:

• Svartid (online)
• Batch-vindu (batch)
• Gjennomstrømning ( For eksempel , antall transaksjoner per tidsenhet)
• Utnyttelse ( For eksempel , andel ressurser som brukes)

Test verktøy

For det meste krever ytelsestesting bruk av passende verktøy:

• Lastgenereringsverktøy
• Ytelsesovervåkingsverktøy
• Verktøy for ytelsesanalyse
• Applikasjonsprofileringsverktøy
• Base-fôr verktøy.

Viktige datoer og leveranser

Dokumentet for tilnærming til ytelsestest skal beskrive følgende:

• Dato og tid for hver prestasjonstest.
• Typer av tester og funksjonalitetsblanding som skal inkluderes i hver Performance Test-gjennomføring.
• Fullføringsdatoer for ytelsestest.

Ikke-funksjonelle testtyper

Følgende bilde viser typene ikke-funksjonell testing:

Ytelsestesting:

Evaluerer den generelle ytelsen til systemet .

Nøkkelelementene er som følger:

• Validerer at systemet oppfyller forventet responstid.
• Evaluerer at de viktige elementene i applikasjonen oppfyller ønsket responstid.
• Det kan også gjennomføres som en del av integrasjonstesting og systemtesting.

Lastetesting:

Evaluerer om systemets ytelse er som forventet under normale og forventede forhold.

Viktige poeng er:

• Validerer at systemet fungerer som forventet når samtidige brukere får tilgang til applikasjonen og får forventet responstid.
• Denne testen gjentas med flere brukere for å få responstid og gjennomstrømning.
• På tidspunktet for testing bør databasen være realistisk.
• Testen skal utføres på en dedikert server som stimulerer det faktiske miljøet.

Stress Testing:

Evaluerer om systemets ytelse er som forventet når det er lite ressurs.

Viktige poeng er:

• Test på lite minne eller lite diskplass på klienter / servere som avslører feilene som ikke kan bli funnet under normale forhold.
• Flere brukere utfører de samme transaksjonene på de samme dataene.
• Flere klienter er koblet til serverne med forskjellige arbeidsbelastninger.
• Reduser tenketiden til 'null' for å stresse serverne til maksimalt stress.

Tenk tid: Akkurat som tidsintervallet mellom å skrive inn bruker og passord.

Volumtesting:

Evaluerer oppførselen til programvaren når et stort datamengde er involvert.

Viktige poeng er:

• Når programvaren er utsatt for store datamengder, sjekker du grensen der programvaren mislykkes.
• Maksimal databasestørrelse opprettes, og flere klienter spør databasen eller oppretter en større rapport.
• Eksempel - Hvis applikasjonen behandler databasen for å lage en rapport, vil en volumtest være å bruke et stort resultatsett og sjekke om rapporten er skrevet ut riktig.

Brukervennlighetstesting:

Evaluerer systemet for menneskelig bruk eller sjekker om det er egnet for bruk.

Viktige poeng er:

• Er produksjonen korrekt og meningsfull, og er den samme som forventet per virksomhet?
• Er feilene diagnostisert riktig?
• Er brukergrensesnittet riktig og i samsvar med standarden?
• Er applikasjonen enkel å bruke?

Testing av brukergrensesnitt:

Evaluerer GUI.

Viktige poeng er:

• GUI bør gi hjelp og verktøytips for å gjøre det enkelt å bruke.
• Konsekvent for utseendet?
• Data krysses riktig fra en side til en annen?
• GUI skal ikke irritere brukeren eller bli vanskelig å forstå.

Kompatibilitetstesting:

Evaluerer at applikasjonen er kompatibel med annen maskinvare / programvare med minimum og maksimal konfigurasjon.

Viktige poeng er:

• Test hver maskinvare med minimum og maksimal konfigurasjon.
• Test med forskjellige nettlesere.
  Testtilfeller er de samme som de ble utført under funksjonstesting.
• I tilfelle antall maskinvare og programvare er for mange, kan vi bruke OATS-teknikker for å komme til testsakene for å få maksimal dekning.

Recovery Testing:

Evaluerer at applikasjonen avsluttes elegant i tilfelle feil, og dataene blir gjenopprettet riktig fra maskinvare- og programvarefeil.

Testene er ikke begrenset til nedenstående punkter:

• Strømbrudd, til klienten mens du gjør CURD-aktiviteter.
• Ugyldige databasepekere og nøkler.
• Databaseprosessen avbrytes eller avsluttes for tidlig.
• Databasepekere, felt og nøkler er ødelagt manuelt og direkte i databasen.
• Koble fra kommunikasjonen fysisk, slå den av, skru ned rutere og nettverksservere.

Ustabilitetstesting:

Evaluerer og bekrefter om programvaren installeres og avinstalleres riktig.

hvordan åpne fil med java

Viktige poeng er:

• Validerer at systemkomponentene er riktig installert på den angitte maskinvaren.
• Validerer at navigasjonen på den nye maskinen oppdaterer eksisterende installasjon og eldre versjoner.
• Validerer at med utilstrekkelig diskplass er det ingen uakseptabel oppførsel.

Dokumentasjonstesting:

Evaluerer dokumentene og andre brukerhåndbøker.

Viktige punkter inkluderer:

• Validerer at de oppgitte dokumentene er tilgjengelige i produktet.
• Validerer alle brukerhåndbøkene, setter opp instruksjoner, leser meg filer, utgivelsesmerknader og online hjelp.

Failover-testing:

Failover-testing gjøres for å verifisere at i tilfelle systemfeil er systemet i stand til å håndtere ekstra ressurser som servere.

For å forhindre en slik situasjon spiller sikkerhetskopiering en stor rolle. Å lage et backup-system er hva prosessen handler om. Hvis sikkerhetskopien er tilgjengelig, hjelper det å få systemet tilbake.

Sikkerhetstesting:

Sikkerhetstesting gjøres for å sikre at applikasjonen ikke har smutthull som kan føre til tap av data eller trusler. Det er en av de viktigste aspektene ved ikke-funksjonell testing, og hvis det ikke utføres riktig, kan det føre til sikkerhetstrusler.

Det inkluderer testautentisering, autorisasjon, integritet og tilgjengelighet.

Skalerbarhetstesting:

Skalerbarhetstesting gjøres for å verifisere om applikasjonen er i stand til å håndtere økt trafikk, antall transaksjoner, datavolum osv. Systemet skal fungere som forventet når datamengden eller endringen i datastørrelsen gjøres.

Testing av samsvar:

Overholdelsestesting gjøres for å verifisere om de definerte standardene følges eller ikke. Revisjon gjøres for å verifisere det samme.

Til Eksempel , Revisjon gjøres for å verifisere prosessen med å lage testtilfeller / testplaner og plassere dem på den delte plasseringen med standardnavnet som gjøres eller ikke. I QC følges standardtestsakenavnet mens du navngir testtilfellene eller ikke. Dokumentasjonen er fullstendig og godkjent eller ikke.

Dette er noen få tips som er dekket under revisjon.

Utholdenhetstesting:

Utholdenhetstesting gjøres for å verifisere systemets atferd når en belastning økes til en viss grad over lang tid.

Det kalles også Soak testing & Capacity testing. Det hjelper å verifisere om det er minnelekkasjer i systemet. Utholdenhetstesting er en delmengde av belastningstesting.

Lokaliseringstesting:

Lokaliseringstesting er gjort for å verifisere applikasjonen på forskjellige språk, dvs. forskjellige steder. Søknaden bør verifiseres for en bestemt kultur eller lokalitet. Hovedfokuset er å teste innholdet, GUI for applikasjonen.

Internasjonaliseringstesting:

Internasjonaliseringstesting er også kjent som i18n-testing.

I18n representerer I – atten bokstaver- N. Det gjøres for å verifisere om applikasjonen fungerer som forventet i alle språkinnstillingene. Den bekrefter at funksjonalitet eller applikasjoner i seg selv ikke brytes, dvs. at applikasjonen skal være i stand til å håndtere alle internasjonale innstillinger.

Det bekrefter også at applikasjonen blir installert uten problemer.

Pålitelighetstesting:

Pålitelighetstesting gjøres for å verifisere om applikasjonen er pålitelig og testes i en bestemt periode i det definerte miljøet. En applikasjon skal gi samme resultat som forventet hver gang, bare da kan den betraktes som pålitelig.

Portabilitetstesting:

Portabilitetstesting gjøres for å verifisere om en programvare / applikasjon er installert på et annet system eller på en annen plattform, skal den kunne kjøre som forventet, dvs. ingen funksjonalitet skal påvirkes på grunn av en endring i miljøet.

Mens du tester, er det også nødvendig å teste endringen med maskinvarekonfigurasjonen, slik som harddiskplass, prosessor, og også med forskjellige operativsystemer for å sikre at applikasjonens riktige oppførsel og forventede funksjonalitet er intakt.

Baseline Testing:

Baseline testing er også kjent som referansetesting da det skaper en base for enhver ny applikasjon som skal testes.

For eksempel: I den første iterasjonen var responstiden for en applikasjon 3 sekunder. Nå er dette satt som en referanse for neste iterasjon, og i neste iterasjon endres responstiden til 2 sekunder. Det er i utgangspunktet et valideringsdokument som brukes som en base for fremtidige referanser.

Effektivitetstesting:

Effektivitetstesting gjøres for å verifisere om applikasjonen fungerer effektivt og antall ressurser som kreves, verktøy som kreves, kompleksitet, kundekrav, miljø som kreves, tid, hva slags prosjekt det er osv.

Dette er noen av pekepinnene som kan bidra til å definere hvor effektivt et program vil fungere hvis alle de vurderte parametrene fungerer som forventet.

Testing av katastrofegjenoppretting:

Denne testingen er gjort for å verifisere suksessgraden for gjenoppretting av et program eller et system hvis det oppstår en kritisk feil, og om systemet er i stand til å gjenopprette dataene og applikasjonen, eller systemet kan takle det lett for å returnere slik det fungerte tidligere, dvs. fra den operasjonelle fronten.

Vedlikeholdstesting:

Når applikasjonen / produktet er aktivt, er det sjanser for at et problem kommer opp i live-miljøet, ellers vil kunden ønske en forbedring av applikasjonen som allerede er live.

I dette tilfellet er vedlikeholdstestteam tilgjengelig for å teste ovennevnte scenarier. Når applikasjonen er aktiv, trenger den fortsatt vedlikehold som vedlikeholdstestteamet jobber med.

Ikke-funksjonelle testverktøy

Det er flere verktøy tilgjengelig i markedet for Performance (Load & Stress) testing.

Få av dem er oppført nedenfor:

• JMeter
• Loadster
• Loadrunner
• Loadstorm
• Neoload
• Prognose
• Lastingen er fullført
• Webserver Stress Tool
• WebLoad Professional
• Loadtracer
• vPerformer

Er ikke-funksjonell testing alltid utført uten dokumentasjon og testtilfeller? Hvorfor?

“Vi blir alltid lært hvordan vi skal skrive funksjonelle testtilfeller. Hvorfor det? Utføres ‘ikke-funksjonell testing’ uten dokumentasjon (med andre ord på ad hoc-basis) eller er det en egen prosess som er mye vanskeligere å forstå? Hvordan skrives testsaker for forskjellige typer tester som skjer i en applikasjon? ”

Dette er et av de mest originale, særegne og out-of-the-box spørsmålene jeg har blitt spurt i nyere tid. La oss finne svaret.

Hvorfor får vi aldri se og øve oss på å skrive ikke-funksjonelle testsaker?

La oss starte med det vi vet, og som alltid et praktisk scenario.

Eksempel: Følgende er trinnene som skal utføres på en online bankapplikasjon for å utføre en overføring. La oss bruke det som vår referansetest.

1. Logg inn på siden.
2. Velg bankkontoen.
3. Velg betalingsmottaker (denne betalingsmottakeren kan tilhøre samme bank eller en annen - dette avhenger av datavalget ditt for å utføre dette trinnet. I alle fall velger du en. Vi kommer også til å anta at betalingsmottakeren allerede er lagt til.) .
4. Angi beløpet som skal overføres (positiv verdi, innenfor grensen, riktig format osv.).
5. Klikk på Overfør og sjekk om bekreftelse er mottatt, kontosaldoen er oppdatert og alt det der.

Dette er funksjonstestsaken, ikke sant?

La oss si at vi presterer på den samme applikasjonen, på samme overføringsside Testing av ytelse, sikkerhet og brukervennlighet . Dette er ikke-funksjonelle typer, ikke sant?

Hvordan skulle vi skrive testsakene?

# 1) Usability Testing Test cases

Brukervennlighetstesting er en sjanger av programvaretesting som omhandler brukeropplevelse. Dette er noen av spørsmålene vi prøver å svare på.

• Hvor enkelt er applikasjonen å bruke?
• Hvor tilfredsstillende er opplevelsen av å bruke systemet?
• Hvis ikke så kjent med en gang, hvor lett er det å lære?

Mer informasjon om det er her: Veiledning for brukervennlighetstesting

Hvordan vil en bruker bestemme svarene på spørsmålene ovenfor i sammenheng med brukervennlighetstesting?

Brukeren vil utføre nøyaktig de samme trinnene som i den funksjonelle testsaken. Har jeg rett?

# 2) Prestasjonstesting Testtilfeller

Det er flere varianter av ytelsestesting, men i sin kjerne brukes den til å få statistikk om systemet, dets ressursutnyttelse, responstid, nettverksforbruk, etc. på forskjellige belastningspunkter.

Sjekk ut vår Tester for ytelsestesting å vite mer om det.

Nå, hvis jeg skulle teste utførelsen av overføringenes transaksjon, ville jeg ha 10, 20, 30, 100 ... 1000 ... osv. Brukere som utfører overføringsoperasjonen samtidig eller trinnvis, avhengig av hva jeg vil målrette og samle inn data om.

Hvilke trinn vil hver bruker utføre for å kunne bruke overføringen mens ytelsestesten pågår?

De samme nøyaktige trinnene som funksjonstesten, ikke sant?

# 3) Sikkerhetstesting av testtilfeller

Security Testing er en gren av QA som hjelper til med å gjøre programvaresystemene hacktette. Den identifiserer sårbarheter (potensielle problemområder i programvaresystemet), utnytter dem gjennom penetrasjon eller testingsteknikk med hvite luer, og når løkkehull blir funnet, blir de jobbet med.

Når vil jeg sjekke om overføringene er hack-sikre og er rettet riktig til de tiltenkte mottakerne, og at det ikke er noen svarte flekker i hele prosessen? Jeg vil utføre overføringen mens overvåkingsprosessen for sikkerhetslekkasjer fortsetter parallelt.

Derfor utfører jeg faktisk nøyaktig de samme trinnene som jeg normalt ville gjort i tilfelle en funksjonell testtilfelle.

Jeg antar at vi har nok til å fastslå at trinnene i alle situasjoner er de samme. Metoden og intensjonen bak prosessen er det som er annerledes.

La oss ta et sammenlignende blikk:

Det som er interessant å merke seg er at uansett hvilken form for testing vi vil gjøre, er alle trinnene de samme .

Den virkelige forskjellen er at:

1. Hvem utfører disse trinnene?
2. Hva er intensjonen, eller med andre ord hva prøver jeg å oppnå via denne testen?
3. Verktøyene og teknikkene som brukes.

Når vi kommer tilbake til spørsmålet vårt, hvorfor lærer vi aldri å skrive ikke-funksjonelle testsaker med alle de detaljerte trinnene som ligger der?

Det er fordi ,I sin kjerne er testtrinnene for en variant av testtyper på en bestemt funksjon de samme, funksjonelle eller ikke. Det er intensjonen som gjør en forskjell og kanskje metoden.

Konklusjon

Før du utfører ikke-funksjonell testing, er det viktig å planlegge teststrategien riktig for å sikre riktig testing. Det er forskjellige verktøy som er tilgjengelige i markedet for å utføre denne typen tester som Load Runner, RPT, etc.

Denne testingen spiller en viktig rolle for suksessen til en applikasjon og for å bygge opp et godt kundeforhold, og det bør derfor ikke overses. Dette er en av de viktigste delene av programvaretesting og testing kan ikke betraktes som komplett uten dette.

Vi kan inkludere ikke-funksjonelle testdetaljer i testplanen eller kan lage en egen strategi for den. I begge tilfeller er målet å ha riktig dekning av ikke-funksjonelle aspekter ved programvaren.

Vi håper at denne prosessen med å gå dypt inn i dette emnet har vært like morsom for deg som den har blitt presentert for dere alle. Vi vil gjerne høre din tilbakemelding og tanker om dette emnet.

Hvordan håndterer du ikke-funksjonell testing i teamene dine? Og som alltid, gi oss beskjed hvis du er enig eller uenig eller har noe å legge til det vi har på gang her.

Anbefalt lesing

• Funksjonstesting mot ikke-funksjonell testing
• Alpha Testing og Beta Testing (En komplett guide)
• Veiledning for testing av webapplikasjoner
• Komplett funksjonell testguide med typer og eksempel
• Build Verification Testing (BVT Testing) Komplett guide
• Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
• Nybegynnerveiledning for testing av webapplikasjon
• Lastetesting komplett guide for nybegynnere