Gå til innholdet

Kontroller lanseringen av nettbutikken med en gjennomgående testordre

Knytt testbetaling, ordre, frakt og delvis refusjon til ett akseptansetilfelle. Hold forventede og observerte resultater atskilt.

Philipp Reuter2 min lesetid
Testpanel med tre felt: to grønne haker og et kryss i et felt med rød ramme.

Kontroller før butikkstart en utvalgt bestillingsflyt helt frem til de tilknyttede systemene. En bekreftelsesside viser bare en del av forløpet. Ved akseptanse må det være tydelig hvilken testordre som ble betalt, overført, sendt og eventuelt delvis refundert.

Skill testen fra virkelige transaksjoner

Shopify beskriver simulerte betalinger for testordrer. WooCommerce peker også på virkninger for tilknyttede tjenester. En testmodus i betalingsskjemaet er derfor ingen garanti for hele kjeden.

Bruk et egnet separat testmiljø med testkontoer og leverandørenes tiltenkte sandbox-tilgang, altså testtilgang. Meldinger går til kontrollerte testpostkasser. For lager, frakt og andre tilkoblinger må det være fastslått at ingen virkelig kundeordre eller sending utløses. Mangler en tjeneste en egnet testmulighet, simuleres trinnet separat og grensen dokumenteres.

Forbered et konkret akseptansetilfelle

Alle identifikatorer, beløp og forventninger er oppdiktet. Det forenklede kortbetalingstilfellet bruker 2 enheter av P-14 til 25 EUR hver, totalt 50 EUR; avgifter og fraktkostnader er ikke beregnet her. Eksemplet viser avstemming av data og tilstander, ikke en allerede utført test.

Trinn

Tilknyttet testreferanse

Forventning

Handlekurv

TEST-48, vare P-14

2 enheter; testtotal 50 EUR

Testbetaling

PAY-48

Vellykket simulering på 50 EUR

Ordre og overføring

ORD-48 i nettbutikken, ERP-48 i administrasjonssystemet

Samme vare med mengde 2; entydig forbindelse mellom ordrene

Testfrakt

SHIP-48 knyttet til ORD-48

2 enheter i simulert frakt; ingen virkelig sending

Testretur

RET-48 knyttet til ORD-48

1 enhet av P-14 tydelig knyttet til returen

REF-48 knyttet til PAY-48

Simulering på 25 EUR; passende kobling til returen

Virksomhetens administrasjonssystem kalles her ERP. Referansene er våre egne eksempeldata, ikke obligatoriske feltnavn i de nevnte plattformene.

Se etter bevis ved hver grense

Kontroller mengde, vare og referanse i nettbutikken og det aktuelle testmålet. At en overføringsforespørsel er mottatt, beviser ikke at ordren er ferdig opprettet. Dette tilfellet krever derfor en bekreftet målreferanse.

Ved returen behandles varetilstand og betaling hver for seg. I eksemplet blir 1 enhet tilgjengelig igjen først etter den avtalte testkontrollen. En simulert refusjon alene beviser ingen lagerendring. En fraktstatus beviser heller ikke at betaling er mottatt.

Legg til en feilvei og noter grensen

Legg til en avvist testbetaling og et avbrutt svar under ordreoverføringen. Visningen må da ikke melde ubekreftet suksess. Før et nytt forsøk må det kunne avklares om transaksjonen allerede er opprettet, slik at ingen ekstra ordre oppstår.

Noter faktisk observert resultat og brukte versjoner av nettbutikk og integrasjon ved hvert trinn. Det gjennomarbeidede tilfellet med forventninger er malen. Dekker en simulering et eksternt trinn bare delvis, forblir begrensningen del av akseptansen. Andre nødvendige betalingsmåter, land og spesialtilfeller legges til som separate kontroller.

Kilder

Skrevet av

  • Philipp ReuterRedaktør for programvarekvalitetPhilipp Reuter skriver om programvaretesting og forberedelse av nye versjoner hos ASES. Artiklene hans handler om feilanalyse, akseptansetester og kontroll av endringer i eksisterende applikasjoner.

Følg ASES

Les videre

Alle artikler

E-handel med ASES

Nettbutikker, markedsplasser og B2B-portaler