En komplett icke-funktionell testguide för nybörjare

complete non functional testing guide

En komplett guide till icke-funktionell testning: Dess syfte, typer, verktyg, testfall med exempel

Vad är icke-funktionell testning?

Icke-funktionell testning görs för att verifiera applikationens icke-funktionella krav som prestanda, användbarhet etc.

Det verifierar om systemets beteende är enligt kravet eller inte. Den täcker alla aspekter som inte omfattas av funktionstestning . I vår dagliga testning ägnas stor uppmärksamhet åt funktionstester och funktionskrav.

Kunderna är också intresserade av att uppfylla funktionskraven som är direkt relaterade till funktionerna i en applikation. Men i själva fasen, dvs. när du testas funktionellt, kommer programvaran på marknaden och används av de verkliga slutanvändarna, och det finns chanser för att den ska möta vissa problem relaterade till prestanda.

Dessa problem är inte relaterade till systemets funktionalitet, men de kan påverka användarupplevelsen på ett negativt sätt. Därför är det viktigt att programvaran eller applikationen också testas för icke-funktionella krav för att undvika negativ kundupplevelse.

Testning klassificeras i stort sett i två typer:

• Funktionell testning
• Icke-funktionell testning

Vad du kommer att lära dig:

• Betydelse
• Ändamål
• Exempel
• Fördelar
• Hur fångar jag in icke-funktionella krav?
  • # 1) Användar / tekniska berättelser
  • # 2) Godtagningskriterier
  • # 3) I artefakter
• Skillnad i funktionella och icke-funktionella krav
• Testar denna Black Box eller White Box?
• Icke-funktionell testfall checklista
  • Checklista för prestandatestning
  • Checklista för säkerhetstestning
  • Checklista för dokumentationstestning
• Tillvägagångssätt
  • Testomfång
  • Testa mätvärden
  • Testverktyg
  • Viktiga datum och leveranser
• Icke-funktionella testtyper
• Icke-funktionella testverktyg
  • # 1) Användbarhetstestning Testfall
  • # 2) Prestandatestning Testfall
  • # 3) Säkerhetstestning av fall
• Slutsats
• Rekommenderad läsning

Betydelse

Denna testning saknades på grund av uppmärksamhet med tanke på att den inte påverkar systemets funktionalitet.

De icke-funktionella kraven fick inte heller tillräcklig uppmärksamhet i de tidigare testcyklerna. Detta har dock förändrats nu. Icke-funktionella tester är nu viktigast eftersom de tar hänsyn till alla applikationsprestanda och säkerhetsfrågor idag.

Denna testning har större inverkan på applikationer när det gäller prestanda för applikationen under hög användartrafik. Denna testning säkerställer att din applikation är stabil och kan hantera belastning under extrema förhållanden.

Som själva namnet visar koncentrerar sig denna testning på applikationens icke-funktionella aspekt. Så vad är de icke-funktionella aspekterna? Eller ska jag säga vilka funktioner som inte är relaterade till applikationens funktionalitet?

Här är svaren på dessa:

• Hur fungerar applikationen under normala omständigheter?
• Hur beter sig applikationen när för många användare loggar in samtidigt?
• Kan applikationen hantera stress?
• Hur säker är applikationen?
• Kan applikationen återhämta sig efter en katastrof?
• Kan applikationen beter sig på samma sätt i en annan miljö eller ett annat operativsystem?
• Hur lätt är det att porta applikationen i ett annat system?
• Är de dokument / användarmanual som medföljer applikationen lätt att förstå?

Listan fortsätter. Men poängen här är att - bidrar inte dessa funktioner till applikationens kvalitet? Svaret är ja. Dessa funktioner är lika viktiga.

Föreställ dig att en applikation uppfyller alla användarkrav perfekt, men en del obehöriga användare går enkelt och spricker de data som användaren har angett i applikationen, eller så dör applikationen när mer än 5BB av någon fil laddas upp. Så skulle du säga att ansökan är av god kvalitet? Uppenbarligen inte rätt !!

Ändamål

Det enda syftet med denna typ av testning är att säkerställa att de icke-funktionella aspekterna av applikationen testas och att applikationen fungerar bra i sammanhang med densamma.

Syftet är att täcka testningen av alla applikationens egenskaper som hjälper till att tillhandahålla en applikation som uppfyller affärsförväntningarna.

Exempel

Detta är en viktig testtyp.

Funktionell testning testar applikationens funktionalitet och säkerställer att den fungerar som förväntat men den icke-funktionella testningen säkerställer att applikationen fungerar tillräckligt bra för att möta affärsförväntningarna.

För att förstå dess betydelse, låt oss ta ett enkelt exempel:

En applikation utvecklas och testas helt för funktionalitet, men icke-funktionell testning utförs inte på samma.

Under tiden när applikationen går live kan det resultera i kritiska eller större problem som när belastningen ökar på applikationen, det blir för långsamt och tar mycket tid att öppna.

Svarstiden kan öka eller när belastningen ökar till en viss grad kan applikationen krascha. Detta visar hur viktigt det är att testa en applikations icke-funktionella aspekter.

Fördelar

Nedan ges några av fördelarna med ett icke-funktionellt test:

• Det täcker testningen som inte kan täckas vid funktionstestning.
• Det säkerställer att applikationen körs effektivt och är tillräckligt pålitlig.
• Det säkerställer säkerheten för applikationen.

Hur fångar jag in icke-funktionella krav?

Medan vi utför testning är fokus främst på funktionstestning som testar produktens funktionalitet. Men icke-funktionell testning är lika viktig som funktionstestning och dess krav bör beaktas redan från starten av produkten.

Icke-funktionella krav används för att utföra icke-funktionell testning. Dessa krav inkluderar prestanda som förväntas från applikationen eller programvaran som testas. Detta inkluderar i princip den tid det tar av programvaran att driva ett visst system.

Icke-funktionella krav fångar också beteendet när ett stort antal människor använder programvaran samtidigt. För det mesta upplevs att servrarna är upptagen eller otillgängliga på grund av tung belastning (dvs. fler människor använder den samtidigt). Att boka järnvägsbiljetter online kan vara bäst exempel av en sådan situation.

Dokumentation av det icke-funktionella kravet korrekt och utförande av testningen korrekt kommer därför att säkerställa hög tillfredsställelse när det gäller användbarhet av potentiella kunder.

Även om denna testning inte har en direkt affärspåverkan på systemets funktionalitet, kan den öka användarupplevelsen och användarvänligheten i högre utsträckning vilket i sin tur kommer att ha en större inverkan på programvarans kvalitet.

Exempel:

Tänk på samma exempel på Facebook-inloggningssidan. I det här fallet är omfattningen av icke-funktionell testning att notera den tid som krävs av systemet för att logga in på Facebook efter att du har angett giltiga referenser.

Det kan också testas som när (låt oss säga 100) användarna loggar in samtidigt, hur lång tid det tar att logga in användaren på Facebook.

Detta säkerställer att systemet kan hantera belastning och trafik vilket i sin tur har en bra användarupplevelse.

I agile bör det icke-funktionella kravet fångas med hjälp av ingångar.

Ett icke-funktionellt krav bör fångas som:

• Användar / tekniska berättelser
• I acceptanskriterier
• I artefakt

9

# 1) Användar / tekniska berättelser

Ett icke-funktionellt krav kan fångas med användarberättelser eller tekniska berättelser. Att fånga icke-funktionella krav som en användarberättelse är samma som att fånga alla andra krav. Den enda skillnaden i användaren och en teknisk berättelse är att användarberättelsen kräver diskussion och har synlighet.

# 2) Godtagningskriterier

Acceptanskriterier är den punkt som definieras för att acceptera produkten av kunden, dvs. att få produkten accepterad till de definierade punkterna ska vara i godkänt tillstånd.

Ett icke-funktionellt krav bör ingå i acceptanskriterierna men ibland är det inte möjligt att testa de icke-funktionella kraven med varje berättelse, dvs. med varje iteration. Därför bör kraven endast läggas till eller testas med relevant iteration.

# 3) I artefakter

En separat artefakt bör förberedas för de icke-funktionella kraven, vilket i sin tur skulle hjälpa till att få en bättre uppfattning om vad som behöver testas och hur det kan göras i iterationer.

Skillnad i funktionella och icke-funktionella krav

Det finns flera skillnader mellan de funktionella och icke-funktionella kraven och få av dem anges nedan:

Ytterligare läsning => Skillnader mellan funktionell och icke-funktionell testning

Testar denna Black Box eller White Box?

Det icke-funktionella testet kommer under a svart låda testning Metod.

Denna teknik är inte begränsad till att bara testa funktionaliteten utan kan också användas för att testa de icke-funktionella kraven såväl som prestanda, användbarhet etc. Black box-testteknik kräver ingen kunskap om det interna systemet, dvs det kräver inte kunskapen om kod till testaren.

Icke-funktionell testfall checklista

En checklista används för att säkerställa att ingen viktig aspekt lämnas utan testning.

En checklista används vanligtvis när det inte finns tid för dokumentation och produkten måste testas eller när det finns en tidsbegränsning kan en checklista användas för att säkerställa att alla viktiga aspekter har täckts.

Låt oss se enexempelöver checklista för testning av prestanda, säkerhet och dokumentation.

Checklista för prestandatestning

• Svarstiden av applikationen bör verifieras d.v.s. hur lång tid tar det att ladda applikationen, varje ingång som ges till applikationen ger utdata på hur mycket tid, uppdaterar webbläsaren etc.
• Genomströmning ska verifieras för antalet transaktioner som genomförts under en belastningstest.
• Miljö inställningen bör vara densamma som den levande miljön, annars skulle resultaten inte vara desamma.
• Processtid - Processaktiviteter som import och export av Excel, alla beräkningar i applikationen bör testas.
• Interoperabilitet ska verifieras, dvs. en programvara ska kunna samverka med den andra programvaran eller systemen.
• ETL tiden bör verifieras, dvs den tid det tar att extrahera, omvandla och ladda data från en databas till en annan.
• Ökar belastningen på ansökan bör verifieras.

Checklista för säkerhetstestning

• Autentisering: Endast en autentisk användare ska kunna logga in.
• Auktoriserad: Användaren ska kunna logga in på de moduler som han är auktoriserad för eller som användaren har fått åtkomst till.
• Lösenord: Lösenordskrav bör verifieras, dvs lösenord ska vara enligt hur kravet definierar dvs längd, specialtecken, siffror etc.
• Paus: Om applikationen är inaktiv ska den ta timeout under en angiven tid.
• Säkerhetskopiering av data: Säkerhetskopiering av data ska tas vid en viss tidpunkt och ska kopieras till en säker plats.
• Interna länkar till webbapplikationen ska inte vara tillgänglig om den placeras direkt i webbläsaren.
• All kommunikation ska krypteras.

Checklista för dokumentationstestning

• Användar- och systemdokumentation.
• Dokument för utbildningsändamål.

Tillvägagångssätt

Utveckla ett specifikt tillvägagångssättdokument för Performance Test-steget genom att förfina den övergripande teststrategin. Denna testmetod styr planeringen och genomförandet av alla prestandatestuppgifter.

brute force password cracker nedladdning för android

• Testomfång
• Testa mätvärden
• Testverktyg
• Viktiga datum och leveranser

Testomfång

Genomför prestandatestning från olika perspektiv, såsom användarprestanda, affärsprocesser, systemstabilitet, resursförbrukning och så vidare. Typer av prestandatest som ska utföras diskuteras i avsnittet ovan i artikeln (som belastningstest, stresstest etc.)

Testa mätvärden

Testmetoden förfinar mätvärdena för att mäta och rapportera under testning, till exempel:

• Svarstid (online)
• Partifönster (batch)
• Genomströmning ( Till exempel , antalet transaktioner per tidsenhet)
• Användning ( Till exempel , procentandelen resurser som används)

Testverktyg

För det mesta kräver prestandatestning användning av lämpliga verktyg:

• Lastgenereringsverktyg
• Verktyg för prestationsövervakning
• Verktyg för prestationsanalys
• Verktyg för applikationsprofilering
• Basfoderverktyg.

Viktiga datum och leveranser

Arbetsdokumentet för prestandatest bör beskriva följande:

• Datum och tid för varje utförande av prestandatestet.
• Typer av tester och funktionalitetsmix som ska ingå i varje utförande av prestandatest.
• Slutdatum för prestandatest.

Icke-funktionella testtyper

Följande bild visar typerna av icke-funktionell testning:

Prestandatester:

Utvärderar systemets totala prestanda .

Viktiga element är följande:

• Validerar att systemet uppfyller den förväntade svarstiden.
• Utvärderar att de viktiga delarna av applikationen uppfyller önskad svarstid.
• Det kan också genomföras som en del av integrationstestning och systemtestning.

Lasttestning:

Utvärderar om systemets prestanda är som förväntat under normala och förväntade förhållanden.

Viktiga punkter är:

• Validerar att systemet fungerar som förväntat när samtidiga användare får åtkomst till applikationen och får den förväntade svarstiden.
• Detta test upprepas med flera användare för att få svarstiden och genomströmningen.
• Vid testet bör databasen vara realistisk.
• Testet bör utföras på en dedikerad server som stimulerar den verkliga miljön.

Stresstestning:

Utvärderar om systemets prestanda är som förväntat när det är lågt på resurser.

Viktiga punkter är:

• Testa på lågt minne eller lågt diskutrymme på klienter / servrar som avslöjar defekter som inte kan hittas under normala förhållanden.
• Flera användare utför samma transaktioner på samma data.
• Flera klienter är anslutna till servrarna med olika arbetsbelastningar.
• Minska Think Time till 'Noll' för att stressa servrarna till maximal stress.

Tänk tid: Precis som tidsintervallet mellan att skriva din användare och lösenord.

Volymtestning:

Utvärderar programvarans beteende när en stor datamängd är inblandad.

Viktiga punkter är:

• När programvaran är föremål för stora mängder data kontrollerar du gränsen där programvaran misslyckas.
• Maximal databasstorlek skapas och flera klienter frågar efter databasen eller skapar en större rapport.
• Exempel - Om applikationen bearbetar databasen för att skapa en rapport skulle ett volymtest vara att använda en stor resultatuppsättning och kontrollera om rapporten skrivs ut korrekt.

Användbarhetstestning:

Utvärderar systemet för mänsklig användning eller kontrollerar om det är lämpligt för användning.

Viktiga punkter är:

• Är produktionen korrekt och meningsfull och är den samma som förväntades enligt verksamheten?
• Har felen diagnostiserats korrekt?
• Är GUI korrekt och överensstämmer med standarden?
• Är applikationen lätt att använda?

Test av användargränssnitt:

Utvärderar GUI.

Viktiga punkter är:

• GUI bör ge hjälp och verktygstips för att göra det enkelt att använda.
• Konsekvent för sitt utseende?
• Data spåras korrekt från en sida till en annan?
• GUI bör inte irritera användaren eller bli svår att förstå.

Kompatibilitetstest:

Utvärderar att applikationen är kompatibel med annan hårdvara / programvara med minsta och maximala konfiguration.

Viktiga punkter är:

• Testa varje hårdvara med minimal och maximal konfiguration.
• Testa med olika webbläsare.
  Testfall är desamma som de som utfördes under funktionstestning.
• Om antalet hårdvara och programvara är för många, kan vi använda OATS-tekniker för att komma fram till testfallet för att ha maximal täckning.

Återhämtningstest:

Utvärderar att applikationen avslutas graciöst i händelse av fel och data återställs på lämpligt sätt från maskin- och programvarufel.

Testerna är inte begränsade till nedanstående punkter:

• Strömavbrott, till klienten medan du gör CURD-aktiviteter.
• Ogiltiga databaspekare och nycklar.
• Databasprocessen avbryts eller avslutas i förtid.
• Databaspekare, fält och nycklar skadas manuellt och direkt i databasen.
• Koppla bort kommunikationen fysiskt, slå av strömmen, stäng av routrarna och nätverksservrarna.

Instabilitetstest:

Utvärderar och bekräftar om programvaran installeras och avinstalleras korrekt.

hur öppnar jag a.swf-filen

Viktiga punkter är:

• Validerar att systemkomponenterna är korrekt installerade på den angivna hårdvaran.
• Validerar att navigeringen på den nya maskinen uppdaterar befintlig installation och äldre versioner.
• Validerar att med otillräckligt skivutrymme finns det inget oacceptabelt beteende.

Dokumentationstestning:

Utvärderar dokument och andra användarmanualer.

Viktiga punkter inkluderar:

• Validerar att de angivna dokumenten finns i produkten.
• Validerar alla användarhandböcker, ställer in instruktioner, läser mig filer, utgivningsanteckningar och onlinehjälp.

Failover-testning:

Failover-testning görs för att verifiera att i händelse av ett systemfel är systemet tillräckligt kapabelt för att hantera extra resurser som servrar.

För att förhindra en sådan situation spelar säkerhetskopiering en stor roll. Processen handlar om att skapa ett reservsystem. Om säkerhetskopian är tillgänglig hjälper det dig att få tillbaka systemet.

Säkerhetstestning:

Säkerhetstestning görs för att säkerställa att applikationen inte har några kryphål som kan leda till dataförlust eller hot. Det är en av de viktiga aspekterna av icke-funktionell testning och om det inte utförs korrekt kan det leda till säkerhetshot.

Det inkluderar testautentisering, auktorisering, integritet och tillgänglighet.

Skalbarhetstestning:

Skalbarhetstestning görs för att verifiera om applikationen är tillräckligt kapabel för att hantera ökad trafik, antal transaktioner, datavolym etc. Systemet ska fungera som förväntat när datamängden eller förändringen i datastorleken görs.

Test av efterlevnad:

Efterlevnadstestning görs för att verifiera om de definierade standarderna följs eller inte. Granskningar görs för att verifiera detsamma.

För Exempel , Granskningar görs för att verifiera processen för att skapa testfall / testplaner och placera dem på den delade platsen med det standardnamn som görs eller inte. I QC följs standardtestnamnets namn eller inte under namngivning av testfall. Dokumentationen är komplett och godkänd eller inte.

Det här är några få pekare som behandlas under revisionen.

Uthållighetstestning:

Uthållighetsprovning görs för att verifiera systemets beteende när en belastning ökas i en utsträckning under lång tid.

Det kallas också Soak testing & Capacity testing. Det hjälper till att verifiera om det finns minnesläckage i systemet. Uthållighetstestning är en delmängd av belastningstestning.

Lokaliseringstestning:

Lokaliseringstestning görs för att verifiera applikationen på olika språk, dvs. olika språk. Ansökan bör verifieras för en viss kultur eller lokal. Huvudfokus är att testa programmets innehåll, GUI.

Internationaliseringstestning:

Internationaliseringstest är också känt som i18n-testning.

I18n representerar I – arton bokstäver- N. Det görs för att verifiera om applikationen fungerar som förväntat i alla språkinställningar. Det verifierar att alla funktioner eller applikationer i sig inte går sönder, dvs. applikationen ska vara tillräckligt kapabel för att hantera alla internationella inställningar.

Det verifierar också att applikationen installeras utan problem.

Tillförlitlighetstestning:

Pålitlighetstestning görs för att verifiera om applikationen är tillförlitlig och testas under en viss tidsperiod i den definierade miljön. En applikation ska ge samma resultat som förväntat varje gång, först då kan den anses vara tillförlitlig.

Bärbarhetstestning:

Portabilitetstestning görs för att verifiera om en programvara / applikation installeras på ett annat system eller på en annan plattform ska den kunna köras som förväntat, dvs ingen funktionalitet ska påverkas på grund av en förändring i miljön.

Under testningen krävs det också att testa ändringen med hårdvarukonfigurationen som hårddiskutrymme, processor och även med olika operativsystem för att säkerställa att applikationens korrekta beteende och förväntade funktionalitet är intakta.

Baslinjetestning:

Baslinjetestning kallas också riktmärketestning eftersom det skapar en bas för alla nya applikationer som ska testas.

Till exempel: I den första iterationen var svarstiden för en applikation 3 sekunder. Nu har detta ställts in som ett riktmärke för nästa iteration och i nästa iteration ändras svarstiden till 2 sekunder. Det är i grunden ett valideringsdokument som används som bas för framtida referenser.

Effektivitetstest:

Effektivitetstestning görs för att verifiera om applikationen fungerar effektivt och hur många resurser som krävs, verktyg som krävs, komplexitet, kundkrav, miljö som krävs, tid, vilken typ av projekt det är etc.

Det här är några av pekarna som kan hjälpa till att definiera hur effektivt en applikation skulle fungera om alla övervägda parametrar fungerar som förväntat.

Test av katastrofåterhämtning:

Denna testning görs för att verifiera framgångsgraden för återställning av en applikation eller ett system om något kritiskt fel inträffar och om systemet kan återställa data och applikation eller om systemet enkelt klarar av för att återvända som det fungerade tidigare, dvs. från den operativa fronten.

Test av underhållsbarhet:

När applikationen / produkten väl är igång finns det chanser för ett problem att komma upp i den levande miljön eller så kan kunden vilja ha en förbättring av den applikation som redan är live.

I det här fallet finns underhållstestteam tillgängligt för att testa ovan nämnda scenarier. När applikationen är igång behöver den fortfarande underhåll som underhållstestteamet arbetar för.

Icke-funktionella testverktyg

Det finns flera verktyg tillgängliga på marknaden för Performance (Load & Stress) testning.

Få av dem listas nedan:

• JMeter
• Loadster
• Loadrunner
• Loadstorm
• Neoload
• Prognos
• Lastningen är klar
• Webbserver Stressverktyg
• WebLoad Professional
• Loadtracer
• vPerformer

Är icke-funktionell testning alltid utförd utan dokumentation och testfall? Varför?

”Vi lär oss alltid hur man skriver funktionella testfall. Varför är det så? Utförs ”icke-funktionell testning” utan dokumentation (med andra ord på ad hoc-basis) eller är det en separat process som är mycket svårare att förstå? Hur skrivs testfall för olika typer av test som händer i en applikation? ”

Detta är en av de mest originella, distinkta och out-of-the-box frågorna som jag har ställts på senare tid. Låt oss hitta svaret.

Varför får vi aldrig se och öva oss på att skriva icke-funktionella testfall?

Låt oss börja med det vi vet och som alltid ett praktiskt scenario.

Exempel: Följande är stegen som ska utföras i en onlinebankansökan för att utföra en överföring. Låt oss använda det som vårt test för referens.

1. Logga in på webbplatsen.
2. Välj bankkonto.
3. Välj betalningsmottagare (denna betalningsmottagare kan tillhöra samma bank eller en annan - det beror på ditt dataval för att utföra detta steg. I vilket fall som helst, välj en. Vi kommer också att anta att betalningsmottagaren redan har lagts till.) .
4. Ange beloppet som ska överföras (positivt värde, inom gränsen, rätt format etc.).
5. Klicka på Överför och kontrollera om bekräftelse har mottagits, kontosaldot har uppdaterats och allt detta.

Detta är det funktionella testfallet, eller hur?

Låt oss säga att vi presterar på samma applikation, på samma överföringssida Testning av prestanda, säkerhet och användbarhet . Dessa är icke-funktionella typer, eller hur?

Hur skulle vi skriva testfallet?

# 1) Användbarhetstestning Testfall

Användbarhetstestning är en genre av programvarutestning som handlar om användarupplevelse. Det här är några av de frågor som vi försöker svara på.

• Hur lätt är applikationen att använda?
• Hur tillfredsställande är upplevelsen av att använda systemet?
• Om inte så bekant direkt, hur lätt är det att lära sig?

Mer information om det finns här: Guide för användbarhetstestning

Hur skulle en användare bestämma svaren på ovanstående frågor i samband med användbarhetstestning?

Användaren skulle göra exakt samma steg som i funktionstestfallet. Har jag rätt?

# 2) Prestandatestning Testfall

Det finns flera varianter av prestandatest, men i grunden används det för att få statistik om systemet, dess resursutnyttjande, svarstid, nätverksförbrukning etc. vid olika belastningspunkter.

Kolla in vår Självstudier om prestandatestning att veta mer om det.

Nu, om jag skulle testa genomförandet av överföringarnas transaktion skulle jag ha 10, 20, 30, 100 ... 1000 ... etc användare att utföra överföringsoperationen samtidigt eller stegvis beroende på vad jag vill rikta in och samla in data om.

Vilka steg skulle varje användare utföra för att kunna använda överföringen medan prestandatestet pågår?

Samma exakta steg som funktionstestet, eller hur?

# 3) Säkerhetstestning av fall

Säkerhetstestning är en gren av QA som hjälper till att göra mjukvarusystemen hacksäkra. Den identifierar sårbarheter (potentiella problemområden i mjukvarusystemet), utnyttjar dem genom penetration eller testningsteknik och när loop-hål hittas, jobbar de på.

När vill jag kontrollera om överföringarna är hacksäkra och riktas korrekt till avsedda mottagare och att det inte finns några svarta fläckar i hela processen? Jag skulle utföra överföringen medan övervakningsprocessen för säkerhetsläckor fortsätter parallellt.

Därför utför jag i själva verket exakt samma steg som jag normalt skulle göra vid ett funktionellt testfall.

Jag antar att vi har tillräckligt för att fastställa att stegen i alla situationer är desamma. Metoden och avsikten bakom processen är vad som är annorlunda.

Låt oss ta en jämförande titt:

Vad som är intressant att notera är att oavsett vilken typ av test vi vill göra, alla steg är desamma .

Den verkliga skillnaden är att:

1. Vem utför dessa steg?
2. Vad är avsikten, eller med andra ord vad försöker jag uppnå via detta test?
3. De verktyg och tekniker som används.

Kommer vi tillbaka till vår fråga, varför lär vi oss aldrig att skriva icke-funktionella testfall med alla detaljerade steg som finns där?

Det beror på att ,i sin kärna är teststegen för en variation på testtyper på en viss funktion alla samma, funktionella eller inte. Det är avsikten som gör skillnad och kanske metoden.

Slutsats

Innan du utför icke-funktionell testning är det viktigt att planera teststrategin korrekt för att säkerställa korrekt testning. Det finns olika verktyg som finns tillgängliga på marknaden för att utföra denna typ av tester som Load Runner, RPT, etc.

Denna testning spelar en viktig roll för framgången för en applikation och för att bygga upp ett bra kundförhållande och därför bör det inte försummas. Detta är en av de viktiga delarna av testning av programvara och testning kan inte anses vara komplett utan detta.

Vi kan inkludera icke-funktionella testdetaljer i testplanen eller kan skapa en separat strategi för den. I båda fallen är målet att ha korrekt täckning av icke-funktionella aspekter av programvaran.

Vi hoppas att denna fördjupningsprocess har varit lika rolig för dig som den har presenterats för er alla. Vi skulle gärna höra din feedback och tankar om detta ämne.

Hur hanterar du icke-funktionell testning i dina team? Och som alltid, låt oss veta om du håller med eller inte håller med eller har något att lägga till vad vi händer här.

Rekommenderad läsning

• Funktionell testning mot icke-funktionell testning
• Alpha Testing och Beta Testing (En komplett guide)
• Handbok för testning av webbapplikation
• Komplett funktionell testguide med dess typer och exempel
• Byggverifieringstestning (BVT-testning) Komplett guide
• Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
• Nybörjarhandbok för penetreringstestning för webbapplikationer
• Lasttestning Komplett guide för nybörjare