การทดสอบแบบรีเกรสชันในการพัฒนาแอปพลิเคชันมือถือ — คืออะไร ประเภท และวิธีดำเนินการ

การทดสอบรีเกรสชันคืออะไร?

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

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

ตามรายงานของ CISQ 2023 ค่าใช้จ่ายในการแก้ไขข้อบกพร่องแบบรีเกรสชันที่พบในระบบการผลิตสูงกว่าถึง 15 เท่าเมื่อเทียบกับขั้นตอนการรันรีเกรสชันอัตโนมัติ บริษัทที่ลงทุนในการทดสอบรีเกรสชันอัตโนมัติจะลดสัดส่วนของข้อบกพร่องรีเกรสชันในการเผยแพร่จาก 25% เหลือ 5% ภายในหนึ่งปีหลังจากการนำไปใช้ ตามรายงาน Capgemini World Quality Report

ประเภทของการทดสอบรีเกรสชัน

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

การทดสอบรีเกรสชันแบบเต็ม

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

การทดสอบรีเกรสชันแบบเลือกสรร

วิธีการแบบเลือกสรร จะรันเฉพาะการทดสอบที่เกี่ยวข้องกับโมดูลที่เปลี่ยนแปลงเท่านั้น เพื่อกำหนดความเกี่ยวข้อง จะใช้การวิเคราะห์การพึ่งพาในระดับโค้ด: หากคลาส UserRepository ถูกเปลี่ยนแปลง การทดสอบที่ขึ้นอยู่กับ UserRepository โดยตรงหรือโดยอ้อมจะถูกดำเนินการ เครื่องมืออย่าง Jacoco, Android Test Coverage และ Xcode Code Coverage ให้แผนที่การครอบคลุมสำหรับการเลือกที่แม่นยำ การรันแบบเลือกสรรจะดำเนินการในทุก pull request และใช้เวลา 5–15 นาที

รีเกรสชันตามความเสี่ยง

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

ความแตกต่างระหว่างการทดสอบรีเกรสชันและการทดสอบซ้ำ

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

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

ในไปป์ไลน์ CI/CD ทั้งสองกระบวนการจะดำเนินการตามลำดับ หลังจากรวม pull request แล้ว การทดสอบซ้ำของบั๊กเฉพาะจะถูกดำเนินการ ตามด้วยการรันรีเกรสชันแบบเต็มหรือแบบเลือกสรร ตามข้อมูลของ SmartBear (2022) การแยกกระบวนการเหล่านี้ช่วยลดเวลาในการวินิจฉัยการรัน CI ที่ล้มเหลวลง 30% เนื่องจากทีมเห็นทันทีว่าข้อบกพร่องใดเกี่ยวข้องกับรีเกรสชันและข้อบกพร่องใดเกี่ยวข้องกับการแก้ไขที่ใช้ไม่ได้

ระบบอัตโนมัติของการทดสอบรีเกรสชัน

ระบบอัตโนมัติของการทดสอบรีเกรสชันเป็นปัจจัยสำคัญต่อความสำเร็จสำหรับโปรเจกต์มือถือสมัยใหม่ การทดสอบรีเกรสชันด้วยตนเอง ไม่สามารถปรับขนาดได้: ด้วยชุดทดสอบ 200 รายการ การรันหนึ่งครั้งต้องใช้เวลา 2–3 วันทำการของวิศวกร QA ทำให้การรันทุกวันเป็นไปไม่ได้ การทดสอบรีเกรสชันอัตโนมัติจะทำงานใน 10–60 นาทีโดยไม่ต้องมีมนุษย์เกี่ยวข้อง ทำให้สามารถดำเนินการได้ในทุก commit หรือ pull request

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

เพื่อให้ชุดรีเกรสชันเป็นปัจจุบัน การวิเคราะห์การทดสอบ จะถูกใช้: เครื่องมืออย่าง Allure, ReportPortal และ Xray จะติดตามอัตราผ่าน ระยะเวลา และความเสถียรของการทดสอบแต่ละรายการ การทดสอบที่มีความเสถียรต่ำกว่า 90% (มักจะเสียหายเนื่องจากข้อกำหนดที่เปลี่ยนแปลง) จะถูกทำเครื่องหมายเป็นมรดกตกทอดและมอบหมายให้เจ้าของตรวจสอบ

ตัวอย่างการตั้งค่าการทดสอบรีเกรสชัน

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

Android: การทดสอบรีเกรสชันโปรไฟล์

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

@RunWith(AndroidJUnit4::class)
class ProfileRegressionTest {

    @get:Rule
    val composeRule = createComposeRule()

    @Test
    fun profileScreen_rendersCorrectly() {
        val user = User(id = 1, name = "Alice", email = "alice@test.com")
        composeRule.setContent {
            ProfileScreen(user)
        }
        composeRule.onNodeWithText("Alice").assertIsDisplayed()
        composeRule.onNodeWithText("alice@test.com").assertIsDisplayed()
    }

    @Test
    fun profileScreen_handlesNetworkError() {
        setNetworkError()
        composeRule.onNodeWithText("ข้อผิดพลาดในการโหลด").assertIsDisplayed()
    }
}

iOS: การทดสอบรีเกรสชันด้วย XCTest

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

class ProfileRegressionTests: XCTestCase {
    func testProfileScreen_rendersCorrectly() {
        let viewModel = ProfileViewModel(userId: 1)
        let view = ProfileView(viewModel: viewModel)
        viewModel.loadProfile()

        let expectation = expectation(description: "profile loaded")
        viewModel.onProfileLoaded = {
            XCTAssertEqual(viewModel.userName, "Alice")
            XCTAssertEqual(viewModel.userEmail, "alice@test.com")
            expectation.fulfill()
        }
        waitForExpectations(timeout: 3.0)
    }
}

กลยุทธ์การสร้างชุดทดสอบรีเกรสชัน

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

ระยะที่สอง — การนำเครื่องมือวิเคราะห์การพึ่งพามาใช้: Jacoco สำหรับ Android, Xcode Test Plan สำหรับ iOS เครื่องมือเหล่านี้สร้างแผนที่ “การทดสอบ — คลาส — วิธีการ” และช่วยให้สามารถระบุได้ว่าการทดสอบใดได้รับผลกระทบจากการเปลี่ยนแปลงเฉพาะ Spotify Engineering (2022) ระบุว่าการรันแบบเลือกสรรโดยอิงจากการวิเคราะห์การครอบคลุมช่วยลดเวลาในการดำเนินการลง 60–80% ในขณะที่คงประสิทธิภาพการตรวจจับรีเกรสชันไว้ที่ 95%

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