structural testing tutorial what is structural testing
Ce didacticiel complet de test structurel explique ce qu'est le test structurel, ses types, ce qu'est le test de flux de contrôle et le graphique de flux de contrôle, les niveaux de couverture, etc.:
Une recherche rapide sur Google de certains des bogues logiciels les plus coûteux a laissé mon esprit bouleversé - 500 milliards de dollars. Oui, c'est à quel point un bogue peut coûter cher. Lire tout ce qui concerne les vies perdues dans les secteurs des transports et de la santé en raison d'un bogue logiciel peut également être horrible.
Bien que les erreurs de code ne soient pas toujours aussi extrêmes lorsqu'elles impliquent la perte de quantités importantes d'argent et de vies, le seul point clé que nous essayons de transmettre est qu'il ne faut pas négliger les tests.
Lorsque les tests sont effectués fréquemment tout au long du SDLC, cela nous permet de détecter les bogues qui nécessiteraient beaucoup plus de temps pour être corrigés après l'expédition du produit.
Ce qui importe, ce sont les types de tests logiciels que nous choisissons. Il en existe plusieurs, notamment les tests fonctionnels, structurels et basés sur le changement.
Ce didacticiel explique également les types de tests structurels. Apprenez à faire des tests de mutation, des tests basés sur des tranches, des tests de flux de données en détail avec des exemples et des explications.
Ce que vous apprendrez:
- Pourquoi les tests logiciels sont-ils importants
- Qu'est-ce que le test structurel
- Types de tests structurels
- Avantages et inconvénients des tests structurels
- Bonnes pratiques en matière de tests structurels
- Conclusion
Pourquoi les tests logiciels sont-ils importants
En plus d'économiser de l'argent et d'éviter des catastrophes comme les cas mentionnés ci-dessus, il existe plusieurs autres raisons pour justifier l'importance des tests.
Vous trouverez ci-dessous quelques raisons:
# 1) Pour s'assurer que les exigences stipulées sont respectées avant de commencer à construire un projet. Les parties prenantes (par exemple, les développeurs et les clients) doivent s'entendre sur tous les aspects de la solution / produit / logiciel qui sont nécessaires pour construire un projet.
Les tests consistent à vérifier si les exigences logicielles sont satisfaites. Le développeur ou l'entreprise impliquée dans la construction de la solution acquiert également une bonne réputation pour la conception d'une solution de haute qualité gérée par eclat code.
# 2) Il vérifie que la fonction de code fonctionne comme prévu. Les tests consistent également à vérifier la fonctionnalité du logiciel et en cas de dysfonctionnement, il doit être corrigé au cours des premières phases du SDLC (cycle de vie du développement logiciel).
# 3) Il vérifie les performances: par exemple, pour identifier le temps total écoulé pendant l'exécution du code. Si nous utilisons plusieurs Pour les boucles dans notre code, il faudra beaucoup de temps pour obtenir la sortie prévue et peut même parfois expirer.
# 4) Cela aide à obtenir une meilleure expérience utilisateur. Les utilisateurs n’apprécieront pas l’utilisation d’un logiciel défectueux, bogué ou «trop lent». Les utilisateurs seront probablement impatients et abandonneront l'utilisation du logiciel. Les tests nous permettent de mieux nous assurer que les utilisateurs peuvent facilement utiliser nos produits.
# 5) Il vérifie l'évolutivité. Un développeur doit viser à créer un logiciel pouvant être mis à l'échelle.
# 6) Il vérifie les vulnérabilités dans le code. Les tests nous permettent de détecter les failles de sécurité, Par exemple, code qui peut compromettre PII (Informations personnellement identifiables) qui est une priorité élevée pour le RGPD.
Dans cet article, nous allons nous concentrer sur un type de test, à savoir Essais structurels . Comme son nom l'indique, cela a à voir avec la structure du code. Ceci est différent de ce que nous avions mentionné précédemment que les tests aident à déterminer des aspects tels que les performances du code, les fonctionnalités et la sécurité.
Test structurel vs autres types de test
Il existe de nombreux types de tests logiciels. Cependant, le ARRÊTER (International Software Testing Qualifications Board), définit 4 principaux types de tests logiciels, à savoir
- Fonctionnel
- Non fonctionnel
- De construction
- Basé sur le changement
Les différences peuvent être expliquées ci-dessous:
Test fonctionel: Cela implique de vérifier la fonctionnalité du logiciel par rapport aux exigences stipulées. Les données de test sont utilisées comme entrée. Nous vérifions également que la sortie donnée est celle attendue.
Tests non fonctionnels : Cela implique un processus de test pour analyser le fonctionnement du logiciel, par exemple, le nombre d'utilisateurs qu'il peut gérer simultanément.
Essais structurels: Ce type de test est basé sur la structure du code. Par exemple, si un code est destiné à calculer la moyenne des nombres pairs dans un tableau, alors les tests basés sur la structure seraient intéressés par les «étapes qui mènent au calcul de la moyenne», plutôt que de savoir si la sortie finale est une valeur numérique correcte.
Supposons que nous devions vérifier si nous avons défini le code qui différencie les nombres pairs des nombres impairs. Nous pouvons avoir une instruction conditionnelle ici, comme, si un élément de tableau est divisible par deux sans reste, si (arr (i)% 2 === 0) alors le nombre peut être dit comme un nombre pair.
Les tests structurels sont effectués par les mêmes personnes qui écrivent le code comme elles le comprennent le mieux.
Test basé sur le changement : Cela implique de tester les effets des modifications apportées au code, puis de s'assurer que les modifications apportées ont été implémentées. Cela garantit également que les modifications apportées au code ne le brisent pas.
Ce que les tests structurels ne sont pas
Nous avons mentionné précédemment que les tests basés sur la structure se réfèrent à la structure du code. Notez que nous traitons ici du code réel. Nous ne vérifions pas les exigences ni même testons les entrées par rapport aux sorties attendues. Nous ne sommes pas concernés par la fonctionnalité, l'expérience utilisateur ou même les performances à ce stade.
Qu'est-ce que le test structurel
Les tests basés sur la structure peuvent donc être définis comme un type de test logiciel qui teste la structure du code et les flux prévus. Par exemple, vérifier le code réel pour des aspects tels que l'implémentation correcte des instructions conditionnelles, et si chaque instruction du code est correctement exécutée. Il est également connu sous le nom de test basé sur la structure.
Pour effectuer ce type de test, nous devons bien comprendre le code. C'est pourquoi ces tests sont généralement effectués par les développeurs qui ont écrit le code tel qu'ils le comprennent le mieux.
Comment effectuer des tests structurels
Pour tester différents aspects du code, nous devons d'abord comprendre les flux de contrôle.
Test de flux de contrôle
Il s'agit de dériver des tests à partir des flux de contrôle du code (l'ordre dans lequel les instructions, les fonctions et les différents aspects du code sont implémentés).
Processus de test de flux de contrôle:
Graphique de flux de contrôle
Le processus de flux de contrôle commence par créer une représentation visuelle des différentes sections du code qui nous aide à définir les chemins qui peuvent être suivis pendant l'exécution.
Ces représentations visuelles sont appelées graphiques de flux de contrôle (CFG) et comportent plusieurs composants tels que des nœuds, des arêtes, des chemins, des jonctions et des points de décision. Le graphique peut être créé manuellement ou automatiquement, où un logiciel est utilisé pour extraire le graphique du code source.
Examinons ces composants ci-dessous:
# 1) Bloc de processus
Cette partie est utilisée pour représenter une section de code qui est exécutée séquentiellement. Cela signifie qu’elle est exécutée de la même manière à chaque fois et qu’il n’y a pas de décision ou de «ramification» à faire. Il est composé de nœuds avec un chemin d'entrée et de sortie.
Exemple de bloc de processus:
(image la source )
Le bloc de processus n'est pas une partie essentielle du flux de contrôle et, par conséquent, ne doit être testé qu'une seule fois.
# 2) Points de décision
Voici quelques éléments clés du flux de contrôle du code. Au sein de ces nœuds, des décisions sont prises. Cela se fait généralement par comparaison et le flux de contrôle change, en fonction de la décision. Cette partie du CFG est constituée d'un nœud avec au moins 2 sorties.
La décision prise ici pourrait être des instructions conditionnelles telles que des instructions if-else (qui ont deux sorties possibles) et des instructions case (qui peuvent avoir plus de deux sorties).
(image la source )
Dans le diagramme ci-dessus, il y a un point de décision (à partir du conditionnel «âge = 18») qui est suivi des options «oui» ou «non».
# 3) Points de jonction
À partir du diagramme ci-dessus, nous pouvons facilement identifier les points de jonction pour savoir où les points de décision se rejoignent. Les points de jonction peuvent avoir plusieurs chemins d'entrée, mais ne peuvent avoir qu'un seul chemin de sortie.
Bonnes pratiques relatives aux graphiques de flux de contrôle:
Il y a quelques points à noter lors de la construction de graphiques de flux de contrôle:
- Essayez autant que possible de garder le CFG simple. Nous pouvons le faire en combinant des parties qui peuvent être considérées comme «moins importantes», par exemple, blocs de processus.
- Assurez-vous qu'aux points de décision, une seule décision est prise. Dans les CFG plus complexes, il y a des «conséquences» qui surviennent après la prise de décision. Dans notre exemple ci-dessus, nous pourrions également ajouter que si une personne a 18 ans ou plus, elle est éligible et doit payer un billet. Si ce n'est pas le cas, l'entrée est gratuite. La décision «autre» doit «sauter» quelques nœuds, et toutes ces étapes doivent être indiquées dans notre CFG.
Une fois que nous avons défini notre CFG, il est maintenant temps de passer à l'étape suivante du processus de test de flux de contrôle, c'est-à-dire de définir dans quelle mesure nous allons tester le code.
Définition de la quantité à tester:
Quelle quantité de code source doit être testée? Doit-on tester chaque chemin possible? Essayer de couvrir tous les chemins dans nos tests est pratiquement impossible. Nous devons trouver un terrain d'entente pour déterminer la quantité de tests que nous pouvons faire.
Si nous disons que nous visons à tester 50% de notre code, cela pourrait signifier que nous définirons toutes les instructions de code exécutables et viserons à en tester au moins la moitié. Cependant, la question qui se pose ici est «devons-nous alors définir tous les chemins exécutables possibles?»
meilleur nettoyeur de pc gratuit pour windows 10
Encore une fois, cela peut être pratiquement impossible. Une meilleure approche pourrait consister à tester 50% des chemins que nous pouvons identifier à chaque section du code.
Il existe différents niveaux de couverture, à savoir la couverture des relevés, des succursales et des chemins. Nous les examinerons brièvement plus tard.
Création de cas de test:
La prochaine étape consiste à créer les cas de test que nous utiliserons. Les cas de test dans les tests basés sur la structure sont basés sur les facteurs suivants:
- Les instructions exécutables.
- Les «décisions» qui doivent être prises.
- Les chemins possibles qui peuvent être suivis.
- Les conditions à remplir (celles-ci peuvent être multiples ou booléennes).
Les facteurs ci-dessus nous donnent une idée des types de cas de test que nous devons créer. Nous pouvons également utiliser un outil de génération de tests structurels. Si notre code est dans le langage de programmation C, nous pouvons utiliser PathCrawler pour générer du code de test. Un autre outil que nous pouvons utiliser est le fMBT.
Exécution des cas de test:
Ici, nous pouvons exécuter les tests. Nous pouvons entrer des entrées ou des données pour vérifier comment le code l'exécute, puis vérifier si nous obtenons les résultats attendus. Par exemple, entrez un tableau dans un appel de fonction pour observer les résultats que nous obtenons après l'avoir parcouru ou pour vérifier si les points de décision prennent les bonnes décisions.
Analyse des résultats:
Dans cette partie, tout ce que nous faisons est de vérifier si nous obtenons les bons résultats après l'exécution. Par exemple, si nous entrons dans un tableau où toutes les valeurs sont supérieures à 18, alors nous devrions avoir tous les points de décision résultant en «éligible».
Hypothèses du flux de contrôle
Il est important de noter que pour effectuer des tests de flux de contrôle, quelques hypothèses sont formulées. Ceux-ci inclus:
- Les seuls bogues présents sont ceux qui peuvent affecter le flux de contrôle.
- Toutes les variables, fonctions et éléments sont définis avec précision.
Niveaux de couverture dans les flux de contrôle
Comme nous l'avons mentionné précédemment, il existe différents niveaux de couverture dans les tests de flux de contrôle.
Regardons-les brièvement.
# 1) Couverture des relevés
Dans les tests structurels, les instructions de code exécutables jouent un rôle essentiel lorsqu'il s'agit de décider des méthodes de conception des tests.
Nous visons à atteindre une couverture de 100%, ce qui signifie que chaque instruction exécutable a été testée au moins une fois. Plus la couverture est élevée, moins il y a de chances de manquer les bogues et les erreurs.
Il est nécessaire d'utiliser des cas de test ici. Les données dont nous avons besoin sont de nous assurer que chaque instruction exécutable dans un bloc de code est exécutée au moins une fois.
# 2) Couverture de la succursale
Ce niveau de couverture consiste à tester les points dans les branches CFG (où les décisions sont prises). Les résultats sont booléens. Même si une instruction switch est utilisée et qu'il existe plusieurs résultats, chaque bloc de cas est essentiellement une comparaison d'une paire de valeurs.
Tout comme pour la couverture des relevés, nous devrions viser une couverture de succursale à 100%. Pour y parvenir, nous devons tester chaque résultat à chaque niveau de décision au moins une fois. Puisque nous avons affaire à des résultats booléens, nous devrions viser à exécuter au moins 2 tests par section de code.
# 3) Couverture de chemin
Ce niveau de couverture est plus complet que celui des décisions et des déclarations. Le but ici est de «découvrir» tous les chemins possibles et de les tester au moins une fois. Cela peut prendre beaucoup de temps. Il peut cependant aider à découvrir des bogues ou des erreurs dans notre code, voire des aspects que nous devons définir, par exemple, entrée utilisateur.
Types de tests structurels
(image la source )
Test de mutation
Le test de mutation est une technique de test basée sur les erreurs dans laquelle diverses variantes d'une application logicielle sont testées par rapport à l'ensemble de données de test.
>> Reportez-vous à ce tutoriel pour un examen approfondi de Test de mutation.
Test basé sur les tranches
Le test basé sur une tranche (SBT) peut être défini comme une technique de test logiciel basée sur tranches - parties exécutables du programme ou groupes d'instructions qui affectent certaines valeurs à des points d'intérêt particuliers dans le programme, par exemple, parties où les variables sont définies ou la sortie d'un groupe d'instructions.
Comment trancher
Exemple de tranchage dans SBT: Code pour imprimer les nombres pairs et impairs (Python)
num_list = range(1,12) even_nums = () odd_nums = () for var in num_list: if var%2==0: even_nums.append(var) print(f'Even numbers: {even_nums}') elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}') 
Il y a deux façons de regarder une tranche: En suivant le chemin d'une variable d'intérêt ou la partie du code qui affecte la sortie.
Dans notre exemple, si nous regardons la sortie des nombres impairs, nous pouvons tracer la partie du code qui nous mène à cette sortie.
La clé de sécurité du réseau est-elle la même que le mot de passe wifi
Dans les critères de découpage donnés par Mark Weiser (qui a introduit SBT), une tranche est définie à l'aide de cette formule: S (v, n) , où, v fait référence à la variable en question ( par exemple, où une variable est définie), et n est la déclaration d'intérêt ( par exemple, où la sortie est donnée), et S représente la tranche.
Dans l'exemple ci-dessus, pour obtenir la tranche, nous partons de notre sortie sur la ligne 10, qui devient notre n . Notre variable est où .
Nos critères de découpage sont donc:
S(v,n) = S(var,10)Notre préoccupation, ce sont les déclarations qui nous conduisent à la sortie.
Ceux-ci sont:
10,9,8,4,3,1
Donc, notre tranche dans ce code est:
num_list = range(1,12) odd_nums = () for var in num_list: elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')
Types de tests basés sur les tranches
Il existe deux types de SBT: statique et dynamique
# 1) Test basé sur les tranches dynamiques
L'exemple SBT expliqué ci-dessus où nous avons regardé les instructions qui affectent l'impression des nombres impairs est SBT dynamique. Notre préoccupation est très précise. Nous arrivons à nous concentrer uniquement sur ce qui affecte directement la sortie particulière.
Nous exécutons le code et utilisons des données de test pour nous assurer qu'il fonctionne comme prévu. Nous pourrions augmenter la gamme à la gamme (1,50), par exemple, pour voir s'il ne génère toujours que des nombres impairs. Le SBT dynamique est également appelé test de validation.
# 2) StatiqueTest basé sur les tranches
Contrairement à Dynamic SBT, les tests statiques se concentrent sur une variable particulière. Si nous pensons à notre sortie dans l'exemple ci-dessus comme où , nous pouvons tracer la tranche qui l'affecte comme 10,9,8,7,6,5,4,3,2,1
C'est fondamentalement le bloc de code entier! Ici, nous vérifions que le code est correct en termes de syntaxe et d'exigences, et nous ne l'exécutons pas. Le SBT statique est également appelé test de vérification.
Il est important de noter que le SBT dynamique est «plus petit» par rapport à son homologue statique. C'est aussi plus spécifique.
Bonnes pratiques / directives pour les tests basés sur les tranches
Les critères de tranchage doivent être déterminés par:
- Instructions où les valeurs sont définies ou affectées à une valeur, ainsi que la valeur réaffectée.
- Déclarations où les valeurs sont reçues de l'extérieur du programme, par exemple, via l'entrée utilisateur.
- Déclarations qui impriment la sortie / retournent la sortie.
- La dernière déclaration du programme, par exemple, un appel de fonction qui peut définir des valeurs ou fournir des valeurs aux arguments
Les avantages des tests basés sur les tranches incluent:
- Puisque dans SBT nous travaillons uniquement avec des domaines d'intérêt spécifiques, il est plus facile de générer efficacement des suites de tests.
- Le chemin est défini par des dépendances dans le code, ce qui est mieux que d'utiliser couverture du chemin.
- Avec SBT, il est plus facile de trouver des erreurs dans le code source.
Les inconvénients des tests basés sur les tranches incluent:
- Si nous utilisons des tests dynamiques lors du test d'une grande base de code, nous aurons besoin de beaucoup de ressources de calcul.
- Si nous utilisons des tests statiques, nous pourrions manquer des erreurs.
Test de flux de données
Le test de flux de données peut être défini comme une technique de test logiciel basée sur des valeurs de données et leur utilisation dans un programme. Il vérifie que les valeurs des données ont été correctement utilisées et qu'elles génèrent les bons résultats. Les tests de flux de données permettent de suivre les dépendances entre les valeurs de données sur un chemin d'exécution particulier.
Anomalies du flux de données
Les anomalies de flux de données sont simplement des erreurs dans un programme logiciel. Ils sont classés en types 1, 2 et 3 respectivement.
Examinons-les ci-dessous:
Type 1: Une variable est définie et une valeur lui est affectée deux fois.
Exemple de code: Python
lst_1 = (1,2,3,4) lst_1 = (5,6,7,8) for var in lst_1: print(var) 
Lst_1 est défini et deux valeurs différentes lui sont affectées. La première valeur est simplement ignorée. Les anomalies de type 1 n'entraînent pas l'échec du programme.
Type 2: La valeur d'une variable est utilisée ou référencée avant d'être définie.
Exemple de code: Python
for var in lst_1: print(var) 
La boucle ci-dessus n'a aucune valeur à parcourir. Les anomalies de type 2 provoquent l'échec du programme.
Type 3: Un la valeur des données est générée, mais n'est jamais utilisée.
Exemple de code: Python
lst_1 = (1,2,3,4) lst_2 = (5,6,7,8) for var in lst_1: print(var) 
La variable lst_2 n'a pas été référencé. Les anomalies de type 3 peuvent ne pas provoquer l'échec du programme.
Processus de test de flux de données
Pour définir les dépendances entre les valeurs de données, nous devons définir les différents chemins qui peuvent être suivis dans un programme. Pour ce faire efficacement, nous devons emprunter à un autre type de test structurel appelé test de flux de contrôle .
Étape 1) Dessiner un graphique de flux de contrôle
Nous devons dessiner un graphe de contrôle, qui est une représentation graphique des chemins que nous pourrions suivre dans notre programme.
Exemple de code: Python
cost = 20 y = int(input('How many visitor seats did you reserve? ')) x = int(input('How many member seats did you reserve? ')) if y>x: bill = cost -1 else: bill = cost print(bill) 
Dans l'exemple de code ci-dessus, un membre devrait bénéficier d'une réduction s'il invite un visiteur.
Graphique de flux de contrôle (CFG):
Étape 2) Explorez la définition et l'utilisation des variables et des valeurs de données.
Une variable dans un programme est définie ou utilisée. Dans CFG, nous avons des variables à chaque nœud. Chaque nœud est nommé en fonction du type de variable qu'il héberge. Si une variable est définie à un nœud particulier, elle crée un nœud de définition. Si une variable est utilisée sur un nœud, elle crée un nœud d'utilisation.
Si nous considérons le coût variable dans CFG, ce sont les nœuds de définition et d'utilisation:
| Nœud | Taper | Code |
|---|---|---|
| un | Définition du nœud | coût = 20 |
| 5 | Nœud d'utilisation | facture = coût -1 |
| sept | Nœud d'utilisation | facture = coût |
Étape 3) Définissez les chemins d'utilisation des définitions.
Il existe deux types de chemins d'utilisation des définitions: du chemins et chemins dc. Les chemins du sont des chemins de définition qui commencent par un nœud de définition et se terminent par un nœud d'utilisation. C'est le cas du chemin en référence au coût variable ci-dessus.
Un exemple de chemin dc, un chemin clair de décision, est le chemin en ce qui concerne la variable de facturation comme ci-dessous:
| Nœud | Taper | Code |
|---|---|---|
| 5 | Définition du nœud | facture = coût -1 |
| sept | Définition du nœud | facture = coût |
| 8 | Nœud d'utilisation | imprimer (facture) |
dc path a plus d'un nœud de définition même s'il se termine toujours à un nœud d'utilisation.
Étape 4) Créez la suite de tests.
Ceci ajoute une entrée. Notez que nous devons avoir une suite de tests différente pour chaque variable. La suite de tests nous aidera à identifier les anomalies de flux de données.
Types de test de flux de données
Il existe deux types - Statique et dynamique .
Statique signifie que nous parcourons le code et CFG pour identifier les anomalies de données, sans l'exécuter. Dynamique signifie que nous identifions en fait les chemins spécifiques, puis créons des suites de tests pour les tester dans le but de «détecter» les anomalies que nous avons pu manquer lors des tests statiques.
Avantages et inconvénients des tests de flux de données:
- Le test de flux de données est idéal pour identifier les anomalies de flux de données, ce qui en fait une méthode de test structurel très efficace.
- Son inconvénient est qu'il est nécessaire de bien connaître le langage utilisé pour écrire le code pour utiliser les tests de flux de données. Cela prend également du temps.
Avantages et inconvénients des tests structurels
Voyons maintenant les raisons pour lesquelles les tests structurels sont une excellente approche et explorons également certains de ses inconvénients.
Avantages:
- Permet des tests de code approfondis, entraînant des erreurs minimes. Les tests basés sur la structure permettent aux logiciels d'être testés de manière approfondie. Les différents niveaux de couverture - déclaration par déclaration, chaque point de décision et chemin visent à atteindre une couverture de 100%, ce qui réduit considérablement les risques d'erreurs non détectées.
- La possibilité d'automatiser . Il existe plusieurs outils que nous pouvons utiliser pour automatiser les tests. Cela nous aidera à atteindre une couverture de code maximale et dans un délai plus court par rapport aux tests manuels.
- Il en résulte un code de meilleure qualité . Les développeurs ont la possibilité d'étudier la structure et l'implémentation du code et de corriger les erreurs, ainsi que d'améliorer ces aspects. Cela nous permet de garder à l'esprit la grande structure lorsque nous écrivons les parties suivantes du code ou implémentons les fonctionnalités restantes.
- Cela peut être fait à chaque phase du SDLC - Les tests structurels peuvent être effectués à chaque phase du SDLC sans attendre que le développement soit terminé à 100%. Cela facilite l'identification des erreurs au début et permet ainsi de gagner beaucoup de temps par rapport aux tests une fois le développement terminé.
- Cela aide à se débarrasser du code mort . Cela peut être considéré comme un code 'supplémentaire' ou inutile, par exemple, code qui calculera un résultat mais ne l'utilisera jamais dans aucun des calculs suivants.
- Efficacité - Puisque les développeurs qui écrivent le code sont les mêmes que ceux qui le testent, il n'est pas nécessaire d'impliquer d'autres personnes comme le contrôle qualité.
Désavantages:
- Les développeurs qui effectuent des tests basés sur la structure doivent avoir une compréhension approfondie du langage . D'autres développeurs et QA qui ne maîtrisent pas bien le langage ne peuvent pas aider aux tests.
- Cela peut devenir assez coûteux en temps et en argent . Beaucoup de temps et de ressources sont nécessaires pour effectuer des tests efficacement.
- Cela entraîne des retards dans la livraison des fonctionnalités . C'est parce que les développeurs sont retirés de la création de logiciels pour faire des tests.
- La mise à l'échelle est un problème, en particulier lorsque de grandes applications sont impliquées . Une grande application équivaut à un nombre excessivement élevé de routes à parcourir. Atteindre une couverture à 100% devient impossible.
- Il peut y avoir des cas et des itinéraires manqués , par exemple, dans un cas où les fonctionnalités ne sont pas complètement développées ou doivent encore être développées. Cela signifie qu'il doit être combiné avec d'autres types de tests tels que les tests d'exigences (où nous vérifions les fonctionnalités spécifiées qui devaient être construites).
Bonnes pratiques en matière de tests structurels
Certains des facteurs qui nécessitent une attention lors de la réalisation de tests basés sur la structure sont les suivants:
- Étiquetez et nommez clairement les tests . Si quelqu'un d'autre a besoin d'exécuter les tests, il doit être en mesure de les localiser facilement.
- Avant d'améliorer le code, c'est-à-dire en le refactorisant et en l'optimisant pour une utilisation dans différents environnements, assurez-vous que sa structure et son flux sont idéaux.
- Exécutez les tests séparément . De cette façon, il est facile d'identifier les bogues et de les corriger. D'un autre côté, nous sommes moins susceptibles de manquer des bogues ou des chemins en raison de chevauchements dans les sections de code, les blocs ou les chemins.
- Générez des tests avant d'apporter des modifications . Les tests doivent s'exécuter comme prévu. De cette façon, si quelque chose se brise, il est facile de retracer et de résoudre le problème.
- Gardez les tests pour chaque section ou bloc de code séparés . De cette façon, s'il y a des changements sur toute la ligne, nous n'avons pas besoin de changer beaucoup de tests.
- Corrigez les bugs avant de passer aux tests . Si nous identifions des bogues, il vaut mieux les corriger avant de procéder au test de la section ou du bloc de code suivant.
- Ne sautez jamais les tests structurels en supposant qu’un AQ «effectuera toujours des tests de toute façon». Même si les bogues peuvent sembler insignifiants au début, cumulativement, ils peuvent entraîner un code bogué qui ne pourra jamais atteindre son objectif.
FAQ pour les tests basés sur la structure
Nous explorerons ici les questions fréquemment posées en matière de tests basés sur la structure.
Q # 1) Quelle est la différence entre les tests fonctionnels et les tests structurels?
Répondre: Le test fonctionnel est un type de test logiciel basé sur les exigences stipulées dans le SRS (Software Requirements Specifications). Cela est généralement fait dans le but de trouver des disparités entre les spécifications du SRS et le fonctionnement du code. Les tests structurels sont basés sur la structure interne du code et sa mise en œuvre. Une compréhension approfondie du code est requise.
Q # 2) Quels sont les types de tests structurels?
Répond à les types incluent:
- Test de flux de données
- Test de mutation
- Test de flux de contrôle
- Tests basés sur les tranches
Q # 3) Qu'est-ce qu'un exemple de test structurel?
Réponse: Voici un exemple montrant la couverture des relevés:
const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums(); La quantité de couverture que nous obtenons dépend des données de test que nous fournissons en entrée (si elles remplissent les conditions de somme> 0).
Q # 4) Quelle est la différence entre les tests de flux de données et les tests de flux de contrôle?
Répondre: Les tests de flux de données et les tests de flux de contrôle utilisent des graphiques de flux de contrôle. La seule différence est que dans les tests de flux de contrôle, nous nous concentrons sur les chemins générés à partir du code, tandis que dans les tests de flux de données, nous nous concentrons sur les valeurs de données, leur définition et leur utilisation dans les chemins identifiés dans un programme.
Q # 5) À quoi sert le test de flux de données?
Répondre: Le test de flux de données est idéal pour identifier les anomalies dans l'utilisation des valeurs de données dans les chemins dans un graphique de flux de contrôle, par exemple, une variable à laquelle une valeur a été attribuée deux fois, une variable qui a été définie et non utilisée, ou une variable qui a été utilisée ou référencée et non définie.
Q # 6) Quelle est la différence entre le tranchage et le découpage en dés dans les tests logiciels?
Répondre: Trancher signifie se concentrer sur des déclarations d'intérêt particulières dans un programme et ignorer le reste. Le découpage en dés consiste à identifier une tranche qui a une mauvaise entrée, puis à la découper davantage pour tracer le comportement correct.
Q # 7) Quelle est la différence entre le test de mutation et la couverture de code?
Répondre: Dans les tests de mutation, nous considérons le nombre de mutants tués comme un pourcentage du total des mutants. La couverture de code est simplement la quantité de code qui a été testée dans un programme.
Conclusion
Dans ce didacticiel, nous avons examiné en profondeur les tests structurels - ce que c'est, ce qu'il n'est pas, comment s'y prendre, les types de couverture, les avantages et les inconvénients, les meilleures pratiques et même quelques FAQ concernant ce type de test logiciel.
Il y a encore tellement plus que nous pouvons en apprendre sur les tests basés sur la structure. Dans les prochains didacticiels, nous explorerons la couverture du code (instruction, décision, branche et chemin), les types de tests structurels (mutation, flux de données et basé sur des tranches), et même les outils que nous pouvons utiliser pour automatiser ces processus de test.
Il est important de noter qu'il n'existe aucun type de test logiciel ni aucune approche efficace à 100%. Il est toujours conseillé de combiner différents types et approches de test.
Par exemple, les tests structurels sont largement complétés par des tests d'exigences, car il se peut que certaines fonctionnalités n'aient pas été développées au moment où les tests structurels ont été effectués.
Les techniques de test structurel sont basées sur les erreurs que font les programmeurs humains lors de l'écriture de code. L'hypothèse est que le programmeur est un expert et sait ce qu'il ou elle code, mais se trompe de temps en temps.
Les différents types de tests structurels que nous avons examinés - les tests de mutation, les tests basés sur les tranches et les tests de flux de données peuvent être attribués à des erreurs telles que l'utilisation du mauvais opérateur (test de mutation) ou le référencement d'une variable avant de l'utiliser (test de flux de données) .
lecture recommandée
- Tutoriel sur les tests destructifs et les tests non destructifs
- Test fonctionnel vs test non fonctionnel
- Qu'est-ce que la technique de test basée sur les défauts?
- Tutoriel de test de trempage - Qu'est-ce que le test de trempage
- Tutoriel de test SOA: méthodologie de test pour un modèle d'architecture SOA
- Test de charge avec les didacticiels HP LoadRunner
- Qu'est-ce que le test gamma? L'étape finale du test
- Tutoriel de test DevOps: quel sera l'impact de DevOps sur les tests d'assurance qualité?
- Qu'est-ce que les tests de conformité (tests de conformité)?