मोबाइल डेवलपमेंट में रिग्रेशन टेस्टिंग — यह क्या है, प्रकार और कैसे की जाती है

रिग्रेशन टेस्टिंग क्या है?

रिग्रेशन टेस्टिंग एक प्रकार का परीक्षण है जिसका उद्देश्य यह पुष्टि करना है कि कोड परिवर्तनों ने मौजूदा कार्यक्षमता को नहीं तोड़ा है। शब्द “रिग्रेशन” का अर्थ बदतर स्थिति में लौटना है — जब कोई फ़ंक्शन जो पिछले संस्करण में काम करता था, नए संस्करण में काम करना बंद कर देता है। रिग्रेशन टेस्ट प्रत्येक विकास चक्र पर बार-बार निष्पादित किए जाते हैं, जो उन्हें नई सुविधा परीक्षणों से अलग करता है जो एक बार लिखे जाते हैं।

रिग्रेशन टेस्टिंग की आवश्यकता कैस्केडिंग परिवर्तनों के प्रभाव से उत्पन्न होती है: एक मॉड्यूल में बग को ठीक करने से समस्या हल हो सकती है लेकिन आसन्न कार्यक्षमता टूट सकती है जो उस पर निर्भर थी। उदाहरण के लिए, उपयोगकर्ता रिपॉजिटरी में SQL क्वेरी बदलने से प्रमाणीकरण तेज हो सकता है लेकिन डेटा निर्यात टूट सकता है जो उसी क्वेरी का उपयोग करता था। डेटा निर्यात पर एक रिग्रेशन टेस्ट रिलीज़ से पहले इस उल्लंघन का पता लगाएगा।

CISQ 2023 रिपोर्ट के अनुसार, उत्पादन में पाए गए रिग्रेशन दोष को ठीक करने की लागत स्वचालित रिग्रेशन रन चरण की तुलना में 15 गुना अधिक है। Capgemini World Quality Report के अनुसार, स्वचालित रिग्रेशन टेस्टिंग में निवेश करने वाली कंपनियाँ कार्यान्वयन के एक वर्ष के भीतर रिलीज़ में रिग्रेशन दोषों के हिस्से को 25% से घटाकर 5% कर देती हैं।

रिग्रेशन टेस्टिंग के प्रकार

रिग्रेशन टेस्टिंग के कई दृष्टिकोण हैं जो दायरे और परीक्षण चयन मानदंडों में भिन्न हैं। दृष्टिकोण का चुनाव प्रोजेक्ट के आकार, परिवर्तनों की आवृत्ति और CI पाइपलाइन में उपलब्ध समय पर निर्भर करता है। नीचे उनकी विशेषताओं के साथ रिग्रेशन टेस्टिंग के मुख्य प्रकार दिए गए हैं।

पूर्ण रिग्रेशन टेस्टिंग

पूर्ण रिग्रेशन रन बिना किसी अपवाद के प्रोजेक्ट के सभी स्वचालित परीक्षणों को निष्पादित करता है। यह दृष्टिकोण अधिकतम आत्मविश्वास देता है लेकिन महत्वपूर्ण कंप्यूटिंग संसाधनों और समय की आवश्यकता होती है। पूर्ण रन बड़े रिलीज़ से पहले किया जाता है — हर 2–4 सप्ताह में। 5000 परीक्षणों वाले एप्लिकेशन के लिए, पूर्ण रन में बुनियादी ढाँचे के आधार पर 2 से 6 घंटे लगते हैं।

चयनात्मक रिग्रेशन टेस्टिंग

चयनात्मक दृष्टिकोण केवल बदले गए मॉड्यूल से संबंधित परीक्षण चलाता है। संबंध निर्धारित करने के लिए कोड-स्तरीय निर्भरता विश्लेषण का उपयोग किया जाता है: यदि UserRepository वर्ग बदला जाता है, तो UserRepository पर प्रत्यक्ष या ट्रांज़िटिव रूप से निर्भर परीक्षण चलाए जाते हैं। Jacoco, Android Test Coverage और Xcode Code Coverage जैसे उपकरण सटीक चयन के लिए कवरेज मानचित्र प्रदान करते हैं। चयनात्मक रन प्रत्येक pull request पर किया जाता है और 5–15 मिनट लगता है।

जोखिम-आधारित रिग्रेशन

जोखिम-आधारित रिग्रेशन कार्यक्षमता की आलोचनात्मकता और टूटने की संभावना के आधार पर परीक्षणों को रैंक करता है। महत्वपूर्ण कार्य — भुगतान, प्रमाणीकरण, सिंक्रनाइज़ेशन — प्रत्येक कोड परिवर्तन पर परीक्षण किए जाते हैं। सहायक कार्य — “हमारे बारे में” स्क्रीन, एनिमेशन — केवल रिलीज़ से पहले परीक्षण किए जाते हैं। रैंकिंग की उत्पादन घटना डेटा के आधार पर त्रैमासिक समीक्षा की जाती है।

रिग्रेशन टेस्टिंग और रीटेस्ट में अंतर

अक्सर रिग्रेशन टेस्टिंग और रीटेस्ट की अवधारणाओं को भ्रमित किया जाता है, हालाँकि ये अलग-अलग प्रक्रियाएँ हैं। रीटेस्ट दोष सुधार के बाद, पहले विफल हुए किसी विशिष्ट परीक्षण का पुनः चलाना है। रीटेस्ट का उद्देश्य यह सुनिश्चित करना है कि सुधार काम करता है: बग अब पुन: उत्पन्न नहीं होता। रीटेस्ट एक बार किया जाता है, सुधार और डेवलपर द्वारा सुधार की पुष्टि के तुरंत बाद।

रिग्रेशन टेस्टिंग मौजूदा कार्यक्षमता पर परीक्षण चलाना है जिसे बदला नहीं गया है। लक्ष्य यह सुनिश्चित करना है कि एक दोष को ठीक करने से कहीं और कोई नया दोष उत्पन्न नहीं हुआ है। रिग्रेशन टेस्ट प्रत्येक विकास चक्र पर बार-बार चलाए जाते हैं, भले ही कौन से विशिष्ट बग ठीक किए गए हों। मुख्य अंतर: रीटेस्ट सुधार को सत्यापित करता है, रिग्रेशन सुधार के परिणामों को सत्यापित करता है।

CI/CD पाइपलाइन में, दोनों प्रक्रियाएँ क्रमिक रूप से चलती हैं। pull request मर्ज करने के बाद, विशिष्ट बग का रीटेस्ट चलाया जाता है, उसके बाद पूर्ण या चयनात्मक रिग्रेशन रन किया जाता है। SmartBear (2022) के अनुसार, इन प्रक्रियाओं को अलग करने से विफल CI रन के निदान का समय 30% कम हो जाता है, क्योंकि टीम तुरंत देख लेती है कि कौन से दोष रिग्रेशन से संबंधित हैं और कौन से गैर-काम करने वाले सुधारों से।

रिग्रेशन टेस्टिंग का स्वचालन

रिग्रेशन टेस्टिंग का स्वचालन आधुनिक मोबाइल प्रोजेक्ट्स के लिए एक महत्वपूर्ण सफलता कारक है। मैनुअल रिग्रेशन टेस्टिंग स्केलेबल नहीं है: 200 परीक्षणों के सूट के साथ, एक रन के लिए QA इंजीनियर के 2–3 कार्य दिवसों की आवश्यकता होती है, जिससे दैनिक रन असंभव हो जाते हैं। स्वचालित रिग्रेशन टेस्ट मानव हस्तक्षेप के बिना 10–60 मिनट में चलते हैं, जिससे उन्हें प्रत्येक commit या pull request पर निष्पादित किया जा सकता है।

• यूनिट टेस्ट — रिग्रेशन सूट की नींव (70%)। सेकंडों में चलते हैं, एमुलेटर की आवश्यकता नहीं होती, और टूटे हुए वर्ग की सटीक पहचान देते हैं।
• इंटीग्रेशन टेस्ट — दूसरा स्तर (20%)। नियंत्रित निर्भरताओं के साथ नेटवर्क लेयर, डेटाबेस और सिस्टम सेवाओं की जाँच करते हैं।
• UI टेस्ट और E2E टेस्ट — पिरामिड का शीर्ष (10%)। महत्वपूर्ण उपयोगकर्ता परिदृश्यों को कवर करते हैं: पंजीकरण, भुगतान, सिंक्रनाइज़ेशन।

रिग्रेशन सूट को अपडेट रखने के लिए टेस्ट एनालिटिक्स का उपयोग किया जाता है: Allure, ReportPortal और Xray जैसे उपकरण प्रत्येक परीक्षण की पास दर, अवधि और स्थिरता को ट्रैक करते हैं। जिन परीक्षणों की स्थिरता 90% से नीचे गिर जाती है (अक्सर आवश्यकताओं में बदलाव के कारण टूट जाते हैं), उन्हें विरासत के रूप में चिह्नित किया जाता है और समीक्षा के लिए मालिक को सौंपा जाता है।

रिग्रेशन टेस्ट सेट करने का उदाहरण

आइए JUnit 5 लाइब्रेरी और Espresso का उपयोग करके Android पर एक स्वचालित रिग्रेशन टेस्ट सेट करने पर नज़र डालें। उदाहरण चयनात्मक रिग्रेशन प्रदर्शित करता है — परीक्षण सत्यापित करता है कि उपयोगकर्ता रिपॉजिटरी को रिफैक्टर करने के बाद प्रोफ़ाइल स्क्रीन नहीं टूटती है। 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 के लिए, रिग्रेशन टेस्ट API से डेटा प्राप्त करने के बाद UI अपडेट के एसिंक्रोनस सत्यापन के लिए XCTestExpectation का उपयोग करता है। परीक्षण नेटवर्क प्रतिक्रिया का अनुकरण करता है और सत्यापित करता है कि 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 से अधिक परीक्षण), पूर्ण रन बहुत लंबा हो जाता है और चयनात्मक दृष्टिकोण की आवश्यकता होती है।

दूसरा चरण — निर्भरता विश्लेषण उपकरणों का कार्यान्वयन: Android के लिए Jacoco, iOS के लिए Xcode Test Plan। ये उपकरण “परीक्षण — वर्ग — विधि” का मानचित्र बनाते हैं और यह निर्धारित करने की अनुमति देते हैं कि किसी विशिष्ट परिवर्तन से कौन से परीक्षण प्रभावित होते हैं। Spotify Engineering (2022) के अनुसार, कवरेज विश्लेषण पर आधारित चयनात्मक रन 95% रिग्रेशन पहचान प्रभावशीलता बनाए रखते हुए निष्पादन समय को 60–80% कम करता है।

तीसरा चरण — निरंतर निगरानी और अनुकूलन। जो परीक्षण 6 महीने से विफल नहीं हुए हैं, उन्हें कम-प्राथमिकता वाले सूट में स्थानांतरित किया जाता है। जो परीक्षण महीने में एक बार से अधिक विफल होते हैं, वे समीक्षा के लिए उम्मीदवार हैं: या तो वे वास्तविक समस्याओं को पकड़ते हैं (फिक्स की आवश्यकता है) या वे बहुत नाजुक हैं (स्थिरीकरण की आवश्यकता है)। रिग्रेशन सूट की त्रैमासिक समीक्षा इसकी प्रभावशीलता और निष्पादन गति बनाए रखने के लिए मानक अभ्यास है।