Kaip patikrinti „Tracking API“ vežėjų aprėptį prieš įsipareigojant (testavimo planas + kontrolinis sąrašas)

Norėdami patikrinti sekimo API vežėjų aprėptį prieš priimdami sprendimą, atlikite koncepcijos patvirtinimo bandymą naudodami savo siuntas, palyginkite rezultatus su vežėjų sekimo įrašais ir įvertinkite našumą pagal vežėją, paslaugą ir siuntimo maršrutą. Reikalaukite naudingų sekimo įvykių, tikslaus vežėjo identifikavimo ir patikimo atnaujinimų pristatymo, o ne vien sekimo numerio priėmimo. Prieš pradėdami bandymą susitarkite dėl išlaikymo ir neišlaikymo kriterijų.

Šis bandymų planas skirtas inžinerijos, logistikos valdymo ir elektroninės prekybos operacijų komandoms, besirenkančioms sekimo API. Jo tikslas – atskirti vežėją, esantį teikėjo kataloge, nuo to, ar teikėjas palaiko siuntų matomumą, kurio iš tikrųjų reikia jūsų verslui.

Apibrėžkite aprėptį kaip operacinį rezultatą

Bendras vežėjų skaičius neatsako į klausimą, ar API gali sekti jūsų siuntas. Priėmimo kriterijai turėtų atskirti kelis aprėpties lygius:

• Katalogo aprėptis: Teikėjas savo paskelbtoje medžiagoje identifikuoja vežėją.
• Registracijos aprėptis: API priima galiojančią siuntą sekimui.
• Įvykių aprėptis: API grąžina naudingus šios siuntos vežėjo įvykius.
• Gyvavimo ciklo aprėptis: Sekimas išlieka naudingas iki pristatymo, išimties ar kito svarbaus rezultato.
• Operacinė aprėptis: Jūsų programa gauna ir interpretuoja šiuos atnaujinimus pagal sutartus reikalavimus.

Tai yra siūlomos vertinimo kategorijos, o ne pramonės sertifikatas. Naudokite jas, kad diskusijos su tiekėjais būtų tikslios. Sėkminga registracija neįrodo, kad vėlesni įvykiai bus gauti, o pristatyta siunta su viena galutine būsena neįrodo, kad matomumas tranzito metu buvo pakankamas.

Pirkimo sprendimas turėtų būti grindžiamas patikrinta jūsų siuntimo derinio aprėptimi, o kritiniai trūkumai turėtų būti vertinami atskirai nuo bendro balo.

1. Sukurkite jūsų verslą atspindinčią siuntų matricą

Pradėkite nuo siuntų, esančių jūsų užsakymų valdymo sistemoje, sandėlio platformoje arba siuntimo įrašuose. Pasirinkite verslo laikotarpį, apimantį įprastą vežėjų derinį ir sezonines paslaugas, kurias ketinate toliau naudoti. Neleiskite, kad tiekėjo pasirinktas demonstracinis rinkinys taptų vieninteliu įrodymu.

Grupuokite siuntas pagal vežėją, paslaugą, kilmę, paskirties vietą ir perdavimo modelį. Vidaus skubiosios, tarptautinės pašto ir ekonominės paslaugos turėtų likti atskiros, jei joms taikomi skirtingi sekimo reikalavimai, net jei kiekvienoje grupėje nurodytas tas pats vežėjo pavadinimas.

Bandymų grupė	Ką įtraukti	Ką tai nustato
Pagrindiniai siuntimo maršrutai	Dažnai naudojami vežėjo, paslaugos ir šalies deriniai	Ar API tinka kasdienėms operacijoms
Kritiniai mažesnės apimties maršrutai	Paslaugos, svarbios dėl įsipareigojimų klientams arba pakeitimo išlaidų	Ar bendras balas neslepia rimto trūkumo
Tarptautiniai perdavimai	Siuntos, perduodamos kilmės ir paskirties šalių operatoriams	Ar matomumas išlieka po perdavimo
Išimtys ir grąžinimai	Žinomi nesėkmingi bandymai, vėlavimai ir kelionės grąžinant siuntą siuntėjui	Ar būsenos padeda atlikti tinkamą veiksmą klientui
Neigiamos kontrolės	Netinkami įvesties duomenys, nesutampantys vežėjai ir autorizuoti bandomieji įrašai	Ar klaidas galima atskirti nuo galiojančio sekimo

Naudokite ir užbaigtas, ir aktyvias siuntas. Užbaigtos siuntos padeda įvertinti istorinį išsamumą ir galutinės būsenos tikslumą. Aktyvios siuntos būtinos, kad galėtumėte stebėti atnaujinimų laiką ir perdavimus jiems vykstant. Vien istoriniai rezultatai negali nustatyti veikimo realiuoju laiku.

Neigiamas kontrolines siuntas neįtraukite į galiojančių siuntų aprėpties vardiklį. Taip pat atskirkite siuntas, laukiančias pirmojo fizinio nuskaitymo, nuo siuntų, kurios jau turi vežėjo įvykių. Priešingu atveju įprasta būsena prieš išsiuntimą gali atrodyti kaip aprėpties trūkumas.

Kokio dydžio turėtų būti imtis?

Nėra universalaus imties dydžio, įrodančio vežėjo aprėptį. Pradėkite nuo valdomo bandomojo projekto, kad rastumėte integracijos klaidas, o tada išplėskite jį į visas reikalingas siuntų grupes. Įtraukite skirtingas išsiuntimo datas ir gyvavimo ciklo etapus, o ne daug beveik identiškų siuntinių iš vienos partijos.

Nurodykite kiekvienos grupės imties dydį. Švarus kelių siuntų rezultatas yra preliminarus įrodymas, o ne garantija. Jei retas, bet svarbus atvejis bandymo metu nepasitaiko, pažymėkite scenarijų kaip nepatikrintą ir suplanuokite atskirą patvirtinimą, užuot skyrę jam išlaikytą rezultatą.

2. Prieš integraciją susitarkite dėl bandymo sutarties

Prieš bet kuriai komandai pamatant rezultatus, raštu apibrėžkite, kas laikoma sėkme. Inžinerijos vadovas turėtų apibrėžti duomenų ir pristatymo reikalavimus; logistikos vadovas turėtų nustatyti privalomus maršrutus ir būsenų reikšmes; pirkimų vadovas turėtų patvirtinti, kad išbandyta konfigūracija atitinka siūlomą komercinę paslaugą.

Paprašykite kiekvieno kandidato patvirtinti:

• Kokie tikslūs vežėjų identifikatoriai ir paslaugų variantai taikomi jūsų siuntų matricai.
• Ar sekimui reikia pašto kodo, paskirties šalies, paskyros autorizacijos ar kitos įvesties.
• Ar bandymui naudojami gamybiniai duomenų šaltiniai ir ar kokie nors bandymo apribojimai turi įtakos bandymui.
• Kaip dokumentuojamas istorinių duomenų prieinamumas, sekimo trukmė, apklausos ir webhook pristatymas.
• Kurie registracijos, atnaujinimo, prenumeratos ar pakartotinio bandymo veiksmai pagal siūlomą planą gali būti apmokestinami.
• Kaip turėtų būti eskaluojamas trūkstamas atnaujinimas arba su vežėju susijęs incidentas.

Vertindami 17TRACK, pradėkite nuo Tracking API produkto puslapio ir oficialios API dokumentacijos, kad išsiaiškintumėte produkto ir integracijos klausimus. Taikykite tą pačią siuntų matricą ir priėmimo taisykles, kurias naudojate bet kuriam kitam kandidatui. Viešo sekimo puslapio rezultatas turėtų būti laikomas kryžmine patikra, o ne įrodymu, kokį API atsakymą gaus jūsų programa.

Neskirkite neišlaikyto rezultato vien todėl, kad dokumente neaiškiai aprašyta tam tikra galimybė. Užregistruokite ją kaip reikalaujančią patvirtinimo, užduokite konkretų klausimą ir, jei įmanoma, patikrinkite atsakymą.

3. Sukurkite kiekvienos siuntos įrodymų įrašą

Naudokite skaičiuoklę arba bandymų duomenų bazę su vienu įrašu kiekvienai siuntai ir susietais įvykių stebėjimais. Išsaugokite pakankamai informacijos neatitikimui atkurti, tačiau neplatinkite nereikalingų klientų duomenų.

• Vidinis bandymo ID ir saugiai saugomas sekimo numeris.
• Numatomas vežėjas, paslauga, kilmė, paskirties vieta ir žinomas tolesnis vežėjas.
• API versija, aplinka, konfigūracija ir registracijos laikas.
• Pateiktas vežėjo identifikatorius ir bet kokie papildomi privalomi įvesties duomenys.
• Registracijos atsakymas, aptiktas vežėjas, grąžinta būsena ir neapdoroti įvykių duomenys.
• Vežėjo nuorodų momentinės kopijos su stebėjimo laiko žymomis.
• API stebėjimo laiko žymos ir webhook gavimo laiko žymos, jei taikoma.
• Verdiktas, neatitikimo kategorija, tyrimo vadovas ir pakartotinio bandymo rezultatas.

Stebėjimo laiko žymoms naudokite UTC, išsaugodami pradines įvykių laiko žymas ir poslinkius. Nuskaitymo įvykio laikas ir laikas, kada jūsų sistema gauna šį nuskaitymą, yra skirtingi matavimai. Juos supainiojus galima gauti klaidinančius delsos rezultatus.

Naudokite siuntų įrašus, kuriuos turite teisę tvarkyti. Apribokite prieigą prie duomenų ir iš pirkimų ataskaitų pašalinkite adresus, gavėjų vardus bei kitą nereikalingą asmeninę informaciją.

4. Atlikite bandymą keturiais etapais

A etapas: Registracija ir vežėjo identifikavimas

Užregistruokite galiojančias siuntas naudodami dokumentuotas įvestis. Jei galimas ir automatinis aptikimas, ir aiškus vežėjo pasirinkimas, išbandykite juos atskirai. Užregistruokite neteisingus, dviprasmiškus atitikmenis, atmestas įvestis ir priimtus įrašus, kurie niekada nesukuria įvykių.

Jei aiškus pasirinkimas sėkmingas po to, kai automatinis aptikimas nepavyksta, klasifikuokite problemą kaip aptikimo spragą, o ne visišką vežėjo nepasiekiamumą. Šis skirtumas svarbus, jei jūsų siuntimo sistema jau žino vežėją ir gali jį patikimai pateikti.

Naudodami neigiamas kontrolines siuntas patikrinkite, ar API nepateikia negaliojančio arba nesutampančio įrašo kaip užtikrintai identifikuotos siuntos. Neatspėliokite atsitiktinių sekimo numerių, kurie gali priklausyti kitiems klientams.

B etapas: Įvykių turinys ir būsenų reikšmė

Palyginkite API įvykius su laiko žymomis pažymėtais įrašais iš atitinkamo vežėjo sekimo kanalo. Patikrinkite įvykių aprašus, jei pateikiamos – vietas, įvykių tvarką ir galutinius rezultatus. Išsaugokite neapdorotą vežėjo aprašą kartu su bet kokia normalizuota API būsena.

Sutelkite dėmesį į skirtumus, kurie keičia verslo veiksmus. Nesėkmingas pristatymo bandymas neturėtų suaktyvinti el. laiško apie pristatymą. Įvykis „grąžinama siuntėjui“ neturėtų būti supainiotas su kliento grąžinimu, kurį gavo jūsų sandėlis. Su muitine susijęs atnaujinimas neturėtų būti automatiškai interpretuojamas kaip prašymas atlikti mokėjimą.

Vežėjų nuorodos taip pat gali skirtis pateikimu arba atnaujinimo laiku. Jei atsiranda neatitikimas, užfiksuokite abu stebėjimus ir prieš priskirdami kaltę atlikite tyrimą. Įrašų su įsigytomis etiketėmis, kuriuose nėra fizinių nuskaitymų, būseną prieš išsiuntimą vertinkite atskirai.

C etapas: Aktyvūs atnaujinimai ir pristatymas į jūsų sistemą

Stebėkite aktyvias siuntas vienodu dažniu, laikydamiesi dokumentuotų apribojimų. Palyginkite, kada įvykis pirmą kartą tampa matomas atliekant vežėjo nuorodų patikras, su tuo, kada jis pirmą kartą tampa matomas per API. Tai vadinkite stebimu matomumo vėlavimu: tai pagal jūsų stebėjimo tvarkaraštį apribotas įvertis, o ne tikslus teikėjo vidinio apdorojimo laiko matavimas.

Jei webhook yra siūlomos integracijos dalis, registruokite gavimo laiką ir apdorojimo rezultatą. Naudodami dokumentuotus mechanizmus arba sutartas bandymo procedūras, patikrinkite pasikartojančių įvykių tvarkymą, pakartotinius bandymus po laikino galinio taško sutrikimo ir praleistų atnaujinimų atkūrimą. Venkite tyčia trikdyti gamybinius galinius taškus.

Vežėjo įvykis, kuris pasiekia API, bet niekada nepasiekia jūsų užsakymų sistemos, nėra tas pats gedimas kaip įvykis, kurio trūksta API. Šias išvadas laikykite atskirai, kad atsakinga komanda galėtų sutvarkyti tinkamą sluoksnį.

D etapas: Tęstinumas gabenant tarptautiniu mastu

Sekite siuntas per eksportą, atvykimą į paskirties šalį, perdavimą ir pristatymą, jei šie etapai stebimi. Užregistruokite, ar pateikiamas tolesnis vežėjas arba pakaitinis sekimo numeris ir ar jūsų integracija gali susieti jį su pirminiu užsakymu.

Gabenant tarptautiniu mastu, tikrinkite visą kelionę, o ne tik kilmės vežėją. Jei siunta pristatoma, bet API lieka eksporto etape, ji neatitinka viso kelio matomumo reikalavimo. Ir atvirkščiai, laikinas nuskaitymų nebuvimas tarptautinio tranzito metu savaime neįrodo API gedimo.

5. Įvertinkite rezultatus neslėpdami spragų

Naudokite aiškius vardiklius ir rodykite rezultatus pagal vežėjo, paslaugos ir maršruto grupes. Šie rodikliai sudaro praktinę rezultatų suvestinę:

• Registracijos sėkmė: Priimtų galiojančių siuntų dalis iš visų pateiktų galiojančių siuntų.
• Naudingų įvykių aprėptis: Tinkamų siuntų, grąžinančių pagal jūsų priėmimo taisykles reikalingus įvykius, dalis iš visų patikrintų tinkamų siuntų.
• Vežėjo identifikavimo tikslumas: Teisingai identifikuotų vežėjų dalis iš siuntų, įvertintų aptikimui.
• Galutinio rezultato tikslumas: Teisingų galutinių rezultatų dalis iš užbaigtų siuntų, kurių patvirtintas atskaitos rezultatas.
• Stebimas matomumo vėlavimas: API matomumo laiko ir vežėjo nuorodos matomumo laiko skirtumo pasiskirstymas susietiems įvykiams.
• Atnaujinimų pristatymo sėkmė: Reikalingų atnaujinimų, kuriuos jūsų programa sėkmingai gavo ir apdorojo, dalis iš API stebėtų reikalingų atnaujinimų.

Prieš apskaičiuodami naudingų įvykių aprėptį, apibrėžkite tinkamumą. Pavyzdžiui, siunta, kurioje nėra vežėjo nuskaitymo, neturėtų būti laikoma neturinčia tranzito įvykio, kurio dar nėra. Kartu su balu pateikite pašalintus ir neišspręstus įrašus, kad pašalinimai negalėtų nepastebimai pagerinti rezultato.

Jei reikia bendro įverčio, maršrutų lygmens naudingų įvykių rezultatus sverkite pagal numatomą siuntimo derinį. Visoms grupėms naudokite tą pačią metriką ir parodykite svorius. Nejunkite vieno vežėjo registracijos sėkmės su kito vežėjo gyvavimo ciklo sėkme.

Nustatykite ribas pagal verslo reikalavimus, o ne pagal išgalvotą pramonės standartą. Klientų pranešimų procesas ir pagalbos tarnybos skydelis gali toleruoti skirtingus vėlavimus. Pateikite įprastą ir lėtesnės kraštinės elgseną; vien vidurkis gali paslėpti trikdančius vėlavimus.

6. Priimkite sąlyginį pirkimo sprendimą

Kiekvieną reikalingą grupę klasifikuokite kaip išlaikiusią, neišlaikiusią arba neaiškią. Neaiški reiškia, kad įrodymų nepakanka, pavyzdžiui, stebėjimo metu neįvyko perdavimas, o ne tai, kad teikėjas neturi tokios galimybės.

Patvirtinkite diegimą, kai privalomos grupės atitinka sutartus reikalavimus, o likę apribojimai turi priimtinus sprendimus. Patvirtinkite ribotą paleidimą, kai išlaiko tik aiškiai apibrėžtas pogrupis. Pratęskite bandymą, kai įrodymų nepakanka. Atmeskite siūlomą apimtį, kai po tyrimo ir pakartotinio bandymo išlieka kritinis trūkumas.

Komercinį tinkamumą laikykite atskirai nuo techninės aprėpties. Pakartokite išmatuotą darbo krūvį pagal siūlomas atsiskaitymo sąlygas, įskaitant taikomas registracijas, atnaujinimus, pakartotinius bandymus ir nuolatinį sekimą. Jei atsiskaitymo vienetai ar ribos neaiškūs, gaukite rašytinį paaiškinimą; nedarykite išvadų remdamiesi sėkmingais bandomaisiais skambučiais.

Kontrolinis sąrašas prieš įsipareigojant

• Privalomi vežėjai, paslaugos ir maršrutai aiškiai įvardyti.
• Atstovaujamos ir aktyvios, ir užbaigtos siuntos.
• Neigiamos kontrolės atskirtos nuo galiojančių siuntų aprėpties.
• Automatinis aptikimas ir aiškus vežėjo pasirinkimas, jei įmanoma, įvertinti atskirai.
• Reikalingos papildomos įvestys dokumentuotos ir prieinamos jūsų sistemose.
• Vežėjo nuorodų įrodymai ir neapdoroti API atsakymai saugiai išsaugoti.
• Patikrinti tarptautiniai perdavimai ir galutiniai rezultatai.
• Webhook gavimas ir programos apdorojimas matuojami atskirai nuo API prieinamumo.
• Kiekviena metrika turi apibrėžtą vardiklį, stebėjimo laikotarpį ir pašalinimo taisyklę.
• Kritinių maršrutų nesėkmių negalima nusverti bendru balu.
• Nepatikrinti scenarijai turi atsakingą asmenį ir patvirtinimo planą.
• Patvirtinta gamybinė konfigūracija, pagalbos eskalavimas ir atsiskaitymo prielaidos.
• Prieš visišką perkėlimą suderintas ribotas paleidimas ir atsarginis procesas.

DUK

Ar kataloge nurodytas vežėjas reiškia, kad palaikomos visos jo paslaugos?

Taip manyti nereikėtų. Laikykite įrašą kataloge pradžios tašku, tada patikrinkite paslaugą, šalių porą, reikalingas įvestis ir jūsų operacijose naudojamus gyvavimo ciklo įvykius. Jei vien vežėjo pavadinimas neidentifikuoja aktualios paslaugos, paprašykite paaiškinimo.

Ar galiu tikrinti aprėptį naudodamas tik pristatytų siuntų sekimo numerius?

Pristatytų siuntų įrašai gali padėti įvertinti istorinį išsamumą ir galutinės būsenos tikslumą. Jie negali nustatyti, kaip greitai atnaujinimai gaunami tranzito metu arba ar jūsų webhook procesas atsigauna po sutrikimų. Prieš patvirtindami gamybinę integraciją įtraukite aktyvių siuntų.

Ką turėčiau daryti, kai API ir vežėjo puslapio duomenys nesutampa?

Surinkite abiejų šaltinių laiko žymomis pažymėtus įrodymus, patikrinkite vežėją ir sekimo numerį, taip pat laiko juostas ir būsenų susiejimą. Pakartokite stebėjimą ir pateikite atkuriamą pagalbos užklausą. Vienas nesutampantis momentinis vaizdas yra priežastis tirti, bet nepakankamas įrodymas priežasčiai nustatyti.

Ar dėl kiekvieno trūkstamo nuskaitymo bandymas turėtų būti laikomas neišlaikytu?

Ne. Vežėjo nuorodoje gali nebūti nuskaitymo arba jis gali nepatekti į jūsų privalomų įvykių rinkinį. Laikykite atitinkamą reikalavimą neįvykdytu, kai tikėtinas ir patikrinamas įvykis neatsiranda per sutartą stebėjimo laikotarpį. Nežinomus atvejus laikykite atskirai nuo patvirtintų nesėkmių.

Ar pradėjus naudoti paslaugą vežėjo aprėptį reikia tikrinti iš naujo?

Taip. Toliau stebėkite tipines siuntas ir atlikite pakartotinį bandymą, kai pridedate vežėją, paslaugą, paskirties rinką arba iš esmės kitokią integracijos konfigūraciją. Išsaugokite pradines priėmimo taisykles, kad vėlesnius rezultatus būtų galima palyginti.

Šaltiniai

Toliau pateikti oficialūs ištekliai yra pradžios taškai vertinant 17TRACK ir patvirtinant integracijos reikalavimus. Šiame straipsnyje pateiktos bandymų procedūros, balų skaičiavimo apibrėžtys ir pirkimo kontrolinis sąrašas yra redakcinės rekomendacijos, o ne paskelbtos paslaugų garantijos.

• 17TRACK Tracking API — oficiali produkto nuoroda, skirta 17TRACK API vertinimui.
• 17TRACK API dokumentacija — oficiali techninė nuoroda, kurią reikia palyginti su siūlomu įgyvendinimu ir bandymo konfigūracija.