Vad är funktionell testning?
- 10 minuter
I det här avsnittet går du med i Tailspin-teamet när de definierar funktionella tester för sin pipeline. Funktionstester kontrollerar om varje funktion i programvaran gör vad den ska.
Teamet definierar först vad ett funktionellt test omfattar. De utforskar vissa typer av funktionella tester. Sedan bestämmer de sig för det första testet som ska läggas till i pipelinen.
Veckomöte
Teamet har sitt veckomöte. Andy demonstrerar utgivningspipelinen. Teamet ser ett lyckat bygge gå genom pipelinen, från en fas till en annan. Slutligen befordras webbappen till Stagingmiljö.
Amita: Jag är så nöjd med pipelinen. Det gör mitt liv mycket enklare. För det första får jag automatiskt en version distribuerad till testmiljön . Det innebär att jag inte behöver ladda ned och installera byggartefakter manuellt på mina testservrar. Det är en betydande tidssparare.
Dessutom eliminerar de enhetstester som Mara och Andy skrev alla regressionsbuggar innan jag får versionen. Det tar bort en stor källa till frustration. Jag ägnar inte tid åt att hitta och dokumentera regressionsbuggar.
Men jag är orolig för att alla mina tester fortfarande är manuella. Processen går långsamt och vi kan inte visa något för ledningen förrän jag är klar. Det är svårt eftersom testning är viktigt. Testning säkerställer att användarna får rätt upplevelse. Men trycket är på att leverera snabbare.
Andy: Jag är säker på att vi kan hjälpa dig. Vilken typ av tester tar upp det mesta av din tid?
Amita: Jag tror att UI-testerna gör det. Jag måste klicka igenom varje steg för att se till att jag får rätt resultat, och jag måste göra det för varje webbläsare vi stöder. Det är väldigt tidskrävande. Och när webbplatsen växer i komplexitet är gränssnittstestning inte praktiskt på lång sikt.
Mara: Användargränssnittstester anses vara funktionella tester.
Tim: Till skillnad från vad, icke-funktionella tester?
Mara: Exakt. Och icke-funktionella tester är något som du i synnerhet bryr dig om.
Tim: Okej, jag är förvirrad.
Vad är funktionella och icke-funktionella tester?
Mara:Funktionstester kontrollerar att varje funktion i programvaran gör vad den ska. Hur programvaran implementerar varje funktion är inte viktigt i dessa tester. Det viktiga är att programvaran fungerar korrekt. Du anger indata och kontrollerar att utdata är vad du förväntar dig. Det är så Amita testar användargränssnittet. Om hon till exempel väljer den bästa spelaren på rankningslistan förväntar hon sig att se spelarens profil.
Icke-funktionella tester kontrollerar egenskaper som prestanda och tillförlitlighet. Ett exempel på ett icke-funktionellt test är att kontrollera hur många personer som kan registrera sig samtidigt i appen. Belastningstestning är ett annat exempel på ett icke-funktionellt test. Dessa problem med prestanda och tillförlitlighet är saker du bryr dig om, Tim.
Tim: De är verkligen det. Jag måste tänka på det här ett tag. Jag kanske vill lägga till lite automatisering i pipelinen också, men jag är inte säker på vad jag vill göra. Vilka typer av automatiserade tester kan jag köra?
Mara: Nu ska vi fokusera på funktionell testning. Det är den typ av testning som Amita gör, och det låter som ett område där vi vill förbättra.
Vilka typer av funktionella tester kan jag köra?
Det finns många typer av funktionella tester. De varierar beroende på funktionaliteten du behöver testa och den tid eller ansträngning som krävs för att köra dem.
Följande avsnitt innehåller några vanliga funktionella tester.
Röktestning
Röktestning verifierar de mest grundläggande funktionerna i ditt program eller din tjänst. Dessa tester körs ofta innan mer fullständiga och uttömmande tester. Röktester bör köras snabbt.
Anta till exempel att du utvecklar en webbplats. Ditt röktest kan använda curl för att kontrollera att webbplatsen är nåbar och att hämtning av startsidan genererar en 200 (OK) HTTP-status. Om du hämtar startsidan genererar en annan statuskod, till exempel 404 (hittades inte) eller 500 (internt serverfel), vet du att webbplatsen inte fungerar. Du vet också att det inte finns någon anledning att köra andra tester. I stället diagnostiserar du felet, åtgärdar det och startar om dina tester.
Enhetstestning
I korthet verifierar enhetstestning de mest grundläggande komponenterna i ditt program eller bibliotek, till exempel en enskild funktion eller metod. Du anger en eller flera indata tillsammans med det förväntade resultatet. Testlöparen utför varje test och kontrollerar om de faktiska resultaten matchar de förväntade resultaten.
Anta till exempel att du har en funktion som utför en aritmetikåtgärd som innehåller division. Du kan ange några värden som du förväntar dig att användarna ska ange. Du kan också ange gränsvärden som 0 och -1. Om du förväntar dig att en viss indata ska generera ett fel eller ett undantag kan du kontrollera att funktionen genererar det felet.
De användargränssnittstester som du ska köra senare i den här modulen är enhetstester.
Integreringstestning
Integreringstestning verifierar att flera programvarukomponenter fungerar tillsammans för att bilda ett komplett system. Ett e-handelssystem kan till exempel innehålla en webbplats, en produktdatabas och ett betalningssystem. Du kan skriva ett integrationstest som lägger till objekt i kundvagnen och sedan köper artiklarna. Testet verifierar att webbprogrammet kan ansluta till produktdatabasen och sedan uppfylla ordern.
Du kan kombinera enhetstester och integreringstester för att skapa en strategi för skiktad testning. Du kan till exempel köra enhetstester på var och en av dina komponenter innan du kör integreringstesterna. Om alla enhetstester godkänns kan du gå vidare till integreringstesterna med större förtroende.
Regressionstest
En regression inträffar när befintligt beteende antingen ändras eller bryts när du har lagt till eller ändrat en funktion. Regressionstestning hjälper dig att avgöra om kod, konfiguration eller andra ändringar påverkar programvarans övergripande beteende.
Regressionstestning är viktigt eftersom en ändring i en komponent kan påverka beteendet för en annan komponent. Anta till exempel att du optimerar en databas för skrivprestanda. Läsprestandan för databasen, som hanteras av en annan komponent, kan oväntat sjunka. Minskningen av läsprestanda är en regression.
Du kan använda olika strategier för att testa för regression. Dessa strategier varierar vanligtvis beroende på hur många tester du kör för att verifiera att en ny funktion eller felkorrigering inte bryter befintliga funktioner. Men när du automatiserar testerna kan regressionstestning innebära att du bara kör alla enhetstester och integreringstester varje gång programvaran ändras.
Grundläggande test
Sanity-testning innebär att testa varje viktig komponent i en programvara för att verifiera att programvaran verkar fungera och kan genomgå mer noggranna tester. Du kan tänka dig att sanstester är mindre noggranna än regressionstester eller enhetstester, men sanitetstester är bredare än röktester.
Även om rimlighetskontroller kan automatiseras görs de ofta manuellt som svar på en funktionsändring eller en felkorrigering. Till exempel kan en programtestare som validerar en felkorrigering också verifiera att andra funktioner fungerar genom att ange några typiska värden. Om programvaran verkar fungera som förväntat kan den gå igenom ett mer grundligt testpass.
Testning av användargränssnitt
Användargränssnittstestning verifierar beteendet för ett programs användargränssnitt. Användargränssnittstester hjälper till att kontrollera att sekvensen eller ordningen för användarinteraktioner leder till det förväntade resultatet. De här testerna hjälper också till att kontrollera att indataenheter, till exempel tangentbordet eller musen, påverkar användargränssnittet korrekt. Du kan köra användargränssnittstester för att verifiera beteendet för ett internt Windows-, macOS- eller Linux-program. Du kan också använda användargränssnittstester för att kontrollera att användargränssnittet fungerar som förväntat i webbläsare.
Ett enhetstest eller integrationstest kan verifiera att användargränssnittet tar emot data korrekt. Men användargränssnittstestning hjälper till att kontrollera att användargränssnittet visas korrekt och att resultatet fungerar som förväntat för användaren.
Ett användargränssnittstest kan till exempel verifiera att rätt animering visas som svar på ett knappklick. Ett andra test kan verifiera att samma animering visas korrekt när fönstrets storlek ändras.
I den här modulen arbetar du med användargränssnittstester som kodas för hand. Men du kan också använda ett capture-and-replay-system för att automatiskt skapa dina användargränssnittstester.
Användbarhetstestning
Användbarhetstestning är en form av manuell testning som verifierar ett programs beteende ur användarens perspektiv. Teamet som bygger programvaran utför vanligtvis användbarhetstestningen.
Användargränssnittstestning fokuserar på om en funktion fungerar som förväntat, men användbarhetstestning hjälper till att verifiera att programvaran är intuitiv och uppfyller användarens behov. Med andra ord hjälper användbarhetstestning till att verifiera om programvaran är "användbar".
Anta till exempel att du har en webbplats som innehåller en länk till användarens profil. Ett användargränssnittstest kan kontrollera att länken finns och att den tar upp användarens profil när länken väljs. Men om människor inte enkelt kan hitta den här länken kan de bli frustrerade när de försöker komma åt sin profil.
Användaracceptanstester
Användargodkännandetestning (UAT) fokuserar, till exempel användbarhetstestning, på ett programs beteende ur användarens perspektiv. Till skillnad från användbarhetstestning utförs UAT vanligtvis av verkliga slutanvändare.
Beroende på programvaran kan slutanvändarna bli ombedda att utföra specifika uppgifter. Eller så kan de få utforska programvaran utan att följa specifika riktlinjer. För anpassad programvara sker UAT vanligtvis direkt med klienten. För mer allmän programvara kan team köra betatester . I betatester får användare från olika geografiska regioner eller användare med särskilda intressen tidig åtkomst till programvaran.
Feedback från testare kan vara direkt eller indirekt. Direkt feedback kan komma i form av verbala kommentarer. Indirekt feedback kan komma i form av mätning av testarnas kroppsspråk, ögonrörelser eller den tid det tar att utföra vissa uppgifter.
Vi har redan gått igenom vikten av att skriva tester. Men bara för att betona det, här är en kort video där Abel Wang, molnrådgivare på Microsoft, förklarar hur du kan hjälpa till att säkerställa kvalitet i din DevOps-plan.
Fråga Abel
Vad väljer teamet?
Tim: Alla dessa tester låter viktiga. Vad ska vi ta itu med först?
Andy: Vi har redan funktionella enhetstester. Vi är ännu inte redo att utföra användargodkännandetestning. Baserat på vad jag hör tycker jag att vi bör fokusera på UI-testning. Just nu är det den långsammaste delen av vår process. Amita, håller du med?
Amita: Ja, jag håller med. Vi har fortfarande lite tid kvar på det här mötet. Andy eller Mara, vill du hjälpa mig att planera ett automatiserat användargränssnittstest?
Mara: Absolut. Men låt oss få några förberedelser ur vägen. Jag vill diskutera vilket verktyg vi ska använda och hur vi ska köra testerna.
Vilka verktyg kan jag använda för att skriva användargränssnittstester?
Mara: Vad är våra alternativ när det gäller att skriva användargränssnittstester? Jag vet att det finns många. Vissa verktyg är öppen källkod. Andra erbjuder betald kommersiell support. Här är några alternativ som kommer att tänka på mig:
- Windows Application Driver (WinAppDriver): WinAppDriver hjälper dig att automatisera användargränssnittstester i Windows-appar. Dessa appar kan skrivas i Universell Windows-plattform (UWP) eller Windows Forms (WinForms). Vi behöver en lösning som fungerar i en webbläsare.
- Selen: Selenium är ett portabelt ramverk för programvarutestning med öppen källkod för webbprogram. Den körs på de flesta operativsystem och stöder alla moderna webbläsare. Du kan skriva Selenium-tester på flera programmeringsspråk, inklusive C#. Du kan faktiskt använda NuGet-paket som gör det enkelt att köra Selenium som NUnit-tester. Vi använder redan NUnit för våra enhetstester.
- SpecFlow: SpecFlow är för .NET-projekt. Den är inspirerad av ett verktyg vid namn Gurka. Både SpecFlow och Gurka stöder beteendedriven utveckling (BDD). BDD använder en parser med naturligt språk som heter Gherkin för att hjälpa både tekniska team och icke-tekniska team att definiera affärsregler och krav. Du kan kombinera antingen SpecFlow eller Gurka med Selenium för att skapa användargränssnittstester.
Andy tittar på Amita.
Andy: Jag vet att dessa alternativ är nya för dig, så har du något emot om vi väljer Selenium? Jag har viss erfarenhet av det, och det stöder språk som jag redan känner till. Selenium ger oss även automatiskt stöd för flera webbläsare.
Amita: Visst. Det är bättre om någon av oss har lite erfarenhet.
Hur gör jag för att köra funktionella tester i pipelinen?
I Azure Pipelines kör du funktionella tester precis som du kör andra processer eller tester. Fråga dig själv:
- I vilket steg kommer testerna att köras?
- På vilket system kommer testerna att köras? Kommer de att köras på agenten eller på infrastrukturen som är värd för programmet?
Låt oss gå med i teamet när de svarar på dessa frågor.
Mara: En sak som jag är glad över är att vi nu kan testa i en miljö som liknar produktion, där appen faktiskt körs. Funktionella tester som användargränssnittstester är meningsfulla i det sammanhanget. Vi kan köra dem i testfasen i vår pipeline.
Amita: Jag håller med. Vi kan underhålla samma arbetsflöde om vi kör automatiserade användargränssnittstester i samma fas som jag kör manuella tester i. Automatiserade tester sparar tid och gör att jag kan fokusera på användbarhet.
Tim: Amita testar webbplatsen från sin bärbara Windows-dator eftersom det är så de flesta av våra användare besöker webbplatsen. Men vi bygger på Linux och distribuerar sedan Azure App Service på Linux. Hur hanterar vi det?
Mara: Bra fråga. Vi har också ett val om var vi kör testerna. Vi kan köra dem:
- Om agenten: antingen en Microsoft-agent eller en agent som vi erbjuder.
- Vid testinfrastruktur: antingen lokalt eller i molnet.
Vårt befintliga teststeg innehåller ett jobb. Det jobbet distribuerar webbplatsen till App Service från en Linux-agent. Vi kan lägga till ett andra jobb som kör användargränssnittstesterna från en Windows-agent. Windows-agenten som hanteras av Microsoft är redan konfigurerad för att köra Selenium-tester.
Andy: Återigen, låt oss hålla oss till vad vi vet. Låt oss använda en Microsoft-hostad Windows-agent. Senare kan vi köra samma tester från agenter som kör macOS och Linux om vi behöver ytterligare testtäckning.
Planen
Mara: OK. Det här ska vi göra:
- Kör Selenium UI-tester från en Microsoft-värd Windows-agent.
- Låt testerna hämta webbinnehållet från appen som körs på App Service i testfasen .
- Kör testerna i alla webbläsare som vi stöder.
Andy: Jag ska arbeta med Amita på den här. Amita, vi ses i morgon bitti. Jag vill forska lite innan vi träffas.
Amita: Bra! Vi ses då.
Skapa en funktionell testplan
Vi har sett teamet bestämma hur de ska implementera sina första funktionella tester. Om ditt team precis har börjat införliva funktionella tester i sin pipeline (eller även om du redan gör det), kom ihåg att du alltid behöver en plan.
Många gånger, när någon frågar teammedlemmar om deras prestandatestningsplan, är det vanligt att de svarar med en lista över verktyg som de kommer att använda. En lista över verktyg är dock inte en plan. Du måste också ta reda på hur testmiljöerna ska konfigureras. Du måste fastställa vilka processer som ska användas och avgöra hur lyckade eller misslyckade ser ut.
Se till att planen:
- Tar hänsyn till företagets förväntningar.
- Tar hänsyn till målanvändarens förväntningar.
- Definierar de mått som du ska använda.
- Definierar de KPI:er som du ska använda.
Prestandatestning måste vara en del av planeringen redan från början. Om du använder en berättelse eller Kanban-tavla kan du överväga att ha ett område nära det där du kan planera din teststrategi. Som en del av iterationsplaneringen bör du markera luckor i teststrategin. Det är också viktigt att ta reda på hur du övervakar prestanda när programmet har distribuerats, och inte bara mäta prestanda innan det släpps.