สร้างข้อมูลทดสอบด้วยวิธีไหนดี เปรียบเทียบ 6 แนวทางและข้อจำกัดที่ต้องรู้

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

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

วิธีสร้างข้อมูลทดสอบมีกี่แบบ และควรเลือกอย่างไร?

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

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

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

แบบที่หนึ่ง ใช้ไลบรารีในโค้ด

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

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

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

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

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

แบบที่สอง บริการสร้างข้อมูลออนไลน์

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

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

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

ผิดตอนไหน เมื่อข้อมูลออกอินเทอร์เน็ตไม่ได้ เมื่อสายงานอัตโนมัติต้องรันแบบออฟไลน์ หรือเมื่อต้องสร้างครั้งละหลายแสนแถว

แบบที่สาม เครื่องมือสร้างข้อมูลในเบราว์เซอร์

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

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

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

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

แบบที่สี่ เขียนไฟล์ตัวอย่างด้วยมือ

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

ข้อดีข้อหลังนี้สำคัญกว่าที่คิด เพราะหมายความว่าไฟล์นี้ยังใช้ได้แม้เครื่องมือที่เคยใช้สร้างข้อมูลจะเลิกพัฒนาหรือเปลี่ยนรูปแบบไปแล้ว ในขณะที่วิธีที่พึ่งพาบริการภายนอกจะพังทันทีเมื่อฝั่งนั้นเปลี่ยนอะไรสักอย่าง

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

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

แบบที่ห้า ปิดบังข้อมูลจากโปรดักชัน

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

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

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

ผิดตอนไหน เมื่อข้อกำหนดด้านการปฏิบัติตามกฎหมายไม่อนุญาตอย่างชัดเจน หรือเมื่อเราไม่มีความสามารถตรวจสอบว่ากฎการปิดบังครอบคลุมฟิลด์อ่อนไหวครบทุกตัวหรือไม่

แบบที่หก ใช้ชุดตัวอย่างเดิมซ้ำทุกที่

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

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

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

วิธีไหนเหมาะกับงานแบบไหน?

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

รวมวิธีเข้าด้วยกันอย่างไรไม่ให้ขัดกัน?

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

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

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

ตรวจสอบข้อมูลชุดที่สร้างมาอย่างไร?

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

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

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

ควรคอมมิตไฟล์ข้อมูลทดสอบเข้า repo หรือไม่?

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

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

ใช้ไลบรารีกับเครื่องมือออนไลน์ผสมกันได้ไหม?

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

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

ทำไมไม่ใช้ข้อมูลโปรดักชันทั้งหมดไปเลย?

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

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

ก้าวต่อไป

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

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

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