วิธีทดสอบการรองรับผู้ให้บริการขนส่งของ Tracking API ก่อนตัดสินใจใช้งาน (แผนการทดสอบ + รายการตรวจสอบ)

หากต้องการทดสอบความครอบคลุมผู้ให้บริการขนส่งของ API ติดตามพัสดุก่อนตัดสินใจใช้งาน ให้ทำ proof of concept โดยใช้พัสดุของคุณเอง ตรวจสอบผลลัพธ์กับบันทึกการติดตามของผู้ให้บริการขนส่ง และวัดประสิทธิภาพแยกตามผู้ให้บริการ บริการ และเส้นทางการจัดส่ง กำหนดให้มีเหตุการณ์การติดตามที่ใช้งานได้ การระบุผู้ให้บริการขนส่งที่ถูกต้อง และการส่งข้อมูลอัปเดตที่เชื่อถือได้ ไม่ใช่เพียงการยอมรับหมายเลขติดตามเท่านั้น ตกลงเกณฑ์ผ่าน/ไม่ผ่านก่อนเริ่มการทดลอง

แผนการทดสอบนี้จัดทำขึ้นสำหรับทีมวิศวกรรม การจัดการโลจิสติกส์ และการดำเนินงานอีคอมเมิร์ซที่กำลังเลือก API ติดตามพัสดุ โดยมีวัตถุประสงค์เพื่อแยกความแตกต่างระหว่างการที่ผู้ให้บริการขนส่งปรากฏอยู่ในไดเรกทอรีของผู้ให้บริการ API กับการที่ผู้ให้บริการ API รองรับการมองเห็นสถานะพัสดุตามที่ธุรกิจของคุณต้องการจริง

กำหนดความครอบคลุมในรูปแบบผลลัพธ์ด้านการดำเนินงาน

จำนวนผู้ให้บริการขนส่งที่ระบุไว้ในภาพรวมไม่สามารถตอบได้ว่า API สามารถติดตามพัสดุของคุณได้หรือไม่ เกณฑ์การยอมรับควรแยกความครอบคลุมออกเป็นหลายระดับ:

• ความครอบคลุมด้านการระบุรายชื่อ: ผู้ให้บริการระบุผู้ให้บริการขนส่งไว้ในเอกสารที่เผยแพร่
• ความครอบคลุมด้านการลงทะเบียน: API ยอมรับพัสดุที่ถูกต้องเพื่อการติดตาม
• ความครอบคลุมด้านเหตุการณ์: API ส่งคืนเหตุการณ์ของผู้ให้บริการขนส่งที่เป็นประโยชน์สำหรับพัสดุนั้น
• ความครอบคลุมตลอดวงจรชีวิต: การติดตามยังคงมีประโยชน์จนถึงการจัดส่ง เหตุผิดปกติ หรือผลลัพธ์อื่นที่เกี่ยวข้อง
• ความครอบคลุมด้านการดำเนินงาน: แอปพลิเคชันของคุณได้รับและตีความข้อมูลอัปเดตเหล่านั้นภายในข้อกำหนดที่ตกลงกัน

หมวดหมู่เหล่านี้เป็นแนวทางการประเมินที่เสนอ ไม่ใช่การรับรองมาตรฐานอุตสาหกรรม ใช้หมวดหมู่เหล่านี้เพื่อทำให้การหารือกับผู้ขายมีความชัดเจน การลงทะเบียนสำเร็จไม่ได้พิสูจน์ว่าเหตุการณ์ในภายหลังจะมาถึง และพัสดุที่จัดส่งแล้วพร้อมสถานะสุดท้ายเพียงรายการเดียวไม่ได้พิสูจน์ว่าการมองเห็นสถานะระหว่างขนส่งเพียงพอ

การตัดสินใจซื้อควรอิงจากความครอบคลุมที่ทดสอบกับส่วนผสมการจัดส่งของคุณ โดยแยกช่องว่างที่สำคัญออกจากคะแนนรวม

1. สร้างเมทริกซ์พัสดุที่สะท้อนธุรกิจของคุณ

เริ่มจากพัสดุในระบบจัดการคำสั่งซื้อ แพลตฟอร์มคลังสินค้า หรือบันทึกการจัดส่ง เลือกช่วงเวลาทางธุรกิจที่ครอบคลุมส่วนผสมผู้ให้บริการขนส่งตามปกติ รวมถึงบริการตามฤดูกาลที่คาดว่าจะใช้งานต่อ อย่าให้ชุดข้อมูลสาธิตที่ผู้ขายเลือกกลายเป็นหลักฐานเพียงอย่างเดียว

จัดกลุ่มพัสดุตามผู้ให้บริการขนส่ง บริการ ต้นทาง ปลายทาง และรูปแบบการส่งต่อ การจัดส่งด่วนภายในประเทศ ไปรษณีย์ข้ามพรมแดน และบริการประหยัดควรแยกกันเมื่อมีข้อกำหนดการติดตามที่แตกต่างกัน แม้ว่าจะปรากฏชื่อผู้ให้บริการขนส่งรายเดียวกันในแต่ละกลุ่ม

กลุ่มทดสอบ	สิ่งที่ควรรวม	สิ่งที่ใช้ยืนยัน
เส้นทางการจัดส่งหลัก	ชุดผู้ให้บริการขนส่ง-บริการ-ประเทศที่ใช้งานบ่อย	API เหมาะกับการดำเนินงานประจำวันหรือไม่
เส้นทางปริมาณน้อยที่สำคัญ	บริการที่สำคัญเนื่องจากข้อผูกพันต่อลูกค้าหรือต้นทุนการเปลี่ยนสินค้า	คะแนนรวมซ่อนช่องว่างร้ายแรงหรือไม่
การส่งต่อข้ามพรมแดน	พัสดุที่ส่งต่อระหว่างผู้ให้บริการต้นทางและปลายทาง	การมองเห็นสถานะยังคงต่อเนื่องหลังการส่งต่อหรือไม่
เหตุผิดปกติและการคืนสินค้า	ความพยายามจัดส่งที่ล้มเหลว ความล่าช้า และการเดินทางส่งคืนผู้ส่งที่ทราบอยู่แล้ว	สถานะสนับสนุนการดำเนินการต่อลูกค้าที่เหมาะสมหรือไม่
ชุดควบคุมเชิงลบ	ข้อมูลนำเข้าที่ไม่ถูกต้อง ผู้ให้บริการขนส่งไม่ตรงกัน และระเบียนทดสอบที่ได้รับอนุญาต	ข้อผิดพลาดแยกจากการติดตามที่ถูกต้องได้หรือไม่

ใช้ทั้งพัสดุที่จัดส่งเสร็จแล้วและพัสดุที่กำลังดำเนินการ พัสดุที่เสร็จสมบูรณ์ช่วยประเมินรายละเอียดในอดีตและความถูกต้องของสถานะสุดท้าย ส่วนพัสดุที่กำลังดำเนินการจำเป็นต่อการสังเกตเวลาอัปเดตและการส่งต่อขณะเกิดขึ้นจริง ผลลัพธ์ในอดีตเพียงอย่างเดียวไม่สามารถยืนยันประสิทธิภาพแบบเรียลไทม์ได้

ไม่นำชุดควบคุมเชิงลบไปรวมในตัวหารของความครอบคลุมพัสดุที่ถูกต้อง และแยกพัสดุที่รอการสแกนทางกายภาพครั้งแรกออกจากพัสดุที่มีเหตุการณ์ของผู้ให้บริการขนส่งแล้ว มิฉะนั้นพฤติกรรมปกติก่อนการจัดส่งอาจดูเหมือนความล้มเหลวด้านความครอบคลุม

ตัวอย่างควรมีขนาดเท่าใด

ไม่มีขนาดตัวอย่างสากลที่ใช้พิสูจน์ความครอบคลุมของผู้ให้บริการขนส่งได้ เริ่มจากโครงการนำร่องที่จัดการได้เพื่อค้นหาข้อผิดพลาดในการผสานรวม จากนั้นขยายไปยังกลุ่มพัสดุที่จำเป็นทั้งหมด รวมวันที่ส่งและระยะวงจรชีวิตที่แตกต่างกัน แทนการใช้พัสดุจำนวนมากที่เกือบเหมือนกันจากชุดเดียว

รายงานจำนวนตัวอย่างสำหรับทุกกลุ่ม ผลลัพธ์ที่ดีจากพัสดุเพียงไม่กี่รายการเป็นเพียงหลักฐานเบื้องต้น ไม่ใช่การรับประกัน หากเหตุผิดปกติที่พบได้น้อยแต่สำคัญไม่เกิดขึ้นระหว่างการทดลอง ให้ระบุสถานการณ์นั้นว่าไม่ได้ทดสอบ และจัดการตรวจสอบแยกต่างหาก แทนการให้ผลผ่าน

2. ตกลงเงื่อนไขการทดสอบก่อนการผสานรวม

บันทึกสิ่งที่ถือว่าประสบความสำเร็จก่อนที่ทีมใดทีมหนึ่งจะเห็นผลลัพธ์ ผู้รับผิดชอบด้านวิศวกรรมควรกำหนดข้อกำหนดด้านข้อมูลและการส่งมอบ ผู้รับผิดชอบด้านโลจิสติกส์ควรระบุเส้นทางและความหมายของสถานะที่จำเป็น และผู้รับผิดชอบด้านจัดซื้อควรยืนยันว่าการกำหนดค่าที่ทดสอบตรงกับบริการเชิงพาณิชย์ที่เสนอ

ขอให้ผู้สมัครแต่ละรายยืนยัน:

• ตัวระบุผู้ให้บริการขนส่งและรูปแบบบริการที่แน่นอนซึ่งใช้กับเมทริกซ์พัสดุของคุณ
• การติดตามจำเป็นต้องใช้รหัสไปรษณีย์ ประเทศปลายทาง การอนุญาตบัญชี หรือข้อมูลอื่นหรือไม่
• การทดลองใช้แหล่งข้อมูลจริงหรือไม่ และข้อจำกัดของการทดลองมีผลต่อการทดสอบหรือไม่
• มีการจัดทำเอกสารเกี่ยวกับความพร้อมใช้งานของข้อมูลย้อนหลัง ระยะเวลาการติดตาม การเรียกตรวจสอบ และการส่ง webhook อย่างไร
• การลงทะเบียน การรีเฟรช การสมัครรับข้อมูล หรือการลองใหม่รายการใดอาจมีค่าใช้จ่ายตามแผนที่เสนอ
• ควรยกระดับกรณีข้อมูลอัปเดตหายไปหรือเหตุการณ์เฉพาะผู้ให้บริการขนส่งอย่างไร

สำหรับการประเมิน 17TRACK ให้ใช้ หน้าผลิตภัณฑ์ Tracking API และ เอกสาร API อย่างเป็นทางการ เป็นจุดเริ่มต้นสำหรับคำถามด้านผลิตภัณฑ์และการผสานรวม ใช้เมทริกซ์พัสดุและกฎการยอมรับเดียวกับที่ใช้กับผู้สมัครรายอื่น ผลลัพธ์จากหน้าติดตามสาธารณะควรใช้เป็นการตรวจสอบไขว้ ไม่ใช่หลักฐานยืนยันการตอบกลับ API ที่แอปพลิเคชันของคุณจะได้รับ

อย่าตัดสินว่าไม่ผ่านเพียงเพราะเอกสารไม่ชัดเจนเกี่ยวกับความสามารถบางอย่าง ให้บันทึกว่าอยู่ระหว่างรอการยืนยัน ตั้งคำถามที่เฉพาะเจาะจง และทดสอบคำตอบเมื่อทำได้

3. สร้างบันทึกหลักฐานสำหรับพัสดุทุกชิ้น

ใช้สเปรดชีตหรือฐานข้อมูลทดสอบที่มีหนึ่งระเบียนต่อพัสดุและเชื่อมโยงกับการสังเกตเหตุการณ์ เก็บข้อมูลให้เพียงพอสำหรับทำซ้ำการตรวจสอบความคลาดเคลื่อน โดยไม่เผยแพร่ข้อมูลลูกค้าที่ไม่จำเป็น

• รหัสทดสอบภายในและหมายเลขติดตามที่จัดเก็บอย่างปลอดภัย
• ผู้ให้บริการขนส่ง บริการ ต้นทาง ปลายทาง และผู้ให้บริการขนส่งปลายทางที่ทราบ
• เวอร์ชัน API สภาพแวดล้อม การกำหนดค่า และเวลาลงทะเบียน
• ตัวระบุผู้ให้บริการขนส่งที่ส่งไปและข้อมูลเพิ่มเติมที่จำเป็น
• การตอบกลับการลงทะเบียน ผู้ให้บริการขนส่งที่ตรวจพบ สถานะที่ส่งคืน และ payload เหตุการณ์ดิบ
• ภาพบันทึกจากข้อมูลอ้างอิงของผู้ให้บริการขนส่งพร้อมเวลาที่สังเกต
• เวลาที่สังเกตจาก API และเวลาที่ได้รับ webhook หากเกี่ยวข้อง
• ผลตัดสิน หมวดหมู่ความคลาดเคลื่อน ผู้รับผิดชอบการตรวจสอบ และผลการทดสอบซ้ำ

ใช้ UTC สำหรับเวลาที่สังเกต โดยเก็บเวลาของเหตุการณ์ดั้งเดิมและส่วนชดเชยเวลาไว้ด้วย เวลาที่เกิดเหตุการณ์สแกนกับเวลาที่ระบบของคุณได้รับข้อมูลสแกนนั้นเป็นการวัดคนละอย่าง การสับสนระหว่างสองเวลานี้อาจทำให้ผลความหน่วงคลาดเคลื่อน

ใช้ระเบียนพัสดุที่คุณได้รับอนุญาตให้ประมวลผล จำกัดการเข้าถึง payload และลบที่อยู่ ชื่อผู้รับ และข้อมูลส่วนบุคคลอื่นที่ไม่จำเป็นออกจากรายงานจัดซื้อ

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 — ข้อมูลอ้างอิงทางเทคนิคอย่างเป็นทางการสำหรับตรวจสอบกับการใช้งานและการกำหนดค่าการทดสอบที่เสนอ