Öhdəlik götürməzdən əvvəl Tracking API-nin daşıyıcı əhatəsini necə yoxlamaq olar (Test planı + Yoxlama siyahısı)

İzləmə API-sinin daşıyıcı əhatəsini öhdəlik götürməzdən əvvəl yoxlamaq üçün öz göndərişlərinizdən istifadə edərək konsepsiyanın sübutunu həyata keçirin, nəticələri daşıyıcının izləmə qeydləri ilə müqayisə edin və performansı daşıyıcı, xidmət və daşınma marşrutu üzrə ölçün. Təkcə izləmə nömrəsinin qəbul edilməsini deyil, istifadə edilə bilən izləmə hadisələrini, dəqiq daşıyıcı identifikasiyasını və yeniləmələrin etibarlı şəkildə çatdırılmasını tələb edin. Sınaq başlamazdan əvvəl keçid/uğursuzluq meyarlarını razılaşdırın.

Bu sınaq planı izləmə API-si seçən mühəndislik, logistika idarəetməsi və e-ticarət əməliyyatları komandaları üçündür. Məqsəd daşıyıcının provayder kataloqunda görünməsi ilə həmin provayderin biznesinizin həqiqətən ehtiyac duyduğu göndəriş görünürlüğünü dəstəkləməsini fərqləndirməkdir.

Əhatəni əməliyyat nəticəsi kimi müəyyən edin

Daşıyıcıların ümumi sayı API-nin göndərişlərinizi izləyə bilib-bilmədiyi sualına cavab vermir. Qəbul meyarlarınız əhatənin bir neçə səviyyəsini fərqləndirməlidir:

• Siyahıya alınmış əhatə: Provayder dərc etdiyi materiallarda daşıyıcını müəyyən edir.
• Qeydiyyat əhatəsi: API izləmə üçün etibarlı göndərişi qəbul edir.
• Hadisə əhatəsi: API həmin göndəriş üçün faydalı daşıyıcı hadisələrini qaytarır.
• Həyat dövrü əhatəsi: İzləmə çatdırılmaya, istisnaya və ya digər müvafiq nəticəyə qədər faydalı olaraq qalır.
• Əməliyyat əhatəsi: Tətbiqiniz razılaşdırılmış tələblər çərçivəsində bu yeniləmələri qəbul edir və şərh edir.

Bunlar sənaye sertifikasiyası deyil, təklif olunan qiymətləndirmə kateqoriyalarıdır. Təchizatçı müzakirələrini dəqiq etmək üçün onlardan istifadə edin. Uğurlu qeydiyyat sonrakı hadisələrin gələcəyini sübut etmir və yalnız bir yekun statusu olan çatdırılmış göndəriş daşınma zamanı görünürlüğün kifayət etdiyini sübut etmir.

Satınalma qərarı ümumi baldan ayrıca nəzərdən keçirilən kritik boşluqlarla birlikdə daşınma çeşidinizin sınaqdan keçirilmiş əhatəsinə əsaslanmalıdır.

1. Biznesinizi əks etdirən göndəriş matrisi yaradın

Sifarişlərin idarəetmə sisteminizdən, anbar platformanızdan və ya daşınma qeydlərinizdən göndərişlərlə başlayın. Daimi daşıyıcı çeşidinizi və istifadə etməyə davam etməyi gözlədiyiniz mövsümi xidmətləri əhatə edən biznes dövrü seçin. Təchizatçının seçdiyi nümayiş dəstinin yeganə sübutunuz olmasına imkan verməyin.

Göndərişləri daşıyıcı, xidmət, göndərilmə yeri, təyinat yeri və təhvil nümunəsi üzrə qruplaşdırın. Eyni daşıyıcı adı hər qrupda görünsə belə, daxili ekspress, sərhədlərarası poçt və ekonom xidmətlər müxtəlif izləmə tələblərinə malik olduqda ayrı saxlanmalıdır.

Sınaq qrupu	Daxil ediləcəklər	Müəyyən etdiyi məsələ
Əsas daşınma marşrutları	Tez-tez istifadə etdiyiniz daşıyıcı-xidmət-ölkə kombinasiyaları	API-nin gündəlik əməliyyatlara uyğun olub-olmaması
Kritik, daha az həcmli marşrutlar	Müştəri öhdəlikləri və ya əvəzetmə xərcləri səbəbindən əhəmiyyətli olan xidmətlər	Ümumi balın ciddi boşluğu gizlədib-gizlətməməsi
Sərhədlərarası təhvilvermələr	Mənşə və təyinat operatorları arasında ötürülən göndərişlər	Görünürlüğün təhvilvermədən sonra qorunub-qorunmaması
İstisnalar və qaytarmalar	Məlum uğursuz cəhdlər, gecikmələr və göndəriciyə qaytarılma marşrutları	Statusların düzgün müştəri əməliyyatını dəstəkləyib-dəstəkləməməsi
Mənfi nəzarətlər	Etibarsız girişlər, uyğun gəlməyən daşıyıcılar və səlahiyyətli sınaq qeydləri	Xətaların etibarlı izləmədən fərqləndirilə bilməsi

Həm tamamlanmış, həm də canlı göndərişlərdən istifadə edin. Tamamlanmış göndərişlər tarixi təfərrüatları və yekun statusun dəqiqliyini qiymətləndirməyə kömək edir. Yeniləmə vaxtını və təhvilvermələri baş verdiyi anda müşahidə etmək üçün canlı göndərişlər zəruridir. Yalnız tarixi nəticələr canlı performansı müəyyən edə bilməz.

Mənfi nəzarətləri etibarlı göndəriş əhatəsi üçün məxrəcdən kənarda saxlayın. Həmçinin ilk fiziki skanı gözləyən göndərişləri artıq daşıyıcı hadisələri olan göndərişlərdən ayırın. Əks halda, normal göndərilməöncəsi davranış əhatə uğursuzluğu kimi görünə bilər.

Nümunə nə qədər böyük olmalıdır?

Daşıyıcı əhatəsini sübut edən universal nümunə ölçüsü yoxdur. İnteqrasiya xətalarını tapmaq üçün idarəolunan pilotla başlayın, sonra tələb olunan göndəriş qrupları üzrə genişləndirin. Bir partiyadan çoxsaylı, demək olar ki, eyni bağlamalar əvəzinə müxtəlif göndərilmə tarixlərini və həyat dövrü mərhələlərini daxil edin.

Hər qrup üçün nümunə sayını bildirin. Bir neçə göndərişdən əldə edilən təmiz nəticə ilkin sübutdur, zəmanət deyil. Nadir, lakin vacib istisna sınaq zamanı baş verməzsə, həmin ssenarini sınaqdan keçirilməmiş kimi qeyd edin və ona keçid vermək əvəzinə ayrıca yoxlama təşkil edin.

2. İnteqrasiyadan əvvəl sınaq müqaviləsini razılaşdırın

Komandalardan hər hansı biri nəticələri görməzdən əvvəl uğurun nədən ibarət olduğunu yazılı şəkildə müəyyən edin. Mühəndislik üzrə məsul şəxs məlumat və çatdırılma tələblərini müəyyən etməlidir; logistika üzrə məsul şəxs məcburi marşrutları və status mənalarını müəyyən etməlidir; satınalma üzrə məsul şəxs sınaqdan keçirilmiş konfiqurasiyanın təklif olunan kommersiya xidmətinə uyğun olduğunu təsdiqləməlidir.

Hər namizəddən aşağıdakıları təsdiqləməsini istəyin:

• Göndəriş matrisiniz üçün hansı dəqiq daşıyıcı identifikatorlarının və xidmət variantlarının tətbiq edildiyi.
• İzləmənin poçt indeksi, təyinat ölkəsi, hesab avtorizasiyası və ya başqa giriş tələb edib-etmədiyi.
• Sınaqda istehsal məlumat mənbələrindən istifadə olunub-olunmadığı və hər hansı sınaq məhdudiyyətinin testə təsir edib-etmədiyi.
• Tarixi əlçatanlığın, izləmə müddətinin, sorğulamanın və webhook çatdırılmasının necə sənədləşdirildiyi.
• Təklif olunan plan üzrə hansı qeydiyyat, yeniləmə, abunəlik və ya təkrar cəhd əməliyyatlarının ödənişli ola biləcəyi.
• Çatışmayan yeniləmənin və ya daşıyıcıya xas insidentin necə eskalasiya edilməli olduğu.

17TRACK qiymətləndirməsi üçün məhsul və inteqrasiya suallarına başlanğıc nöqtəsi kimi Tracking API məhsul səhifəsindən və rəsmi API sənədlərindən istifadə edin. İstənilən digər namizəd üçün istifadə etdiyiniz eyni göndəriş matrisini və qəbul qaydalarını tətbiq edin. İctimai izləmə səhifəsinin nəticəsi çarpaz yoxlama kimi qəbul edilməlidir, tətbiqinizin alacağı API cavabının sübutu kimi yox.

Sənəddə imkanın aydın olmaması səbəbindən dərhal uğursuzluq təyin etməyin. Bunu təsdiq tələb edən məsələ kimi qeyd edin, konkret sual verin və mümkün olduqda cavabı sınaqdan keçirin.

3. Hər göndəriş üçün sübut qeydi yaradın

Hər göndəriş üçün bir qeyd və əlaqələndirilmiş hadisə müşahidələri olan elektron cədvəldən və ya sınaq məlumat bazasından istifadə edin. Lazımsız müştəri məlumatlarını yaymadan uyğunsuzluğu yenidən yaratmaq üçün kifayət qədər məlumatı qoruyun.

• Daxili sınaq ID-si və təhlükəsiz saxlanılan izləmə nömrəsi.
• Gözlənilən daşıyıcı, xidmət, mənşə, təyinat və məlum sonrakı daşıyıcı.
• API versiyası, mühit, konfiqurasiya və qeydiyyat vaxtı.
• Təqdim edilmiş daşıyıcı identifikatoru və tələb olunan əlavə girişlər.
• Qeydiyyat cavabı, aşkar edilmiş daşıyıcı, qaytarılmış status və xam hadisə məlumatları.
• Müşahidə vaxtları ilə daşıyıcı istinad görüntüləri.
• Tətbiq olunduqda API müşahidə vaxtları və webhook qəbul vaxtları.
• Qərar, uyğunsuzluq kateqoriyası, araşdırmaya məsul şəxs və yenidən sınaq nəticəsi.

Müşahidə vaxtları üçün UTC-dən istifadə edin, lakin ilkin hadisə vaxtlarını və ofsetləri qoruyun. Skanın hadisə vaxtı ilə sisteminizin həmin skanı qəbul etdiyi vaxt fərqli ölçülərdir. Onları qarışdırmaq yanıltıcı gecikmə nəticələri yarada bilər.

Emal etməyə səlahiyyətiniz olan göndəriş qeydlərindən istifadə edin. Məlumat yüklərinə çıxışı məhdudlaşdırın və satınalma hesabatlarından ünvanları, alıcı adlarını və digər lazımsız şəxsi məlumatları silin.

4. Sınağı dörd mərhələdə həyata keçirin

A mərhələsi: Qeydiyyat və daşıyıcının identifikasiyası

Etibarlı göndərişləri sənədləşdirilmiş girişlərdən istifadə edərək qeydiyyatdan keçirin. Həm avtomatik aşkarlama, həm də dəqiq daşıyıcı seçimi mövcuddursa, onları ayrıca sınaqdan keçirin. Səhv uyğunluqları, qeyri-müəyyən uyğunluqları, rədd edilmiş girişləri və qəbul edilən, lakin heç vaxt hadisə yaratmayan qeydləri qeyd edin.

Avtomatik aşkarlama uğursuz olduqdan sonra dəqiq seçim uğurlu olarsa, məsələni daşıyıcının tam əlçatmazlığı deyil, aşkarlama boşluğu kimi təsnif edin. Daşınma sisteminiz daşıyıcını artıq bilirsə və onu etibarlı şəkildə təqdim edə bilirsə, bu fərq əhəmiyyətlidir.

Mənfi nəzarətlər üçün API-nin etibarsız və ya uyğun gəlməyən qeydi inamla müəyyən edilmiş göndəriş kimi təqdim etmədiyini yoxlayın. Digər müştərilərə aid ola biləcək təsadüfi izləmə nömrələrini təxmin etməyin.

B mərhələsi: Hadisə məzmunu və status mənası

API hadisələrini müvafiq daşıyıcının izləmə kanalından alınmış vaxt möhürlü qeydlərlə müqayisə edin. Hadisə təsvirlərini, təqdim edildikdə yerləri, hadisələrin ardıcıllığını və yekun nəticələri yoxlayın. Normallaşdırılmış API statusu ilə yanaşı xam daşıyıcı təsvirini də qoruyun.

Biznes əməliyyatlarını dəyişən fərqlərə diqqət yetirin. Uğursuz çatdırılma cəhdi çatdırılma e-poçtunu işə salmamalıdır. Göndəriciyə qaytarılma hadisəsi müştəri qaytarmasının anbarınız tərəfindən qəbul edilməsi ilə səhv salınmamalıdır. Gömrüklə bağlı yeniləmə avtomatik olaraq ödəniş tələbi kimi şərh edilməməlidir.

Daşıyıcı istinadları təqdimat və ya yeniləmə vaxtına görə də fərqlənə bilər. Uyğunsuzluq yaranarsa, günahlandırmadan əvvəl hər iki müşahidəni qeyd edin və araşdırın. Fiziki skanları olmayan alınmış etiket qeydləri üçün göndərilməöncəsi vəziyyəti ayrıca qiymətləndirin.

C mərhələsi: Canlı yeniləmələr və sisteminizə çatdırılma

Sənədləşdirilmiş məhdudiyyətlərə riayət edən ardıcıl tezliklə canlı göndərişləri müşahidə edin. Hadisənin daşıyıcı istinad yoxlamalarınızda ilk dəfə görünməsi ilə API vasitəsilə ilk dəfə görünməsi arasındakı vaxtı müqayisə edin. Bunu müşahidə olunan görünürlük gecikməsi adlandırın: bu, müşahidə cədvəlinizlə məhdudlaşan təxmindir və provayderin daxili emal vaxtının dəqiq ölçüsü deyil.

Webhook-lar təklif olunan inteqrasiyanın bir hissəsidirsə, qəbul vaxtını və emal nəticəsini qeyd edin. Sənədləşdirilmiş mexanizmlərdən və ya razılaşdırılmış sınaq prosedurlarından istifadə edərək dublikatların işlənməsini, müvəqqəti endpoint xətasından sonra təkrar cəhdləri və buraxılmış yeniləmələrin bərpasını yoxlayın. İstehsal endpoint-lərini qəsdən pozmaqdan çəkinin.

API-yə çatan, lakin sifariş sisteminizə heç vaxt çatmayan daşıyıcı hadisəsi API-də çatışmayan hadisə ilə eyni uğursuzluq deyil. Məsul komandanın düzgün səviyyəni düzəldə bilməsi üçün bu nəticələri ayrı saxlayın.

D mərhələsi: Sərhədlərarası davamlılıq

Göndərişləri ixrac, təyinat yerinə çatma, təhvilvermə və müşahidə edilə bildiyi hallarda çatdırılma mərhələləri boyunca izləyin. Sonrakı daşıyıcının və ya əvəzləyici izləmə nömrəsinin göstərilib-göstərilmədiyini və inteqrasiyanızın onu ilkin sifarişlə əlaqələndirib-əlaqələndirə bildiyini qeyd edin.

Sərhədlərarası daşınma üçün yalnız mənşə daşıyıcısını deyil, tam marşrutu sınaqdan keçirin. Bağlama çatdırılır, lakin API ixrac mərhələsində qalırsa, o, başdan-başa görünürlük tələbini yerinə yetirməyib. Əksinə, beynəlxalq tranzit zamanı skanların müvəqqəti olmaması öz-özlüyündə API uğursuzluğunun sübutu deyil.

5. Boşluqları gizlətmədən nəticələri bal ilə qiymətləndirin

Aydın məxrəclərdən istifadə edin və nəticələri daşıyıcı-xidmət-marşrut qrupları üzrə göstərin. Bu ölçülər praktik qiymətləndirmə cədvəli yaradır:

• Qeydiyyat uğuru: Təqdim edilmiş etibarlı göndərişlər içərisində qəbul edilmiş etibarlı göndərişlərin payı.
• İstifadə edilə bilən hadisə əhatəsi: Qəbul qaydalarınızın tələb etdiyi hadisələri qaytaran uyğun göndərişlərin sınaqdan keçirilmiş uyğun göndərişlərə nisbəti.
• Daşıyıcının identifikasiyası dəqiqliyi: Düzgün daşıyıcı identifikasiyalarının aşkarlama üçün qiymətləndirilmiş göndərişlərə nisbəti.
• Yekun nəticənin dəqiqliyi: Düzgün yekun nəticələrin təsdiqlənmiş istinad nəticəsi olan tamamlanmış göndərişlərə nisbəti.
• Müşahidə olunan görünürlük gecikməsi: Uyğunlaşdırılmış hadisələr üçün API görünürlük vaxtı ilə daşıyıcı istinadının görünürlük vaxtı arasındakı fərqin paylanması.
• Yeniləmələrin çatdırılması uğuru: Tətbiqiniz tərəfindən uğurla qəbul edilən və emal olunan tələb olunan yeniləmələrin API-də müşahidə edilmiş tələb olunan yeniləmələrə nisbəti.

İstifadə edilə bilən hadisə əhatəsini hesablamazdan əvvəl uyğunluğu müəyyən edin. Məsələn, daşıyıcı skanı olmayan göndəriş hələ mövcud olmayan tranzit hadisəsinin çatışmadığı kimi hesablanmamalıdır. Nəticədən kənarlaşdırılmış və həll edilməmiş qeydləri balla birlikdə bildirin ki, kənarlaşdırmalar nəticəni səssizcə yaxşılaşdıra bilməsin.

Ümumi təxminə ehtiyacınız varsa, marşrut səviyyəsində istifadə edilə bilən hadisə nəticələrini gözlənilən daşınma çeşidinizə görə çəkin. Bütün qruplar üzrə eyni metrikdən istifadə edin və çəkiləri göstərin. Bir daşıyıcı üçün qeydiyyat uğurunu digəri üçün həyat dövrü uğuru ilə birləşdirməyin.

Hədləri uydurulmuş sənaye göstəricisinə deyil, biznes tələblərinə əsasən müəyyən edin. Müştəri bildirişləri iş axını və dəstək paneli fərqli gecikmələrə dözə bilər. Tipik və daha yavaş quyruq davranışını bildirin; yalnız orta göstərici pozucu gecikmələri gizlədə bilər.

6. Şərti satınalma qərarı verin

Hər tələb olunan qrupu keçmiş, uğursuz və ya qeyri-müəyyən kimi təsnif edin. Qeyri-müəyyən o deməkdir ki, sübut kifayət deyil — məsələn, müşahidə zamanı təhvilvermə baş verməyib — provayderin bu imkana malik olmadığı deyil.

Məcburi qruplar razılaşdırılmış tələblərə cavab verdikdə və qalan məhdudiyyətlərin məqbul alternativləri olduqda yerləşdirməni təsdiqləyin. Yalnız dəqiq müəyyən edilmiş alt qrup keçdikdə məhdudlaşdırılmış tətbiqi təsdiqləyin. Sübut natamam olduqda sınağı uzadın. Araşdırma və yenidən sınaqdan sonra kritik boşluq qalırsa, təklif olunan əhatəni rədd edin.

Kommersiya uyğunluğunu texniki əhatədən ayrı saxlayın. Tətbiq olunan qeydiyyat, yeniləmə, təkrar cəhd və davamlı izləmə daxil olmaqla ölçülmüş iş yükünü təklif olunan ödəniş şərtlərinə əsasən yenidən hesablayın. Ödəniş vahidləri və ya limitlər qeyri-müəyyəndirsə, yazılı açıqlama alın; onları uğurlu sınaq çağırışlarından çıxarmayın.

Öhdəlikdən əvvəl yoxlama siyahısı

• Məcburi daşıyıcılar, xidmətlər və marşrutlar açıq şəkildə adlandırılıb.
• Həm canlı, həm də tamamlanmış göndərişlər təmsil olunur.
• Mənfi nəzarətlər etibarlı göndəriş əhatəsindən ayrılıb.
• Mümkün olduqda avtomatik aşkarlama və dəqiq daşıyıcı seçimi ayrıca qiymətləndirilib.
• Tələb olunan əlavə girişlər sənədləşdirilib və sistemlərinizdə mövcuddur.
• Daşıyıcı istinad sübutları və xam API cavabları təhlükəsiz saxlanılır.
• Sərhədlərarası təhvilvermələr və yekun nəticələr yoxlanılıb.
• Webhook qəbulu və tətbiq emalı API əlçatanlığından ayrıca ölçülür.
• Hər metrik üçün müəyyən edilmiş məxrəc, müşahidə pəncərəsi və kənarlaşdırma qaydası var.
• Kritik marşrut uğursuzluqları ümumi balla aradan qaldırıla bilməz.
• Sınaqdan keçirilməmiş ssenarilərin məsul şəxsi və yoxlama planı var.
• İstehsal konfiqurasiyası, dəstəyə eskalasiya və ödəniş fərziyyələri təsdiqlənib.
• Tam miqyaslı miqrasiyadan əvvəl məhdud tətbiq və geri qayıtma prosesi razılaşdırılıb.

Tez-tez verilən suallar

Siyahıya alınmış daşıyıcı onun bütün xidmətlərinin əhatə olunduğu deməkdir?

Bunu fərz etməyin. Siyahını başlanğıc nöqtəsi kimi qəbul edin, sonra əməliyyatınızın istifadə etdiyi xidməti, ölkə cütünü, tələb olunan girişləri və həyat dövrü hadisələrini yoxlayın. Yalnız daşıyıcının adı müvafiq xidməti müəyyən etmədikdə açıqlama istəyin.

Əhatəni yalnız çatdırılmış izləmə nömrələrindən istifadə edərək sınaqdan keçirə bilərəm?

Çatdırılmış qeydlər tarixi təfərrüatları və yekun statusun dəqiqliyini qiymətləndirməyə kömək edə bilər. Onlar tranzit zamanı yeniləmələrin nə qədər tez gəldiyini və ya webhook iş axınınızın fasilələrdən sonra bərpa olunub-olunmadığını müəyyən edə bilməz. İstehsal inteqrasiyasını təsdiqləməzdən əvvəl canlı göndərişləri daxil edin.

API və daşıyıcının səhifəsi razılaşmadıqda nə etməliyəm?

Hər ikisindən vaxt möhürlü sübut toplayın, daşıyıcını və izləmə nömrəsini yoxlayın, vaxt zonalarını və status uyğunlaşdırılmasını nəzərdən keçirin. Müşahidəni təkrarlayın və yenidən yaradıla bilən dəstək işi qaldırın. Tək uyğunsuz görüntü araşdırma səbəbidir, səbəbi müəyyən etmək üçün kifayət qədər sübut deyil.

Hər çatışmayan skan sınağın uğursuz sayılmasına səbəb olmalıdır?

Xeyr. Daşıyıcı istinadında skan olmaya bilər və ya tələb olunan hadisə dəstinizə daxil olmaya bilər. Gözlənilən, yoxlanıla bilən hadisə razılaşdırılmış müşahidə pəncərəsindən kənarda çatışmadıqda müvafiq tələbi uğursuz hesab edin. Naməlum halları təsdiqlənmiş uğursuzluqlardan ayrı saxlayın.

Daşıyıcı əhatəsi istifadəyə verildikdən sonra yenidən sınaqdan keçirilməlidirmi?

Bəli. Nümunəvi göndərişləri izləməyə davam edin və daşıyıcı, xidmət, təyinat bazarı və ya əhəmiyyətli dərəcədə fərqli inteqrasiya konfiqurasiyası əlavə etdikdə yenidən sınaqdan keçirin. Sonrakı nəticələrin müqayisə oluna bilməsi üçün ilkin qəbul qaydalarını qoruyun.

Mənbələr

Aşağıdakı rəsmi resurslar 17TRACK-i qiymətləndirmək və inteqrasiya tələblərini təsdiqləmək üçün başlanğıc nöqtələridir. Bu məqalədəki sınaq prosedurları, bal hesablanması tərifləri və satınalma yoxlama siyahısı redaksiya tövsiyələridir, dərc edilmiş xidmət zəmanətləri deyil.

• 17TRACK Tracking API — 17TRACK API qiymətləndirməsi üçün rəsmi məhsul istinadı.
• 17TRACK API documentation — təklif olunan tətbiqiniz və sınaq konfiqurasiyanızla müqayisə etmək üçün rəsmi texniki istinad.