Gå til indholdet

Kontrollér webshoppens lancering med en gennemgående testordre

Knyt testbetaling, ordre, forsendelse og delvis tilbagebetaling til ét accepttilfælde. Hold forventede og observerede resultater adskilt.

Philipp Reuter2 min. læsetid
Testpanel med tre felter: to grønne flueben og et kryds i et rødt indrammet felt.

Kontroller før butiksstart et udvalgt bestillingsforløb frem til de tilknyttede systemer. En bekræftelsesside viser kun en del af forløbet. Ved accept skal det være tydeligt, hvilken testordre der blev betalt, overført, sendt og eventuelt delvist tilbagebetalt.

Adskil testen fra rigtige handlinger

Shopify beskriver simulerede betalinger til testordrer. WooCommerce påpeger også virkninger på tilknyttede tjenester. En testtilstand i betalingsformularen er derfor ikke en garanti for hele kæden.

Brug et egnet separat testmiljø med testkonti og udbydernes beregnede sandbox-adgange, altså testadgange. Beskeder går til kontrollerede testpostkasser. For lager, forsendelse og andre forbindelser skal det stå klart, at der ikke udløses en rigtig kundeordre eller forsendelse. Mangler en tjeneste en egnet testmulighed, simuleres trinnet separat, og grænsen dokumenteres.

Forbered et gennemarbejdet accepttilfælde

Alle identifikatorer, beløb og forventninger er fiktive. Det forenklede kortbetalingsforløb bruger 2 enheder af P-14 til 25 EUR hver, i alt 50 EUR; skatter og fragtomkostninger er ikke beregnet her. Eksemplet viser afstemning af data og tilstande, ikke en allerede udført test.

Trin

Tilknyttet testreference

Forventning

Indkøbskurv

TEST-48, vare P-14

2 enheder; testtotal 50 EUR

Testbetaling

PAY-48

Vellykket simulering på 50 EUR

Ordre og overførsel

ORD-48 i butikken, ERP-48 i administrationssystemet

Samme vare med mængde 2; entydig forbindelse mellem ordrerne

Testforsendelse

SHIP-48 knyttet til ORD-48

2 enheder i simuleret forsendelse; ingen rigtig forsendelse

Testreturnering

RET-48 knyttet til ORD-48

1 enhed af P-14 tydeligt knyttet til returneringen

REF-48 knyttet til PAY-48

Simulering på 25 EUR; passende kobling til returneringen

Virksomhedens administrationssystem kaldes her ERP. Referencerne er vores egne eksempeldata, ikke obligatoriske feltnavne i de nævnte platforme.

Se efter bevis ved hver grænse

Kontroller mængde, vare og reference i butikken og det relevante testmål. En vellykket modtagelse af en overførselsanmodning beviser ikke, at ordren er færdigoprettet. Dette tilfælde kræver derfor en bekræftet målreference.

Ved returneringen behandles varens tilstand og betalingen adskilt. I eksemplet føres 1 enhed først som tilgængelig igen efter den aftalte testkontrol. En simuleret tilbagebetaling alene beviser ikke en lagerændring. En forsendelsesstatus beviser heller ikke en modtaget betaling.

Tilføj en fejlvej, og noter grænsen

Tilføj en afvist testbetaling og et afbrudt svar ved ordreoverførslen. Visningen må da ikke melde ubekræftet succes. Før et nyt forsøg skal det kunne afklares, om handlingen allerede er oprettet, så der ikke opstår en ekstra ordre.

Noter det faktisk observerede resultat og de anvendte versioner af butik og integration ved hvert trin. Det gennemarbejdede forventningstilfælde er skabelonen. Dækker en simulering kun delvist et eksternt trin, forbliver begrænsningen en del af accepten. Andre nødvendige betalingsmetoder, lande og særtilfælde tilføjes som separate kontroller.

Kilder

Skrevet af

  • Philipp ReuterRedaktør for softwarekvalitetPhilipp Reuter skriver om softwaretest og forberedelse af nye releases hos ASES. Hans artikler handler om fejlanalyse, accepttest og kontrol af ændringer i eksisterende applikationer.

Følg ASES

Læs videre

Alle artikler

E-handel med ASES

Webshops, markedspladser og B2B-portaler