Vad är testautomatisering? En enkel och tydlig introduktion
Det finns två typer av testning i mjukvaruvärlden – manuell och automatiserad. Vissa typer av manuell testning, t.ex. upptäcktstestning och användbarhetstestning, är ovärderliga. Du kan göra andra typer av testning – som regressionstestning och funktionstestning – manuellt, men det är en ganska slösaktig praxis för människor att göra samma sak om och om igen. Det är denna typ av repetitiva tester som lämpar sig för testautomatisering.
Testautomatisering är en metod för att köra tester automatiskt, hantera testdata och använda resultaten för att förbättra programvarukvaliteten. Det är i första hand en kvalitetssäkringsåtgärd, men dess aktiviteter innebär att hela mjukvaruproduktionsteamet engagerar sig. Från affärsanalytiker till utvecklare och DevOps-ingenjörer, för att få ut det mesta av testautomatisering krävs att alla deltar.
Detta inlägg kommer att ge dig en förståelse på hög nivå för vad testautomatisering handlar om. Det finns alla typer av tester, men alla bör inte automatiseras; låt oss därför börja med allmänna kriterier för testautomatisering.
Kriterier för automatisering
Ett test måste uppfylla vissa kriterier för att kunna automatiseras – annars kan det sluta med att det kostar mer än det sparar. Ett viktigt mål med automatisering är trots allt att spara tid, arbete och pengar. Här är några allmänna kriterier för testautomatisering. Det här är utgångspunkter, men tänk på det. Dina kriterier kan skilja sig åt beroende på dina omständigheter.
Upprepningsbart
Testet måste kunna upprepas. Det finns ingen mening med att automatisera ett test som bara kan köras en gång. Ett upprepningsbart test har följande tre steg:
- Sätt upp testet, inklusive data och miljö.
- Uppför funktionen och mät resultatet.
- Rensa upp data och miljö.
I det första steget vill vi kunna sätta miljön i ett konsekvent tillstånd. Med andra ord, om vi har ett test för att försöka lägga till en befintlig användare måste vi se till att användaren finns innan vi utför testet. När testet är klart ska miljön återgå till bastillståndet.
Determinant
När en funktion är determinant innebär det att resultatet är detsamma varje gång den körs med samma indata. Samma sak gäller för tester som kan automatiseras. Säg till exempel att vi vill testa en additionsfunktion. Vi vet att 1 + 1 = 2 och att 394,19 + 5,81 = 400,00. Addition är en bestämningsfunktion.
Mjukvara, å andra sidan, kan använda ett så stort antal variabla indata att det är svårt att få samma resultat över tiden. Vissa variabler kan till och med vara slumpmässiga, vilket kan göra det svårt att bestämma det specifika resultatet. Mjukvarudesign kan kompensera för detta genom att tillåta testinmatningar genom en testharness.
Andra funktioner i en applikation kan vara additiva; till exempel skulle skapandet av en ny användare öka antalet användare. När vi lägger till en användare vet vi åtminstone att antalet användare bara bör öka med en. Att köra tester parallellt kan dock ge oväntade resultat. Isolering kan förhindra denna typ av falska positiva resultat.
Unopinionated
Det går inte att automatisera åsiktsfrågor. Det är här som användbarhetstester, betatester och så vidare verkligen briljerar. Användarfeedback är viktigt, men det kan inte automatiseras … tyvärr!
Typer av automatiserade tester
Det finns så många typer av tester, varav många kan automatiseras, att vi inte riktigt kan få med alla i ett inlägg. Men här finns tillräckligt många för att ge dig en bra utgångspunkt.
Kodanalys
Det finns faktiskt många olika typer av kodanalysverktyg, inklusive statisk analys och dynamisk analys. Vissa av dessa tester letar efter säkerhetsbrister, andra kontrollerar stil och form. Dessa tester körs när en utvecklare kontrollerar in kod. Förutom att konfigurera regler och hålla verktygen uppdaterade finns det inte mycket testskrivande att göra med dessa automatiserade tester.
Enhetstester
Du kan också automatisera en enhetstestsvit. Enhetstester är utformade för att testa en enskild funktion, eller enhet, av en operation i isolering. De körs vanligtvis på en byggserver. Dessa tester är inte beroende av databaser, externa API:er eller fillagring. De måste vara snabba och är utformade för att endast testa koden, inte de externa beroendena.
Integrationstester
Integrationstester är ett annat slags djur när det gäller automatisering. Eftersom ett integrationstest – ibland kallat end-to-end-test – måste interagera med externa beroenden är de mer komplicerade att sätta upp. Ofta är det bäst att skapa falska externa resurser, särskilt när det gäller resurser som ligger utanför din kontroll.
Om du till exempel har en logistikapplikation som är beroende av en webbtjänst från en leverantör kan ditt test misslyckas oväntat om leverantörens tjänst är nere. Betyder det att din app är trasig? Kanske, men du bör ha tillräcklig kontroll över hela testmiljön för att skapa varje scenario explicit. Var aldrig beroende av en extern faktor för att avgöra resultatet av ditt testscenario.
Automatiserade acceptanstester
Det finns flera metoder idag som använder automatiserade acceptanstester (AAT), men de gör i princip samma sak. Beteendedriven utveckling (BDD) och automatiserad acceptanstestdriven utveckling (AATDD) liknar varandra. De följer båda samma praxis att skapa acceptanstestet innan funktionen utvecklas.
I slutändan körs det automatiserade acceptanstestet för att avgöra om funktionen levererar det som överenskommits. Därför är det viktigt att utvecklare, verksamheten och QA skriver dessa tester tillsammans. De fungerar som regressionstester i framtiden och säkerställer att funktionen håller vad som förväntas.
Regressionstester
Om inte AAT:er finns på plats måste du skriva regressionstester i efterhand. Även om båda är former av funktionella tester är det väldigt olika hur de skrivs, när de skrivs och av vem de skrivs. Liksom AAT:er kan de styras via ett API av kod eller ett användargränssnitt. Det finns verktyg för att skriva dessa tester med hjälp av ett GUI.
Prestandatester
Det finns många olika typer av prestandatester, men alla testar någon aspekt av en applikations prestanda. Klarar den av extrema påfrestningar? Testar vi systemet för hög värme? Är det enkel svarstid under belastning vi är ute efter? Vad sägs om skalbarhet?
I vissa fall kräver dessa tester att man emulerar ett stort antal användare. I det fallet är det viktigt att ha en miljö som klarar av att utföra en sådan bedrift. Molnresurser finns tillgängliga för att hjälpa till med den här typen av tester, men det är också möjligt att använda resurser på plats.
Rökprov
Vad är ett rökprov? Det är ett grundläggande test som vanligtvis utförs efter en driftsättning eller ett underhållsfönster. Syftet med ett röktest är att se till att alla tjänster och beroenden är igång och fungerar. Ett röktest är inte avsett att vara ett fullständigt funktionstest. Det kan köras som en del av en automatiserad driftsättning eller utlösas genom ett manuellt steg.
Allmän process för testautomatisering
Nu när vi har sett kriterier för automatisering och tillräckligt många typer av automatiserade tester för att få en känsla för saker och ting, kommer här den allmänna processen för testautomatisering. Det finns tre huvudsteg för testautomatisering: förbereda, vidta åtgärder, rapportera resultat.
Förbereda
Först måste vi förbereda tillståndet, testdata och den miljö där testerna äger rum. Som vi har sett kräver de flesta tester att miljön är i ett visst tillstånd innan en åtgärd äger rum. I ett typiskt scenario kräver detta en del inställningar. Antingen måste data manipuleras eller så måste programmet sättas i ett visst tillstånd eller både och!
Att vidta åtgärder
När tillståndet och/eller miljön är i det fördefinierade tillståndet är det dags att vidta åtgärder! Testdrivrutinen kommer att köra testet, antingen genom att anropa en applikations API eller användargränssnitt eller genom att köra koden direkt. Testföraren är ansvarig för att ”köra” testerna, men testhanteringssystemet tar på sig ansvaret för att samordna allt, inklusive att rapportera resultat.
Rapportera resultat
Ett system för testautomatisering kommer att registrera och rapportera resultat. Dessa resultat kan komma i ett antal olika format och kan till och med skapa problembiljetter eller buggar i ett arbetsspårningssystem. Det grundläggande resultatet är dock godkänt eller underkänt. Vanligtvis finns det en grön eller röd indikator för varje testscenario för att indikera godkänt eller misslyckat.
Ibland är testerna ofullständiga eller körs inte av någon anledning. När detta inträffar har automationssystemet en fullständig logg över resultatet så att utvecklarna kan granska det. Denna logg hjälper dem att spåra problemet. I idealfallet kan de spela upp scenariot igen när de har satt en lösning på plats.
Slutsatsen
Slutsatsen är denna: testautomatisering hjälper till att förbättra kvaliteten med snabbhet. Men alla tester kan inte automatiseras. Det är definitivt en investering inblandad. Med så många typer av tester är det viktigt att du får rätt blandning. Testpyramiden är en enkel tumregel för att hjälpa till att göra detta rätt. Den säger att de flesta tester bör vara enhetstester, följt av servicetester och sedan UI-tester.
Ett system för testautomatisering samordnar testfrågor, inklusive hantering av testdata, körning av tester och spårning av resultat. Testautomatisering är nästa steg för team som blir överväldigade av bördan att upprepa samma manuella tester som borde automatiseras.
Author bio: Det här inlägget skrevs av Phil Vuollet. Phil använder programvara för att automatisera processer för att förbättra effektiviteten och repeterbarheten. Han skriver om ämnen som är relevanta för teknik och företag, håller ibland föredrag om samma ämnen och är en familjefar som tycker om att spela fotboll och brädspel med sina barn.