Menu

Applicatie testen - In de basis van softwaretesten!

application testing into basics software testing

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Inleiding tot applicatietesten

Applicatietesten is zo'n activiteit die door bijna elke softwaretester in zijn carrière regelmatig wordt uitgevoerd. Deze twee woorden zijn zeer breed in praktische aspecten. Hier worden echter alleen de kern en de belangrijkste gebieden besproken. Het doel van dit artikel is om alle primaire gebieden aan te raken, zodat de lezers alle basisbriefing op één plek krijgen.

Applicatie testen

In een one-liner kunnen we zeggen dat applicatietesten een proces is waarmee de functionaliteit, bruikbaarheid en consistentie van de gehele applicatie wordt getest.

Wat je leert:

Applicatietesten: uitleg van de basisprincipes van softwaretests

Categorieën van toepassingen

Of het nu gaat om kleine rekenmachinesoftware met alleen de elementaire rekenkundige bewerkingen of een online bedrijfsoplossing; er zijn drie categorieën toepassingen:

Categorieën van toepassingen

Voor desktoptoepassingen moet bij het testen rekening worden gehouden met de gebruikersinterface, bedrijfslogica, database, rapporten, rollen en rechten, integriteit, bruikbaarheid, functionaliteit, prestaties, beveiliging, hardware- en softwarecompatibiliteit en gegevensstroom.

Voor webapplicaties moeten testers voldoende belang hechten aan de prestaties, belasting en beveiliging van de applicatie.

Andere belangrijke testtypen die onder het testen van webapplicaties vallen, zijn functionele testen, cross-browser testen, UAT, bètatesten, regressietesten, compatibiliteitstesten, rooktesten, verkennende testen, compatibiliteit en meertalige ondersteuningstesten en stresstesten.

Voor mobiele applicaties zijn de belangrijkste soorten tests die moeten worden uitgevoerd, UI-tests, op regels gebaseerde tests, regressie-, functionele en beveiligingstests.

AUT (te testen applicatie) is dus ofwel de desktopsoftware, ofwel een website of een mobiele app.

Applicatie testen

Methodologieën voor het testen van toepassingen

Dit is een bekend en goed besproken aspect dat er slechts 3 universeel aanvaarde testmethodes zijn:

# 1) Zwarte doos ​ Bij black-box-testen wordt de AUT gevalideerd aan de hand van zijn vereisten rekening houdend met de inputs en verwachte outputs, ongeacht hoe de inputs worden omgezet in outputs. Testers houden zich het minst bezig met interne structuur of code die de bedrijfslogica van de applicatie implementeert.

Zwarte doos

Er zijn vier primaire technieken om testcases te ontwerpen voor Black Box Testing:

  • BVA ( Grenswaardeanalyse ​
  • EP (equivalentiepartitionering)
  • Beslissingstabellen
  • Staatovergangstabellen (en diagrammen)

Black box-testen worden vaak gebruikt voor functionele, niet-functionele en regressietesten.

#twee) Witte doos ​ De primaire focus van deze methodologie is om te valideren hoe de bedrijfslogica van de applicatie wordt geïmplementeerd door de code / het programma.

Witte doos

De interne structuur van de applicatie wordt hier getest en de technieken die hiervoor beschikbaar zijn zijn:

  • Code dekking
  • Paddekking

Beide bovengenoemde technieken bevatten verschillende andere strategieën die in een ander artikel kunnen worden besproken. Sommige technieken worden besproken in de ‘ Test Case Design Technieken ’Onderwerp.

# 3) Grijze doos ​ Praktisch gezien is dit een mix van de zwarte doos en de witte doos.

Grijze doos

ik wil producten testen voor bedrijven

In deze methodiek test de tester vooral de applicatie met de Black-box-benadering. Maar voor sommige bedrijfskritische of kwetsbare modules van een applicatie wordt getest via een witte doos.

Toepassing Testhulpmiddelen

Er zijn veel Tools voor het testen van applicaties vandaag op de markt verkrijgbaar. Deze omvatten zowel betaalde als open-sourcehulpmiddelen. Bovendien zijn sommige tools doelspecifiek.

Bijvoorbeeld, UI-testen, functionele tests, databasetests, belastingtests, prestaties, beveiligingstests en linkvalidatietests, enz. Sommige tools zijn echter sterk genoeg om de mogelijkheid te bieden om verschillende belangrijke aspecten van een applicatie te testen.

Het belangrijkste concept bij ‘Application Testing’ is functioneel testen. Onze focus zal dus liggen op functionele testtools.

Hier is de lijst met enkele van de belangrijkste en meest fundamentele functies die worden geboden door bijna alle ‘Functionele testtools’.

  • Opnemen en afspelen
  • Parametriseer de waarden
  • Scripteditor
  • Uitvoeren (de test of het script, met debug- en updatemodi)
  • Verslag over Run-sessie

Verschillende leveranciers bieden een aantal specifieke functies die hun product uniek maken voor producten van andere concurrenten. Maar de vijf hierboven genoemde functies zijn de meest voorkomende en zijn te vinden in bijna alle functionele testtools.

Hieronder volgt de lijst van enkele veel gebruikte Functionele testtools ​

1) HP QTP ( Snelle test professional ​
twee) Selenium
3) IBM Rational Robot
4) Test voltooid
5) Druk om te testen
6) Telerik

Softwaretestplan (ALSTUBLIEFT)

Voor elke activiteit is altijd enige planning vereist en hetzelfde geldt voor softwaretests. Zonder een goed plan is er altijd een groot risico op afleiding tijdens het testen. Als dit risico een feit wordt, kunnen de resultaten vreselijk zijn.

5 hoofdonderdelen van een goed testplan

# 1) Reikwijdte

  • Overview of AUT
  • Functies (of gebieden) die moeten worden getest
  • Uitsluitingen (kenmerken of gebieden die niet moeten worden getest) met reden
  • Afhankelijkheden (van testactiviteiten op elkaar, indien van toepassing)

# 2) Doelstellingen: Dit gedeelte beschrijft de doelen van testactiviteiten, bijv. validatie van bugfixes, nieuwe functies toegevoegd of vernieuwing van AUT, etc.

# 3) Focus: In dit gedeelte wordt beschreven welk aspect van de toepassing wordt meegenomen in het testen, b.v. veiligheid, functionaliteit, bruikbaarheid, betrouwbaarheid, prestatie of efficiëntie, etc.

# 4) Aanpak: In dit gedeelte wordt beschreven welke testmethodologie zal worden toegepast voor welke gebieden van AUT. Bijvoorbeeld in de STP van een ERP-applicatie; het naderingsgedeelte kan de informatie bevatten dat black-box-testen de aanpak voor salarisadministratie zullen zijn. Aan de andere kant is de aanpak voor rapporten het testen van de grijze doos.

# 5) Schema: In dit gedeelte wordt beschreven wie wat, waar, wanneer en hoe gaat doen op de AUT. Het planningsgedeelte is in feite een ‘4Ws en 1H’ van de STP. Normaal gesproken wordt de planning opgesteld als een eenvoudige tabel, maar elke organisatie kan zijn eigen aangepaste indeling hebben volgens hun eigen behoeften.

Als het testplan klaar is en de applicatie in ontwikkeling is, ontwerpen en documenteren testers de testcases. In het gedeelte 'Applicatietesten - Methodologieën' hierboven heb ik de TC-ontwerptechnieken opgesomd.

Applicatie testcycli

Als de AUT klaar is om te testen, begint de praktijkfase van de testcyclus waarin testers de testcases daadwerkelijk uitvoeren op AUT. Houd er rekening mee dat hier de testcyclus wordt besproken, ongeacht testniveaus (eenheid, module, integratie, systeem- en gebruikersacceptatie) en testomgevingen (dev, QA, clientreplica, live).

# 1) Rook testen ​ Dit is de allereerste testcyclus. Het doel van rooktesten is om te verifiëren dat er geen crashes zijn in de applicatie en dat het geschikt is voor verder testen. Deze trede is breed en ondiep.

# 2) Sanity testen: Dit is de tweede testcyclus. Het doel is om te controleren of een specifieke module correct werkt en geschikt is voor volledige tests. Deze stap is smal en diep.

Pro-tip: Meestal is er niet voldoende tijd beschikbaar om de bovenstaande twee cycli afzonderlijk uit te voeren. In de praktijk wordt dus een combinatie van beide cycli toegepast.

# 3) Functioneel testen : Het correct en volwaardig testen van de applicatie wordt uitgevoerd in deze applicatietestcyclus. De primaire focus van deze activiteit is om te controleren of de bedrijfslogica van de applicatie werkt zoals verwacht.

# 4) Regressietesten ​ Dit is de laatste aanvraagcyclus. Hier worden de bugfixes en / of updates geverifieerd. Bovendien zorgt regressietesten er ook voor dat er geen storing optreedt in andere delen van AUT als gevolg van fixes en wijzigingen.

Bugs worden bij elke testcyclus geregistreerd. Er is geen duidelijke grens tussen de testcycli. In Regressie wordt bijvoorbeeld de functionaliteit ook geverifieerd en het kan ook eerst rook, gezond verstand of hun fusie vereisen.

We hebben hierboven gesproken over vier verschillende applicatietestcycli. We moeten hier ook begrijpen dat elke applicatietestcyclus bepaalde stappen omvat. Over het algemeen heeft elke testcyclus de stappen zoals weergegeven in de onderstaande afbeelding:

Applicatie testcycli

Applicatie testen - Beste praktijken

Ik denk dat er honderden artikelen op internet beschikbaar zijn. Elk artikel suggereert een ander aantal best practices, variërend van 7 tot 30 (die ik tot nu toe heb gezien). Ik heb echter maar 5 tips voor lezers.

  • Plan Naar behoren
  • Test Scherp
  • Log de bugs Duidelijk
  • Doe de regressietest Efficiënt
  • Verbeter de bovenstaande vier vaardigheden Doorlopend

Bovendien moet u de testgevallen goed prioriteren en eerst de belangrijkste bedrijfsstromen dekken.

Gevolgtrekking

Applicatietesten is een veelomvattend onderwerp en het is de primaire activiteit van bijna alle softwaretesters.

In dit artikel heb ik een overzicht gegeven van de meest fundamentele en noodzakelijke gebieden die onder applicatietesten vallen. Het omvat strategieën, verschijnselen, benaderingen, tools, technologieën en richtlijnen. Ik heb het conceptuele en praktische inzicht van applicatietesten behandeld, samen met de meest prominente aandachtsgebieden.

Aanbevolen literatuur

^