สถานีเครื่องมือหมายเลข 9
กลับไปที่รายการ

กลยุทธ์การทดสอบใน CI/CD: รับประกันคุณภาพสำหรับการใช้งานทุกครั้ง

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

ประกันคุณภาพ ซีไอ/ซีดี การดำเนินการ GitHub กลยุทธ์การทดสอบ ระดับคุณภาพ DevOps

อัปเดตล่าสุด:2026-03-07

บทความนี้ใช้ GitHub Actions เป็นตัวอย่าง การตั้งค่าสำหรับเครื่องมือ CI/CD อื่นๆ อาจแตกต่างกัน

1. เหตุใด CI/CD จึงจำเป็นต้องมี QA

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

2. ขั้นที่ 1: ขั้นยอมรับ (กระตุ้นทุก ๆ การกด)

เป้าหมายเวลาดำเนินการ: < 5 นาที

  • การวิเคราะห์แบบคงที่

    ESLint, ไพลินท์, SonarQube

  • การทดสอบหน่วย

    รวดเร็ว เป็นอิสระ ไม่มีการพึ่งพาจากภายนอก

  • ความครอบคลุมของรหัส

    กำหนดเกณฑ์ขั้นต่ำ (เช่น 80%)

3. ขั้นตอนที่ 2: ขั้นตอนการทดสอบการรวมระบบ

เป้าหมายเวลาดำเนินการ: < 15 นาที

  • การทดสอบ API

    ตรวจสอบการโต้ตอบระหว่างบริการ

  • การทดสอบฐานข้อมูล

    การย้ายข้อมูล ความสมบูรณ์ของข้อมูล

  • การเยาะเย้ยบริการของบุคคลที่สาม

    ไม่ขึ้นอยู่กับบริการภายนอก

4. ขั้นที่ 3: ขั้นตอนการทดสอบ E2E

เป้าหมายเวลาดำเนินการ: < 30 นาที

  • การทดสอบกระบวนการหลัก

    เส้นทางสำคัญ เช่น การเข้าสู่ระบบ การซื้อ การชำระเงิน ฯลฯ

  • การทดสอบข้ามเบราว์เซอร์

    โครม, ไฟร์ฟอกซ์, ซาฟารี

  • การทดสอบการถดถอยทางสายตา

    เพอร์ซี่, โครเมติก

5. ขั้นที่ 4: ระดับก่อนการปรับใช้งาน

บรรทัดสุดท้ายของการป้องกันคุณภาพ:

  • การทดสอบประสิทธิภาพ

    รับรองว่าประสิทธิภาพจะไม่ลดลง

  • สแกนความปลอดภัย

    OWASPZAP、สไนค์

  • การตรวจสอบด้วยตนเอง

    การอนุมัติด้วยตนเองเมื่อจำเป็น

6. การตั้งค่าประตูคุณภาพ

เมื่อใดที่ควรบล็อกการปรับใช้งาน: ความล้มเหลวในการทดสอบหน่วย (ความทนทานเป็นศูนย์) ความครอบคลุมต่ำกว่าเกณฑ์ ช่องโหว่ด้านความปลอดภัยที่มีความรุนแรงสูง การลดลงของตัวชี้วัดประสิทธิภาพเกิน 10% ความล้มเหลวในการทดสอบหลัก E2E

7. ข้อผิดพลาดทั่วไปในการทดสอบ CI/CD

หลีกเลี่ยงปัญหาทั่วไปเหล่านี้:

  • ทดสอบช้าเกินไป

    ย้ายการทดสอบที่ช้าไปยังบิลด์ยามค่ำคืนที่ไม่มีการบล็อก

  • การทดสอบที่ไม่สม่ำเสมอ

    การทดสอบที่ไม่เสถียรจะต้องได้รับการซ่อมแซมหรือแยกทันที ไม่เช่นนั้นทีมจะคุ้นเคยกับการเพิกเฉยต่อไฟแดง

  • สภาพแวดล้อมที่ไม่สอดคล้องกัน

    ใช้ Docker เพื่อให้แน่ใจว่าสภาพแวดล้อม CI สอดคล้องกับการใช้งานจริง

  • ทดสอบเส้นทางแห่งความสุขเท่านั้น

    การทดสอบเชิงลบมีความสำคัญพอๆ กับกรณี Edge

ℹ️

คำแถลงทั่วไป

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

ข้อเสนอแนะ