Les testeurs sont tous doués pour dessiner. Voyons qui ne sait pas utiliser les diagrammes de code ?

L'équipe de la communauté open source chinoise a réalisé sa première diffusion en direct, racontant l'histoire de la communauté open source chinoise au nom du partage.

Donnez à tout le monde 30 secondes pour réfléchir à ce que c'est ?

Diagramme de classes initial de la fonction du module de connexion d'un certain système

Il s'agit du diagramme de classes initial de la fonction du module de connexion d'un certain système.

Alors que les logiciels modernes deviennent de plus en plus complexes, les Code Graphs offrent aux testeurs un moyen intuitif de rendre la logique de code complexe facile à comprendre. Cet article se penchera sur les graphiques de code et démontrera comment les graphiques de code visuels peuvent améliorer les capacités des testeurs de logiciels et comment effectuer des tests à travers des scénarios réels et des exemples pratiques.

1. Qu'est-ce qu'un diagramme de code ?

Le diagramme de code fait référence à un outil graphique utilisé pour représenter la structure du code, les relations entre les classes ou les interactions entre les éléments de code. Les types courants incluent les diagrammes de classes, les diagrammes de séquence, les diagrammes d'activités, les diagrammes de composants, etc.

La carte de code se compose des deux parties suivantes :

Les nœuds ( Nodes ) représentent des éléments de code, tels que des classes, des objets et des activités ;
Les bords représentent les relations entre les nœuds, telles que l'association, l'héritage et la dépendance .

Prenons comme exemple le diagramme de classes d'une relation de combinaison :

Diagramme de classes de relation de combinaison

2. Avantages de la visualisation du code

La visualisation du code affiche graphiquement la structure et les relations du code. Les membres de l'équipe bénéficient de nombreux avantages en utilisant des diagrammes de code pendant le processus de test du logiciel, tels que l'amélioration de la communication et de la collaboration entre eux, l'augmentation de l'efficacité et de la concentration, etc. Cela aide les testeurs de logiciels à comprendre plus rapidement la logique et les relations du code, réduisant ainsi le temps consacré à la lecture et à la compréhension du code.

1Améliorer la communication et la collaboration

Le rôle important des diagrammes de code est d’aider à combler le fossé entre les personnes techniques et non techniques. Les testeurs peuvent facilement expliquer le déroulement du code aux responsables, aux clients ou aux membres qui ne connaissent pas le code.

Stelios Manioudakis, ancien ingénieur logiciel de Siemens, s'est pris comme exemple pour illustrer pleinement le rôle des diagrammes de code dans l'amélioration de la communication et de la collaboration.

À ses débuts en tant que testeur de logiciels, il a travaillé sur un projet visant à développer une nouvelle application de suivi de la condition physique. Ils analysent les données des capteurs grâce à des algorithmes de suivi du sommeil pour déterminer les étapes du sommeil (sommeil léger, sommeil profond) et générer des rapports de sommeil. Mais lors du test de l'algorithme, ils ont rencontré beaucoup de difficultés, car il est difficile pour les personnes non techniques de comprendre la logique de l'algorithme uniquement par le code.

C'est là que les diagrammes de code sont utiles. Ils utilisent le flux d'algorithmes visuels et les points de décision pour différentes lectures de capteurs et calculs de schémas de sommeil afin de permettre aux chefs de produit et aux concepteurs d'interface utilisateur de comprendre les scénarios potentiels qui doivent être testés à l'aide de diagrammes de code, tels que des schémas de sommeil instables ou des données de capteur manquantes.

De plus, les cartes de code facilitent la collaboration avec les développeurs. Lors des révisions de code, les testeurs et les développeurs peuvent mieux identifier les différences potentielles entre la logique prévue et la mise en œuvre réelle en se référant à la carte du code. En fin de compte, l'algorithme de suivi du sommeil de l'application de suivi de la condition physique a réussi le test et le diagramme de code a joué un rôle majeur.

2 Améliorer l’efficacité et la concentration

Les testeurs peuvent planifier, écrire et exécuter des tests plus efficacement grâce à des diagrammes de code, réduisant ainsi le travail répétitif et améliorant ainsi la couverture et la qualité des tests.

Prenons l'exemple de l'algorithme push news. Cet algorithme fait des recommandations personnalisées aux utilisateurs en fonction de leurs intérêts et de leurs interactions. Au départ, les testeurs doivent parcourir attentivement le code ligne par ligne, une approche longue et laborieuse qui rend difficile l'identification de tous les scénarios de test potentiels. Mais les diagrammes de code affichent de manière intuitive des facteurs d’influence tels que les préférences de l’utilisateur, les interactions entre les publications et la fraîcheur du contenu. De plus, les diagrammes de code fournissent des points de décision clairs et des chemins de branchement.

Sujets d'actualité : concentrez-vous sur les scénarios de test dans lesquels les sujets d'actualité sont affichés en premier dans le flux d'informations pour garantir que les utilisateurs ne manqueront pas de contenu populaire.
Recommandations personnalisées : donnez la priorité aux tests de différents profils d'utilisateurs ayant des intérêts et des interactions différents pour vérifier si l'algorithme recommande avec précision un contenu pertinent.
Cas extrêmes : les cas extrêmes potentiels, tels que les utilisateurs inactifs ou les utilisateurs ayant une interaction limitée, sont mis en évidence. Les testeurs peuvent concevoir des cas de test spécifiques pour garantir que l'algorithme n'échoue pas dans ces circonstances.

Il est évident que l’utilisation de diagrammes de code est beaucoup plus rapide que l’inspection du code ligne par ligne. Cela permet aux testeurs de prioriser les domaines clés de l'algorithme, garantissant ainsi des tests approfondis et offrant aux utilisateurs une expérience de fil d'actualité plus fiable et personnalisée.

3Améliorer la maintenabilité des documents

La documentation peut aider les membres de l'équipe à comprendre plus rapidement le déroulement du programme et les points de test potentiels après la refactorisation du code ou lorsque de nouveaux membres de l'équipe doivent réviser le code.

Par exemple : le système de gestion des stocks d'une plateforme de commerce électronique a été créé il y a de nombreuses années. Aujourd'hui, la maintenance est devenue de plus en plus complexe et les nouvelles fonctions sont de plus en plus difficiles à mettre en œuvre. Pendant le processus d'ajustement du système, face à une logique complexe de gestion des stocks, le diagramme de code affiche intuitivement tout, de l'ajout et de la mise à jour du produit au traitement des commandes et à la gestion du niveau de stock.

De cette manière, les testeurs peuvent garantir que le système de gestion des stocks ajusté est maintenu efficacement et que le rôle des diagrammes de code va de soi.

Communiquez plus clairement : utilisez des diagrammes de code pour expliquer les fonctionnalités du système aux nouveaux membres de l'équipe. Associés aux commentaires de code, ces diagrammes fournissent un aperçu clair et concis, permettant de comprendre plus rapidement la logique du système et les considérations de test.
Révision efficace du code : lors de la révision du code, le référencement aux diagrammes de code et aux commentaires de code peut aider à identifier rapidement les problèmes potentiels. En visualisant l'impact des changements sur le processus global, les équipes peuvent garantir que les modifications n'auront pas d'effets secondaires involontaires sur d'autres parties du système.
Maintenance évolutive : à mesure que le système évolue et que de nouvelles fonctionnalités sont ajoutées, les diagrammes de code servent de points de référence précieux. Même les testeurs qui n'ont pas été impliqués dans le projet peuvent facilement comprendre la logique existante et les domaines d'impact potentiels, permettant ainsi des efforts de test plus efficaces et ciblés.

4. Détectez les problèmes le plus tôt possible

Les diagrammes de code peuvent révéler des problèmes qui pourraient passer inaperçus lors d'une révision de code en texte brut, car les diagrammes de code plus compliqués indiquent un code plus complexe, qui est plus sujet aux erreurs.

Par exemple, le système de prise de rendez-vous de l'hôpital a introduit une nouvelle fonctionnalité lors du processus de mise à jour : permettre aux patients de reprogrammer leurs rendez-vous en ligne. Après la révision du code et la conception du scénario de test, de nouvelles fonctionnalités peuvent être utilisées si aucun problème majeur n’est détecté.

Cependant, étant donné la complexité du traitement de parties spécifiques de rendez-vous conflictuels, les testeurs ont décidé d'utiliser des diagrammes de code pour une inspection et une validation plus approfondies. Les diagrammes de code illustrent les problèmes potentiels qui pourraient être négligés lors d'une révision textuelle :

Points de décision multiples : de nombreux points de décision basés sur divers facteurs tels que les rendez-vous existants, la disponibilité du médecin et les contraintes de temps. Cette structure de branchement complexe entraîne un risque d'erreur plus élevé car il est difficile d'envisager tous les scénarios possibles lors des tests.
Logique cachée : la nature complexe des diagrammes rend très difficile la compréhension visuelle de la logique du code. Cela soulève des inquiétudes quant à d’éventuelles conditions cachées ou à un comportement inattendu dans le code.

En conséquence, les testeurs ont réajusté les nouvelles fonctions sur la base du diagramme de code :

Prioriser les tests : donnez la priorité aux tests de scénarios impliquant des dates conflictuelles. Concentrez-vous sur les cas extrêmes et les combinaisons qui peuvent exposer des erreurs potentielles dans une logique complexe.
Collaborer avec les développeurs : à l'aide de représentations visuelles, les testeurs discutent des complexités découvertes avec les développeurs. La collaboration a abouti à des efforts de refactorisation du code qui ont simplifié la logique et réduit la complexité cyclomatique.

Les testeurs utilisent des cartes de code pour identifier de manière proactive les problèmes potentiels et travailler avec les développeurs pour les résoudre. Cela garantit l’intégrité et la fiabilité du système de planification des rendez-vous à l’hôpital.

5 connexions de programmation structurées

Les diagrammes de code s'intègrent parfaitement aux principes de la programmation structurée (séquence, sélection et répétition). Ces structures de base correspondent directement à des modèles graphiques spécifiques, simplifiant ainsi les tests de ces structures communes.

(1) Conception de test simplifiée : la programmation structurée met l'accent sur des structures clairement définies, telles que la séquence, la sélection (if-else) et la répétition (boucle). Les cartes de code mappent ces structures directement à des modèles spécifiques :

Séquence : un nœud de ligne droite représentant une instruction suivant une autre instruction

Sélection : une structure de branchement avec un seul nœud d'entrée, un nœud conditionnel et deux bords sortants (un pour vrai et un pour faux), menant à une séquence distincte d'instructions

Répéter : un modèle de boucle avec un nœud d'entrée, un nœud de condition, un bord renvoyant le nœud de condition et un bord pointant vers le corps de la boucle (séquence d'instructions)

(2) Visualisation plus facile des cas de test : en identifiant ces modèles familiers dans les diagrammes de code, les testeurs peuvent rapidement comprendre le déroulement du programme et les cas de test correspondants. Par exemple, le modèle de boucle dans le diagramme représente la nécessité de scénarios de test pour couvrir diverses itérations de la boucle, y compris les conditions aux limites et le comportement attendu.

6 En savoir plus sur la mesure de la complexité

Le numéro de cycle est une mesure basée sur la complexité du graphe de code qui permet d'évaluer la difficulté de tester un programme. Plus la complexité est élevée (plus il y a de chemins), plus les tests seront approfondis. Mais entrons dans les détails.

Nombre de boucles : cette métrique est dérivée de la structure du graphe de code et est utilisée pour estimer le nombre de chemins d'exécution indépendants dans un programme. Plus le nombre de boucles est élevé, plus la complexité est élevée, généralement en raison de facteurs tels que des boucles imbriquées, plusieurs points de décision ou des instructions GOTO .
Planification intelligente des tests : les numéros de cycle servent de guide aux testeurs, indiquant l'effort requis pour des tests complets. Un programme avec un nombre de boucles plus élevé nécessite plus de cas de test pour couvrir tous les chemins d'exécution potentiels qu'un programme avec un nombre de boucles inférieur. Cela aide les testeurs à prioriser leur travail et à garantir une couverture complète des sections complexes.

Voici un exemple rapide, considérons un programme simple avec deux instructions if-else consécutives :

if condition1:
  # statements for if condition1 is true
else:
  if condition2:
    # statements for if condition2 is true
  else:
    # statements for both conditions false

Un programme simple avec deux instructions if-else consécutives

nœud:

Nœud 1 : Le point de départ du programme, représentant le début de l'exécution du code.
Nœud 2 : Condition du nœud de décision1 . Ce nœud évalue la condition et détermine le flux d'exécution en fonction du résultat (vrai ou faux).
Nœud 3 : Le bloc d'instructions condition1 est exécuté s'il est vrai . Ce nœud représente tout le code dans le bloc "if" de condition1 .
Nœud 4 : Le nœud "else" associé à condition1 . Ce nœud représente le chemin alternatif si la condition2 n'est pas vérifiée (c'est-à-dire que la condition1 est fausse).
Nœud 5 : Nœud de décision de condition2 . Ce nœud évalue la condition et décide du flux d'exécution en fonction du résultat (vrai ou faux).
Nœud 6 : le bloc d'instructions exécuté lorsque la condition2 est vraie. Ce nœud représente tout le code du bloc de code "if" de condition2 .
Nœud 7 : Le nœud "else" associé à condition2 - ce nœud représente la fin du programme et représente le code qui est exécuté si condition1 et condition2 sont fausses.

côté:

Edge 1 : connecte le nœud 1 et le nœud 2 , représentant le flux initial du point de départ au premier point de décision
Edge 2 (true) : condition1 connecte le nœud 2 et le nœud 3 , indiquant le processus à exécuter s'il est vrai.
Edge 3 (false) : la condition1 connecte le nœud 2 et le nœud 4 , indiquant que si elle est fausse, le flux alternatif sera adopté
Edge 4 : connecte le nœud 4 et le nœud 5 , indiquant le flux du bloc "else" vers le deuxième point de décision de la condition1
Edge 5 (true) : condition2 connecte le nœud 5 et le nœud 6 , indiquant le processus à exécuter si vrai
Edge 6 (false) : condition2 connecte le nœud 5 et le nœud 7 , indiquant le point final lorsqu'il est faux

Le graphe de code correspondant aura une structure de branchement avec trois points de décision et plusieurs chemins d'exécution. Le nombre de cycles de ce graphe est de 4 (nœuds - arêtes + 2 ). Cela indique que la logique peut être plus complexe et nécessiter plus de cas de test qu'un programme avec une structure plus simple.

En comprenant ces avantages, les testeurs de logiciels peuvent exploiter les diagrammes de code pour naviguer efficacement dans la logique du programme, concevoir des scénarios de test efficaces et contribuer à la fourniture de logiciels de haute qualité.

Expliquons en détail comment dériver le cercle numéro 4 .

La complexité cyclomatique nous indique combien de chemins indépendants existe dans un programme. Plus il y a de chemins, plus le test est complexe.
Dans ce code, nous avons deux décisions (vérifier condition1 et condition2 ). Chaque décision crée une bifurcation potentielle sur le chemin (vrai ou faux).
Cependant, puisque la condition1 du bloc else pointe directement vers la condition de décision2 , il n’y a pas de véritable branchement à cet endroit. C'est comme une voie à sens unique menant à un autre point de décision.
Par conséquent, nous ne comptons que les points de décision indépendants : point initial , condition1 (vrai ou faux) , condition2 (vrai ou faux).

Puisque nous avons 3 points de décision, mais que l'ajout de 1 à cause du point de départ est une manière courante de calculer la complexité cyclomatique, le nombre final est 3 + 1 = 4 .

souviens-toi:

Une complexité cyclomatique plus élevée ne signifie pas nécessairement que le code est mauvais, mais cela indique que davantage de scénarios de tests devront peut-être être envisagés.
Avec une complexité de 4 , cet extrait de code n'est pas trop complexe, mais à mesure que le nombre de décisions et d'imbrications de conditions augmentent, la complexité cyclomatique et l'effort de test augmentent considérablement.

3. Limites des diagrammes de code

Bien que les diagrammes de code présentent l’avantage d’améliorer la communication et la collaboration, ainsi que d’augmenter l’efficacité et la concentration, les testeurs doivent également prêter attention aux éléments suivants :

1 ne peut pas exécuter l'élément

Ignorer les commentaires et les déclarations : les diagrammes de code se concentrent principalement sur le flux de contrôle au sein d'un programme, représenté par des instructions exécutables. Les éléments non exécutables tels que les commentaires et les déclarations de données sont généralement ignorés car ils n'affectent pas directement l'exécution du code.
Potentiel de malentendu : même si l'omission de ces éléments peut simplifier le diagramme, cela peut provoquer certains malentendus. Les testeurs doivent être conscients de ces éléments ignorés et s'assurer qu'ils sont pris en compte lors des tests pour éviter de négliger les problèmes potentiels liés à l'initialisation des données, aux commentaires logiques ou à d'autres sections de code non exécutables.

2 Distinguer la faisabilité du chemin

Défis liés à l'identification de chemins significatifs : tous les chemins d'un graphe de code ne représentent pas des séquences d'exécution valides ou significatives. Certains chemins sont techniquement réalisables (topologiquement réalisables) en fonction de la structure du graphe, mais sont illogiques ou dénués de sens (sémantiquement irréalisables) dans le contexte de la logique du programme.
Effort de test accru : identifier et hiérarchiser les chemins de test viables peut être difficile et nécessiter des efforts supplémentaires de la part des testeurs. Ils doivent analyser la logique et le contexte du programme pour distinguer les chemins valides des chemins non valides, ce qui peut entraîner une conception et un temps d'exécution de scénario de test supplémentaires.

3 Atténuer ces limitations

Combiner avec d'autres techniques de test : les diagrammes de code fonctionnent mieux lorsqu'ils sont combinés avec d'autres techniques de test telles que la révision du code ou l'analyse du flux de données. Ces techniques peuvent aider à identifier les éléments non exécutables et leur impact potentiel, tout en aidant également à comprendre la logique d'un programme pour mieux évaluer la faisabilité d'un chemin.
Concentrez-vous sur les chemins critiques : les testeurs peuvent prioriser les tests sur les chemins critiques ou à haut risque dans le graphe de code. Cela implique de prendre en compte des facteurs tels que les conditions de boucle, les entrées attendues de l'utilisateur et les scénarios d'erreur potentiels pour déterminer le chemin qui aura le plus grand impact sur le test.

En comprenant et en contournant ces limitations, les testeurs peuvent utiliser efficacement les graphiques de code. Des tests complets et efficaces peuvent être effectués tout en reconnaissant leurs limites inhérentes et la nécessité de les combiner avec d'autres méthodes de test.

4. Écrivez à la fin

Le logiciel de messagerie d'entreprise développé indépendamment par l'équipe logicielle ZenTao intègre l'application open source draw.oi , qui combine organiquement chat et collaboration. Tous les diagrammes de code de cet article sont complétés à l'aide de cette fonction. En utilisant des diagrammes de code, les testeurs de logiciels peuvent acquérir une compréhension plus approfondie de la logique du programme. Ils peuvent concevoir des cas de test plus efficaces et contribuer à fournir des logiciels de haute qualité.

bruyant

Nous devons admettre qu'à mesure que le paysage logiciel continue d'évoluer, les diagrammes de code continueront d'être un outil important pour garantir la fiabilité et la robustesse des applications.

*Référence : Code Graphs : A Guide for Testers par Stelios Maniooudakis