การทดสอบการถดถอย การบำรุงรักษาการทดสอบ และการต่อสู้กับการทดสอบที่เปราะบาง

กำไร:

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

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

สาเหตุของการทดสอบที่เปราะบาง

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

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

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

ทดสอบการบำรุงรักษา: รักษาบรรจุภัณฑ์ให้แข็งแรง

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

1. การทำความสะอาดการทดสอบซ้ำ/ไม่จำเป็น เมื่อเวลาผ่านไป มีกรณีจำนวนมากสะสมการทดสอบในสิ่งเดียวกัน AI แนะนำให้จัดกลุ่มและรวมการทดสอบที่คล้ายกัน

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

3. การทดสอบการเลือก/การจัดลำดับความสำคัญ การรันแพ็คเกจทั้งหมดกับการเปลี่ยนแปลงแต่ละครั้งมีราคาแพง ด้วยการวิเคราะห์ผลกระทบของการทดสอบ (เลือกเฉพาะการทดสอบที่เกี่ยวข้องตามรหัสที่เปลี่ยนแปลง) AI จะแนะนำว่าควรทำการทดสอบใดก่อน อย่างไรก็ตาม จำเป็นต้องมีแพ็คเกจก่อนวางจำหน่ายแบบเต็ม

การกักกัน: การจัดการการทดสอบที่เปราะบางอย่างเหมาะสม

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

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

ตารางกลยุทธ์การถดถอย

สถานะ

กลยุทธ์

บทบาทของเอไอ

การแก้ไขเล็กน้อย

พื้นที่ได้รับผลกระทบ + ทดสอบควัน

เลือกการทดสอบที่เกี่ยวข้อง

คุณลักษณะใหม่

โมดูลที่เกี่ยวข้อง + บูรณาการ

เสนอกรณีถดถอยใหม่

รีแฟกเตอร์ขนาดใหญ่

แพ็คเกจการถดถอยแบบเต็ม

การวิเคราะห์ช่องว่างความครอบคลุม

ก่อนเผยแพร่

ครบชุด+สำรวจ

การประมาณลำดับความสำคัญและระยะเวลา

ไลฟ์สดแก้ไขด่วน

เส้นทางที่มุ่งเน้น + วิกฤต

ชุดทดสอบความปลอดภัยขั้นต่ำ

พรอมต์อ่อน / พรอมต์แข็งแกร่ง

อ่อนแอ: "การทดสอบนี้บางครั้งล้มเหลว แก้ไขได้"

แข็งแกร่ง: "การทดสอบนี้ล้มเหลว 3 ใน 10 การรัน รหัสไม่เปลี่ยนแปลง วินิจฉัยสาเหตุของความไม่เสถียร: อาจเป็นจังหวะเวลา/การแข่งขัน การพึ่งพาคำสั่งซื้อ สถานะที่ใช้ร่วมกัน การพึ่งพาภายนอก หรือความแตกต่างของสภาพแวดล้อม แสดงว่าบรรทัดใดในจุดทดสอบของแต่ละสาเหตุที่เป็นไปได้ เสนอวิธีแก้ปัญหาแบบถาวร อย่าแนะนำวิธีแก้ปัญหาที่ระงับอาการ เช่น 'เพิ่มการลองใหม่' — หากหลีกเลี่ยงไม่ได้ เขียนเหตุผลอย่างชัดเจน ทดสอบ: [รหัส] เส้นทางข้อผิดพลาด: [บันทึก]"

พรอมต์อันทรงพลัง; ชี้นำการวินิจฉัยถึงสาเหตุที่แท้จริงและห้ามการระงับอาการอย่างชัดเจน

เทมเพลตที่สามารถคัดลอกได้สี่แบบ

1) การวินิจฉัยการทดสอบที่เปราะบาง:

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

2) เสนอกรณีถดถอย:

มีการเปลี่ยนแปลงต่อไปนี้: [สรุปการเปลี่ยนแปลง/PR] แสดงรายการพฤติกรรมปัจจุบันที่การเปลี่ยนแปลงนี้จะเสียหาย และเสนอกรณีทดสอบการถดถอยสำหรับแต่ละรายการ เน้นบริเวณที่เกิดผลข้างเคียงและการพึ่งพาร่วมกันโดยเฉพาะ

3) การล้างข้อมูลการทดสอบซ้ำ:

ตรวจสอบชุดทดสอบด้านล่าง จัดกลุ่มกรณีที่ซ้ำกันหรือทับซ้อนกันที่ทดสอบพฤติกรรมเดียวกัน แนะนำว่าอันไหนควรเก็บไว้ อันไหนควรรวมไว้แต่ละกลุ่ม แจ้งเตือนหากมีความเสี่ยงต่อการสูญเสียความคุ้มครอง การทดสอบ: [รายการ/รหัส]

4) การเลือกผลการทดสอบ:

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

มินิเคสสามอัน

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

กรณีที่ 2 — พัสดุหดตัว ความเร็วเพิ่มขึ้น ชุดการทดสอบการถดถอย 1,400 รายการใช้เวลา 55 นาที ด้วย "การทำความสะอาดการทดสอบซ้ำ" การทดสอบ 380 รายการจึงกลายเป็นการทดสอบซ้ำหรือครอบคลุม ผสาน แพ็กเกจลดลงเหลือ 900 การทดสอบ เวลาลดลงเหลือ 34 นาที ความครอบคลุมไม่ได้ลดลงจนวัดผลได้ ความคิดเห็นที่เร็วขึ้นช่วยให้ทีมทำการทดสอบบ่อยขึ้น

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

ข้อผิดพลาดทั่วไป

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

โดยสรุป

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

งานสมัคร

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

รายการตรวจสอบ

• [ ] ฉันได้วินิจฉัยสาเหตุของการทดสอบที่เปราะบางแล้ว ฉันไม่ได้ระงับอาการ
• [ ] ฉันถือว่าการลองใหม่เป็นทางเลือกสุดท้ายที่สมเหตุสมผล ไม่ใช่วิธีแก้
• [ ] ฉันได้ทำการทดสอบอย่างเป็นอิสระและกำหนดไว้ได้ (แยกจากการพึ่งพาภายนอก)
• [ ] ฉันตัดการทดสอบซ้ำ/ไม่จำเป็นออกจากชุดการถดถอย
• [ ] ฉันเลือกที่จะทดสอบตามการเปลี่ยนแปลง แต่ใช้งานแพ็คเกจเต็มก่อนเผยแพร่
• [ ] ฉันให้ความสำคัญกับเสื้อแดงทุกใบอย่างจริงจัง ต่อต้านวัฒนธรรม "ติดอีก ผ่านไป"