En komplet ikke-funktionel testguide til begyndere

complete non functional testing guide

En komplet guide til ikke-funktionel test: Formål, typer, værktøj, testtilfælde med eksempler

Hvad er ikke-funktionel test?

Ikke-funktionel test udføres for at kontrollere det ikke-funktionelle krav til applikationen som ydeevne, brugervenlighed osv.

Det verificerer, om systemets opførsel er i overensstemmelse med kravet eller ej. Den dækker alle de aspekter, der ikke er dækket af funktionstest . I vores daglige test lægges der stor vægt på funktionstestning og funktionelle krav.

Kunderne er også interesserede i at opfylde de funktionelle krav, der er direkte relateret til applikationens funktionalitet. Men i den faktiske fase, dvs. når du er funktionelt testet, kommer softwaren på markedet og bruges af de rigtige slutbrugere, og der er chancer for, at den står over for nogle problemer relateret til ydeevnen.

Disse problemer er ikke relateret til systemets funktionalitet, men de kan påvirke brugeroplevelsen negativt. Derfor er det vigtigt, at softwaren eller applikationen også testes for ikke-funktionelle krav for at undgå negativ kundeoplevelse.

Test er stort set klassificeret i to typer:

• Funktionel testning
• Ikke-funktionel test

Hvad du lærer:

• Betydning
• Formål
• Eksempel
• Fordele
• Hvordan kan man opfange ikke-funktionelle krav?
  • # 1) Bruger / tekniske historier
  • # 2) Acceptkriterier
  • # 3) I artefakter
• Forskel i funktionelle og ikke-funktionelle krav
• Testes denne Black Box eller White Box?
• Ikke-funktionel testtilfælde-tjekliste
  • Tjekliste til ydelsestest
  • Tjekliste til sikkerhedstest
  • Tjekliste til dokumentationstest
• Tilgangsdokument
  • Testomfang
  • Test målinger
  • Testværktøjer
  • Nøgledatoer og leverancer
• Ikke-funktionelle testtyper
• Ikke-funktionelle testværktøjer
  • # 1) Usability Testing Test cases
  • # 2) Ydeevne Test Test tilfælde
  • # 3) Sikkerhedstestning af testsager
• Konklusion
• Anbefalet læsning

Betydning

Denne test manglede behørig opmærksomhed i betragtning af at den ikke påvirker systemets funktionalitet.

De ikke-funktionelle krav blev heller ikke givet tilstrækkelig opmærksomhed i de tidligere testcyklusser. Dette er dog ændret nu. Ikke-funktionelle tests er nu vigtigst, da de overvejer al applikationsydelse og sikkerhedsproblemer i disse dage.

Denne testning har større indflydelse på applikationer, når det kommer til applikationens ydeevne under høj brugertrafik. Denne test sikrer, at din applikation er stabil og er i stand til at håndtere belastning under ekstreme forhold.

Som selve navnet skildrer, koncentrerer denne test sig om det ikke-funktionelle aspekt af applikationen. Så hvad er de ikke-funktionelle aspekter? Eller skal jeg sige, hvad er de funktioner, der ikke er relateret til applikationens funktionalitet?

Her er svarene på disse:

• Hvordan fungerer applikationen under normale omstændigheder?
• Hvordan opfører applikationen sig, når for mange brugere logger ind samtidigt?
• Kan applikationen håndtere stress?
• Hvor sikker er applikationen?
• Kan applikationen komme sig efter en katastrofe?
• Kan applikationen opføre sig på samme måde i et andet miljø eller operativsystem?
• Hvor let er det at porte applikationen i et andet system?
• Er dokumenterne / brugervejledningen, der følger med applikationen, let at forstå?

Listen fortsætter. Men pointen her er, at - bidrages ikke disse funktioner til applikationens kvalitet? Svaret er JA. Disse funktioner er lige så vigtige.

Forestil dig, at en applikation opfylder alle brugernes krav perfekt, men en eller anden uautoriseret bruger går let og knækker de data, der er indtastet af brugeren i applikationen, eller applikationen dør, når mere end 5BB af en fil uploades. Så vil du sige, at applikationen er af god kvalitet? Naturligvis ikke rigtigt !!

Formål

Det eneste formål med denne type test er at sikre, at applikationens ikke-funktionelle aspekter testes, og applikationen fungerer godt i sammenhæng med det samme.

Formålet er at dække test af alle karakteristika ved applikationen, som hjælper med at levere en applikation, der opfylder forretningsforventningen.

Eksempel

Dette er en vigtig testtype.

Funktionel test tester applikationens funktionalitet og sikrer, at den fungerer som forventet, men den ikke-funktionelle test sikrer, at applikationen fungerer godt nok til at imødekomme forretningsforventningerne.

Lad os tage et simpelt eksempel for at forstå dets betydning:

En applikation er udviklet og testes fuldstændigt for funktionalitet, men ikke-funktionel test udføres ikke på den samme.

I mellemtiden, når applikationen går live, kan det resultere i kritiske eller større problemer, som når belastningen øges på applikationen, den bliver for langsom og tager meget tid at åbne.

Svartiden kan øges, eller når belastningen øges til en vis grad, kan applikationen gå ned. Dette viser, hvor vigtigt det er at teste en applikations ikke-funktionelle aspekter.

Fordele

Nedenfor gives nogle af fordelene ved en ikke-funktionel test:

• Den dækker testen, som ikke kan dækkes af funktionel test.
• Det sikrer, at applikationen kører effektivt og er pålidelig nok.
• Det sikrer applikationens sikkerhed.

Hvordan kan man opfange ikke-funktionelle krav?

Mens vi udfører test, er fokus primært på funktionstest, der tester produktets funktionalitet. Men ikke-funktionel test er lige så vigtig som funktionel test, og dens krav skal tages i betragtning lige fra produktets start.

Ikke-funktionelle krav bruges til at udføre ikke-funktionel test. Disse krav inkluderer den ydelsesoutput, der forventes fra applikationen eller softwaren, der testes. Dette inkluderer dybest set den tid, det tager af softwaren at betjene et bestemt system.

Ikke-funktionelle krav fanger også adfærden, når et stort antal mennesker bruger softwaren på samme tid. Det meste af tiden opleves det, at serverne er travle eller utilgængelige på grund af tung belastning (dvs. flere mennesker bruger den på samme tid). Det kan være bedst at bestille online jernbanebilletter eksempel af en sådan situation.

Dokumentation af det ikke-funktionelle krav korrekt og udførelse af test korrekt vil derfor sikre høj tilfredshed med hensyn til anvendelighed af de potentielle kunder.

Selvom denne test ikke har en direkte forretningspåvirkning på systemets funktionalitet, kan den øge brugeroplevelsen og brugervenligheden i højere grad, hvilket igen vil have større indflydelse på softwarekvaliteten.

Eksempel:

Overvej det samme eksempel på Facebook-login-siden. I dette tilfælde er omfanget af ikke-funktionel test at notere den tid, systemet kræver for at logge ind på Facebook efter indtastning af gyldige legitimationsoplysninger.

Det kan også testes som hvornår (lad os sige 100) brugerne logger ind på samme tid, hvor lang tid det tager at logge ind brugeren på Facebook.

Dette sikrer, at systemet kan håndtere belastning og trafik, hvilket igen har en god brugeroplevelse.

I agile skal det ikke-funktionelle krav fanges ved hjælp af input.

Et ikke-funktionelt krav skal fanges som:

• Bruger / tekniske historier
• I acceptkriterier
• I artefakt

9

# 1) Bruger / tekniske historier

Et ikke-funktionelt krav kan fanges ved hjælp af brugerhistorier eller tekniske historier. Optagelse af ikke-funktionelle krav som en brugerhistorie er den samme som for at indfange ethvert andet krav. Den eneste forskel i brugeren og en teknisk historie er, at brugerhistorien kræver diskussion og har synlighed.

# 2) Acceptkriterier

Godkendelseskriterier er det punkt, der er defineret til at acceptere produktet af kunden, dvs. at få produktet accepteret til de definerede punkter skal være i godkendt tilstand.

Et ikke-funktionelt krav skal inkluderes i acceptkriterierne, men nogle gange er det ikke muligt at teste de ikke-funktionelle krav med hver historie, dvs. med hver iteration. Derfor skal kravene kun tilføjes eller testes med den relevante iteration.

# 3) I artefakter

En separat artefakt skal udarbejdes for de ikke-funktionelle krav, hvilket igen vil hjælpe med at få en bedre idé om, hvad der skal testes, og hvordan det kan gøres i iterationer.

Forskel i funktionelle og ikke-funktionelle krav

Der er flere forskelle mellem de funktionelle og ikke-funktionelle krav, og få af dem er angivet nedenfor:

Yderligere læsning => Forskelle mellem funktionel og ikke-funktionel test

Testes denne Black Box eller White Box?

Den ikke-funktionelle test kommer under en test af sort boks teknik.

Denne teknik er ikke begrænset til kun at teste funktionaliteterne, men kan også bruges til at teste de ikke-funktionelle krav såvel som ydeevne, brugervenlighed osv. Black box testteknik kræver ikke noget kendskab til det interne system, dvs. det kræver ikke kendskabet til kode til testeren.

Ikke-funktionel testtilfælde-tjekliste

En tjekliste bruges til at sikre, at intet vigtigt aspekt er tilbage uden test.

En tjekliste bruges normalt, når der ikke er tid til dokumentation, og produktet skal testes, eller når der er en tidsbegrænsning, kan en tjekliste bruges til at sikre, at alle de vigtige aspekter er blevet dækket.

Lad os se eneksempelaf tjekliste til test, ydeevne, sikkerhed og dokumentation.

Tjekliste til ydelsestest

• Svartiden af applikationen skal verificeres, dvs. hvor lang tid tager det at indlæse applikationen, ethvert input, der gives til applikationen, giver output i hvor lang tid, opdatering af browseren osv.
• Gennemstrømning skal verificeres for antallet af transaktioner, der er gennemført under en belastningstest.
• Miljø opsætningen skal være den samme som det levende miljø, ellers ville resultaterne ikke være de samme.
• Process tid - Behandle aktiviteter som import og eksport af excel, alle beregninger i applikationen skal testes.
• Interoperabilitet skal verificeres, dvs. en software skal kunne interagere med den anden software eller systemer.
• ETL tiden skal verificeres, dvs. den tid, det tager at udtrække, transformere og indlæse data fra en database til en anden.
• Stigende belastning på ansøgningen skal verificeres.

Tjekliste til sikkerhedstest

• Godkendelse: Kun en autentisk bruger skal kunne logge ind.
• Autoriseret: Brugeren skal kun kunne logge ind på de moduler, som han er autoriseret til, eller som brugeren har fået adgang til.
• Adgangskode: Adgangskravskrav skal verificeres, dvs. adgangskode skal være i overensstemmelse med, hvordan kravet definerer, dvs. længde, specialtegn, tal osv.
• Tiden er gået: Hvis applikationen er inaktiv, skal den timeout inden for et bestemt tidspunkt.
• Sikkerhedskopiering af data: Databackup skal tages på et bestemt tidspunkt og skal kopieres til et sikkert sted.
• Interne links til webapplikationen skal ikke være tilgængelig, hvis den placeres direkte i browseren.
• Al kommunikation skal krypteres.

Tjekliste til dokumentationstest

• Bruger- og systemdokumentation.
• Dokumenter til uddannelsesformål.

Tilgangsdokument

Udvikl et specifikt tilgangsdokument til Performance Test-scenen ved at forfine den overordnede teststrategi. Denne testtilgang guider i planlægning og udførelse af alle Performance Test-opgaver.

youtube til mp3 konverter høj kvalitet gratis download

• Testomfang
• Test målinger
• Testværktøjer
• Nøgledatoer og leverancer

Testomfang

Udfør ydelsestestning fra forskellige perspektiver, såsom brugerens ydeevne, forretningsprocesser, systemstabilitet, ressourceforbrug og så videre. Typer af ydelsestest, der skal udføres, diskuteres i ovenstående afsnit af artiklen (som belastningstest, stresstest osv.)

Test målinger

Testmetoden forfiner de målinger, der skal måles og rapporteres under test, såsom:

• Svartid (online)
• Batch-vindue (batch)
• Gennemstrømning ( For eksempel , antallet af transaktioner pr. tidsenhed)
• Udnyttelse ( For eksempel , procentdelen af ​​anvendte ressourcer)

Testværktøjer

For det meste kræver ydelsestest brug af passende værktøjer:

• Load generation værktøjer
• Værktøjer til ydeevneovervågning
• Værktøjer til præstationsanalyse
• Applikationsprofileringsværktøjer
• Basisforingsværktøjer.

Nøgledatoer og leverancer

Dokumentet til præstationsprøvetilgang skal beskrive følgende:

• Dato og klokkeslæt for hver præstationstest.
• Typer af test og funktionalitetsblanding, der skal medtages i hver Performance Test-udførelse.
• Afslutningsdatoer for præstationstest.

Ikke-funktionelle testtyper

Følgende billede viser typerne af ikke-funktionel test:

Ydeevne test:

Evaluerer systemets samlede ydeevne .

Nøgleelementerne er som følger:

• Validerer, at systemet lever op til den forventede svartid.
• Evaluerer, at de væsentlige elementer i applikationen lever op til den ønskede responstid.
• Det kan også udføres som en del af integrationstest og systemtest.

Belastningstest:

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

Nøglepunkter er:

• Validerer, at systemet fungerer som forventet, når samtidige brugere får adgang til applikationen og får den forventede svartid.
• Denne test gentages med flere brugere for at få svartiden og kapaciteten.
• På testtidspunktet skal databasen være realistisk.
• Testen skal udføres på en dedikeret server, der stimulerer det faktiske miljø.

Stresstest:

Evaluerer, om systemets ydeevne er som forventet, når den har få ressourcer.

Nøglepunkter er:

• Test på lav hukommelse eller lav diskplads på klienter / servere, der afslører de mangler, som ikke kan findes under normale forhold.
• Flere brugere udfører de samme transaktioner på de samme data.
• Flere klienter er forbundet til serverne med forskellige arbejdsbelastninger.
• Reducer tænketiden til 'Nul' for at stresse serverne til deres maksimale stress.

Tænk tid: Ligesom tidsintervallet mellem at skrive din bruger og adgangskode.

Volumen test:

Evaluerer softwarens opførsel, når en stor mængde data er involveret.

Nøglepunkter er:

• Når softwaren er underlagt store mængder data, kontrolleres grænsen, hvor softwaren mislykkes.
• Maksimal databasestørrelse oprettes, og flere klienter spørger databasen eller opretter en større rapport.
• Eksempel - Hvis applikationen behandler databasen for at oprette en rapport, ville en volumintest være at bruge et stort resultatsæt og kontrollere, om rapporten er udskrevet korrekt.

Brugervenlighedstest:

Evaluerer systemet til human brug eller kontrollerer, om det er egnet til brug.

Nøglepunkter er:

• Er output korrekt og meningsfuldt, og er det det samme som forventet pr. Virksomhed?
• Er fejlene diagnosticeret korrekt?
• Er GUI korrekt og i overensstemmelse med standarden?
• Er applikationen nem at bruge?

Test af brugergrænseflade:

Evaluerer GUI.

Nøglepunkter er:

• GUI skal give hjælp og værktøjstip for at gøre det let at bruge.
• Konsekvent for sit udseende?
• Data krydses korrekt fra en side til en anden?
• GUI bør ikke irritere brugeren eller blive vanskelig at forstå.

Kompatibilitetstest:

Evaluerer, at applikationen er kompatibel med anden hardware / software med minimal og maksimal konfiguration.

Nøglepunkter er:

• Test hver hardware med minimum og maksimum konfiguration.
• Test med forskellige browsere.
  Testtilfælde er de samme som dem, der blev udført under funktionstestning.
• Hvis antallet af hardware og software er for mange, kan vi bruge OATS-teknikker til at nå frem til testsagerne for at få maksimal dækning.

Restitutionstest:

Evaluerer, at applikationen slutter yndefuldt i tilfælde af fejl, og dataene gendannes korrekt fra hardware- og softwarefejl.

Testene er ikke begrænset til nedenstående punkter:

• Strømsvigt til klienten, mens han laver CURD-aktiviteter.
• Ugyldige databasemarkører og nøgler.
• Databaseprocessen afbrydes eller afsluttes for tidligt.
• Databasemarkører, felter og nøgler er beskadiget manuelt og direkte i databasen.
• Frakobl kommunikationen fysisk, sluk for strømmen, slå routere og netværksservere ned.

Ustabilitetstest:

Evaluerer og bekræfter, om softwaren installeres og afinstalleres korrekt.

hvordan man åbner torrentede filer på Windows 10

Nøglepunkter er:

• Validerer, at systemkomponenterne er installeret korrekt på den angivne hardware.
• Validerer, at navigationen på den nye maskine opdaterer den eksisterende installation og ældre versioner.
• Validerer, at der med utilstrækkelig diskplads ikke er nogen uacceptabel adfærd.

Dokumentationstest:

Evaluerer dokumenterne og andre brugervejledninger.

Nøglepunkter inkluderer:

• Validerer, at de angivne dokumenter er tilgængelige i produktet.
• Validerer alle brugervejledninger, opsæt instruktioner, læs mig filer, frigivelsesnotater og online hjælp.

Failover-test:

Failover-test udføres for at verificere, at i tilfælde af systemfejl er systemet i stand til at håndtere ekstra ressourcer som servere.

For at forhindre en sådan situation spiller backup-test en stor rolle. Oprettelse af et backup-system handler om processen. Hvis sikkerhedskopien er tilgængelig, hjælper det med at få systemet tilbage.

Sikkerhedstest:

Sikkerhedstest gøres for at sikre, at applikationen ikke har smuthuller, der kan føre til tab af data eller trusler. Det er et af de vigtige aspekter ved ikke-funktionel test, og hvis det ikke udføres korrekt, kan det føre til sikkerhedstrusler.

Det inkluderer testgodkendelse, autorisation, integritet og tilgængelighed.

Test af skalerbarhed:

Test af skalerbarhed udføres for at kontrollere, om applikationen er i stand til at håndtere øget trafik, antal transaktioner, datamængde osv. Systemet skal fungere som forventet, når datamængden eller ændring i datastørrelse er færdig.

Test af overholdelse:

Overensstemmelsestest udføres for at kontrollere, om de definerede standarder følges eller ej. Der foretages revisioner for at kontrollere det samme.

Til Eksempel , Der foretages revisioner for at verificere processen med at oprette testsager / testplaner og placere dem på den delte placering med det standardnavn, der udføres eller ej. I QC følges standardnavnsnavnet eller ej under navngivning af testsagerne. Dokumentationen er komplet og godkendt eller ej.

Dette er de få punkter, der er dækket under revisionen.

Udholdenhedstest:

Udholdenhedstest gøres for at verificere systemets adfærd, når en belastning øges til en grad i lang tid.

Det kaldes også som Soak-test og kapacitetstest. Det hjælper med at kontrollere, om der er hukommelseslækager i systemet. Udholdenhedstest er en delmængde af belastningstest.

Lokaliseringstest:

Lokaliseringstest gøres for at verificere applikationen på forskellige sprog, dvs. forskellige lokaliteter. Ansøgningen skal verificeres for en bestemt kultur eller lokalitet. Hovedfokus er at teste applikationens indhold, GUI.

Internationaliseringstest:

Internationaliseringstest er også kendt som i18n-test.

I18n repræsenterer I – atten bogstaver- N. Det gøres for at kontrollere, om applikationen fungerer som forventet i alle sprogindstillinger. Det bekræfter, at enhver funktionalitet eller applikation i sig selv ikke går i stykker, dvs. applikationen skal være i stand til at håndtere alle de internationale indstillinger.

Det verificerer også, at applikationen bliver installeret uden problemer.

Pålidelighedstest:

Pålidelighedstest udføres for at kontrollere, om applikationen er pålidelig og testes i en bestemt tidsperiode i det definerede miljø. En applikation skal give den samme output som forventet hver gang, kun da kan den betragtes som pålidelig.

Portabilitetstest:

Portabilitetstest udføres for at kontrollere, om en software / applikation er installeret på et andet system eller på en anden platform, skal den kunne køre som forventet, dvs. ingen funktionalitet skal påvirkes på grund af en ændring i miljøet.

Under test er det også nødvendigt at teste ændringen med hardwarekonfigurationen, såsom harddiskplads, processor og også med forskellige operativsystemer for at sikre, at applikationens korrekte opførsel og forventede funktionalitet er intakte.

Baseline test:

Baseline test er også kendt som benchmark test da det skaber en base for enhver ny applikation, der skal testes.

For eksempel: I den første iteration var svartiden for en applikation 3 sekunder. Nu er dette sat som et benchmark for den næste iteration, og i den næste iteration ændres svartiden til 2 sekunder. Det er grundlæggende et valideringsdokument, der bruges som base for fremtidige referencer.

Effektivitetstest:

Effektivitetstest udføres for at kontrollere, om applikationen fungerer effektivt, og antallet af krævede ressourcer, krævede værktøjer, kompleksitet, kundekrav, krævet miljø, tid, hvilken type projekt det er osv.

Dette er nogle af de punkter, der kan hjælpe med at definere, hvor effektivt en applikation fungerer, hvis alle de betragtede parametre fungerer som forventet.

Test af katastrofegendannelse:

Denne test udføres for at kontrollere succesraten for gendannelse af en applikation eller et system, hvis der opstår kritisk fejl, og om systemet er i stand til at gendanne dataene og applikationen, eller hvis systemet let kan klare det for at vende tilbage som det fungerede tidligere, dvs. den operationelle front.

Test af vedligeholdelsesevne:

Når applikationen / produktet er sat i live, er der chancer for, at et problem opstår i det levende miljø, ellers kan kunden øge en forbedring af den applikation, der allerede er live.

I dette tilfælde er vedligeholdelsestestteam tilgængeligt til at teste ovennævnte scenarier. Når applikationen er gået i live, har den stadig brug for vedligeholdelse, som vedligeholdelsestestteamet arbejder med.

Ikke-funktionelle testværktøjer

Der er flere værktøjer tilgængelige på markedet for Performance (Load & Stress) test.

Få af dem er anført nedenfor:

• JMeter
• Loadster
• Loadrunner
• Loadstorm
• Neoload
• Vejrudsigt
• Indlæsning fuldført
• Webserver Stress Tool
• WebLoad Professional
• Loadtracer
• vPerformer

Udføres ikke-funktionel test altid uden dokumentation og testtilfælde? Hvorfor?

”Vi læres altid, hvordan man skriver funktionelle testcases. Hvorfor det? Udføres 'ikke-funktionel test' uden dokumentation (med andre ord på ad hoc-basis) eller er det en separat proces, der er meget sværere at forstå? Hvordan skrives testcases til forskellige slags test, der sker i en applikation? ”

Dette er et af de mest originale, karakteristiske og out-of-the-box spørgsmål, som jeg er blevet stillet i nyere tid. Lad os finde svaret.

Hvordan kommer vi aldrig til at se og øve os i at skrive ikke-funktionelle testsager?

Lad os starte med det, vi ved, og som altid et praktisk scenario.

Eksempel: Følgende er de trin, der skal udføres i en onlinebankapplikation for at udføre en overførsel. Lad os bruge det som vores test til reference.

1. Log ind på siden.
2. Vælg bankkontoen.
3. Vælg betalingsmodtager (denne betalingsmodtager kan tilhøre den samme bank eller en anden - det afhænger af dit datavalg for at udføre dette trin. Under alle omstændigheder skal du vælge en. Vi antager også, at betalingsmodtageren allerede er tilføjet.) .
4. Indtast det beløb, der skal overføres (positiv værdi inden for grænsen, korrekt format osv.).
5. Klik på Overfør, og kontroller, om bekræftelse er modtaget, kontosaldo er opdateret og alt det der.

Dette er den funktionelle testtilfælde, ikke?

På den samme applikation, på den samme overførselsside, lad os sige, at vi udfører Test af ydeevne, sikkerhed og brugervenlighed . Disse er ikke-funktionelle typer, ikke?

Hvordan ville vi skrive testsagerne?

# 1) Usability Testing Test cases

Usability testing er en genre af softwaretest, der beskæftiger sig med brugeroplevelse. Dette er nogle af de spørgsmål, som vi prøver at besvare.

• Hvor let er applikationen at bruge?
• Hvor tilfredsstillende er oplevelsen af ​​at bruge systemet?
• Hvis ikke det velkendte med det samme, hvor let er det at lære?

Mere info om det er her: Guide til brugervenlighedstest

Hvordan ville en bruger bestemme svarene på ovenstående spørgsmål i forbindelse med brugervenlighedstest?

Brugeren ville udføre nøjagtigt de samme trin at udføre som i den funktionelle test sag. Har jeg ret?

# 2) Ydeevne Test Test tilfælde

Der er flere variationer i ydelsestest, men i kernen bruges det til at hente statistikker om systemet, dets ressourceudnyttelse, responstid, netværksforbrug osv. Ved forskellige belastningspunkter.

Tjek vores Ydelser til test af ydeevne at vide mere om det.

Hvis jeg nu skulle teste udførelsen af ​​overførslernes transaktion, ville jeg have 10, 20, 30, 100 ... 1000 ... osv. Brugere, der udfører overførselsoperationen samtidigt eller trinvist afhængigt af hvad jeg vil målrette mod og indsamle data om.

Hvilke trin ville hver bruger udføre for at bruge overførslen, mens præstationstesten er i gang?

De samme nøjagtige trin som funktionstesten, korrekt?

# 3) Sikkerhedstestning af testsager

Security Testing er en gren af ​​QA, der hjælper med at gøre softwaresystemerne hackesikre. Det identificerer sårbarheder (potentielle problemområder i softwaresystemet), udnytter dem gennem penetration eller white-hat testteknik, og når der findes loop-huller, arbejdes der med dem.

Hvornår vil jeg kontrollere, om overførslerne er hackesikre og er rettet korrekt til de tilsigtede modtagere, og at der ikke er sorte pletter i hele processen? Jeg ville udføre overførslen, mens overvågningsprocessen for sikkerhedslækager fortsætter parallelt.

Derfor udfører jeg faktisk nøjagtigt de samme trin, som jeg normalt ville gøre i tilfælde af en funktionel testsag.

Jeg antager, vi har nok til at fastslå, at trinene i alle situationer er de samme. Metoden og intentionen bag processen er, hvad der er anderledes.

Lad os tage et sammenlignende blik:

Hvad der er interessant at bemærke er, at uanset hvilken form for test vi ønsker at gøre, er alle trin de samme .

Den virkelige forskel er, at:

1. Hvem udfører disse trin?
2. Hvad er hensigten, eller med andre ord, hvad prøver jeg at opnå via denne test?
3. De anvendte værktøjer og teknikker.

Når vi kommer tilbage til vores spørgsmål, hvorfor lærer vi aldrig at skrive ikke-funktionelle testsager med alle de detaljerede trin, der er der til det?

Det er fordi ,grundlæggende er testtrin til en variation af testtyper på en bestemt funktion alle de samme, funktionelle eller ej. Det er hensigten, der gør en forskel, og måske metoden.

Konklusion

Før du udfører ikke-funktionel test, er det vigtigt at planlægge teststrategien korrekt for at sikre korrekt test. Der er forskellige værktøjer, der er tilgængelige på markedet til at udføre denne type tests som Load Runner, RPT osv.

Denne test spiller en vigtig rolle for en applikations succes og for at opbygge et godt kundeforhold, og det bør derfor ikke overses. Dette er en af ​​de vigtige dele af softwaretest, og test kan ikke betragtes som komplet uden dette.

Vi kan inkludere ikke-funktionelle testoplysninger i testplanen eller kan oprette en separat strategi for den. I begge tilfælde er målet at have korrekt dækning af ikke-funktionelle aspekter af softwaren.

Vi håber, at denne proces med at gå dybt ned i dette emne har været lige så sjov for dig, som den er blevet præsenteret for jer alle. Vi vil meget gerne høre din feedback og tanker om dette emne.

Hvordan håndterer du ikke-funktionel test i dine teams? Og som altid, så lad os vide, hvis du er enig eller uenig eller har noget at tilføje til det, vi foregår her.

Anbefalet læsning

• Funktionel testning mod ikke-funktionel testning
• Alpha-test og betatestning (En komplet guide)
• Vejledning til test af webapplikationssikkerhed
• Komplet funktionel testguide med dens typer og eksempel
• Build Verification Testing (BVT Testing) Komplet guide
• Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
• Begyndervejledning til penetrationstest af webapplikationer
• Load Testing Komplet guide til begyndere