การถดถอย — ความหมาย สาเหตุ และวิธีการทดสอบ
การถดถอย คือบั๊กที่เกิดขึ้นหลังจากทำการเปลี่ยนแปลงโค้ด แม้ว่าฟังก์ชันการทำงานเดียวกันจะทำงานได้อย่างถูกต้องก่อนหน้านี้ การถดถอยหมายถึงการเปลี่ยนแปลงใหม่ได้ «ทำลาย» สิ่งที่ถูกเขียนและทดสอบไปแล้วก่อนหน้านี้ นี่เป็นหนึ่งในปัญหาที่พบบ่อยและอันตรายที่สุดในการพัฒนา: เมื่อแก้ไขบั๊กหนึ่งตัว นักพัฒนาอาจเผลอทำลายฟีเจอร์อื่นอีกสามตัวโดยไม่รู้ตัว ตามข้อมูลของ Capers Jones Software Engineering 2023 ความหนาแน่นเฉลี่ยของบั๊กการถดถอยคือ 1–3 ต่อทุก 100 บรรทัดของโค้ดที่เปลี่ยนแปลง มาทำความเข้าใจสาเหตุของการถดถอย วิธีการตรวจจับ และกลยุทธ์การป้องกันกัน
ประเด็นสำคัญ
- การถดถอย คือบั๊กที่เกิดขึ้นหลังจากเปลี่ยนแปลงโค้ดที่เคยทำงานได้มาก่อน
- สาเหตุหลักคือ ผลข้างเคียง ของการเปลี่ยนแปลง: โค้ดเชื่อมต่อกันด้วยการพึ่งพาที่ซ่อนอยู่
- การทดสอบหน่วย และการทดสอบการถดถอยเป็นเครื่องมือหลักในการตรวจจับการถดถอย
- การทดสอบการถดถอยด้วยตนเอง ไม่สามารถปรับขนาดได้ — จำเป็นต้องมีระบบอัตโนมัติ
- ไปป์ไลน์ CI/CD ที่มี การทดสอบอัตโนมัติ จับการถดถอยได้ก่อนถึงโปรดักชัน
การถดถอยในการพัฒนาคืออะไร
การถดถอย คือสถานการณ์ที่ฟังก์ชันการทำงานที่เคยใช้ได้ในเวอร์ชันก่อนหน้าหยุดทำงานหลังจากทำการเปลี่ยนแปลง การเปลี่ยนแปลงอาจเป็นอะไรก็ได้: การแก้ไขบั๊ก การเพิ่มฟีเจอร์ใหม่ การรีแฟคเตอร์ การอัปเดตไลบรารี หรือแม้แต่การเปลี่ยนการกำหนดค่า การถดถอยเป็นศัตรูหลักของความเสถียร: ทุกการเปลี่ยนแปลงมีความเสี่ยงที่จะทำลายสิ่งที่ได้รับการตรวจสอบและเผยแพร่แล้ว
คำนี้มาจากการทดสอบ: การทดสอบการถดถอย คือกระบวนการรันการทดสอบที่มีอยู่ซ้ำหลังจากการเปลี่ยนแปลงแต่ละครั้งเพื่อตรวจสอบว่าฟังก์ชันการทำงานเก่าไม่ถูกทำลาย หากการทดสอบที่เคยผ่านมาก่อนล้มเหลว แสดงว่าเกิดการถดถอยขึ้น ในความหมายที่กว้างขึ้น การถดถอยไม่ใช่แค่ความล้มเหลวของการทดสอบ แต่เป็นการเสื่อมสภาพของพฤติกรรมใด ๆ ที่ผู้ใช้หรือ QA สังเกตเห็น ตามข้อมูลของ Tricentis State of Testing 2023 การถดถอยคิดเป็น 35–45% ของบั๊กทั้งหมดที่พบในโปรดักชัน
สิ่งที่แยกการถดถอยออกจากบั๊กทั่วไปคือ บริบทของเวลา: บั๊กทั่วไปอาจมีอยู่ตั้งแต่แรกเริ่ม ในขณะที่การถดถอยเป็นผลมาจากการเปลี่ยนแปลงเสมอ ความแตกต่างนี้สำคัญเพราะการหาสาเหตุของการถดถอยเริ่มต้นด้วยการวิเคราะห์สิ่งที่เปลี่ยนแปลงไประหว่างสถานะ «ทำงานได้» และ «หยุดทำงาน» Git bisect เป็นเครื่องมือมาตรฐานสำหรับค้นหาคอมมิตที่ทำให้เกิดการถดถอย
ประเภทของการถดถอยและตัวอย่าง
การถดถอยเฉพาะที่ — การเปลี่ยนแปลงในโมดูล A ทำลายฟังก์ชันการทำงานในโมดูล A เดียวกัน ตัวอย่าง: นักพัฒนาเขียนฟังก์ชันการเรียงลำดับใหม่และมันหยุดจัดการกับอาร์เรย์ว่างอย่างถูกต้อง การถดถอยเฉพาะที่ตรวจจับและแก้ไขได้ง่ายที่สุดเพราะสาเหตุและผลกระทบอยู่ใกล้กัน
การถดถอยระยะไกล — การเปลี่ยนแปลงในโมดูล A ทำลายฟังก์ชันการทำงานในโมดูล B ซึ่งไม่ได้เชื่อมต่อโดยตรงด้วยโค้ดแต่เชื่อมต่อด้วยข้อมูลหรือเวลา ตัวอย่าง: การเปลี่ยนสคีมาฐานข้อมูลในโมดูล «ผู้ใช้» ทำลายรายงานในโมดูล «การวิเคราะห์» ที่ใช้ตารางเดียวกัน การถดถอยระยะไกลเป็นสิ่งที่ร้ายกาจที่สุด: นักพัฒนาไม่สงสัยว่าการเปลี่ยนแปลงของตนจะส่งผลกระทบต่อโมดูลอื่น
การถดถอยจากผลข้างเคียง — การเปลี่ยนแปลงผลข้างเคียง (การบันทึก การแคช การส่งการแจ้งเตือน) ทำลายพฤติกรรมที่คาดหวัง ตัวอย่าง: นักพัฒนาเพิ่มแคชเพื่อเพิ่มความเร็ว แต่เนื่องจากแคชที่ล้าสมัย ผู้ใช้จึงเห็นข้อมูลที่เก่า การถดถอยจากผลข้างเคียงนั้นตรวจจับได้ยากด้วยการทดสอบอัตโนมัติเพราะผลข้างเคียงมักไม่ครอบคลุมโดยการทดสอบ
การถดถอยด้านประสิทธิภาพ — โค้ดยังคงทำงานได้อย่างถูกต้องตามหน้าที่แต่ช้ากว่าก่อน ตัวอย่าง: อัลกอริทึมการเข้ารหัสใหม่ให้ผลลัพธ์เหมือนเดิม แต่เวลาในการดำเนินการเพิ่มขึ้นจาก 2 ms เป็น 200 ms การถดถอยด้านประสิทธิภาพไม่ถูกตรวจจับโดยการทดสอบหน่วยทั่วไป — จำเป็นต้องมีเกณฑ์วัดและโปรไฟลิง
| ประเภทการถดถอย | ตัวอย่าง | วิธีการตรวจจับ |
|---|---|---|
| เฉพาะที่ | การเรียงลำดับเสีย | การทดสอบหน่วย |
| ระยะไกล | การเปลี่ยนสคีมา DB | การทดสอบการรวมระบบ |
| ผลข้างเคียง | แคชเก่า | การทดสอบ E2E |
| ประสิทธิภาพ | การตอบสนองช้าลง | เกณฑ์วัด |
ทำไมการถดถอยจึงเกิดขึ้น
สาเหตุแรกคือ การเชื่อมโยงของโค้ด ยิ่งโมดูลพึ่งพากันมากเท่าใด โอกาสที่การเปลี่ยนแปลงในโมดูลหนึ่งจะทำให้เกิดการถดถอยในอีกโมดูลหนึ่งก็ยิ่งสูงขึ้น รูปแบบตรงข้ามคลาสสิก: God Object (ออบเจกต์ที่ทำทุกอย่าง), Shotgun Surgery (การเปลี่ยนแปลงที่จุดเดียวต้องแก้ไขอีกหลายสิบจุด), การพึ่งพาแบบวงจร การลดการเชื่อมโยงเป็นเรื่องของสถาปัตยกรรม: หลักการ SOLID, Dependency Injection, สถาปัตยกรรมเฮกซะโกนัล
สาเหตุที่สองคือ การขาดการทดสอบ สำหรับฟังก์ชันการทำงานที่เปลี่ยนแปลง หากโค้ดไม่ครอบคลุมโดยการทดสอบ นักพัฒนาจะรู้เกี่ยวกับการถดถอยจาก QA หรือผู้ใช้เท่านั้น ตาม Google Testing Blog โปรเจกต์ที่มีความครอบคลุมการทดสอบ >75% มีการถดถอยน้อยกว่าโปรเจกต์ที่มีความครอบคลุม <25% ถึง 5 เท่า TDD (การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ) รับประกันว่าการทดสอบถูกเขียนก่อนโค้ด ไม่ใช่ «เมื่อมีเวลา»
สาเหตุที่สามคือ ปัจจัยมนุษย์ นักพัฒนาไม่ทราบเกี่ยวกับฟังก์ชันการทำงานที่เกี่ยวข้อง ไม่เข้าใจการพึ่งพาทั้งหมด หรือเพียงแค่รีบร้อน สาเหตุคือการแบ่งปันความรู้เกี่ยวกับฐานโค้ดที่ไม่เพียงพอ วิธีแก้ไข: การตรวจสอบโค้ดกับนักพัฒนาจากโมดูลอื่น การเขียนโปรแกรมแบบคู่ การจัดทำเอกสารสถาปัตยกรรม Bus factor ของโปรเจกต์แปรผกผันกับจำนวนการตัดสินใจทางสถาปัตยกรรมที่ถูกบันทึกไว้
การทดสอบการถดถอยและบทบาทของมัน
การทดสอบการถดถอย คือกระบวนการรันการทดสอบที่มีอยู่ซ้ำหลังจากการเปลี่ยนแปลงแต่ละครั้งเพื่อตรวจสอบว่าฟังก์ชันการทำงานเก่าไม่ถูกทำลาย มันเป็นวิธีเดียวที่จะรับประกันว่าการเปลี่ยนแปลงใหม่ไม่ได้รบกวนโค้ดที่มีอยู่ หากไม่มีการทดสอบการถดถอย ทุกการเผยแพร่คือการเสี่ยงโชค: นักพัฒนาหวังว่าจะไม่ทำลายอะไรแต่ไม่สามารถยืนยันได้
การทดสอบการถดถอยด้วยตนเองเป็นวิธีที่ แพงที่สุด และมีประสิทธิภาพน้อยที่สุด เมื่อโปรเจกต์เติบโตขึ้น จำนวนสถานการณ์การทดสอบการถดถอยเพิ่มขึ้นเป็นเส้นตรง ในขณะที่เวลาในการดำเนินการด้วยตนเองเพิ่มขึ้นแบบทวีคูณ หลังจากพัฒนา 2–3 ปี การทดสอบการถดถอยด้วยตนเองอาจใช้เวลา 2–3 สัปดาห์ ทำให้การเผยแพร่บ่อยครั้งเป็นไปไม่ได้ ทางออกเดียวคือระบบอัตโนมัติ
การทดสอบการถดถอยอัตโนมัติแบ่งออกเป็นระดับตาม พีระมิดการทดสอบ:
- การทดสอบหน่วย — รวดเร็ว แยกส่วน ครอบคลุมฟังก์ชันและเมธอดแต่ละรายการ
- การทดสอบการรวมระบบ — ตรวจสอบปฏิสัมพันธ์ระหว่างโมดูล ฐานข้อมูล บริการภายนอก
- การทดสอบ E2E — ตรวจสอบสถานการณ์ผู้ใช้ที่สมบูรณ์ผ่าน UI หรือ API
- การทดสอบสแนปช็อต — เปรียบเทียบเอาต์พุตปัจจุบันของคอมโพเนนต์กับข้อมูลอ้างอิง
ตาม Google Testing Blog สัดส่วนที่เหมาะสมคือ 70% การทดสอบหน่วย, 20% การทดสอบการรวมระบบ, 10% E2E การเบี่ยงเบนจากสัดส่วนนี้จะลดประสิทธิภาพของการทดสอบการถดถอย: การทดสอบ E2E มากเกินไปทำให้ไปป์ไลน์ช้าลง การทดสอบหน่วยน้อยเกินไปทำให้บั๊กขนาดเล็กไม่ถูกตรวจจับ
กลยุทธ์สำหรับการทดสอบการถดถอยอัตโนมัติ
กลยุทธ์แรกคือ การถดถอยแบบเต็มรูปแบบ รันการทดสอบทั้งหมดของโปรเจกต์ วิธีที่น่าเชื่อถือที่สุดแต่ก็ช้าที่สุด เหมาะสำหรับโปรเจกต์ขนาดเล็ก (มากถึง 10,000 การทดสอบ เวลารัน <30 นาที) สำหรับโปรเจกต์ขนาดใหญ่ การถดถอยแบบเต็มรูปแบบอาจใช้เวลาหลายชั่วโมง ทำให้ไปป์ไลน์ CI/CD ไม่สามารถปฏิบัติได้
กลยุทธ์ที่สองคือ การถดถอยแบบเลือกสรร รันเฉพาะการทดสอบที่เกี่ยวข้องกับโค้ดที่เปลี่ยนแปลง กราฟการพึ่งพาของโค้ดถูกใช้เพื่อกำหนดความสัมพันธ์ เครื่องมือ: Bazel (Google), Nx (JavaScript), sbt (Scala) การถดถอยแบบเลือกสรรประหยัดเวลา 60–80% แต่ต้องการการสร้างกราฟการพึ่งพาที่แม่นยำ — ข้อผิดพลาดนำไปสู่การถดถอยที่ไม่ถูกตรวจจับ
กลยุทธ์ที่สามคือ การถดถอยตามลำดับความสำคัญ การทดสอบทั้งหมดถูกจัดลำดับตามความสำคัญ: เส้นทางวิกฤต (สถานการณ์ผู้ใช้ที่สำคัญที่สุด), ความเสี่ยงสูง (โค้ดที่มีประวัติบั๊ก), โค้ดที่เปลี่ยนแปลง (โค้ดที่ได้รับผลกระทบจากการเปลี่ยนแปลง) การทดสอบที่มีลำดับความสำคัญสูงสุดจะถูกรันก่อน — หากผ่าน นักพัฒนาจะได้รับข้อเสนอแนะที่รวดเร็ว การรันแบบจำกัดเวลา: การทดสอบวิกฤตจะถูกตรวจสอบภายใน 10 นาที ส่วนที่เหลือจะรันในพื้นหลัง
วิธีป้องกันการถดถอยในโปรเจกต์
ขั้นตอนแรกและสำคัญที่สุดคือ วัฒนธรรมการเขียนทดสอบ ทุกการเปลี่ยนแปลงควรมาพร้อมกับการทดสอบที่ตรวจสอบว่าการเปลี่ยนแปลงทำงานได้ และการทดสอบที่ตรวจสอบว่าไม่มีอะไรเสียหาย TDD (การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ) ให้ผลลัพธ์ที่ดีที่สุด: นักพัฒนาเขียนการทดสอบที่ล้มเหลวก่อน จากนั้นเขียนโค้ดที่ทำให้ผ่านการทดสอบ นี่รับประกันว่าการทดสอบมีอยู่ก่อนโค้ด
ขั้นตอนที่สองคือ ไปป์ไลน์ CI/CD ที่มีการรันการทดสอบบังคับ Pull request ไม่สามารถรวมได้จนกว่าการทดสอบทั้งหมดจะผ่าน ไม่สามารถ «ข้าม» การทดสอบเนื่องจากความเร่งด่วน — การเปลี่ยนแปลงเร่งด่วนจะผ่านชุดการทดสอบที่เร่งขึ้นแต่บังคับ ตาม Google DevOps Research ทีมที่มี CI/CD บังคับมีการถดถอยในโปรดักชันน้อยกว่า 3 เท่า
ขั้นตอนที่สามคือ การตรวจสอบในโปรดักชัน แม้การทดสอบที่ดีที่สุดก็ไม่รับประกันการป้องกัน 100% จากการถดถอย เครื่องมือการสังเกตการณ์ (Sentry, Datadog, New Relic) ควรติดตามเมตริกหลักหลังการปรับใช้แต่ละครั้ง: อัตราข้อผิดพลาด, ความหน่วง, ปริมาณงาน การย้อนกลับอัตโนมัติเมื่อเกินเกณฑ์เป็นตาข่ายนิรภัยหากการถดถอยถึงโปรดักชัน
ขั้นตอนที่สี่คือ การตรวจสอบโค้ดด้วยมุมมองการถดถอย ผู้ตรวจสอบควรถามว่า «โมดูลอื่นใดอีกที่อาจเสียหายจากการเปลี่ยนแปลงนี้?» การตรวจสอบว่าโค้ดถูกต้องนั้นไม่เพียงพอ — ต้องตรวจสอบว่ามันจะไม่รบกวนฟังก์ชันการทำงานที่เกี่ยวข้อง รายการตรวจสอบการตรวจสอบโค้ดควรรวมรายการ «ตรวจสอบการถดถอยในโมดูลที่เกี่ยวข้อง»
คำถามที่พบบ่อย
การถดถอยแตกต่างจากบั๊กทั่วไปอย่างไร?
การถดถอยคือบั๊กที่ ไม่มีมาก่อน บั๊กทั่วไปอาจมีอยู่ตั้งแต่การสร้างฟีเจอร์ การถดถอยมักเกี่ยวข้องกับการเปลี่ยนแปลงเฉพาะ — ซึ่งช่วยให้ใช้ git bisect เพื่อค้นหาสาเหตุได้
จะหาสาเหตุของการถดถอยอย่างรวดเร็วได้อย่างไร?
ใช้ git bisect: ระบุคอมมิตที่ทุกอย่างทำงานได้และคอมมิตที่เสียหาย Git ค้นหาแบบทวิภาคในประวัติและค้นหาคอมมิตที่ทำให้เกิดการถดถอย ซึ่งทำงานแม้ในโปรเจกต์ขนาดใหญ่ที่มีคอมมิตเป็นพัน
ต้องใช้การทดสอบกี่ครั้งเพื่อป้องกันการถดถอย?
ไม่มีตัวเลขที่แน่นอน แต่มีกฎเชิงประจักษ์: ความครอบคลุมของ โฟลว์ผู้ใช้หลัก ควรเป็น 100% ความครอบคลุมของฟังก์ชันทั้งหมดควรอย่างน้อย 70% คุณภาพสำคัญกว่าปริมาณ: การทดสอบหนึ่งที่ตรวจสอบกรณีขอบมีค่ามากกว่าสิบการทดสอบบนเส้นทางปกติ
การถดถอยสามารถเกิดจากโครงสร้างพื้นฐานแทนโค้ดได้หรือไม่?
ได้ และเรียกว่า การถดถอยของโครงสร้างพื้นฐาน การอัปเดตระบบปฏิบัติการ การเปลี่ยนเวอร์ชันฐานข้อมูล การอัปเดตใบรับรอง SSL หรือการเปลี่ยนการกำหนดค่าเว็บเซิร์ฟเวอร์สามารถทำลายโค้ดที่ทำงานได้ IaC (โครงสร้างพื้นฐานเป็นโค้ด) และการทดสอบโครงสร้างพื้นฐาน (Test Kitchen, Terratest) ช่วยตรวจจับการถดถอยดังกล่าว
จะโน้มน้าวทีมให้เขียนการทดสอบการถดถอยได้อย่างไรหากพวกเขาไม่เคยเขียน?
เริ่มต้นด้วย โฟลว์ผู้ใช้วิกฤตหนึ่งรายการ เขียนการทดสอบอัตโนมัติสำหรับสถานการณ์ที่สำคัญที่สุด (การเข้าสู่ระบบ การชำระเงิน) สาธิตว่าการทดสอบตรวจจับการถดถอยอย่างไร เมื่อทีมเห็นประโยชน์ ค่อย ๆ ขยายความครอบคลุม
สรุป
- การถดถอย คือบั๊กที่เกิดขึ้นหลังจากเปลี่ยนโค้ดที่เคยทำงานได้มาก่อน
- การถดถอยสี่ประเภท: เฉพาะที่, ระยะไกล, ผลข้างเคียง และประสิทธิภาพ
- สาเหตุหลัก: การเชื่อมโยง ของโค้ด, การขาดการทดสอบ และปัจจัยมนุษย์
- การทดสอบการถดถอยเป็นกระบวนการบังคับเพื่อรักษาความเสถียร
- ระบบอัตโนมัติ ของการทดสอบการถดถอยผ่านพีระมิดการทดสอบ (70/20/10)
- CI/CD ที่มีการรันการทดสอบบังคับ สกัดกั้น การถดถอยตั้งแต่เริ่มต้น
- Git bisect เป็นเครื่องมือมาตรฐานสำหรับค้นหาคอมมิตที่ทำให้เกิดการถดถอย
เราจะพัฒนาแอปพลิเคชันบนมือถือแบบครบวงจร
IT Sectr สร้างแอปพลิเคชัน iOS และ Android สำหรับสตาร์ทอัพและธุรกิจตั้งแต่ปี 2017 เราจะให้คำแนะนำและเสนอวิธีแก้ปัญหาที่ดีที่สุดแก่คุณ
อ่านเพิ่มเติม