Menu

Funktionstestning mod ydelsestestning: Bør det gøres samtidigt?

functional testing vs performance testing

Prøv Vores Instrument Til At Fjerne Problemer

Funktionel testning vs Performance Testing:

Forskelle mellem Ydelsestest, belastningstest og stresstest blev forklaret med eksempler i vores sidste tutorial.

Softwaretest dækker en lang række områder, hvor enhver verifikation eller validering af softwarefunktionalitet kan forekomme. Lejlighedsvis bliver ikke-funktionelle aspekter mindre angående de funktionelle aspekter. De udføres ikke praktisk; samtidigt under softwaretest.

=> Klik her for at få komplette præstationsprøvetutorials-serier

Denne artikel forklarer de ekstra fordele ved softwareproduktets kvalitet under forskellige scenarier i softwaretestens livscyklus når både funktionelle og ikke-funktionelle tages samtidigt.

funktionel ydelsestest 5

Hvad du lærer:

Hurtig forskel mellem Performance Testing og Functional Testing

Sl NOFunktionel testning
Test af ydeevne
1For at kontrollere nøjagtigheden af ​​softwaren med bestemte input i forhold til forventet outputFor at kontrollere systemets opførsel under forskellige belastningsforhold
toDet kan være manuelt eller automatiseret
Det kan udføres effektivt, hvis det automatiseres
3Én bruger, der udfører alle handlinger
Flere brugere, der udfører de ønskede handlinger
4Involvering krævet af kunde, tester og udviklerInvolvering påkrævet fra kunde-, test-, udvikler-, DBA- og N / W-ledelsesteam
5Testmiljø i produktionsstørrelse er ikke obligatorisk, og H / W-kravene er minimaleKræver tæt på produktionstestmiljø & flere H / W-faciliteter for at udfylde belastningen

Hvorfor skal funktionstest og præstationstest udføres samtidigt?

Funktionstestning bliver meget vigtigere for enhver softwareudgivelse. Faktisk resultatbaseret verifikation og validering i det replikerede produktions- eller testmiljø er det, hvor testningen normalt sker.

Fejllækage kan blive et af de største problemer:

Testere har mere ansvar end udviklere med hensyn til produktets kvalitet. Dybest set ønsker de ikke, at det testede produkt skal have lækage af defekter. Testere har generelt en tendens til kun at udføre funktionel test for at opnå dette.

funktionel ydelsestest 1

Det følgende er en samtale mellem enTest Manager og en Tester :

(Test Manager kaldes 'TM' og Tester som 'TR')

TM : Hej kammerat ... Hvordan har vi det med produktet 'A' test?

TR : Ja ... Vi skrider frem igennem på en større måde.

TM : Det er fantastisk ... Og hvad er vores rækkevidde med hensyn til præstationstest, mens funktionel test er under udførelse?

TR : Vi dækker dem ikke, vores leveringer menes kun at være i det funktionelle område og ikke på det ikke-funktionelle område. Det testmiljø, vi bruger, er heller ikke en nøjagtig kopi af produktionen.

Der er et par spørgsmål fra ovenstående samtale, der skal overvejes:

  • Har funktionstest en afhængig faktor i forhold til ydeevne?
  • Hvad hvis softwarens ydelse er forringet, men levering af produktet sker uden at kontrollere ydelsen?
  • Ydelsestest - er det sameksisterende inden for den funktionelle testproces?

Det er blevet en almindelig praksis for testere, at de ikke arbejder på de ikke-funktionelle aspekter, medmindre de bliver bedt om det. Det er almindeligt at undgå ikke-funktionel test indtil klienten har rapporteret om problemer med ydelsen af ​​den software, der testes.

Så der er to spørgsmål, du kan overveje:

  1. Ydeevne - påvirker det funktionstestning?
  2. Holder vi præstationsafprøvning som en separat levering, selvom det bekymrer klienten?

Ydeevne test er vigtig !

hvad bruges java til i dag

Software fungerer baseret på forskellige arkitekturer og følgende modeller, herunder:

  1. Påkrævede svar svar modeller
  2. Transaktionsbaserede systemer
  3. Belastningsbaserede systemer
  4. Datareplikeringsbaserede systemer

Ovennævnte systematiske models funktionelle testadfærd afhænger af systemets ydeevne.

funktionel ydelsestest 2

Automatiseringssynspunktet kræver meget opmærksomhed mod ydelsestest.

Det følgende er en samtale mellem enklient og Test Manager.

(Kunden kaldes 'CL' og testmanager som 'TM')

CL : Derfor når jeg til den løsning, vi har anmodet om, håber jeg, at der vil være flere gentagelser af den test, der sker i øjeblikket.

TM : Ja, dette kan gøres. Som du har sagt, vil der være en højere sandsynlighed for iterativ test, vi vil gerne foreslå automatisering til at håndtere den funktionelle (regression) test.

CL : OK godt, send os din tilgang, så vi kan godkende dette. Automatisering vil have et meget højere output med minimal indsats.

TM : Nemlig. Vi arbejder på fremgangsmåden og vender tilbage til dig med et bevis på konceptet.

Fra ovenstående samtale er det klart, at kundernes behov er at optimere effektiviteten.

Casestudie

Virksomhed ABC arbejder på et projekt til udvikling af software A. Testning af software A udføres af virksomheden XYZ.

Kontrakten for firmaet ABC og XYZ har nogle begrænsninger for deres samarbejde. Enhver diskussion mellem de to virksomheder skal ske en gang om ugen eller tre gange om måneden. Systemet fungerer på en model af anmodning-svar-tilstand. Udviklingsfasen er afsluttet af Company ABC.

Nu er det tid for virksomhed XYZ at udføre den formelle funktionelle test på software A. XYZ begynder at arbejde med at teste software A. De har givet en ren chit på softwaren og har givet 'Go' til live implementering efter 2 testcyklusser.

På trods af kvalitetscertifikatet fra testteamet gik live implementeringen ikke godt. Der var mange bugs efter produktionen. Der var et stort antal problemer, som klienterne stod over for, herunder en pause i funktionaliteten til de end-to-end forretningsprocesser.

Så hvad er nu det?problem?

test af funktionel ydeevne 3

  • Er det et problem med en begrænsning af samarbejdet mellem udviklings- og testteamet?
  • Er det, at kravene ikke blev fanget 100%?
  • Er det, at produktet ikke blev testet i et korrekt testmiljø?
  • Eller andre årsager?

Efter omhyggelig undersøgelse og analyse erfølgende blev udledt:

test af funktionel ydelse 4

  1. Der var få af de afhængige og indbyrdes afhængige applikationer, som havde problemer med ydeevnen, mens de hentede svarene.
  2. De anvendte testindgange var ikke absolutte.
  3. Softwarets robusthed blev ikke taget hånd om.
  4. Masser af synkroniseringsproblemer mellem de mange uafhængige applikationer.
  5. Softwaretesten havde udført flere omarbejdninger, som ikke blev overvejet.

Derfor efterafhjælpende handlingerplanlægningsteam trådte ind, blev følgende foreslået:

  1. Interaktionen mellem udviklingsteamet og testteamet skal øges.
  2. Alle afhængige applikationer skal forbindes og inkluderes i systemets funktionelle test
  3. Værdien for anmodning og timeout for svar skal øges for at give plads til miljøer, der ikke er produceret
  4. Forskellige input, der spænder mellem enkle og komplekse, skal bruges til funktionel test
  5. Ikke-funktionel test, især ydeevne- og belastningstest, skal udføres som anbefalet af det afhjælpende team.
  6. Ud over systemtest skal systemintegrationstest udføres.
  7. Der skal tilvejebringes et minimalt tidsrum mellem to test-iterationer. Dette er til at teste de tidligere identificerede fejl igen.
  8. Alle fejl identificeret i tidligere iterationer skal rettes i den aktuelle iteration.

Testteamet implementerede alle de foreslåede handlinger, og der var et stort antal mangler afdækket på kort tid.

Bemærkninger:

  1. Live implementeringsplanen for softwaren forbedres betydeligt ved at optimere testcyklustiderne.
  2. Der var gode fremskridt med optimering af softwarekvalitet. Derfor var der et enormt fald i supportbilletter efter implementering.
  3. Genarbejdet blev reduceret, og det blev testet gentagelser i stedet for genarbejde. Mellem de forskellige iterationer blev der observeret bedre forbedringer i kvaliteten.

Konklusion

At udføre ikke-funktionel test under funktionel testudførelse er mere fordelagtig og vil tilføje flere fordele til den overordnede softwarekvalitet. Dette vil identificere præstationsfejl (begrænset til testmiljøet og afhængighed) og dermed reducere situationer med funktionelle antagelser om problemer.

Tilstrækkelig planlægning til udførelse af funktionel og ikke-funktionel test (til et minimumsniveau) skal foretages for at bevare et stærkt forhold mellem de andre interessenter i projektet.

Om forfatter: Dette er en artikel skrevet af Nagarajan. Han arbejder som en testleder med over 6 års testerfaring inden for forskellige funktionelle områder som Banking, Airlines, Telecom med hensyn til både manuel og automatisering.

Vores kommende tutorial forklarer mere om Performance Test Plan og Test Strategy.

=> Besøg her for komplette ydeevne-test tutorials-serier

PREV-vejledning | NÆSTE vejledning

Anbefalet læsning

^