Wat is functioneel testen?

Voltooid

In deze sectie gaat u lid worden van het Tailspin-team wanneer ze functionele tests definiëren voor hun pijplijn. Functionele tests controleren of elke functie van de software doet wat het moet.

Het team definieert eerst wat een functionele test dekt. Ze verkennen enkele soorten functionele tests. Vervolgens beslissen ze over de eerste test om toe te voegen aan hun pijplijn.

Wekelijkse vergadering

Het team heeft hun wekelijkse vergadering. Andy demonstreert de release-pijplijn. Het team kijkt naar een geslaagde build door de pijplijn, van de ene fase naar de andere. Ten slotte wordt de web-app gepromoveerd naar Fasering.

Amita: Ik ben zo blij met de pijplijn. Het maakt mijn leven veel gemakkelijker. Voor één ding krijg ik automatisch een release geïmplementeerd in de testomgeving . Dat betekent dat ik buildartefacten niet handmatig moet downloaden en installeren op mijn testservers. Dat is een aanzienlijke tijdbesparing.

Ook de eenheidstests die Mara en Andy schreef, elimineren alle regressiefouten voordat ik de release krijg. Dat verwijdert een grote bron van frustratie. Ik besteed geen tijd aan het vinden en documenteren van regressiefouten.

Maar ik maak me zorgen dat al mijn tests nog steeds handmatig zijn. Het proces is traag en we kunnen niets laten zien aan het management totdat ik klaar ben. Het is moeilijk omdat testen belangrijk is. Testen zorgt ervoor dat de gebruikers de juiste ervaring krijgen. Maar de druk staat op om sneller te leveren.

Andy: Ik weet zeker dat we je kunnen helpen. Wat voor soort tests duren de meeste tijd?

Amita: Ik denk dat de UI-tests wel doen. Ik moet elke stap doorlopen om ervoor te zorgen dat ik het juiste resultaat krijg en dat moet ik doen voor elke browser die we ondersteunen. Het is erg tijdrovend. En naarmate de website complexer wordt, is het testen van gebruikersinterfaces op lange termijn niet praktisch.

Mara: UI-tests worden beschouwd als functionele tests.

Tim: In tegenstelling tot wat, niet-functionele tests?

Mara: Precies. En niet-functionele tests zijn iets waar u in het bijzonder om geeft.

Tim: Oké, ik ben in de war.

Wat zijn functionele en niet-functionele tests?

Mara:Functionele tests controleren of elke functie van de software doet wat het moet. Hoe de software elke functie implementeert, is niet belangrijk in deze tests. Wat belangrijk is, is dat de software zich correct gedraagt. U geeft invoer op en controleert of de uitvoer is wat u verwacht. Zo test Amita de gebruikersinterface. Als ze bijvoorbeeld de beste speler op het leaderboard selecteert, verwacht ze het profiel van die speler te zien.

Niet-functionele tests controleren kenmerken zoals prestaties en betrouwbaarheid. Een voorbeeld van een niet-functionele test is controleren hoeveel personen zich tegelijk kunnen aanmelden bij de app. Belastingstests zijn een ander voorbeeld van een niet-functionele test. Deze zorgen over prestaties en betrouwbaarheid zijn zaken waar u om geeft, Tim.

Tim: Ze zijn inderdaad. Ik moet hier even over nadenken. Ik wil misschien ook wat automatisering toevoegen aan de pijplijn, maar ik weet niet zeker wat ik wil doen. Welke soorten geautomatiseerde tests kan ik uitvoeren?

Mara: Voorlopig richten we ons op functionele tests. Het is het soort testen dat Amita doet. En het klinkt als een gebied waar we willen verbeteren.

Welke soorten functionele tests kan ik uitvoeren?

Er zijn veel soorten functionele tests. Ze variëren per functionaliteit die u moet testen en de tijd of moeite die ze doorgaans nodig hebben om te worden uitgevoerd.

In de volgende secties worden enkele veelgebruikte functionele tests weergegeven.

Betrouwbaarheidstests

Betrouwbaarheidstests controleren de meest eenvoudige functionaliteit van uw toepassing of service. Deze tests worden vaak uitgevoerd voordat volledigere en uitgebreidere tests worden uitgevoerd. Betrouwbaarheidstests moeten snel worden uitgevoerd.

Stel dat u een website ontwikkelt. Uw betrouwbaarheidstest kan worden gebruikt curl om te controleren of de site bereikbaar is en dat het ophalen van de startpagina een HTTP-status van 200 (OK) oplevert. Als het ophalen van de startpagina een andere statuscode produceert, zoals 404 (Niet gevonden) of 500 (interne serverfout), weet u dat de website niet werkt. U weet ook dat er geen reden is om andere tests uit te voeren. In plaats daarvan diagnosticeert u de fout, lost u deze op en start u de tests opnieuw.

Het testen van modules

U hebt met eenheidstests gewerkt in de kwaliteitstests uitvoeren in uw build-pijplijn met behulp van de Azure Pipelines-module .

Kortom, eenheidstests controleren de meest fundamentele onderdelen van uw programma of bibliotheek, zoals een afzonderlijke functie of methode. U geeft een of meer invoergegevens op samen met de verwachte resultaten. De testloper voert elke test uit en controleert of de werkelijke resultaten overeenkomen met de verwachte resultaten.

Stel dat u een functie hebt waarmee een rekenkundige bewerking wordt uitgevoerd die deling omvat. U kunt een aantal waarden opgeven die u verwacht dat uw gebruikers invoeren. U geeft ook edge-casewaarden op, zoals 0 en -1. Als u verwacht dat een bepaalde invoer een fout of uitzondering produceert, kunt u controleren of de functie die fout produceert.

De UI-tests die u later in deze module gaat uitvoeren, zijn eenheidstests.

Integratietests

Integratietests controleren of meerdere softwareonderdelen samenwerken om een volledig systeem te vormen. Een e-commercesysteem kan bijvoorbeeld een website, een productendatabase en een betalingssysteem bevatten. U kunt een integratietest schrijven waarmee items aan het winkelwagentje worden toegevoegd en vervolgens de items worden gekocht. De test controleert of de webtoepassing verbinding kan maken met de productendatabase en vervolgens aan de order kan voldoen.

U kunt eenheidstests en integratietests combineren om een gelaagde teststrategie te maken. U kunt bijvoorbeeld eenheidstests uitvoeren op elk van uw onderdelen voordat u de integratietests uitvoert. Als alle eenheidstests slagen, kunt u met meer vertrouwen doorgaan naar de integratietests.

Het testen van regressie

Een regressie treedt op wanneer bestaand gedrag wordt gewijzigd of verbroken nadat u een functie hebt toegevoegd of gewijzigd. Met regressietests kunt u bepalen of code, configuratie of andere wijzigingen van invloed zijn op het algehele gedrag van de software.

Regressietests zijn belangrijk omdat een wijziging in het ene onderdeel van invloed kan zijn op het gedrag van een ander onderdeel. Stel dat u een database optimaliseert voor schrijfprestaties. De leesprestaties van die database, die door een ander onderdeel worden verwerkt, kunnen onverwacht afnemen. De daling in leesprestaties is een regressie.

U kunt verschillende strategieën gebruiken om te testen op regressie. Deze strategieën variëren doorgaans met het aantal tests dat u uitvoert om te controleren of een nieuwe functie of bugfix de bestaande functionaliteit niet onderbreekt. Wanneer u de tests automatiseert, kan regressietests echter alleen alle eenheidstests en integratietests uitvoeren telkens wanneer de software verandert.

Sanity testen

Sanity testen omvat het testen van elk belangrijk onderdeel van een stuk software om te controleren of de software lijkt te werken en kan grondiger worden getest. U kunt sanitytests beschouwen als minder grondig dan regressietests of eenheidstests, maar saniteitstests zijn breder dan betrouwbaarheidstests.

Hoewel sanitytests kunnen worden geautomatiseerd, wordt dit vaak handmatig gedaan als reactie op een functiewijziging of een bugfix. Een softwaretester die een foutoplossing valideert, kan bijvoorbeeld ook controleren of andere functies werken door een aantal typische waarden in te voeren. Als de software werkt zoals verwacht, kan deze een uitgebreidere testpas doorlopen.

Testen van gebruikersinterface

Het testen van de gebruikersinterface (UI) controleert het gedrag van de gebruikersinterface van een toepassing. Ui-tests helpen te controleren of de volgorde van gebruikersinteracties het verwachte resultaat oplevert. Met deze tests kunt u ook controleren of invoerapparaten, zoals het toetsenbord of de muis, van invloed zijn op de gebruikersinterface. U kunt UI-tests uitvoeren om het gedrag van een systeemeigen Windows-, macOS- of Linux-toepassing te controleren. U kunt ook UI-tests gebruiken om te controleren of de gebruikersinterface zich gedraagt zoals verwacht in webbrowsers.

Een eenheidstest of integratietest kan controleren of de gebruikersinterface gegevens correct ontvangt . Het testen van de gebruikersinterface helpt echter te controleren of de gebruikersinterface correct wordt weergegeven en of het resultaat werkt zoals verwacht voor de gebruiker.

Een UI-test kan bijvoorbeeld controleren of de juiste animatie wordt weergegeven als reactie op een klik op een knop. Een tweede test kan controleren of dezelfde animatie correct wordt weergegeven wanneer het venster wordt gewijzigd.

In deze module werkt u met UI-tests die handmatig zijn gecodeerd. Maar u kunt ook een capture-and-replay-systeem gebruiken om automatisch uw UI-tests te bouwen.

Bruikbaarheidstests

Bruikbaarheidstests zijn een vorm van handmatige tests waarmee het gedrag van een toepassing vanuit het perspectief van de gebruiker wordt gecontroleerd. Bruikbaarheidstests worden doorgaans uitgevoerd door het team dat de software bouwt.

Terwijl ui-tests zich richten op het gedrag van een functie zoals verwacht, helpt bruikbaarheidstests te controleren of de software intuïtief is en voldoet aan de behoeften van de gebruiker. Met andere woorden, bruikbaarheidstests helpen controleren of de software 'bruikbaar' is.

Stel dat u een website hebt die een koppeling naar het profiel van de gebruiker bevat. Een UI-test kan controleren of de koppeling aanwezig is en of het profiel van de gebruiker wordt weergegeven wanneer op de koppeling wordt geklikt. Als mensen deze koppeling echter niet gemakkelijk kunnen vinden, raken ze mogelijk gefrustreerd wanneer ze toegang proberen te krijgen tot hun profiel.

Gebruikersacceptatie testen

Gebruikersacceptatietests (UAT), zoals bruikbaarheidstests, richten zich op het gedrag van een toepassing vanuit het perspectief van de gebruiker. In tegenstelling tot bruikbaarheidstests wordt UAT doorgaans uitgevoerd door echte eindgebruikers.

Afhankelijk van de software kunnen eindgebruikers worden gevraagd om specifieke taken te voltooien. Of ze kunnen de software verkennen zonder specifieke richtlijnen te volgen. Voor aangepaste software gebeurt UAT doorgaans rechtstreeks met de client. Voor meer algemene software kunnen teams bètatests uitvoeren. In bètatests krijgen gebruikers van verschillende geografische regio's of gebruikers met bepaalde interesses vroeg toegang tot de software.

Feedback van testers kan direct of indirect zijn. Directe feedback kan in de vorm van mondelinge opmerkingen komen. Indirecte feedback kan worden geleverd in de vorm van het meten van de lichaamstaal, oogbewegingen of de tijd die ze nodig hebben om bepaalde taken uit te voeren.

We hebben al het belang van het schrijven van tests besproken. Maar om het te benadrukken, hier volgt een korte video waarin Abel Wang, Cloud Advocate bij Microsoft, uitlegt hoe u de kwaliteit van uw DevOps-plan kunt garanderen.

Vraag het aan Abel

Waar kiest het team voor?

Tim: Al deze tests klinken belangrijk. Wat moeten we eerst aanpakken?

Andy: We hebben al werkende eenheidstests. We zijn nog niet klaar om gebruikersacceptatietests uit te voeren. Op basis van wat ik hoor, denk ik dat we ons moeten richten op ui-tests. Het is nu het langzaamste deel van ons proces. Amita, ben je het ermee eens?

Amita: Ja, ik ben het ermee eens. We hebben nog wat tijd over in deze vergadering. Andy of Mara, wilt u mij helpen bij het plannen van een geautomatiseerde UI-test?

Mara: Absoluut. Maar laten we een paar preliminaries uit de weg halen. Ik wil bespreken welk hulpprogramma we moeten gebruiken en hoe we de tests gaan uitvoeren.

Welke hulpprogramma's kan ik gebruiken om UI-tests te schrijven?

Mara: Wat zijn onze opties als het gaat om het schrijven van UI-tests? Ik weet dat er veel zijn. Sommige hulpprogramma's zijn open source. Anderen bieden betaalde commerciële ondersteuning. Hier volgen enkele opties waarmee u rekening moet houden:

• Windows-toepassingsstuurprogramma (WinAppDriver): WinAppDriver helpt u bij het automatiseren van UI-tests op Windows-apps. Deze apps kunnen worden geschreven in Universeel Windows-platform (UWP) of Windows Forms (WinForms). We hebben een oplossing nodig die in een browser werkt.
• Selenium: Selenium is een draagbaar opensource-framework voor softwaretests voor webtoepassingen. Het wordt uitgevoerd op de meeste besturingssystemen en ondersteunt alle moderne browsers. U kunt Selenium-tests schrijven in verschillende programmeertalen, waaronder C#. In feite kunt u NuGet-pakketten gebruiken waarmee u Selenium eenvoudig kunt uitvoeren als eenheidstests. We gebruiken al NUnit voor onze eenheidstests.
• SpecFlow: SpecFlow is bedoeld voor .NET-projecten. Het is geïnspireerd op een tool genaamd Komkommer. Zowel SpecFlow als Komkommer ondersteunen gedraggestuurde ontwikkeling (BDD). BDD maakt gebruik van een parser in natuurlijke taal genaamd Listenkin om zowel technische teams als niet-technische teams te helpen bedrijfsregels en vereisten te definiëren. U kunt SpecFlow of Komkommer combineren met Selenium om UI-tests te bouwen.

Andy kijkt naar Amita.

Andy: Ik weet dat deze opties nieuw voor je zijn, dus vind je het erg als we Selenium kiezen? Ik heb er ervaring mee en het ondersteunt talen die ik al ken. Selenium biedt ons ook automatische ondersteuning voor meerdere browsers.

Amita: Zeker. Het is beter als een van ons wat ervaring heeft.

Hoe kan ik functionele tests uitvoeren in de pijplijn?

In Azure Pipelines voert u functionele tests uit, net zoals u een ander proces of een andere test uitvoert. Stel uzelf de volgende vragen:

• In welke fase worden de tests uitgevoerd?
• Op welk systeem worden de tests uitgevoerd? Worden ze uitgevoerd op de agent of in de infrastructuur die als host fungeert voor de toepassing?

We nemen deel aan het team terwijl ze deze vragen beantwoorden.

Mara: Een ding waar ik trots op ben, is dat we nu kunnen testen in een omgeving die lijkt op productie, waar de app daadwerkelijk wordt uitgevoerd. Functionele tests zoals UI-tests zijn logisch in die context. We kunnen ze uitvoeren in de testfase van onze pijplijn.

Amita: Ik ben het ermee eens. We kunnen dezelfde werkstroom onderhouden als we geautomatiseerde UI-tests uitvoeren in dezelfde fase waarin ik handmatige tests uitvoer. Geautomatiseerde tests besparen ons tijd en stellen mij in staat om me te concentreren op bruikbaarheid.

Tim: Amita test de website van haar Windows-laptop omdat de meeste van onze gebruikers de site bezoeken. Maar we bouwen voort op Linux en implementeren vervolgens Azure-app Service op Linux. Hoe kunnen we dat afhandelen?

Mara: Geweldige vraag. We hebben ook een keuze over waar we de tests uitvoeren. We kunnen ze uitvoeren:

• Op de agent: een Microsoft-agent of een agent die we hosten
• On-testinfrastructuur: on-premises of in de cloud

Onze bestaande testfase bevat één job. Met deze taak wordt de website vanuit een Linux-agent geïmplementeerd in App Service. We kunnen een tweede taak toevoegen waarmee de UI-tests van een Windows-agent worden uitgevoerd. De Windows-agent die wordt gehost door Microsoft is al ingesteld om Selenium-tests uit te voeren.

Andy: Nogmaals, laten we ons houden aan wat we weten. Laten we een Door Microsoft gehoste Windows-agent gebruiken. Later kunnen we dezelfde tests uitvoeren vanaf agents met macOS en Linux als we extra testdekking nodig hebben.

Het plan

Mara: OK. Hier ziet u wat we gaan doen:

• Selenium UI-tests uitvoeren vanuit een Door Microsoft gehoste Windows-agent
• Laat de tests de webinhoud ophalen uit de app die wordt uitgevoerd in App Service, in de testfase
• Voer de tests uit op alle browsers die we ondersteunen

Andy: Ik werk met Amita. Amita, laten we morgenochtend vergaderen. Ik wil graag wat onderzoek doen voordat we elkaar ontmoeten.

Amita: Geweldig! Zie je dan.

Een functioneel testplan maken

We hebben gezien dat het team besluit hoe ze hun eerste functionele tests gaan implementeren. Als uw team net begint met het opnemen van functionele tests in hun pijplijn (of zelfs als u dat al doet), moet u er rekening mee houden dat u altijd een plan nodig hebt.

Vaak, wanneer iemand teamleden vraagt over hun prestatietestplan, is het gebruikelijk dat ze reageren met een lijst met hulpprogramma's die ze gaan gebruiken. Een lijst met hulpprogramma's is echter geen plan. U moet ook instellen hoe de testomgevingen worden geconfigureerd. U moet de processen bepalen die moeten worden gebruikt en bepalen hoe succes of mislukking eruitziet.

Zorg ervoor dat uw plan:

• Houdt rekening met de verwachtingen van het bedrijf.
• Houdt rekening met de verwachtingen van de doelgebruikers.
• Definieert de metrische gegevens die u gaat gebruiken.
• Definieert de KPI's die u gaat gebruiken.

Prestatietests moeten direct vanaf het begin deel uitmaken van uw planning. Als u een verhaal of Kanban-bord gebruikt, kunt u overwegen een gebied in de buurt te hebben waar u uw teststrategie kunt plannen. Als onderdeel van de iteratieplanning moeten hiaten in de teststrategie worden gemarkeerd. Het is ook belangrijk om te bepalen hoe u de prestaties bewaakt zodra de toepassing is geïmplementeerd en niet alleen de prestaties meet voordat deze wordt uitgebracht.