Tests de régression dans le développement mobile — ce que c'est, types et comment les réaliser

Qu'est-ce que les tests de régression ?

Les tests de régression sont un type de test visant à confirmer que les modifications de code n'ont pas cassé les fonctionnalités existantes. Le terme « régression » signifie un retour à un état pire — lorsqu'une fonction qui fonctionnait dans la version précédente cesse de fonctionner dans la nouvelle. Les tests de régression sont exécutés de manière répétée à chaque cycle de développement, ce qui les distingue des tests de nouvelles fonctionnalités qui sont écrits une seule fois.

La nécessité des tests de régression découle de l'effet de modifications en cascade : corriger un bogue dans un module peut résoudre le problème mais casser les fonctionnalités adjacentes qui en dépendaient. Par exemple, modifier une requête SQL dans le référentiel d'utilisateurs peut accélérer l'authentification mais casser l'exportation de données qui utilisait la même requête. Un test de régression sur l'exportation de données détectera cette violation avant la publication.

Selon le rapport CISQ 2023, le coût de correction d'un défaut de régression trouvé en production est 15 fois plus élevé qu'au stade de l'exécution automatisée de régression. Les entreprises qui investissent dans les tests de régression automatisés réduisent la part des défauts de régression dans les publications de 25 % à 5 % dans l'année suivant la mise en œuvre, selon le Capgemini World Quality Report.

Types de tests de régression

Il existe plusieurs approches des tests de régression qui diffèrent par leur portée et leurs critères de sélection des tests. Le choix de l'approche dépend de la taille du projet, de la fréquence des modifications et du temps disponible dans le pipeline CI. Voici les principaux types de tests de régression avec leurs caractéristiques.

Tests de régression complets

L'exécution de régression complète exécute tous les tests automatisés du projet sans exception. Cette approche offre une confiance maximale mais nécessite des ressources informatiques et du temps considérables. Une exécution complète est effectuée avant les publications majeures — toutes les 2 à 4 semaines. Pour une application avec 5000 tests, une exécution complète prend de 2 à 6 heures selon l'infrastructure.

Tests de régression sélectifs

L'approche sélective exécute uniquement les tests liés aux modules modifiés. Pour déterminer la relation, une analyse des dépendances au niveau du code est utilisée : si la classe UserRepository est modifiée, les tests qui dépendent de UserRepository directement ou transitivement sont exécutés. Des outils comme Jacoco, Android Test Coverage et Xcode Code Coverage fournissent des cartes de couverture pour une sélection précise. Une exécution sélective est effectuée à chaque pull request et prend 5 à 15 minutes.

Régression basée sur les risques

La régression basée sur les risques classe les tests par criticité de la fonctionnalité et probabilité de casse. Les fonctions critiques — paiements, authentification, synchronisation — sont testées à chaque modification de code. Les fonctions auxiliaires — l'écran À propos, les animations — sont testées uniquement avant la publication. Le classement est révisé trimestriellement sur la base des données d'incidents de production.

Différence entre les tests de régression et le re-test

Les concepts de tests de régression et de re-test sont souvent confondus, bien qu'il s'agisse de processus différents. Le re-test est une ré-exécution d'un test spécifique qui avait échoué précédemment, après la correction du défaut. Le but du re-test est de confirmer que la correction fonctionne : le bogue ne se reproduit plus. Le re-test est effectué une fois, immédiatement après la correction et la confirmation de la correction par le développeur.

Les tests de régression sont l'exécution de tests sur les fonctionnalités existantes qui n'ont PAS été modifiées. L'objectif est de s'assurer que la correction d'un défaut n'a pas créé un nouveau défaut ailleurs. Les tests de régression sont exécutés de manière répétée à chaque cycle de développement, indépendamment des bogues spécifiques qui ont été corrigés. La principale différence : le re-test vérifie la correction elle-même, la régression vérifie les conséquences de la correction.

Dans un pipeline CI/CD, les deux processus sont exécutés séquentiellement. Après la fusion d'un pull request, un re-test du bogue spécifique est exécuté, suivi d'une exécution de régression complète ou sélective. Selon SmartBear (2022), la séparation de ces processus réduit le temps de diagnostic des exécutions CI échouées de 30 %, car l'équipe voit immédiatement quels défauts sont liés à la régression et lesquels à des corrections qui ne fonctionnent pas.

Automatisation des tests de régression

L'automatisation des tests de régression est un facteur critique de succès pour les projets mobiles modernes. Les tests de régression manuels ne passent pas à l'échelle : avec une suite de 200 tests, une exécution nécessite 2 à 3 jours de travail d'un ingénieur QA, rendant les exécutions quotidiennes impossibles. Les tests de régression automatisés s'exécutent en 10 à 60 minutes sans intervention humaine, permettant de les exécuter à chaque commit ou pull request.

• Tests unitaires — la base de la suite de régression (70 %). Ils s'exécutent en quelques secondes, ne nécessitent pas d'émulateur et fournissent une identification précise de la classe cassée.
• Tests d'intégration — le deuxième niveau (20 %). Ils vérifient la couche réseau, la base de données et les services système avec des dépendances contrôlées.
• Tests UI et tests E2E — le sommet de la pyramide (10 %). Ils couvrent les scénarios utilisateur critiques : inscription, paiement, synchronisation.

Pour maintenir la suite de régression à jour, l'analytique de tests est utilisée : des outils comme Allure, ReportPortal et Xray suivent les taux de réussite, la durée et la stabilité de chaque test. Les tests dont la stabilité tombe en dessous de 90 % (souvent cassés en raison de changements d'exigences) sont marqués comme hérités et attribués au propriétaire pour révision.

Exemple de configuration d'un test de régression

Examinons la configuration d'un test de régression automatisé sur Android utilisant la bibliothèque JUnit 5 et Espresso. L'exemple montre la régression sélective — le test vérifie qu'après la refactorisation du référentiel d'utilisateurs, l'écran de profil n'est pas cassé. Pour iOS, XCTest est utilisé avec une logique similaire — un test répété sur un scénario clé.

Android : test de régression du profil

Le test utilise MockWebServer pour émuler le serveur et vérifie le chemin complet : chargement des données utilisateur, affichage sur l'écran de profil et gestion des erreurs lorsque le serveur est indisponible. Ces tests sont inclus dans la suite de régression et exécutés à chaque modification du module de profil.

@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("Erreur de chargement").assertIsDisplayed()
    }
}

iOS : test de régression avec XCTest

Pour iOS, le test de régression utilise XCTestExpectation pour la vérification asynchrone de la mise à jour de l'interface utilisateur après réception des données de l'API. Le test émule une réponse réseau et vérifie que les éléments de l'interface ont été mis à jour correctement.

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)
    }
}

Stratégie de construction d'une suite de régression

La construction d'une suite de régression efficace est un processus itératif basé sur les données de défauts et de modifications de code. La stratégie initiale consiste à inclure tous les tests existants dans la suite de régression et à effectuer une exécution complète avant chaque publication. À mesure que la base de tests croît (plus de 2000 tests), une exécution complète devient trop longue et une approche sélective est nécessaire.

La deuxième phase — mise en place d'outils d'analyse des dépendances : Jacoco pour Android, Xcode Test Plan pour iOS. Ces outils construisent une carte « test — classe — méthode » et permettent de déterminer quels tests sont affectés par une modification spécifique. Une exécution sélective basée sur l'analyse de couverture réduit le temps d'exécution de 60 à 80 % tout en maintenant 95 % d'efficacité de détection des régressions, selon Spotify Engineering (2022).

La troisième phase — surveillance continue et optimisation. Les tests qui n'ont pas échoué depuis 6 mois sont déplacés vers une suite de faible priorité. Les tests qui échouent plus d'une fois par mois sont candidats à une révision : soit ils capturent de vrais problèmes (nécessitent une correction), soit ils sont trop fragiles (nécessitent une stabilisation). Une révision trimestrielle de la suite de régression est une pratique standard pour maintenir son efficacité et sa vitesse d'exécution.