Meny

Funksjonstesting mot ytelsestesting: Bør det gjøres samtidig?

functional testing vs performance testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Funksjonell testing mot ytelsestesting:

Forskjeller mellom Ytelsestesting, belastningstesting og stresstesting ble forklart med eksempler i vår siste opplæring.

Testing av programvare dekker et bredt spekter av områder der verifisering eller validering av programvarefunksjonalitet kan forekomme. Noen ganger blir ikke-funksjonelle aspekter mindre angående de funksjonelle aspektene. De utføres ikke praktisk; samtidig under programvaretesting.

=> Klikk her for å få fullstendige ytelsestester

Denne artikkelen forklarer de ekstra fordelene med kvaliteten på programvareproduktet under ulike scenarier i programvaretestingen av livssyklusen når både funksjonelle og ikke-funksjonelle tas samtidig.

funksjonell ytelsestesting 5

Hva du vil lære:

Rask forskjell mellom ytelsestesting og funksjonstesting

Sl NOFunksjonell testing
Ytelsestesting
enFor å verifisere programvarens nøyaktighet med bestemte innganger mot forventet produksjonFor å kontrollere systemets oppførsel under forskjellige belastningsforhold
toDet kan være manuelt eller automatisert
Den kan utføres effektivt hvis den er automatisert
3Én bruker som utfører alle operasjonene
Flere brukere som utfører ønskede operasjoner
4Involvering kreves av kunde, tester og utviklerInvolvering kreves av kunde, tester, utvikler, DBA og N / W Management team
5Testmiljø i produksjonsstørrelse er ikke obligatorisk og H / W-kravene er minimaleKrever nær produksjonstestmiljø og flere H / W-anlegg for å fylle lasten

Hvorfor skal funksjonstesting og ytelsestesting gjøres samtidig?

Funksjonstesting blir mye viktigere for enhver forhåndsutgivelse av programvare. Faktisk resultatbasert verifisering og validering i replikert produksjons- eller testmiljø er der testingen vanligvis skjer.

Feillekkasje kan bli et av de største problemene:

Testere har mer ansvar enn utviklere når det gjelder kvaliteten på produktet. I utgangspunktet vil de ikke at det testede produktet skal ha feillekkasje. Testere har vanligvis en tendens til å bare utføre funksjonell testing for å oppnå dette.

funksjonell ytelsestesting 1

Det følgende er en samtale mellom enTestleder og en tester :

(Test Manager blir referert til som 'TM' og Tester som 'TR')

TM : Hei kompis ... Hvordan har vi det med produkt-A-testingen?

TR : Jepp ... Vi går fremover på en større måte.

TM : Det er fantastisk ... Og hva er vårt omfang når det gjelder ytelsestesting mens funksjonstesting er under utførelse?

TR : Vi dekker ikke over dem, våre leveranser skal bare være i funksjonsområdet og ikke på det ikke-funksjonelle området. Testmiljøet vi bruker er heller ikke en eksakt kopi av produksjonen.

Det er noen spørsmål fra samtalen ovenfor som skal vurderes:

  • Har funksjonstesting en avhengig faktor i forhold til ytelse?
  • Hva om ytelsen til programvaren blir forringet, men levering av produktet skjer uten å sjekke ytelsen?
  • Ytelsestesting - er det eksisterende i funksjonstestprosessen?

Det har blitt en generell praksis for testere å ikke jobbe med de ikke-funksjonelle aspektene med mindre de blir bedt om å gjøre det. Det er vanlig å unngå ikke-funksjonell testing inntil klienten har rapportert om problemer med ytelsen til programvaren som testes.

Så det er to spørsmål du kan vurdere:

  1. Ytelse - påvirker den funksjonell testing?
  2. Holder vi ytelsestesting som en separat leveranse, selv om det bekymrer kunden?

Ytelsestesting er viktig !

nett intervju spørsmål og svar for erfarne

Programvare fungerer basert på forskjellige arkitekturer og følgende modeller, inkludert:

  1. Nødvendige svarsvarsmodeller
  2. Transaksjonsbaserte systemer
  3. Lastbaserte systemer
  4. Datareplikasjonsbaserte systemer

Den ovennevnte systematiske modellens funksjonelle testadferd avhenger av ytelsen til systemet.

funksjonell ytelsestesting 2

Automatiseringssynspunktet krever mye oppmerksomhet mot ytelsestesting.

Det følgende er en samtale mellom enklient og testleder.

(Kunden blir referert til som 'CL' og testansvarlig som 'TM')

CL : Derfor kommer jeg til løsningen vi har bedt om, jeg håper det vil være flere iterasjoner av testingen som skjer for øyeblikket.

TM : Ja, dette kan gjøres. Som du har sagt, vil det være større sannsynlighet for iterativ testing. Vi vil foreslå automatisering for å håndtere funksjonell (regresjon) testing.

CL : OK flott, vennligst send oss ​​din tilnærming så vi kan godkjenne dette. Automatisering vil ha mye høyere effekt med minimal innsats.

TM : Nøyaktig. Vi vil jobbe med tilnærmingen og komme tilbake til deg med et bevis på konseptet.

Fra samtalen ovenfor er det klart at kundenes behov er å optimalisere effektiviteten.

Casestudie

Firma ABC jobber med et prosjekt for utvikling av programvare A. Testing av programvare A gjøres av selskapet XYZ.

Kontrakten for selskapet ABC og XYZ har noen begrensninger for samarbeidet. Enhver diskusjon mellom de to selskapene skal skje en gang i uken eller tre ganger i måneden. Systemet fungerer på en modell av forespørselsresponsmodus. Utviklingsfasen er fullført av Company ABC.

Nå er det på tide for selskapet XYZ å utføre den formelle funksjonelle testingen av programvare A. XYZ begynner å jobbe med å teste programvare A. De har gitt en ren chit på programvaren og har gitt 'Go' for live implementering etter to sykluser med testing.

Til tross for kvalitetssertifikatet fra testteamet gikk ikke live implementeringen bra. Det var mange feil etter produksjonen. Det var et stort antall problemer som klientene møtte, inkludert en pause i funksjonaliteten for de endelige forretningsprosessene.

Så hva er nå?problem?

funksjonell ytelsestesting 3

  • Er det et problem med en begrensning på samarbeid mellom utviklings- og testteamet?
  • Er det slik at kravene ikke ble fanget 100%?
  • Er det slik at produktet ikke ble testet i et riktig testmiljø?
  • Eller andre årsaker?

Etter nøye undersøkelser og analyser harfølgende ble utledet:

funksjonell ytelsestesting 4

  1. Det var få av de avhengige og gjensidig avhengige applikasjonene som hadde ytelsesproblemer mens svarene ble hentet.
  2. Testinngangene som ble brukt var ikke absolutte.
  3. Programvarens robusthet ble ikke ivaretatt.
  4. Mange synkroniseringsproblemer mellom flere uavhengige applikasjoner.
  5. Programvaretestingen hadde gjort flere omarbeid som ikke ble vurdert.

Derfor etterutbedrende tiltakplanleggingsteamet gikk inn, ble følgende foreslått:

  1. Samspillet mellom utviklingsteamet og testteamet må økes.
  2. Alle avhengige applikasjoner må kobles til og inkluderes i systemfunksjonstesten
  3. Verdien for forespørsel og svarstidsavbrudd må økes for å gi rom til miljøer som ikke er i produksjon
  4. Ulike innspill som varierer mellom enkle og komplekse, må brukes i funksjonstesting
  5. Ikke-funksjonell testing, spesielt ytelse og belastningstesting, må gjøres som anbefalt av utbedringsteamet.
  6. I tillegg til systemtesting, må systemintegrasjonstesting utføres.
  7. Det må gis et minimalt tidsforskjell mellom to test-iterasjoner. Dette er for å teste de tidligere identifiserte feilene på nytt.
  8. Alle feil identifisert i tidligere iterasjoner bør fikses i gjeldende iterasjon.

Testteamet implementerte alle de foreslåtte handlingene, og det ble oppdaget et stort antall mangler på kort tid.

Observasjoner:

  1. Programvaren for live implementering av programvaren forbedret seg betydelig ved å optimalisere testsyklusens tider.
  2. Det var gode fremskritt i optimaliseringen av programvarekvaliteten. Derfor var det en enorm nedgang i supportbilletter etter implementering.
  3. Re-works ble redusert, og det ble testet iterasjoner i stedet for re-work. Mellom de forskjellige iterasjonene ble det observert bedre forbedringer i kvaliteten.

Konklusjon

Å utføre ikke-funksjonell testing under funksjonell testutførelse er mer fordelaktig og vil gi flere fordeler til den generelle programvarekvaliteten. Dette vil identifisere ytelsesfeil (begrenset til testmiljøet og avhengighet) og vil dermed redusere situasjoner med funksjonelle forutsetninger.

Tilstrekkelig planlegging for å utføre funksjonell og ikke-funksjonell testing (til et minimumsnivå) må gjøres for å opprettholde et sterkt forhold mellom de andre interessentene i prosjektet.

Om forfatter: Dette er en artikkel skrevet av Nagarajan. Han jobber som en testleder med over 6 års erfaring med testing innen ulike funksjonelle områder som Banking, Airlines, Telecom når det gjelder både manuell og automatisering.

Vår kommende veiledning vil forklare mer om Performance Test Plan og Test Strategy.

=> Besøk her for fullstendige ytelsestestopplæringsserier

PREV Opplæring | NESTE veiledning

Anbefalt lesing

^