Hoppa till innehållet

Kontrollera butiksstart med en genomgående testorder

Koppla testbetalning, order, frakt och delvis återbetalning i ett acceptansfall. Håll förväntade och observerade resultat åtskilda.

Philipp Reuter2 min läsning
Testpanel med tre fält: två gröna bockar och ett kryss i ett rödmarkerat fält.

Kontrollera före butiksstart ett utvalt beställningsflöde hela vägen till anslutna system. En bekräftelsesida visar bara en del av flödet. Vid acceptans måste det gå att se vilken testorder som betalats, överförts, skickats och eventuellt delvis återbetalats.

Skilj testet från verkliga transaktioner

Shopify beskriver simulerade betalningar för testorder. WooCommerce påpekar också effekter på anslutna tjänster. Ett testläge i betalformuläret ger därför ingen garanti för hela kedjan.

Använd en lämplig separat testmiljö med testkonton och leverantörernas avsedda sandboxåtkomst, alltså teståtkomst. Meddelanden går till kontrollerade testbrevlådor. För lager, frakt och andra anslutningar måste det vara fastställt att ingen verklig kundorder eller försändelse utlöses. Saknar en tjänst ett lämpligt testalternativ simuleras steget separat och gränsen dokumenteras.

Förbered ett konkret acceptansfall

Alla identifierare, belopp och förväntningar är fiktiva. Det förenklade kortbetalningsfallet använder 2 enheter av P-14 för 25 EUR vardera, totalt 50 EUR; skatter och fraktkostnader är inte beräknade här. Exemplet visar avstämning av data och tillstånd, inget redan utfört test.

Steg

Kopplad testreferens

Förväntan

Varukorg

TEST-48, artikel P-14

2 enheter; testtotal 50 EUR

Testbetalning

PAY-48

Lyckad simulering på 50 EUR

Order och överföring

ORD-48 i butiken, ERP-48 i administrationssystemet

Samma artikel med mängd 2; entydig koppling mellan orderna

Testfrakt

SHIP-48 kopplad till ORD-48

2 enheter i simulerad frakt; ingen verklig försändelse

Testretur

RET-48 kopplad till ORD-48

1 enhet av P-14 tydligt kopplad till returen

REF-48 kopplad till PAY-48

Simulering på 25 EUR; lämplig koppling till returen

Systemet för att administrera verksamheten kallas här ERP. Referenserna är våra egna exempeldata, inga obligatoriska fältnamn för de nämnda plattformarna.

Granska beviset vid varje gräns

Kontrollera mängd, artikel och referens i butiken och i respektive testmål. En mottagen överföringsbegäran bevisar inte att ordern är färdigskapad. Detta fall kräver därför en bekräftad målreferens.

Vid returen behandlas varustatus och betalning separat. I exemplet blir 1 enhet tillgänglig igen först efter den avtalade testkontrollen. En simulerad återbetalning ensam bevisar ingen lagerändring. En fraktstatus bevisar inte heller mottagen betalning.

Lägg till en felväg och dokumentera gränsen

Lägg till en avvisad testbetalning och ett avbrutet svar vid orderöverföringen. Visningen får då inte ange obekräftad framgång. Före ett nytt försök måste det kunna klargöras om transaktionen redan skapats så att ingen extra order uppstår.

Anteckna det faktiskt observerade resultatet och de använda versionerna av butik och integration för varje steg. Det konkreta förväntade fallet är underlaget. Täcker en simulering ett externt steg bara delvis förblir begränsningen del av acceptansen. Andra nödvändiga betalningssätt, länder och specialfall läggs till som separata kontroller.

Källor

Skriven av

  • Philipp ReuterRedaktör för mjukvarukvalitetPhilipp Reuter skriver om mjukvarutestning och förberedelse av nya releaser på ASES. Hans artiklar handlar om felanalys, acceptanstester och granskning av ändringar i befintliga applikationer.

Följ ASES

Läs vidare

Alla artiklar

E-handel med ASES

Webbutiker, marknadsplatser och B2B-portaler