Ledarskap inom test: Verktyg för testkörning

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Create Free Account

Have an account? Log In

Vad du får och inte får med verktyg för testkörning

Oavsett om du testar Windows-program, webbplatser eller mobila enheter är principerna för testautomatisering samt fördelarna och fallgroparna likartade. Det du får med verktyg är:

• En outtröttlig, förmodat felfri robot som kör vilka skriptade tester du vill, på begäran och så ofta du önskar.
• En exakt jämförelse mellan testernas utdata och/eller resultat och förberedda förväntade resultat, på den detaljnivå som du är villig att programmera in i verktyget.

Det du inte får är:

• Flexibilitet och smidiga reaktioner på avvikelser, fel eller tvivelaktigt beteende.
• En mänsklig testares blick och tankeförmåga, som kan fatta beslut om att utforska, ifrågasätta, experimentera och utmana beteendet hos systemet som testas.
• Tester utan kostnad. Du måste fortfarande utforma tester, förbereda testdata och förväntade resultat, till exempel.
• Även om verktyg för testkörning erbjuder en rad funktioner saknar de ofta avancerade funktioner för datalagring. För en mer heltäckande lösning kan du utforska den bästa tillgängliga programvaran för databashantering.

Låt oss undersöka betydelsen av dessa fördelar och problem.

Om du är en någorlunda kompetent programmerare är det enkelt att implementera procedurtester som utförs av människor som automatiserade procedurer i verktygets skriptspråk, så att verktyget kan köra dem korrekt.

Så länge miljön och de data som används av testprogrammet är konsekventa kan du förvänta dig att testerna körs tillförlitligt om och om igen. Detta är det uppenbara löftet med automatiserad testkörning.

Men automatiserade tester simulerar inte korrekt vad (bra) testare gör när de testar.

Ett test som körs av ett verktyg är INTE likvärdigt med samma test som körs av en människa.

Ett test kan, om det är skriptat, tala om för testaren vad som ska göras. Men testare kan se bortom den enkla jämförelsen mellan ett förväntat resultat och det resultat som visas på en skärm.

Testare måste navigera till testets plats och vara uppmärksamma på avvikande beteende – kommandonas svar, svarstidens längd, skärmens utseende och beteendet hos objekt som påverkas av programmets förändrade tillstånd.

Den mänskliga testaren kan, när en avvikelse upptäcks, pausa, gå tillbaka genom stegen eller undersöka programmet eller data djupare innan hen drar slutsatsen att programmet fungerar korrekt (eller inte) och avgör om det skriptade testet ska fortsätta, om testets data och skript ska justeras eller om testet ska fortsätta enligt plan.

Människor är flexibla, medan verktyg bara gör exakt det som du programmerar dem att göra. I en skärmbaserad transaktion matar verktyget in data, klickar på en knapp och kontrollerar om ett meddelande eller ett visat resultat visas – och det är allt. Med mänskliga testare får du så mycket mer som vi tar för givet. 

I princip är det möjligt att programmera ett verktyg så att det utför alla kontroller som en människa gör instinktivt – men du måste skriva mycket kod och lägga tid på att felsöka dina tester. Även då får du inte människans förmåga att avgöra vad som ska göras härnäst – att pausa, fortsätta, ändra testet under pågående körning eller undersöka en avvikelse mer ingående.

Ingenstans blir verktygens oflexibilitet tydligare än när de reagerar på att skriptet inte längre är synkroniserat med systemet under test. Kanske stämmer ett förväntat resultat inte, systemet kraschar eller användargränssnittets beteende (till exempel en ändrad ordning på fält eller ett nytt fält) skiljer sig från vad skriptet förväntar sig. Vad gör verktyget? Det försöker fortsätta, och en ström av skriptfel eller krascher följer. 

Ja, du kan och bör ha händelsehanterare för oplanerade händelser i skriptet för att fånga testfel. Förlust av synkronisering, skillnader mellan systemets tillstånd och testdata, ändringar i fältens ordning, nya fält eller borttagna fält är sådant som testaren kan känna igen och hantera utan att testningen behöver avstanna helt. Verktyg kan inte göra detta utan en stor programmeringsinsats från din sida.

Det finns också nackdelar med att använda människor för att följa skriptbaserade tester. Testare kan bli besatta av att följa skriptet och glömma att använda sina observationsförmågor. De kan missa uppenbara avvikelser eftersom de koncentrerar sig på att följa skriptet. Detta mindre optimala tillvägagångssätt är exakt vad vi får från automatiserad testkörning.

Blind följsamhet till testskript är en dålig idé för mänskliga testare, men det är det bästa vi kan åstadkomma med testautomatisering.

I denna jämförelse mellan testare som följer skript och verktyg som kör tester har vi inte beaktat vad explorativa testare gör. Det explorativa arbetssättet ger testare friheten att undersöka och testa var och hur de vill. 

Det är tydligt att verktyg inte kan simulera denna aktivitet. Ännu viktigare är att verktyg inte kan avgränsa, prioritera och modellera ett systems funktionalitet och risker samt utforma tester därefter.

Testanalys och testdesign krävs oavsett om ett test körs av en människa eller ett verktyg.

Det finns ytterligare begränsningar för vad verktyg för testkörning kan göra:

• Verktyg för testkörning gör exakt det som du programmerar dem att göra – varken mer eller mindre
• Verktyg utför vanligtvis inte byggen och konfiguration av miljöer och applikationer eller inläsning av testdata
• Verktyg utformar inte testfall eller skript och förbereder inte testdata och förväntade resultat
• Verktyg kan inte fatta genomtänkta beslut när oväntade händelser inträffar.

För att optimera processerna för testkörning kan en integrering med robust programvara för testhantering erbjuda smidigare arbetsflöden och förbättrad rapportering.

Testautomatisering för grafiska användargränssnitt (GUI)

Det har gått ungefär tjugofem år sedan verktyg för testautomatisering av grafiska användargränssnitt kom ut på marknaden, men antalet misslyckade implementeringar av GUI-testverktyg är fortfarande högt. Detta beror främst på att förväntningarna på automatisering sätts för högt – och verktyg som används utan disciplin kommer aldrig att uppfylla dem.

Verktyg för testautomatisering av grafiska användargränssnitt har rykte om sig att vara enkla att använda som produkter, men svåra att hantera när applikationerna under test (och därmed testskripten) behöver ändras. Dessa verktyg är mycket känsliga för förändringar i användargränssnittet. Ändringar av skärmobjektens placering, ordning och storlek samt tillägg eller borttagning av skärmobjekt kan alla påverka skripten. Även mer tekniska ändringar, som att byta namn på skärmobjekt eller ändra ”osynliga” inbäddade GUI-bibliotek, orsakar problem.

Testautomatisering av grafiska användargränssnitt fungerar bäst när det finns disciplin kring:

• Utvecklingsprocessen samt ändringar och releaser hanteras noggrant. Till exempel analyseras ändringars påverkan och testare informeras om dem. 
• Metoden för utveckling av testskript. Erfarna ingenjörer inom testautomatisering använder systematiska namnkonventioner, katalogstrukturer, modulära och återanvändbara komponenter, defensiva programmeringstekniker och så vidare.

Skriptning för testautomatisering är en uppgift som kräver mer än grundläggande programmeringskunskaper och framför allt erfarenhet av automatisering och det verktyg som används. När tester automatiseras i stor skala behövs även designkunskaper. 

Oavsett hur leverantörer beskriver verktygen – ”utan skript”, ”kan användas av icke-programmerare” eller ”användare kan också automatisera” – behöver du fortfarande en programmerares tankesätt, designkunskaper och ett systematiskt arbetssätt.

API- och tjänstetestautomatisering

När det finns komponenter eller funktionalitet som distribueras som tjänster och anropas av tunna klienter eller mobilklienter utförs testningen med hjälp av ett API eller via tjänsteanrop. Detta testläge genomförs antingen med anpassad kod som skrivits av utvecklare eller med särskilda verktyg för API- eller tjänstetestning. Oavsett vilket är det vanliga arbetssättet att automatisera testningen på ett eller annat sätt.

Eftersom API:et ligger ”närmare” koden som ska testas kan testerna fokusera mycket mer på den funktionalitet som ska testas. Komplexiteten i att navigera genom användargränssnittet och att testa själva användargränssnittet kan naturligtvis kringgås. Av denna anledning är den allmänna regeln:

Om funktionaliteten som testas (på kod- eller komponentnivå) kan testas genom ett funktionsanrop, ett API-anrop eller ett tjänsteanrop blir automatisering enklare – och rekommenderas.

Det finns tydliga fördelar med att testa via API:et.

• Även om du måste använda eller skriva kod blir själva testerna mycket enklare att tillämpa (det finns inget användargränssnitt att ta hänsyn till).
• När ett API-anrop har skriptats handlar det bara om att sammanställa det intervall av testfall som du vill tillämpa. Det finns ingen begränsning för hur många tester du kan tillämpa.
• API-baserade tester körs vanligtvis mycket snabbare, vilket gör denna teststil väl lämpad för kontinuerlig leverans där distributionspipen är starkt automatiserad och behöver reagera snabbt.

”Pyramiden för testautomatisering” (en Google-sökning visar hundratals exempel på grafiken) har nästan universellt anammats för att presentera rekommendationen att insatserna inom testautomatisering bör fokusera mer på utvecklar- eller API-tester än på tester via det grafiska användargränssnittet.

• Använd tester av användargränssnittet när användarflödet måste genomföras, men i liten omfattning eftersom testerna är kostsamma och kan ta lång tid att köra.
• Använd API- eller tjänsteanrop när funktionaliteten som testas kan isoleras och när snabbhet och enkel automatisering är avgörande.

Regressionstestning

Det klassiska användningsområdet för automatiserade verktyg är att köra regressionstester. Dessa tester körs en gång och anses vara korrekta representationer av det förväntade beteendet. När antingen programkoden som testas, tillhörande återanvändbara bibliotek eller testmiljön ändras ger dessa tester en viss trygghet i att den nödvändiga funktionaliteten inte har påverkats negativt av ändringen.

Du kan föreställa dig de automatiserade testerna som en form som systemet som testas passar in i. Testerna bör naturligtvis klara alla kontroller som tidigare genomfördes. Genom att köra dem igen försöker du visa funktionell likvärdighet mellan den nya programvaruversionen och den föregående. Det finns några enkla principer som du behöver följa:

• För det första måste de tester och kontroller som genomförs väljas så att de ger dig förtroende för att oönskade beteendeförändringar inte förekommer. Dessa tester fungerar som en ”snubbeltråd” för att upptäcka skillnader i beteende.
• När buggar rättas eller andra programvaruändringar görs kan det finnas beteenden som ändras (på ett korrekt sätt) men som, när de påträffas av dina tester, gör att en kontroll misslyckas. Antingen måste du ändra dina tester i förväg eller låta dem misslyckas och korrigera dem efteråt. Ibland går det snabbare att ta bort misslyckade tester helt och skapa nya tester från grunden som ersättning. Oavsett vilket måste dessa ändrade tester sedan köras till slut och godkännas.
• Om systemet som testas inte är stabilt, har många buggar eller genomgår omfattande förändringar mellan versioner kanske det inte är ekonomiskt hållbart att underhålla en uppsättning automatiserade tester. Även om systemets funktionalitet inte förändras är det möjligt att användargränssnittet fortfarande utvecklas – ett instabilt användargränssnitt gör även automatiseringen svårare att underhålla. Kostnaden för att utreda testfel och underhålla testerna kan överväga deras nytta. Det kan vara klokt att testa systemets mindre stabila delar manuellt tills de stabiliseras.

Att testa via användargränssnittet kan ibland vara omständligt, dyrt och ta lång tid att genomföra. Innan du påbörjar automatisering av tester av det grafiska användargränssnittet, eller ens automatiserar ett enda skript, är det klokt att överväga om det skulle vara enklare, snabbare och mer ekonomiskt att testa den centrala funktionaliteten med hjälp av ett API.

Det klassiska användningsområdet för automatiserade verktyg är att köra regressionstester. För att säkerställa att du använder de mest effektiva verktygen för detta kan du se vår lista över de bästa verktygen för programvarutestning

Ramverk för testautomatisering

Testningsramverk är en viktig del av alla framgångsrika automatiserade testprocesser. Se dem som en uppsättning riktlinjer för att skapa och utforma testfall. Genom att använda dem kan du öka testteamets snabbhet och effektivitet, förbättra testernas noggrannhet, minska riskerna och sänka kostnaderna för testunderhåll. Nu ska vi titta närmare på två av dessa.

När man diskuterar ramverk för testautomatisering är det viktigt att ta hänsyn till vilken roll verktyg för QA-automatisering spelar för att utforma en effektiv teststrategi.

More Articles

• Så integrerar du DevOps-verktyg för AWS
• 9 bästa konferenserna om digital transformation att delta i 2026–2027
• Så använder du DevOps-mätvärden för att skala upp ditt företag

Ramverk för enhetstestning

Ramverk för enhetstestning har funnits i flera år och används i stor utsträckning av programmerare för att testa sin kod. Utvecklartester tenderar att vara ganska lokaliserade – de testar trots allt vanligtvis en enda komponent, medan gränssnitten mot andra komponenter eller databaser simuleras eller ersätts med stubbar. Även om enhetstester behöver steg för konfigurering och nedmontering före och efter att testerna körs, är dessa uppgifter vanligtvis begränsade till att köra tester av en enda komponent. Separata testsviter finns för varje komponent.

Enhetstester som skapas av utvecklare är vanligtvis versionshanterade och administreras parallellt med komponentkoden. Vanligtvis tar verktyg för kontinuerlig integrering källkoden och alla enhetstester och kör dem efter varje incheckning av ny kod och/eller nya tester. Alla utvecklare ser resultatet av dessa tester, så ett testfel i CI blir mycket synligt. Att åtgärda felande tester och kod har hög prioritet i team som använder CI på detta sätt, så att den senaste versionen av systemet alltid klarar alla CI-tester.

Ramverk för automatisering av integrations- och systemtester

Under de senaste åren har verktyg för GUI-tester integrerats med CI-verktyg med hjälp av virtualiserade testenheter, testmiljöer och körning via kommandoradsgränssnitt. Många organisationer har lyckats integrera körningen av enhets-, API- och GUI-tester helt genom CI-tjänster.

Men många testteam driver fortfarande sina egna testmiljöer separat från utvecklings- eller CI-tjänster. Dessa team tenderar att bygga sina egna ramverk för testautomatisering eftersom CI-verktyg är alltför utvecklarorienterade eller eftersom proprietära verktyg är otillräckliga.

GUI-tester implementerar ofta tester från början till slut eller användarresor med olika applikationer, maskinvaruenheter och miljöer. Dessa tester måste sömlöst konfigurera integrerade testmiljöer och förberedda testdata på olika plattformar, vilket kräver privilegierade och komplexa procedurer samt varierande tekniska miljöer för att kunna köras. Den överväldigande majoriteten av team som använder GUI-testautomatisering bygger sina egna unika men effektiva automationsramverk.

Ramverk för GUI-automatisering varierar i komplexitet, från verktyg som liknar enhetstestverktyg till komplexa och heltäckande funktioner som krävs för att hantera miljöer, applikationsbyggen, stora mängder testdata, meddelanden och synkronisering mellan plattformar och miljöer samt meddelanden och aviseringar till teammedlemmar.

Vissa proprietära verktyg levereras med verktyg eller testplattformar för att hantera, köra och rapportera från sviter av automatiserade tester. Dessa har varierande värde, så många organisationer skriver sina egna ramverk för testautomatisering för att utöka deras funktionalitet. Under de senaste åren har automationsramverkens omfattning vuxit, och det finns inte längre någon enkel eller entydig definition. Därför ska vi nu titta på vad ramverk för testautomatisering kan göra för programvaruteam.

Ett ramverk för testautomatisering utökar funktionaliteten hos motorer för testkörning.

Konfiguration av testsuiter

Ramverket integrerar automatiserade tester i meningsfulla samlingar eller kluster av tester. Dessa samlingar kan konfigureras så att tester kan köras i en hierarki av sekvenser, grupper eller godtyckliga urval. Verktygen kan innehålla funktioner för datadrivna tester med hjälp av förberedda tabeller med testdata. Detta är den enklaste typen av ramverk – populära verktyg erbjuder vanligtvis någon form av konfiguration av testsuiter.

Förberedelse och nedmontering

Ramverket hanterar alla aktiviteter för förberedelse och nedmontering för ett enskilt test, en samling eller en hel testsvit. Förberedelser kan innebära att testmiljöer skapas från grunden, fullständig konfiguration samt att testdatabaser och andra datakällor förladdas från grunden. Nedmontering kan innebära rensning av testdata eller återställning eller borttagning av delar av eller fullständiga miljöer. Ramverket kan integreras med orkestreringsverktyg för pipelines och stå under deras kontroll.

Hantering av undantag

Ett fel i ett test – oavsett om det gäller systemet som testas eller en förlust av synkronisering – kan hanteras konsekvent genom att händelsen rapporteras och de återstående testerna i samlingen vanligtvis tillåts fortsätta köras. Ramverket kan programmeras för att hantera fel vid testkontroller, förlust av synkronisering, tidsgränser för körning och andra utvalda testresultat – vart och ett med anpassade procedurer.

Loggning och meddelanden

Ramverket loggar testkörning och körningsstatus konsekvent för alla testsamlingar. Ramverket utlöser antingen rapporter från de verktyg som kör testerna eller tillhandahåller en konsekvent rapportjournal över all aktivitet för testförberedelse, körning och nedmontering. Ramverket kan samverka med ChatOps-botar för att informera teamet om undantag och låta teammedlemmar pausa, stoppa, upprepa eller starta om testsuiter.

Testabstraktion med domänspecifikt språk

Två tydliga typer av ramverk som abstraherar testkörningskod till modeller eller text som är läsbar för människor eller icke-teknisk text har vuxit fram på marknaden:

• Nyckelordsdrivna ramverk gör det möjligt att definiera tester med hjälp av nyckelord. Anrop till funktionerna i körningsmotorn implementeras som kommandon på engelska med platshållare för parametrar eller data. Användardefinierade, återanvändbara moduler kan definieras och anropas med textkommandon på samma sätt. Det finns ramverk för alla slags gränssnitt, inklusive GUI, tjänster, API:er, kommandoradstolkar och så vidare. Skript kan utöva funktionalitet över olika operativsystem och enhetsplattformar.
• Ramverk för beteendedriven utveckling (BDD) gör det möjligt att fånga berättelser och scenarier (exempel) som beskriver funktioners beteende med hjälp av ett domänspecifikt språk (DSL). Det mest populära språket är det så kallade Gherkin, som använder språkstrukturen ”givet … när … då …” för att fånga exempel. Givet/när/då representerar i praktiken förvillkor, steg och eftervillkor för testfall. BDD-verktyg omvandlar texten med givet/när/då till ”steganrop” i ett programmeringsspråk. Utvecklaren (eller testaren) måste implementera ”testfixturerna” eller koden som gör anrop till en motor för testkörning. På så sätt kan kraven på ett krav (berättelsen) kopplas direkt till texten i körningskoden.

Modellbaserade ramverk

I det här fallet gör verktygen det möjligt att skapa en modell av systemet som testas. Detta kan härledas automatiskt från en webbsida där verktyget skannar HTML-koden, identifierar formulär och fält och bygger en modell från vilken vägar genom formulären antingen kan genereras automatiskt eller väljas av testaren. Objektkartor för mobilappar eller andra smarta enheter kan också byggas manuellt. Med hjälp av vägarna genom objektkartan görs anrop till funktionerna i testkörningsmotorn på ett liknande sätt som med BDD- och nyckelordsdrivna verktyg. I princip kan tester byggas grafiskt utan kod. Verktygen inom detta område är relativt nya och förbättras snabbt. Räkna med att användningen av dem kommer att öka i framtiden.

Anmäl dig till nyhetsbrevet The QA Lead för att få ett meddelande när nya delar av serien publiceras. Dessa inlägg är utdrag ur Pauls kurs Ledarskap inom testning, som vi varmt rekommenderar om du vill fördjupa dig i detta och andra ämnen. Om du gör det kan du använda vår exklusiva kupongkod QALEADOFFER och få 60 dollar rabatt på ordinarie kurspris!

Relaterad läsning: 10 BÄSTA VERKTYGEN FÖR ÖVERVAKNING AV WEBBSERVRAR