Hvad er workflowtest i softwaretest? med eksempler
Redaktionelle team
⚡ Smart opsummering
Workflowtestning bekræfter, at hver trinsekvens i en applikation stadig afspejler den forretningsproces, den blev bygget til, og kontrollerer hvert trin, overdragelse og afhængighed fra den første handling til det endelige resultat.
Hvad er Workflow Testing?
Test af arbejdsgange er en type softwaretest, der kontrollerer, at hver softwareworkflow nøjagtigt afspejler den givne forretningsproces. En workflow er en række opgaver, der producerer et ønsket resultat, og den involverer normalt flere faser eller trin. For enhver forretningsproces defineres test af disse sekventielle trin som workflowtest.
Den afgørende forskel er omfanget. En enkelt test sag spørger, om én funktion returnerer det rigtige svar. En workflowtest spørger, om ti af disse funktioner, udført i den rækkefølge, en rigtig bruger følger dem, stadig leverer det resultat, som virksomheden forventer. Derfor hører workflowtestning hjemme blandt de procesorienterede poster i typer af softwaretestning katalog i stedet for med enhedsniveauteknikker.
Eksempel på workflowtest
For eksempel skal du kontrollere, at systemet kan installeres på brugerens platform, og at det kører korrekt.
Et mere detaljeret eksempel er en onlineordre. Kunden tilføjer en vare til kurven, anvender en rabatkode, vælger en leveringsmulighed, betaler og modtager en bekræftelsesmail, mens lageret modtager en plukkeinstruktion. Hvert af disse trin kan gennemføres isoleret og stadig mislykkes som en kæde: rabatten overlever muligvis ikke betalingstrinnet, eller lagerbeskeden forlader muligvis aldrig køen.
Workflowtestning udføres i faser. Sådan udfører du workflowtestning.
- StartfaseDenne fase omfatter indledende testplanlægning og prototypetestning.
- UddybningsfaseDenne fase omfatter baselining af testarkitekturen.
- ByggefasenDenne fase omfatter betydelig testning ved hver build.
- OvergangsfaseDenne fase omfatter regressionstests og test rettelser igen.
Sådan udfører du workflowtestning
Fasemodellen ovenfor beskriver, hvornår arbejdet finder sted. Sekvensen nedenfor beskriver, hvad en tester rent faktisk gør i en af disse faser.
- Kortlæg forretningsprocessen. Tegn arbejdsgangen præcis som virksomheden kører den, inklusive alle beslutningspunkter, godkendelser og overdragelser mellem afdelinger. En forretningsanalytiker er normalt den hurtigste vej til et præcist kort, og Business analytiker Dokumentationen er den reference, kortet kontrolleres i forhold til.
- Angiv indgangs- og udgangskriterier. Registrer den tilstand, systemet skal være i, før arbejdsgangen starter, og den tilstand, der beviser, at den er afsluttet. Uden begge dele er testere uenige om, hvorvidt en kørsel er bestået.
- Design testcasesene. Skriv én sag pr. sti gennem arbejdsgangen, ikke én pr. skærm. Nummerér trinnene, angiv det forventede resultat for hvert trin, og giv hver sag en unik identifikator, så fejl kan identificeres. tractilbage til en sti.
- Forbered realistiske testdata. Genbrug anonymiserede produktionsformede poster i stedet for opfundne værdier. Rabatkoder, skatteregler og adresseformater er de sædvanlige steder, hvor syntetiske data skjuler reelle fejl.
- Kør den primære sti først. Bekræft, at arbejdsgangen fuldføres fra start til slut, før noget bevidst afbrydes. En fejl her ugyldiggør ethvert negativt resultat, der følger.
- Bryd kæden med vilje. Annuller midtvejs, indsend en ugyldig værdi på et beslutningspunkt, timeout en session og afvis en godkendelse. De interessante defekter findes i disse afbrudte stier, ikke i den primære.
- Rapportér, ret og test igen. Log hver fejl i forhold til det trin, der forårsagede den, og gentag derefter hele arbejdsgangen efter udbedringen. Et repareret trin flytter ofte fejlen et trin længere ned i kæden.
Stabile arbejdsgange, der gentager hver udgivelse, er de stærkeste kandidater til automatisering, fordi de samme ordnede trin kører identisk hver gang, og scriptet tjener sig selv ind inden for et par cyklusser.
Hvem skal udføre workflowtest?
Workflowtestning er delt arbejde, fordi ingen enkelt rolle ser hele kæden. Fire roller bærer byrden, hver med sit eget ansvar.
- Testingeniør
- Planlæg testmål og tidsplan
- Definer testcases og procedurer
- Evaluer testresultater
- Komponentingeniør
- Udvikling af testkomponenter
- Automatiser nogle af testprocedurerne
- Integrationstester
- Udførelse integrationstests og rapportering af mangler
- Systemtester
- Udførelse systemtests og rapportering af mangler
Hvad skal testes i en arbejdsgang
Softwarearbejdsgange er dokumenteret i forretningskravsdokumentet, og dette dokument er kilden til sandheden for dækningen. Arbejdsgangstest vil også involvere dele af system- og integrationstest.
En komplet gennemgang af en arbejdsgang undersøger mere end de skærmbilleder, brugeren ser.
- sekvens: Trinene udføres i den dokumenterede rækkefølge, og trinene kan ikke springes over eller gentages i uorden.
- Dataoverdragelse: Værdier, der indtastes tidligt i kæden, forbliver intakte til det sidste trin og til ethvert downstream-system.
- Roller og tilladelser: Hvert trin er kun tilgængeligt for den rolle, der er autoriseret til at udføre det.
- Afbrudte stier: Annullering, timeout, afvisning og nyt forsøg efterlader alle arbejdsgangen i en defineret tilstand.
- Artefakter: Workflow-testmodellen dækker testcases, testprocedurer, testkomponenter og testundersystemer, så hver af disse verificeres efter tur.
- Bemærkninger: E-mails, alarmer og kømeddelelser udløses én gang, med det korrekte indhold, på det korrekte trin.
Workflowtest vs. end-to-end-test vs. systemtest
Disse tre teknikker overlapper hinanden nok til at kunne forveksles, men alligevel besvarer de forskellige spørgsmål. Tabellen sætter grænserne.
| Aspect | Test af arbejdsgange | End-to-end testning | Systemtest |
| Spørgsmål besvaret | Stemmer softwaren overens med forretningsprocessen? | Fungerer hele processen på tværs af alle tilsluttede systemer? | Opfylder det samlede system kravene? |
| Dækningsenhed | Én forretningsproces, trin for trin | Én brugerrejse, fra frontend til backend | Den komplette applikationsudvikling |
| Primær reference | Dokument for forretningskrav | Brugerrejsekort | Specifikation af systemkrav |
| Typisk ejer | Testingeniør med input fra forretningsanalytiker | Automations- eller QA-ingeniør | Systemtester |
I praksis er en workflowtest ofte specifikationen af en end-to-end test er bygget af, mens system test giver den stabile build, som arbejdsgangen kører på.
Bedste praksis og almindelige udfordringer
Teams, der får værdi ud af workflowtestning, har en tendens til at følge det samme lille sæt vaner.
- Prioritér de arbejdsgange, der medfører indtægts- eller lovgivningsmæssige risici, frem for de sjældne.
- Beskriv hvert trin og det forventede resultat i et klart og utvetydigt sprog.
- Bevar et genanvendeligt, realistisk testdatasæt, så kørsler forbliver sammenlignelige på tværs af miljøer.
- Test hver arbejdsgang med gyldige input og med ugyldige input ved hvert beslutningspunkt.
- Opdater testcasesene i det øjeblik, den underliggende forretningsproces ændrer sig.
De tilbagevendende forhindringer er lige så forudsigelige.
- Udokumenterede processer: Arbejdsgangen lever i folks hoveder, så testere validerer imod en antagelse.
- Lange udførelsestider: En arbejdsgang, der spænder over godkendelser, kan tage timer, hvilket begrænser, hvor ofte den kører manuelt.
- Miljødrift: Downstream-systemer i kæden er stoppede eller forældede, og fejl dukker kun op i produktionen.
- Skrøbelig automatisering: Scripts knyttet til skærmlayout afbrydes, når brugergrænsefladen ændres, selv når processen ikke gjorde det.
- Datakollisioner: Parallelle kørsler bruger de samme poster, hvilket resulterer i fejl, der ligner produktfejl.
