Tests logiciels non destructifs (TND) : définition et stratégie de test

Qu’est-ce que le test logiciel non destructif ?

Contrôle non destructif est un type de test logiciel qui implique de tester et d'interagir correctement avec l'application logicielle. En d’autres termes, les tests logiciels non destructifs (CND) peuvent également être appelés tests positifs ou tests Happy Path. Il donne les résultats attendus et prouve que l'application logicielle se comporte comme prévu.

Le terme est emprunté à l'ingénierie, où les essais non destructifs permettent d'inspecter un composant physique sans l'endommager. En informatique, le principe est le même : l'application est utilisée conformément à sa conception et ressort indemne du test.

Exemple : Saisir les données correctes dans un module de connexion et vérifier si celui-ci accepte les identifiants et permet d'accéder à la page suivante.

La capture d'écran ci-dessous montre le formulaire de connexion, avec une valeur valide saisie dans le champ nom d'utilisateur avant l'exécution du test.

Pour effectuer un test non destructif sur l'exemple ci-dessus, saisissez un nom d'utilisateur et un mot de passe valides dans le formulaire de connexion. Puisque les informations saisies correspondent aux exigences, le résultat attendu est positif et le testeur vérifie simplement que l'application passe à la page suivante.

Pourquoi effectuer des tests logiciels non destructifs (CND) ?

Les tests non destructifs répondent à la première question que se pose chaque partie prenante à propos d'une version : la fonctionnalité fait-elle réellement ce qu'elle était censée faire ? Voici les raisons pour lesquelles les équipes les mettent en œuvre.

• Le principal avantage de la méthode CND est qu'elle permet d'améliorer la qualité des logiciels, car les défauts détectés dans le flux principal sont corrigés rapidement.
• Démontrer que les fonctions du logiciel fonctionnent conformément aux spécifications.
• Pour vérifier que les exigences de performance ont été respectées.
• Afin de vérifier que les exigences des utilisateurs finaux sont satisfaites.
• Pour vérifier qu'une petite section de code ou de fonctionnalité fonctionne comme prévu et ne perturbe pas la fonctionnalité associée.
• Pour produire des preuves qui puissent être présentées à un tests d'acceptation des utilisateurs validation finale, lorsque le client souhaite observer le comportement attendu plutôt que les modes de défaillance.

Quand les tests non destructifs (CND) sont-ils effectués ?

Le timing est ici plus important que pour la plupart des techniques, car le bon déroulement conditionne tout ce qui suit.

• Il s'agit de la première forme de test qu'un testeur effectuerait sur une application, c'est-à-dire à l'étape initiale du développement. SDLC.
• Les essais non destructifs sont généralement effectués lorsqu'il n'y a pas assez de temps pour un cycle d'essai complet, car ils permettent tout de même de prouver que les critères d'acceptation sont respectés.
• Il s'exécute avant les scénarios négatifs et destructeurs. Si le flux principal est interrompu, les tests de gestion des erreurs signalent du bruit plutôt que de véritables défauts.
• Elle est répétée après chaque correction de défaut, ce qui explique le chevauchement avec les tests de régression.

Stratégie de test pour les tests non destructifs

La stratégie en matière de contrôle non destructif est volontairement simple, et la discipline consiste à rester positif plutôt qu'à se concentrer sur l'outillage.

• L'approche des essais non destructifs doit être positive.
• L'objectif de la technique CND est de prouver qu'une application fonctionnera lorsqu'elle recevra des données d'entrée valides.
• Aucun environnement ou condition particulière n'est requis pour effectuer des essais non destructifs.
• La meilleure pratique en matière de contrôle non destructif consiste à vérifier si le système fonctionne comme prévu.

Le schéma ci-dessous résume comment cette stratégie est généralement organisée au cours d'un cycle de test.

Comment écrire des cas de test non destructifs (positifs)

Un cas de test non destructif n'est utile que si ses entrées sont valides et que son résultat attendu découle d'une exigence et non d'une supposition du testeur. Les étapes suivantes permettent d'obtenir ce type de cas de test. cas de test.

Étape 1) Choisissez un critère d'acceptation. Lisez l'exigence et reformulez-la sous la forme d'un énoncé unique et vérifiable, par exemple : « le champ nom d'utilisateur accepte de six à vingt caractères alphanumériques ».

Étape 2) Choisissez des données d'entrée valides. Sélectionnez des valeurs qui se situent aisément dans la plage autorisée. Partitionnement d'équivalence Cela s'avère utile ici — une valeur représentative par partition valide suffit généralement.

Étape 3) Écrivez le résultat attendu avant l'exécution. Le résultat attendu doit être consigné dans les spécifications. Le rédiger après l'exécution transforme le test en une simple description du déroulement de la compilation.

Étape 4) Conservez les étapes dans l'ordre de l'utilisateur. La séquence doit correspondre à la manière dont un utilisateur réel effectuerait la tâche, car l'objectif de cette technique est de confirmer le parcours prévu.

Étape 5) Enregistrez l'identifiant de l'exigence. TracLe fait de ramener le dossier à ses critères permet à l'équipe de prouver la couverture lors d'un examen.

Voici un exemple fonctionnel pour le module de connexion.

Notez que rien dans le cas ne tente de casser le champ. Un cas qui saisit cinq caractères pour voir le message d'erreur est un test négatif, pas une méthode non destructive.

Exemples de contrôles non destructifs

L'exemple ci-dessous montre comment se comporte un test non destructif dans une application multi-modules après la correction d'un défaut.

• Une application comporte cinq modules : page de connexion, page d’accueil, page de détails de l’utilisateur, création d’un nouvel utilisateur et création de tâches.
• Supposons qu'un bug soit présent sur la page de connexion : le champ « Nom d'utilisateur » accepte moins de six caractères alphanumériques. Ceci contrevient à la configuration requise, qui stipule que le nom d'utilisateur ne doit pas comporter moins de six caractères ; il s'agit donc d'un défaut.
• Le bug est signalé à l'équipe de développement via la procédure habituelle. processus de gestion des défautsLe problème est résolu et la version est renvoyée à l'équipe de test.
• L'équipe de test vérifie non seulement la page de connexion où le défaut a été corrigé, mais aussi les autres modules. Lors de ces tests avec des données valides, elle effectue des tests non destructifs afin de confirmer que l'application fonctionne toujours correctement.

Essais non destructifs vs essais destructifs

Ces deux techniques sont souvent enseignées ensemble car elles répondent à des questions opposées concernant la même construction. Essais destructifs recherche le point de défaillance du logiciel, tandis que les tests non destructifs confirment que le comportement attendu est maintenu.

Ces deux approches sont complémentaires plutôt qu'alternatives. Les tests non destructifs seuls ne permettent pas de vérifier la gestion des erreurs, et les tests destructifs seuls ne prouvent jamais que le produit remplit sa fonction.

Avantages et limites des tests logiciels non destructifs

Savoir où la technique cesse d'être utile est aussi important que de savoir ce qu'elle couvre.

Avantages

• Rapide à concevoir et à exécuter, car les données de test proviennent directement des spécifications.
• Ne nécessite aucun environnement particulier, injection de fautes ou jeu de données corrompu.
• Produit des preuves qui correspondent exactement aux exigences, ce qui convient aux audits et aux validations.
• Fonctionne tout aussi bien que test manuel et comme prévu tests d'automatisation, afin que les mêmes cas puissent être réutilisés dans une suite de tests de régression.
• Fournit un signal précoce et fiable sur l'état de la construction à tous les niveaux, de l'unité jusqu'à test d'intégration à test du système.

Limites

• Une validation complète ne dit rien sur la façon dont l'application se comporte avec des entrées invalides, de sorte que des défauts graves de gestion des erreurs peuvent y survivre.
• La couverture est limitée par la qualité des exigences. Tout ce qui n'est pas spécifié n'est jamais testé.
• Cela peut créer un faux sentiment de confiance lorsque le chemin idéal est le seul chemin emprunté avant une mise en production.
• Elle ne mesure pas la robustesse, la récupération ou la performance sous stress, qui nécessitent leurs propres techniques issues d'un ensemble plus vaste de types de tests logiciels.

Considérez les essais non destructifs comme le socle sur lequel repose toute autre technique et intégrez-les à votre planification globale. cycle de vie des tests logiciels plutôt que comme une activité ponctuelle.

FAQ