Міндеттеме алмас бұрын Tracking API-дің тасымалдаушыларды қамтуын қалай тексеруге болады (тестілеу жоспары + тексеру тізімі)

Міндеттеме қабылдамас бұрын бақылау API-інің тасымалдаушыларды қамтуын тексеру үшін өз жөнелтілімдеріңізді пайдаланып сынақ нұсқасын іске қосыңыз, нәтижелерді тасымалдаушылардың бақылау жазбаларымен салыстырыңыз және өнімділікті тасымалдаушы, қызмет түрі және тасымалдау бағыты бойынша өлшеңіз. Бақылау нөмірін жай ғана қабылдауға емес, пайдалануға болатын бақылау оқиғаларына, тасымалдаушыны дәл анықтауға және жаңартулардың сенімді жеткізілуіне қойылатын талаптарды белгілеңіз. Сынақ басталмас бұрын өту/өтпеу критерийлерін келісіп алыңыз.

Бұл сынақ жоспары бақылау API-ін таңдайтын инженерлік, логистиканы басқару және электрондық коммерция операциялары командаларына арналған. Оның мақсаты — провайдердің каталогында тасымалдаушының болуы мен сол провайдердің бизнесіңізге іс жүзінде қажет жөнелтілім көрінімділігін қолдауын ажырату.

Қамтуды операциялық нәтиже ретінде анықтаңыз

Тасымалдаушылардың жалпы саны API сіздің жөнелтілімдеріңізді бақылай алатынын көрсетпейді. Қабылдау критерийлері қамтудың бірнеше деңгейін ажыратуы керек:

• Тізімдік қамту: Провайдер тасымалдаушыны жарияланған материалдарында көрсетеді.
• Тіркеу қамтуы: API жарамды жөнелтілімді бақылауға қабылдайды.
• Оқиғалар қамтуы: API сол жөнелтілім үшін пайдалы тасымалдаушы оқиғаларын қайтарады.
• Өмірлік цикл қамтуы: Бақылау жеткізуге, ерекше жағдайға немесе басқа тиісті нәтижеге дейін пайдалы болып қалады.
• Операциялық қамту: Қолданбаңыз келісілген талаптарға сай сол жаңартуларды қабылдап, түсіндіреді.

Бұл — салалық сертификаттау емес, ұсынылған бағалау санаттары. Оларды жеткізушілермен талқылауды нақтылау үшін пайдаланыңыз. Сәтті тіркелу кейінгі оқиғалардың міндетті түрде келетінін дәлелдемейді, ал бір ғана соңғы мәртебесі бар жеткізілген жөнелтілім транзит кезіндегі көрінімділіктің жеткілікті болғанын дәлелдемейді.

Сатып алу туралы шешім тасымалдау қоспаңыздың тексерілген қамтуына негізделуі керек, ал маңызды олқылықтар жалпы ұпайдан бөлек қарастырылуы тиіс.

1. Бизнесіңізді көрсететін жөнелтілім матрицасын құрыңыз

Тапсырыстарды басқару жүйесінен, қойма платформасынан немесе тасымалдау жазбаларынан алынған жөнелтілімдерден бастаңыз. Тұрақты тасымалдаушылар қоспасын және болашақта пайдалануды жоспарлаған маусымдық қызметтерді қамтитын бизнес кезеңін таңдаңыз. Жеткізуші таңдаған демонстрациялық жиынтықты жалғыз дәлелге айналдырмаңыз.

Жөнелтілімдерді тасымалдаушы, қызмет түрі, шығу орны, тағайындалған орын және тапсыру үлгісі бойынша топтастырыңыз. Ішкі жедел жеткізу, трансшекаралық пошта және үнемді қызметтер бақылау талаптары әртүрлі болса, тіпті әр топта бір тасымалдаушы атауы көрсетілсе де, бөлек қалуы керек.

Сынақ тобы	Нені қамту керек	Нені анықтайды
Негізгі тасымалдау бағыттары	Жиі пайдаланылатын тасымалдаушы-қызмет-ел комбинациялары	API-дің күнделікті операцияларға сәйкестігін
Көлемі аз, бірақ маңызды бағыттар	Клиент алдындағы міндеттемелерге немесе ауыстыру шығындарына байланысты маңызды қызметтер	Жалпы ұпайдың елеулі олқылықты жасыратынын
Трансшекаралық тапсырулар	Шығу және тағайындалған орын операторлары арасында берілетін жөнелтілімдер	Көрінімділіктің тапсырудан кейін сақталатынын
Ерекше жағдайлар және қайтарымдар	Белгілі сәтсіз әрекеттер, кідірістер және жіберушіге қайтару бағыттары	Мәртебелердің дұрыс клиенттік әрекетті қолдайтынын
Теріс бақылау үлгілері	Жарамсыз енгізулер, сәйкес келмейтін тасымалдаушылар және рұқсат етілген сынақ жазбалары	Қателердің жарамды бақылаудан ажыратылатынын

Аяқталған және нақты уақытта орындалып жатқан жөнелтілімдердің екеуін де пайдаланыңыз. Аяқталған жөнелтілімдер тарихи егжей-тегжейлер мен соңғы мәртебенің дәлдігін бағалауға көмектеседі. Нақты уақыттағы жөнелтілімдер жаңарту уақытын және тапсыруларды болып жатқан сәтінде бақылау үшін қажет. Тек тарихи нәтижелер нақты уақыттағы өнімділікті анықтай алмайды.

Теріс бақылау үлгілерін жарамды жөнелтілімдер қамтуының бөлімінен бөлек ұстаңыз. Сондай-ақ алғашқы физикалық сканерлеуді күтіп тұрған жөнелтілімдерді тасымалдаушы оқиғалары бар жөнелтілімдерден ажыратыңыз. Әйтпесе, жөнелту алдындағы қалыпты жағдай қамту сәтсіздігі ретінде көрінуі мүмкін.

Үлгі көлемі қандай болуы керек?

Тасымалдаушы қамтылуын дәлелдейтін әмбебап үлгі көлемі жоқ. Интеграция қателерін анықтау үшін басқаруға болатын пилоттық сынақтан бастаңыз, кейін қажетті жөнелтілім топтарының аясын кеңейтіңіз. Бір партиядан алынған көптеген ұқсас сәлемдемелердің орнына әртүрлі жөнелту күндері мен өмірлік цикл кезеңдерін қамтыңыз.

Әр топ үшін үлгі санын көрсетіңіз. Бірнеше жөнелтілімнен алынған таза нәтиже — кепілдік емес, алдын ала дәлел. Егер сирек кездесетін, бірақ маңызды ерекше жағдай сынақ кезінде орын алмаса, бұл сценарийді тексерілмеген деп белгілеп, оған өту мәртебесін берудің орнына бөлек тексеру ұйымдастырыңыз.

2. Интеграцияға дейін сынақ келісімін келісіңіз

Нәтижелерді екі команда да көрмей тұрып, табыстың нені білдіретінін жазып алыңыз. Инженерлік жауапты тұлға деректер мен жеткізу талаптарын анықтауы керек; логистикаға жауапты тұлға міндетті бағыттар мен мәртебелердің мағынасын белгілеуі керек; сатып алуға жауапты тұлға сыналған конфигурацияның ұсынылған коммерциялық қызметке сәйкес келетінін растауы керек.

Әр кандидаттан мыналарды растауды сұраңыз:

• Жөнелтілім матрицасына қолданылатын нақты тасымалдаушы идентификаторлары мен қызмет нұсқалары.
• Бақылау үшін пошта индексі, тағайындалған ел, есептік жазба авторизациясы немесе басқа енгізу қажет пе.
• Сынақта өндірістік деректер көздері пайдаланыла ма және қандай да бір сынақ шектеулері тексеруге әсер ете ме.
• Тарихи деректердің қолжетімділігі, бақылау ұзақтығы, сұрау аралығы және webhook арқылы жеткізу қалай құжатталғаны.
• Ұсынылған жоспар бойынша қандай тіркеу, жаңарту, жазылым немесе қайталап орындау әрекеттері ақылы болуы мүмкін.
• Жаңарту келмегенде немесе тасымалдаушыға тән оқиға болғанда оны қалай эскалациялау керек.

17TRACK бағалауы үшін өнім және интеграция мәселелерін қарастырудың бастапқы нүктесі ретінде Tracking API product page және official API documentation ресурстарын пайдаланыңыз. Кез келген басқа кандидатқа қолданатын жөнелтілім матрицасы мен қабылдау ережелерін дәл солай қолданыңыз. Жалпыға қолжетімді бақылау бетінің нәтижесі сіздің қолданбаңыз алатын API жауабының дәлелі емес, тек салыстырып тексеру құралы ретінде қарастырылуы керек.

Құжатта мүмкіндік түсініксіз болғаны үшін бірден сәтсіздік белгілемеңіз. Оны растауды қажет ететін мәселе ретінде тіркеп, нақты сұрақ қойыңыз және мүмкін болса, жауапты сынақтан өткізіңіз.

3. Әр жөнелтілім үшін дәлелдер жазбасын жасаңыз

Әр жөнелтілімге бір жазба және оған байланыстырылған оқиғаларды бақылау үшін электрондық кестені немесе сынақ дерекқорын пайдаланыңыз. Артық клиенттік деректерді таратпай, сәйкессіздікті қайта жасауға жеткілікті ақпаратты сақтаңыз.

• Ішкі сынақ идентификаторы және қауіпсіз сақталатын бақылау нөмірі.
• Күтілетін тасымалдаушы, қызмет түрі, шығу орны, тағайындалған орын және белгілі кейінгі тасымалдаушы.
• API нұсқасы, орта, конфигурация және тіркеу уақыты.
• Жіберілген тасымалдаушы идентификаторы және қажет кез келген қосымша енгізулер.
• Тіркеу жауабы, анықталған тасымалдаушы, қайтарылған мәртебе және бастапқы оқиға деректері.
• Бақылау уақыттары көрсетілген тасымалдаушыға қатысты жазбалардың көшірмелері.
• API арқылы бақылау уақыттары және қажет болған жағдайда webhook қабылдау уақыттары.
• Қорытынды, сәйкессіздік санаты, тергеуге жауапты тұлға және қайта сынақ нәтижесі.

Бақылау уақыттары үшін UTC пайдаланыңыз, бірақ бастапқы оқиға уақыттары мен ығысуларын сақтаңыз. Сканерлеудің оқиға уақыты мен жүйеңіздің сол сканерлеуді қабылдау уақыты — екі түрлі өлшем. Оларды шатастыру кідіріс нәтижелерін бұрмалауы мүмкін.

Өңдеуге рұқсатыңыз бар жөнелтілім жазбаларын пайдаланыңыз. Деректерге қолжетімділікті шектеп, сатып алу есептерінен мекенжайларды, алушы аттарын және басқа қажетсіз жеке ақпаратты алып тастаңыз.

4. Сынақты төрт кезеңде орындаңыз

A кезеңі: Тіркеу және тасымалдаушыны анықтау

Құжатталған енгізулерді пайдаланып жарамды жөнелтілімдерді тіркеңіз. Автоматты анықтау да, тасымалдаушыны нақты таңдау да қолжетімді болса, оларды бөлек сынаңыз. Қате сәйкестіктерді, екіұшты сәйкестіктерді, қабылданбаған енгізулерді және қабылданғанымен ешқашан оқиға туындатпайтын жазбаларды тіркеңіз.

Егер автоматты анықтау сәтсіз болғаннан кейін нақты таңдау сәтті болса, мәселені тасымалдаушының толық қолжетімсіздігі емес, анықтау олқылығы ретінде жіктеңіз. Бұл сіздің тасымалдау жүйеңіз тасымалдаушыны бұрыннан білсе және оны сенімді түрде жібере алса, маңызды айырмашылық болып табылады.

Теріс бақылау үлгілері үшін API жарамсыз немесе сәйкес келмейтін жазбаны нақты анықталған жөнелтілім ретінде көрсетпейтініне көз жеткізіңіз. Басқа клиенттерге тиесілі болуы мүмкін кездейсоқ бақылау нөмірлерін болжап енгізбеңіз.

B кезеңі: Оқиға мазмұны және мәртебе мағынасы

API оқиғаларын тиісті тасымалдаушының бақылау арнасындағы уақыт белгісі бар жазбалармен салыстырыңыз. Оқиға сипаттамаларын, берілген жағдайда орналасқан жерлерді, оқиғалар ретін және соңғы нәтижелерді тексеріңіз. Қалыпқа келтірілген API мәртебесімен қатар бастапқы тасымалдаушы сипаттамасын сақтаңыз.

Бизнес әрекеттерін өзгертетін айырмашылықтарға назар аударыңыз. Сәтсіз жеткізу әрекеті «жеткізілді» электрондық хатын іске қоспауы керек. Жіберушіге қайтару оқиғасын қоймаңыз алған клиенттік қайтарыммен шатастырмаңыз. Кеденге қатысты жаңарту автоматты түрде төлем сұрауы ретінде түсіндірілмеуі керек.

Тасымалдаушыға қатысты нөмірлердің көрсетілуі немесе жаңартылу уақыты да әртүрлі болуы мүмкін. Сәйкессіздік байқалса, кінәлі тарапты анықтамас бұрын екі бақылауды да тіркеп, зерттеңіз. Физикалық сканерлеусіз сатып алынған жапсырма жазбалары үшін жөнелту алдындағы жағдайды бөлек бағалаңыз.

C кезеңі: Нақты уақыттағы жаңартулар және жүйеңізге жеткізу

Құжатталған шектеулерді сақтайтын тұрақты аралықпен нақты уақыттағы жөнелтілімдерді бақылаңыз. Оқиға тасымалдаушы жазбаларын тексеру кезінде алғаш көрінген уақыт пен API арқылы алғаш көрінген уақытты салыстырыңыз. Мұны бақыланған көрінімділік кідірісі деп атаңыз: ол сіздің бақылау кестеңізбен шектелген бағалау болып табылады, провайдердің ішкі өңдеу уақытының дәл өлшемі емес.

Егер ұсынылған интеграцияның бір бөлігі webhook болса, қабылдау уақытын және өңдеу нәтижесін тіркеңіз. Құжатталған механизмдерді немесе келісілген сынақ рәсімдерін пайдаланып, қайталанатын оқиғаларды өңдеуді, уақытша соңғы нүкте ақауынан кейінгі қайталауларды және өткізіп алған жаңартуларды қалпына келтіруді тексеріңіз. Өндірістік соңғы нүктелердің жұмысын әдейі бұзбаңыз.

Тасымалдаушы оқиғасы API-ге жетіп, бірақ тапсырыстар жүйеңізге жетпесе, бұл оқиғаның API-де мүлде болмауымен бірдей сәтсіздік емес. Жауапты команда тиісті деңгейді түзете алуы үшін бұл нәтижелерді бөлек ұстаңыз.

D кезеңі: Трансшекаралық үздіксіздік

Көрінетін болса, жөнелтілімдерді экспорт, тағайындалған елге келу, тапсыру және жеткізу кезеңдері арқылы бақылаңыз. Кейінгі тасымалдаушы немесе ауыстырылған бақылау нөмірі көрсетілетінін және интеграцияңыздың оны бастапқы тапсырыспен байланыстыра алатынын тіркеңіз.

Трансшекаралық тасымалдау кезінде тек бастапқы тасымалдаушыны емес, толық жолды сынаңыз. Сәлемдеме жеткізілгенімен API экспорт кезеңінде қалса, ол басынан аяғына дейінгі көрінімділік талабына сай келмейді. Керісінше, халықаралық транзит кезінде сканерлеулердің уақытша болмауы өздігінен API сәтсіздігінің дәлелі емес.

5. Олқылықтарды жасырмай нәтижелерді бағалаңыз

Нақты бөлгіштерді пайдаланып, нәтижелерді тасымалдаушы-қызмет-бағыт топтары бойынша көрсетіңіз. Бұл өлшемдер практикалық бағалау картасын құрайды:

• Тіркеу сәттілігі: Қабылданған жарамды жөнелтілімдер саны жіберілген жарамды жөнелтілімдер санына бөлінеді.
• Пайдалануға болатын оқиғалар қамтуы: Қабылдау ережелеріңізде талап етілетін оқиғаларды қайтарған жарамды жөнелтілімдер саны сыналған жарамды жөнелтілімдер санына бөлінеді.
• Тасымалдаушыны анықтау дәлдігі: Дұрыс анықталған тасымалдаушылар саны анықтау үшін бағаланған жөнелтілімдер санына бөлінеді.
• Соңғы нәтиже дәлдігі: Дұрыс соңғы нәтижелер саны расталған анықтамалық нәтижесі бар аяқталған жөнелтілімдер санына бөлінеді.
• Бақыланған көрінімділік кідірісі: Сәйкес келген оқиғалар үшін API көрінетін уақыты мен тасымалдаушы жазбасындағы көрінетін уақыттың айырмасы үлестірімі.
• Жаңартуды жеткізу сәттілігі: Қолданбаңыз сәтті қабылдап, өңдеген талап етілетін жаңартулар саны API-де байқалған талап етілетін жаңартулар санына бөлінеді.

Пайдалануға болатын оқиғалар қамтуын есептемей тұрып жарамдылық шарттарын анықтаңыз. Мысалы, тасымалдаушы сканерлеуі жоқ жөнелтілім әлі пайда болмаған транзит оқиғасының жоқтығы ретінде саналмауы керек. Есептен шығарылған және шешілмеген жазбаларды ұпаймен бірге көрсетіңіз, сонда есептен шығару нәтижені жасырын түрде жақсарта алмайды.

Жалпы бағалау қажет болса, бағыт деңгейіндегі пайдалануға болатын оқиғалар нәтижелерін күтілетін тасымалдау қоспаңызға қарай өлшеңіз. Барлық топта бірдей көрсеткішті пайдаланып, салмақтарды көрсетіңіз. Бір тасымалдаушының тіркеу сәттілігін екіншісінің өмірлік цикл сәттілігімен біріктірмеңіз.

Шектерді ойдан шығарылған салалық көрсеткіштен емес, бизнес талаптарынан белгілеңіз. Клиенттерге хабарлау процесі мен қолдау тақтасы әртүрлі кідірістерге төзе алады. Әдеттегі және баяу шеткі нәтижелерді есептеңіз; орташа мәннің өзі бұзушы кідірістерді жасыруы мүмкін.

6. Шартты сатып алу туралы шешім қабылдаңыз

Әр қажетті топты өткен, өтпеген немесе қорытындысы анықталмаған деп жіктеңіз. Қорытындының анықталмауы дәлелдің жеткіліксіз екенін білдіреді — мысалы, бақылау кезінде тапсыру орын алмаған — провайдердің бұл мүмкіндігі жоқ екенін емес.

Міндетті топтар келісілген талаптарға сай болып, қалған шектеулердің қолайлы айналып өту жолдары болса, іске қосуды мақұлдаңыз. Тек нақты анықталған ішкі жиын өткен жағдайда шектеулі іске қосуды мақұлдаңыз. Дәлел толық болмаса, сынақты ұзартыңыз. Тергеу мен қайта сынақтан кейін маңызды олқылық сақталса, ұсынылған ауқымды қабылдамаңыз.

Коммерциялық сәйкестікті техникалық қамтудан бөлек қарастырыңыз. Қолданылатын тіркеулерді, жаңартуларды, қайталауларды және үздіксіз бақылауды қоса отырып, өлшенген жүктемені ұсынылған есеп айырысу шарттары бойынша қайта жүргізіңіз. Есептеу бірліктері немесе шектеулер түсініксіз болса, жазбаша түсіндірме алыңыз; оларды сәтті сынақ қоңырауларына қарап болжамаңыз.

Міндеттеме қабылдау алдындағы бақылау тізімі

• Міндетті тасымалдаушылар, қызметтер және бағыттар нақты аталған.
• Нақты уақыттағы және аяқталған жөнелтілімдердің екеуі де қамтылған.
• Теріс бақылау үлгілері жарамды жөнелтілімдер қамтуынан бөлек көрсетілген.
• Қолжетімді болған жағдайда автоматты анықтау мен тасымалдаушыны нақты таңдау бөлек бағаланған.
• Қажетті қосымша енгізулер құжатталған және жүйелеріңізде қолжетімді.
• Тасымалдаушы жазбаларының дәлелдері мен API-дің бастапқы жауаптары қауіпсіз сақталған.
• Трансшекаралық тапсырулар мен соңғы нәтижелер тексерілген.
• Webhook қабылдауы мен қолданба өңдеуі API қолжетімділігінен бөлек өлшенген.
• Әр көрсеткіштің анықталған бөлгіші, бақылау кезеңі және есептен шығару ережесі бар.
• Маңызды бағыттардың сәтсіздігі жалпы ұпаймен жоққа шығарылмайды.
• Тексерілмеген сценарийлердің жауапты тұлғасы және тексеру жоспары бар.
• Өндірістік конфигурация, қолдауға эскалациялау және есеп айырысу болжамдары расталған.
• Толық көшіруге дейін шектеулі іске қосу және резервтік процесс келісілген.

Жиі қойылатын сұрақтар

Тізімде көрсетілген тасымалдаушының барлық қызметтері қамтылады деген сөз бе?

Бұлай деп болжамаңыз. Тізімді бастапқы нүкте ретінде қарастырып, кейін операцияңыз пайдаланатын қызметті, елдер жұбын, қажетті енгізулерді және өмірлік цикл оқиғаларын тексеріңіз. Тек тасымалдаушы атауы тиісті қызметті анықтамаса, түсіндірме сұраңыз.

Қамтуды тек жеткізілген бақылау нөмірлері арқылы сынай аламын ба?

Жеткізілген жазбалар тарихи егжей-тегжейлер мен соңғы мәртебенің дәлдігін бағалауға көмектеседі. Бірақ олар транзит кезінде жаңартулардың қаншалықты жылдам келетінін немесе webhook процесінің үзілістерден кейін қалпына келетінін анықтай алмайды. Өндірістік интеграцияны мақұлдамас бұрын нақты уақыттағы жөнелтілімдерді қосыңыз.

API мен тасымалдаушы беті сәйкес келмесе, не істеуім керек?

Екі тараптан да уақыт белгісі бар дәлел жинаңыз, тасымалдаушы мен бақылау нөмірін растаңыз және уақыт белдеулері мен мәртебелердің сәйкестігін тексеріңіз. Бақылауды қайталап, қайта жасауға болатын қолдау сұрауын жіберіңіз. Бір сәйкес келмейтін көрініс — тергеуге себеп, бірақ себепті анықтауға жеткілікті дәлел емес.

Әрбір жетіспейтін сканерлеу сынақтан өтпеуге себеп болуы керек пе?

Жоқ. Тасымалдаушы жазбасында сканерлеу болмауы немесе ол сіз талап ететін оқиғалар жиынына кірмеуі мүмкін. Келісілген бақылау кезеңінен кейін күтілетін, тексеруге болатын оқиға жетіспесе, тиісті талапты өтпеді деп белгілеңіз. Белгісіз жағдайларды расталған сәтсіздіктерден бөлек ұстаңыз.

Іске қосылғаннан кейін тасымалдаушы қамтуын қайта сынау керек пе?

Иә. Өкілдік жөнелтілімдерді бақылауды жалғастырыңыз және тасымалдаушыны, қызметті, тағайындалған нарықты немесе интеграция конфигурациясын елеулі түрде өзгерткенде қайта сынаңыз. Кейінгі нәтижелер салыстырмалы болып қалуы үшін бастапқы қабылдау ережелерін сақтаңыз.

Дереккөздер

Төмендегі ресми ресурстар 17TRACK бағалауын жүргізу және интеграция талаптарын растау үшін бастапқы нүкте болып табылады. Осы мақаладағы сынақ рәсімдері, бағалау анықтамалары және сатып алу бақылау тізімі — редакциялық ұсыныстар, жарияланған қызмет кепілдіктері емес.

• 17TRACK Tracking API — 17TRACK API бағалауына арналған ресми өнім анықтамалығы.
• 17TRACK API documentation — ұсынылған іске асыру және сынақ конфигурациясымен салыстыруға арналған ресми техникалық анықтамалық.