ดักจับอีเมลในงานทดสอบ ทำไมไม่ควรพึ่งบริการอีเมลภายนอก

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

ปัญหาของการพึ่งบริการอีเมลจริงในงานทดสอบ

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

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

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

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

ทำไมวิธีนี้จึงเสถียรกว่าและเร็วกว่า?

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

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

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

การดักจับในเครื่องทำงานอย่างไร?

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

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

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

กับดักที่ทำให้ผลทดสอบไม่นิ่ง

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

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

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

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

สำหรับนักพัฒนา: การแยกพอร์ต ที่อยู่ และการยืนยันผล

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

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

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

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

เริ่มย้ายมาใช้วิธีนี้อย่างไร?

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

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

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

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