Tout d'abord, je voudrais dire que les mathématiques aident à mettre nos pensées en ordre et développent efficacement la pensée logique, et ce sont quelques-unes des qualités les plus nécessaires des participants au développement de logiciels. Parlant de test, il concerne principalement le comportement du système, qui est orthogonal à la représentation structurelle commune aux développeurs de logiciels. La différence entre les représentations structurelles et comportementales est que la structure se concentre sur ce qu'est le logiciel, et la vue comportementale prend en compte ce que fait le logiciel.
L'une des difficultés des testeurs est que la documentation technique de base ou le manuel de développement logiciel est généralement rédigé par et pour les développeurs, et l'accent est mis sur les informations structurelles plutôt que comportementales. Bien sûr, les parties structurelles et comportementales sont très importantes pour les tests, car des erreurs de programmation peuvent être trouvées dans chacune de ces parties. C'est pourquoi nous parlerons de méthodes mathématiques discrètes pour montrer la relation entre la structure du programme et son comportement.
Dans leur travail quotidien, les ingénieurs d'assurance qualité logicielle (AQ) travaillent avec les opérations de formule, le comportement des fonctions et les structures de données. Ils surveillent et vérifient toujours l'état en constante évolution des systèmes, ils ont donc besoin d'avoir une pensée algorithmique et mathématique pour comprendre la logique du logiciel.
Si un développeur utilise une approche mathématique dans son travail, par conséquent, toutes les opérations logiques seront connectées les unes aux autres, les actions suivront une chaîne logique et chaque fonction sera considérée structurellement.
Les mathématiques discrètes nous aident à trouver la meilleure solution dans diverses situations. Par exemple, vous pouvez trouver l'ensemble de cas de test le plus approprié (cas de test), sans couvrir toutes les options possibles. De plus, les mathématiques discrètes nous aident à visualiser le logiciel exact qui a été implémenté et couvert par des tests.
Malheureusement, nous ne vivons pas dans un monde idéal, et les résultats réels attendus de l'utilisation du logiciel et les résultats réels peuvent varier. Ainsi, l'objectif principal du Département Assurance Qualité (QA) est de couvrir efficacement autant de cas de test que possible.
Pour vous montrer ce concept plus en détail, nous avons créé le diagramme de Venn suivant avec un exemple que nous avons décrit plus tôt:
Le diagramme de Venn ci-dessus décrit de nombreuses situations, aidant ainsi à illustrer et à définir des ensembles de situations. Par exemple, cela peut nous aider à voir la différence entre les ensembles d'objets. Les mathématiques discrètes aident à analyser et à optimiser les ensembles d'actions qui peuvent affecter le logiciel en cours de développement.
Théorie des ensembles
En utilisant les principes de la théorie des ensembles de base, nous pouvons créer un pseudo-code pour illustrer tous les cas possibles pour l'application Next Day (un programme qui calcule quel jour sera le prochain en utilisant la date entrée):
M1={month:month has 30 days} M2={month:month has 31 days except December} M3={month:month is February} M4={month:month is December} D1={day:1<=day<=28} D2={day:1<=day<=29} D3={day:1<=day<=30} D4={day:1<=day<=31} Y1={year:year is a leap year} Y2={year:year is not a leap year}
Ce pseudocode a déjà été préparé pour le développement et le test de l'application, de sorte que les testeurs peuvent également appliquer tous les cas de test possibles sur la base de ces données. L'utilisation de données dans ce format permet d'augmenter la vitesse de développement et de réduire les risques d'erreur.
Théorie des graphes
La mathématique la plus discrète est la soi-disant "théorie des graphes", qui étudie les graphes. Les graphiques sont utilisés pour représenter la relation entre certains objets ou données, et un réseau informatique est un exemple approprié de graphique.
Les graphiques sont également fondamentaux pour le processus de développement logiciel. Par exemple, à l'aide d'un graphique, nous pouvons décomposer des fonctions complexes en plusieurs parties plus petites, ce qui nous aide à mieux comprendre la logique métier.
Les graphiques peuvent être directionnels et non directionnels, ce qui signifie que nous pouvons passer d'un nœud à un nœud dans une direction ou dans les deux directions (dans le cas d'un graphique dirigé), ou nous ne pouvons pas passer d'un nœud à un autre (si le graphique est dirigé strictement dans un direction)
Revenons donc aux tests de logiciels et imaginons que nous avons un flux de processus (par exemple, déplacer une tâche dans une sorte de système de suivi des tâches); nous avons une condition pour un problème, et nous pouvons le déplacer vers une autre étape (graphique orienté), ou nous pouvons atteindre un point où nous ne pouvons rien faire avec l'entité (graphique non orienté). Avec cette approche de la visualisation, nous pouvons facilement assembler un ensemble de toutes les actions possibles disponibles pour cette entité:
Continuons et regardons la matrice d'adjacence, qui peut être construite sur la base d'un graphe non orienté. Dans l'exemple ci-dessous, les éléments de la matrice d'adjacence indiquent si les paires de sommets sont adjacentes ou non:
Imaginez maintenant que les nœuds sont les conditions de certaines entités, et si nous construisons la matrice d'adjacence pour ce graphe (ensemble d'entités), nous verrons un ensemble fini d'actions que nous pouvons entreprendre. Par exemple, la modification du statut du nœud «0» au nœud «1» est disponible car ils sont liés les uns aux autres. Mais l'entité «0» ne peut pas être changée en étape «2» ou «3», comme nous pouvons le voir dans notre matrice - «zéro» est écrit dans les cellules. En utilisant cette matrice, nous pouvons éliminer les ensembles inutiles d'étapes d'entité et réduire l'ensemble des cas de test.
Une autre matrice que nous pouvons utiliser pour collecter des cas de test est la matrice d'incidence, qui montre la relation entre deux classes d'objets. Dans la figure suivante, nous voyons un graphique non orienté et sa matrice d'incidence: «1», «2», «3» et «4» sont des nœuds (entités), «e1», «e2», «e3» «e4» sont les bords du graphique , et la matrice illustre les entités et les actions que nous pouvons faire avec elles. Avec le nœud "1", nous pouvons effectuer les actions "e1", "e2" et "e3", mais l'action "e4" n'est pas disponible pour le nœud "1.". Cette méthode est très utile pour créer un ensemble de cas de test.
Imaginez que le testeur a reçu une liste d'entités et d'actions pouvant être effectuées avec ces entités. Avec cette matrice, il peut réduire l'ensemble des cas de test. La réduction du nombre de tests est une partie très importante du processus de test logiciel. Les tests de logiciels dépendent fortement de la réduction du nombre de cas de test, et avec cette approche, la couverture des tests et l'évitement de la redondance sont maximisés.
L'objectif des testeurs de logiciels est de couvrir le produit à l'aide de cas de test efficaces qui vous permettent de tester toutes les combinaisons possibles d'actions. Les testeurs peuvent réussir avec un effort minimal en utilisant des approches mathématiques discrètes (algorithmes) pour trouver l'ensemble optimal de cas de test et maximiser l'efficacité du processus de test logiciel.
Les mathématiques discrètes nous aident également à comprendre comment les logiciels sont réellement créés, car tous les logiciels utilisent des algorithmes et des méthodes de mathématiques discrètes et de logique mathématique. Par conséquent, si nous comprenons comment cela fonctionne, nous pouvons trouver des erreurs ou des problèmes dans le programme qui ne peuvent pas être détectés par l'utilisateur.
Filets de Petri
Voyons un exemple du fonctionnement de l'application sur la technologie des microservices à l'aide de réseaux de Petri (graphique dynamique):
Ici, nous voyons que le système a un état initial et devrait recevoir un signal envoyé par un autre service (un marqueur apparaît). Selon le résultat, l'action suivante doit être effectuée. Ainsi, le réseau de Petri illustre la dynamique de l'ensemble du système. En cas de problème, nous pouvons localiser le défaut plus rapidement.
Réseaux de neurones
Les réseaux de neurones artificiels sont également basés sur des principes de graphe. Ils imitent le traitement de l'information par les neurones du cerveau humain. Chaque partie du système neuronal est basée sur un graphe qui contient des nœuds "d'entrée", une couche "cachée" et des nœuds "de sortie".
Certaines données vont à la couche d'entrée, et les algorithmes de couche cachée traitent ces données et envoient le résultat à l'étage de sortie. Ainsi, un réseau de neurones peut effectuer des actions basées sur ces données. Les réseaux de neurones se composent également de nombreux graphiques similaires avec une logique différente, afin qu'ils puissent prendre des décisions en fonction des paramètres d'entrée.
Millennium Testing
Notre dernier exemple d'utilisation de mathématiques discrètes dans les tests consiste à créer un processus de test logiciel. Actuellement, il existe de nombreuses méthodologies et approches appelées «tests du millénaire», qui ont été développées bien avant leur utilisation réelle, à partir des années 2000, lorsque le développement de logiciels a commencé à se développer rapidement.
Le BDD (Behaviour Driven Development) fait partie du soi-disant Millenium Testing, cette méthodologie est une extension du TDD (Test Driven Development). BDD permet aux testeurs d'établir une relation plus étroite entre les critères d'acceptation d'une fonction donnée et les tests utilisés pour tester cette fonctionnalité. BDD peut transformer des instructions structurées dans un langage naturel en tests exécutables, introduisant ainsi plus de clarté et de compréhension du côté commercial et du développement, car ils commencent à parler un langage commun. La structure de base du workflow BDD est également basée sur un graphe dynamique (Petri Net).
Comme le montre cette structure, chaque processus est accompagné d'un processus différent, et il ne peut pas passer à l'étape suivante tant que l'étape précédente n'est pas terminée. Encore une fois, les principes des mathématiques discrètes nous aident à mieux comprendre le processus.
En conclusion, je voudrais à nouveau énumérer les avantages de l'utilisation de mathématiques discrètes dans le processus de développement logiciel:
- Assistance à la compréhension de la logique métier des fonctionnalités requises
- Simplifiez la possibilité de diviser des tâches complexes en tâches plus simples
- Permettre aux professionnels d'effectuer des tests efficaces avec moins d'efforts
- Aide à comprendre et à visualiser la structure de tout ce que nous voulons
Les exemples ci-dessus montrent comment les mathématiques discrètes peuvent être utilisées pour augmenter efficacement les performances des tests. Chaque aspect des mathématiques discrètes peut aider les développeurs à comprendre le flux de travail logiciel général et ses principes tout au long du cycle de vie du développement logiciel.