Smoke Test ในการพัฒนาแอปมือถือ — คืออะไร ภารกิจ และวิธีการนำไปใช้

Smoke Test คืออะไร?

Smoke Test (การทดสอบควัน) คือชุดของการทดสอบอย่างรวดเร็วที่ตรวจสอบฟังก์ชันหลักของแอปพลิเคชันโดยไม่ต้องวิเคราะห์เชิงลึก คำนี้มาจากวิศวกรรมฮาร์ดแวร์: หากอุปกรณ์เริ่มมีควันหลังจากประกอบเสร็จ จะไม่ถูกส่งไปทดสอบเต็มรูปแบบ ในการพัฒนาแอปมือถือ Smoke Test ทำหน้าที่เดียวกัน — กรองบิลด์ที่เห็นได้ชัดว่าใช้งานไม่ได้ ตาม Microsoft DevOps (2024) การนำ Smoke Test มาใช้ช่วยลดจำนวนข้อบกพร่องที่ถึงทีม QA ได้ 40%

Smoke Test จะทำงานในทุกบิลด์ใหม่ — ทั้ง Android และ iOS ในอุดมคติ Smoke Test ควรใช้เวลาไม่เกิน 15 นาทีและเริ่มทำงานโดยอัตโนมัติหลังจากบิลด์สำเร็จ เกณฑ์การผ่าน — 100% ของการทดสอบในชุด Smoke Test ต้องสำเร็จ หากอย่างน้อยหนึ่งการทดสอบล้มเหลว บิลด์จะถูกทำเครื่องหมายว่าไม่เสถียรและจะไม่ถูกส่งไปทดสอบเพิ่มเติม ตาม Google Testing Blog (2024) วิธีการนี้ช่วยลดเวลาการส่งมอบฟีเจอร์ให้ผู้ใช้ได้ 25%

Smoke Test สามารถทำด้วยตนเอง (รายการตรวจสอบ 5–10 รายการ) หรือแบบอัตโนมัติ ในโปรเจ็กต์มือถือสมัยใหม่ มักนิยมใช้ Smoke Test แบบอัตโนมัติที่รวมอยู่ใน CI/CD Smoke Test แบบ manual จะสมเหตุสมผลเฉพาะในระยะแรกของโปรเจ็กต์เมื่อระบบอัตโนมัติไม่คุ้มค่าทางเศรษฐกิจ ตาม Bitrise (2025) 73% ของทีมพัฒนาแอปมือถือทำให้ Smoke Test เป็นอัตโนมัติ

Smoke Test แตกต่างจากการทดสอบรีเกรสชันอย่างไร?

Smoke Test และการทดสอบรีเกรสชันมักถูกสับสน แต่เป็นแนวปฏิบัติที่แตกต่างกันโดยมีเป้าหมายต่างกัน การทดสอบรีเกรสชันตรวจสอบว่าการเปลี่ยนแปลงโค้ดไม่ได้ทำให้ฟังก์ชันที่มีอยู่เสียหาย มันครอบคลุมทุกโมดูลและสถานการณ์ของแอปพลิเคชัน รวมถึงกรณีที่พบได้ยากและกรณีขอบ Smoke Test ตรวจสอบเฉพาะเส้นทางวิกฤต — สถานการณ์หลักที่หากไม่มีแล้วแอปพลิเคชันจะไร้ประโยชน์ ความลึกของการครอบคลุม คือความแตกต่างหลัก: Smoke Test ครอบคลุม 5–10% ของฟังก์ชัน รีเกรสชันครอบคลุม 80–100%

ความแตกต่างที่สองคือ เวลาดำเนินการ ชุดรีเกรสชันสำหรับแอปพลิเคชันมือถืออาจใช้เวลา 2 ถึง 12 ชั่วโมง ขึ้นอยู่กับขนาดของโปรเจ็กต์และจำนวนแพลตฟอร์ม Smoke Test ใช้เวลา 5–15 นาที ตาม Sauce Labs (2025) เวลาดำเนินการเฉลี่ยของชุดรีเกรสชันสำหรับแอป iOS คือ 4.5 ชั่วโมง และสำหรับ Android — 3.2 ชั่วโมง Smoke Test บนทั้งสองแพลตฟอร์มเสร็จภายใน 10–15 นาที

ความแตกต่างที่สามคือ ตำแหน่งในไปป์ไลน์ Smoke Test จะทำงานทันทีหลังบิลด์ ก่อนการทดสอบรีเกรสชัน หาก Smoke Test ล้มเหลว รีเกรสชันจะไม่เริ่มทำงาน — ซึ่งช่วยประหยัดทรัพยากร CI/CD ประสิทธิภาพของไปป์ไลน์ — Smoke Test กรองบิลด์ที่อาจล้มเหลวในรีเกรสชันได้ถึง 30% และทรัพยากรที่ประหยัดได้เพียงพอสำหรับการทำงานอื่นๆ แบบขนาน

สิ่งที่รวมอยู่ใน Smoke Test ของแอปมือถือ

การเปิดแอป

การเปิดแอป — การทดสอบแรกและสำคัญที่สุด แอปพลิเคชันต้องเปิดโดยไม่ค้างบนอุปกรณ์เป้าหมายทั้งหมด Smoke Test ตรวจสอบการเริ่มต้นแบบ cold start: ติดตั้ง → เปิด → แสดงหน้าจอแรก หากแอปค้างเมื่อเปิด การทดสอบเพิ่มเติมนั้นไร้ประโยชน์ XCUITest และ Espresso ช่วยให้ตรวจสอบการเปิดเป็นอัตโนมัติใน 2–3 บรรทัดของโค้ด อาร์กิวเมนต์การเปิด `-AppleLanguages (ru)` ช่วยตรวจสอบการแปลภาษาเมื่อเริ่มต้น

การยืนยันตัวตน

การยืนยันตัวตน — สถานการณ์วิกฤตที่สอง Smoke Test ต้องตรวจสอบว่าแบบฟอร์มล็อกอินแสดงผล ช่องป้อนข้อมูลตอบสนองต่อการสัมผัส ปุ่มล็อกอินส่งคำขอ และแอปพลิเคชันนำทางไปยังหน้าจอหลักหลังจากการยืนยันตัวตนสำเร็จ ข้อผิดพลาดในการยืนยันตัวตนจะบล็อกการเข้าถึงฟังก์ชันอื่นๆ ทั้งหมด ดังนั้นการตรวจสอบนี้จึงรวมอยู่ในชุดขั้นต่ำ Token refresh — การตรวจสอบเพิ่มเติมสำหรับแอปพลิเคชันที่ใช้ OAuth 2.0

การโหลดเนื้อหาและการนำทาง

การโหลดเนื้อหาหลัก — การทดสอบ Smoke Test ที่สาม หน้าจอหลักหรือฟีดของแอปพลิเคชันต้องโหลดและแสดงข้อมูล หาก API ไม่ตอบสนองหรือการแยกวิเคราะห์คำตอบเสียหาย ผู้ใช้จะเห็นหน้าจอว่าง การตรวจสอบเครือข่ายใน Smoke Test รวมถึงคำขอ GET พื้นฐานไปยังเอนด์พอยต์หลักและการตรวจสอบว่าคำตอบมีโครงสร้างที่คาดหวัง การนำทาง — สถานการณ์ที่สี่ Smoke Test นำทางผ่านหน้าจอหลักของแอปพลิเคชัน: หน้าแรก → ค้นหา → โปรไฟล์ → การตั้งค่า แถบแท็บและเมนูด้านข้างเป็นแหล่งทั่วไปของปัญหาการนำทางที่ Smoke Test จับได้ตั้งแต่ระยะแรก

ระบบอัตโนมัติของ Smoke Test ใน CI/CD

Fastlane — เครื่องมือมาตรฐานสำหรับทำให้ CI/CD มือถือเป็นอัตโนมัติ Smoke Test ใน Fastlane จะทำงานผ่าน `scan` (สำหรับ XCUITest) หรือ `gradle` (สำหรับ Espresso) Fastlane อนุญาตให้กำหนดค่าการทำงานของ Smoke Test บนหลายอุปกรณ์แบบขนาน ซึ่งช่วยลดเวลาโดยรวม การกำหนดค่า ใน Fastfile รวมถึงการกำหนดเป้าหมายชุด Smoke Test และเกณฑ์การผ่าน: 100% การทดสอบสำเร็จ

GitHub Actions (2024) เผยแพร่เทมเพลต CI/CD มือถือที่มี Smoke Test ในตัว เทมเพลตประกอบด้วยสามขั้นตอน: บิลด์ → Smoke Test → รีเกรสชัน หาก Smoke Test ล้มเหลว เทมเพลตจะยุติไปป์ไลน์โดยอัตโนมัติและส่งการแจ้งเตือนไปยัง Slack หรือ Telegram กลยุทธ์เมทริกซ์ ช่วยให้สามารถเรียกใช้ Smoke Test บน iOS สามเวอร์ชันและ Android ห้าโมเดลพร้อมกัน

การแบ่งความรับผิดชอบ ใน CI/CD: Smoke Test ให้ข้อเสนอแนะที่รวดเร็ว ในขณะที่รีเกรสชันให้ความครอบคลุมที่สมบูรณ์ Smoke Test ไม่ควรทำซ้ำรีเกรสชัน และในทางกลับกัน ความละเอียดของ Smoke Test — หนึ่งการตรวจสอบต่อหนึ่งสถานการณ์วิกฤต หาก Smoke Test ใช้เวลามากกว่า 15 นาที จำเป็นต้องปรับให้เหมาะสม: ลบการตรวจสอบที่ซ้ำซ้อนหรือทำการดำเนินการแบบขนาน

# การกำหนดค่า Fastfile สำหรับ Smoke Test
platform :ios do
    lane :smoke do
        scan(
            scheme: 'App',
            devices: ['iPhone 15', 'iPhone SE'],
            testplan: 'SmokeTest',
            output_directory: 'reports/smoke',
            fail_build: true
        )
    end

    lane :regression do
        scan(
            scheme: 'App',
            devices: ['iPhone 15', 'iPhone 14', 'iPhone SE'],
            testplan: 'FullRegression'
        )
    end
end

เครื่องมือสำหรับ Smoke Test

XCUITest — เฟรมเวิร์กของ Apple สำหรับการทดสอบ UI ของแอปพลิเคชัน iOS XCUITest ใช้สำหรับทำให้ Smoke Tests เป็นอัตโนมัติ: เปิดแอป ตรวจสอบองค์ประกอบอินเทอร์เฟซ จำลองการกระทำของผู้ใช้ เมื่อรวมกับ Xcode Server หรือ GitHub Actions XCUITest จะทำงานทุกครั้งที่มีการคอมมิต XCTest — เฟรมเวิร์กพื้นฐานสำหรับการทดสอบหน่วยที่เสริม XCUITest สำหรับการตรวจสอบตรรกะ

Espresso — เฟรมเวิร์กของ Google สำหรับการทดสอบ UI ของ Android Espresso จะซิงโครไนซ์กับเธรด UI และรับรองว่าแอนิเมชันทั้งหมดเสร็จสมบูรณ์ก่อนเริ่มการตรวจสอบ Espresso รองรับการตรวจสอบผ่าน `onView(withId(...)).check(matches(...))` Android Test Orchestrator เรียกใช้ Smoke Test แต่ละรายการในกระบวนการแยกต่างหาก ป้องกันไม่ให้การทดสอบก่อนหน้ามีผลต่อการทดสอบถัดไป

Detox — เฟรมเวิร์กสำหรับ React Native ที่รองรับ Smoke Test และการทดสอบแบบกล่องเทา Detox จะซิงโครไนซ์กับบริดจ์ของ React Native และรอโดยอัตโนมัติให้การดำเนินการแบบอะซิงโครนัสเสร็จสมบูรณ์ การทดสอบแบบกล่องเทา ช่วยให้ Detox ตรวจสอบสถานะของแอปพลิเคชันโดยไม่ต้องเข้าถึงซอร์สโค้ดโดยตรง

ตัวอย่าง Smoke Test ใน Swift และ Kotlin

XCUITest สำหรับ iOS มีสองการตรวจสอบ: เปิดแอปพลิเคชันและแสดงหน้าจอหลัก การทดสอบเปิดแอปผ่าน `XCUIApplication().launch()` และตรวจสอบว่าองค์ประกอบหลัก (เช่น `navigationBar`) มีอยู่ หากแอปค้างเมื่อเปิด XCTest เฟรมเวิร์กจะบันทึกข้อผิดพลาดและการทดสอบจะจบลงด้วย FAIL Smoke Test ไม่ตรวจสอบเนื้อหา — เพียงแค่ว่าหน้าจอเปิดขึ้น

Espresso สำหรับ Android ใช้ `ActivityScenario` เพื่อเปิด Activity และ `onView` เพื่อตรวจสอบองค์ประกอบ ความแตกต่างที่สำคัญระหว่างแพลตฟอร์ม: โปรแกรมจำลอง iOS อาจแสดงพฤติกรรมที่แตกต่างจากอุปกรณ์จริง ดังนั้นจึงแนะนำให้เรียกใช้ Smoke Tests ของ Android บน Firebase Test Lab หรือโปรแกรมจำลอง Firebase Test Lab รองรับการทำงานแบบขนานของ Smoke Tests บน 10 อุปกรณ์

import XCTest

class LoginSmokeTest: XCTestCase {
    let app = XCUIApplication()

    override func setUp() {
        continueAfterFailure = false
        app.launch()
    }

    func testLoginButtonExists() {
        XCTAssertTrue(app.buttons["เข้าสู่ระบบ"].exists)
    }

    func testLoginFlow() {
        app.textFields["email"].tap()
        app.textFields["email"].typeText("test@test.com")
        app.secureTextFields["password"].tap()
        app.secureTextFields["password"].typeText("password123")
        app.buttons["Log In"].tap()
        XCTAssertTrue(app.staticTexts["Welcome"].waitForExistence(timeout: 5))
    }
}

ตัวอย่างด้านบนแสดง Smoke Test สำหรับหน้าจอล็อกอินบน iOS การทดสอบแรกตรวจสอบว่าปุ่มล็อกอินอยู่บนหน้าจอ การทดสอบที่สองดำเนินการเส้นทางการยืนยันตัวตนเต็มรูปแบบและตรวจสอบว่าข้อความต้อนรับแสดงหลังจากล็อกอินสำเร็จ หมดเวลา 5 วินาทีสำหรับ `waitForExistence` เป็นค่ามาตรฐานสำหรับ Smoke Test: หากองค์ประกอบ UI ไม่ปรากฏภายในเวลานั้น แอปพลิเคชันกำลังทำงานไม่ถูกต้อง