google-site-verification=wcf63FocrV5e43m7d0narloCJgc4DvbwP81x65UnGCY
top of page
Rechercher

Différences entre tests de non-régressions et tests fonctionnels



Les tests logiciels représentent un domaine riche et passionnant. Dans ce domaine, les tests sont définis suivant leur utilisation. Quelles sont les déférentes déclinaisons de ces tests ? Comment peut-on définir les tests de non-régressions ? Comment peut-on définir les tests fonctionnels ? Quelle est la finalité de ces tests ? Quels sont les avantages pour les applications ou logiciels de votre boite ?


Le domaine des tests logiciels

Fondamentalement, deux différents tests logiciels sont usités par le prestataire de service iDEV : les tests statiques et les tests dynamiques.


Les tests statiques sont moins poussés, car ils ne couvrent que la revue documentaire, la planification et le code. Ce type de test se fait sans lancer l’application ou le logiciel proprement dit tandis que les tests dynamiques requièrent que le code soit partiellement ou entièrement exécuté.

Le but de ce dernier est de s’assurer que le logiciel est conforme à la demande. Les tests dynamiques interviennent à chaque étape du développement (qualité des composants, intégration, système, acceptation). Les tests fonctionnels (dynamique) de systèmes et d’acceptation feront l’objet de cet article.


Le logiciel livré doit présenter les fonctionnalités prédéfinies dans le cahier des charges. C’est pour cela que les tests fonctionnels interviennent pour assurer la possibilité de dérouler les cas d’usage. Ces tests sont effectués par des services d’ingénierie logicielle spécifiquement les équipes MOA.

Dans le cas d’un site de e-commerce par exemple, les tests fonctionnels sont utilisés pour s’assurer que la fonction de création de comptes d’utilisateur est possible, qu’un utilisateur a accès à son panier, qu’il peut y ajouter des produits et qu’il peut acheter.

Les tests non fonctionnels viennent compléter les tests fonctionnels en s’assurant que le logiciel se comportera efficacement en conditions réelles (test de performance, de fiabilité et d’utilisation). Il est également possible d’évaluer la réponse du site face à un grand nombre d’opérations simultanées grâce au tir de charge.


En effectuant tous ces tests préalables, les défaillances sont détectées tôt et des mesures sont mises en place pour éviter tous problèmes. Il faut également répéter et automatiser ses tests pour garantir la longévité du logiciel : on parle de test de non-régression.


Qu’est-ce qu’un test de non-régression ?

Les tests de non-régression sont utilisés après les tests fonctionnels pour s’assurer que l’ajout d’une nouvelle fonction ne perturbera pas les anciennes fonctions. En gros, le test fonctionnel assure le bon fonctionnement des fonctions individuelles alors que le test de non-régression assure que les nouvelles fonctions s’intègreront bien aux anciennes.


Après la livraison de nouvelles fonctions, celles-ci ne doivent pas rendre indisponibles les fonctions principales du logiciel. Le déploiement du test de non-régression se fait sur un environnement de recette pour effectuer cette vérification.


Les tests de non-régressions permettent de connaître l’impact de l’ajout d’une nouveauté, connaître la réaction du logiciel et ainsi mieux orienter les actions. Les risques projet se trouvent énormément réduits.


Ce test est très efficace lorsqu’il est automatisé. Ainsi, toutes défaillances du logiciel ou toutes régressions sont automatiquement détectées. Ce sont d’ailleurs les tests fonctionnels et non fonctionnels utilisés tout au long du développement qui seront automatisés en test de non-régression.

Les données de performances collectées durant l’implémentation d’une fonctionnalité serviront de base de comparaison en cas de problème de performance d’une version ultérieure.


Lorsque vous installez des tests de non-régression et que vous travaillez dans des délais assez restreints, il est recommandé de définir un « socle critique » qui prendra en compte les fonctionnalités les plus importantes. Ainsi, vous aurez effectué un minimum de test sur les parties les plus importantes du logiciel.


La clé pour minimiser les risques est l’identification précoce des défaillances. Il faut donc effectuer tous les tests suscités pour détecter et corriger le problème très tôt.

Opmerkingen


bottom of page