il y a besoin de savoir si un bug est corrigé ou pas, et sur quelle version (donc d'associer le résultat positif/négatif d'un test à une version).
Ca se fait probablement souvent de facon automatique, sans que les devs n'aient rien a faire. Par exemple, sur GitHub, comme tu peux associer une PR (donc un commit) a une issue, tu peux generer automatiquement un changelog pour une version.
Aurais-tu déjà écrit quelque chose ? C'est disponible ?
Oui. Pas encore.
Dedeun a écrit:
Je note que pour moi, Test "Boites noir/blanche" (ou grise !), Tests Fonctionnel et Critères d'arrêts avec une couverture structurelle, c'est 3 dimensions différentes. Je suis curieux de lire ce que tu penses.
La création de tests fonctionnels se base sur la définition de la fonctionnalité donc par définition en faisant abstraction du code (du coup boîte noire). La création de tests structurels se focalise sur la structure de code pour déterminer les cas de tests donc par définition il faut que ce soit boîte blanche. Après, il est aussi possible de faire la création des tests en se basant sur l'aspect fonctionnel et malgré tout chercher une couverture structurelle. C'est pas complètement incompatible même s'il est clairement possible d'avoir des chemins infaisable pour un sous cas fonctionnel.
Pour le critère d'arrêt des tests c'est très dépendant des domaines. Le risque principal de s'arrêter à la couverture atteinte est que le testeur se focalise sur le fait de couvrir et pas vraiment de trouver les problèmes.
Dedeun a écrit:
Pour moi, les tests hors cible (Test sur un PC, avec compilation native PC, ou, croisée et utilisation sur le PC d'un émulateur de la cible), permet de valider les algorithmes complexes. Sur cible embarquée, on n'a pas toujours les mêmes possibilités de test. J'ai pas de ref sur internet, mais c'est mon expériance.
Ok, donc je dois avoir un point là dessus, mais ça vaut le coup que je vérifie.
Dedeun a écrit:
Mais il faut réaliser la couverture structurelle, en testant les "Low Level Requirements", et là ce n'est pas de l'outillage mais de la procédure de test.
La mesure de couverture outillée est quand même un gain de confiance significatif par rapport à une review des tests effectués en se demandant si la couverture structurelle est bien atteinte.
Dedeun a écrit:
(1) Quel est le publique visé ? (2) Et comment peut-on formaliser des tests autrement ?
(1) École d'ingénieurs avec des étudiants qui vont aller vers plein de domaines différents.
(2) On n'est pas obligé de formaliser les tests justement, c'est plus que rarement le cas en dehors des domaines critiques. En particulier, il n'y a pas souvent de nécessité de formaliser la procédure de test, ni besoin de collecter autant d'informations pour chaque test : le minimum vital c'est entrée concrète du test + oracle concret du test. Généralement, les commits sur le logiciels suffiront à faire le lien avec la merge-request d'origine et l'issue reliée si besoin.
Dans les domaines critiques, l'activité de tests c'est entre 80 et 95% du temps de développement. En dehors du critique, si tu atteints les 50% c'est déjà le bout du monde.
Dedeun a écrit:
(3) En effet, ce n'est pas obligatoire, mais peut-être fournir un avantage/inconvénient : Meilleur test/couverture/compréhension du besoin versus coût/délai/lourdeur du process
J'ai mis un point dessus, c'est plutôt des choses que je précise à l'oral.
Dedeun a écrit:
(4) Je suis un peu surpris: Même dans du soft non critique, il y a besoin de savoir si un bug est corrigé ou pas, et sur quelle version (donc d'associer le résultat positif/négatif d'un test à une version).
Le suivi de projet c'est AMHA en dehors d'un cours sur la vérification de logiciels, sinon le périmètre devient rapidement trop large, j'ai pas 200h pour ce cours. Dans les processus communs de développement aujourd'hui, tant qu'un problème n'est pas traité, le test n'est pas présent dans la branche principale du logiciel. Le jour où l'on s'attaque au bug en question, on crée la branche de développement, le test, et la réparation quasiment dans la foulée (même si on peut tout à fait préparer les branches avec des tests échoués avant). Mais tout ça, c'est de la gestion de projet informatique.
Dans le contexte de la vérification de logiciels, je dois dire que je n'aime vraiment pas l'usage qui est fait du mot "formel" dans les normes. Pour moi (et pour Wikipedia aussi visiblement), la vérification formelle, c'est la vérification basée sur des méthodes formelles (et donc mathématiques), et pas la mise en documentation. La vérification formelle a un sens très fort au sujet des propriétés qu'elle considère, si l'outil répond "OK", on a une preuve mathématique de correction du logiciel pour toute entrée, ce qui est plus fort qu'une couverture par des tests.
Elles me montrent que je suis réellement déformé par le boulot, la lecture de ce forum me rappelle la "vraie vie" !
gbdivers a écrit :
Ca se fait probablement souvent de facon automatique, sans que les devs n'aient rien a faire. Par exemple, sur GitHub, comme tu peux associer une PR (donc un commit) a une issue, tu peux generer automatiquement un changelog pour une version.
Oui, c'est vrai, il n'y a pas besoin forcément de prouver qu'un bug est corrigé, normalement, on fait confiance ! Ce bug se reproduit, c'est qu'il n'est pas corrigé !
Ksass`Peuk a écrit :
La création de tests fonctionnels se base sur la définition de la fonctionnalité donc par définition en faisant abstraction du code (du coup boîte noire). La création de tests structurels se focalise sur la structure de code pour déterminer les cas de tests donc par définition il faut que ce soit boîte blanche. Après, il est aussi possible de faire la création des tests en se basant sur l'aspect fonctionnel et malgré tout chercher une couverture structurelle. C'est pas complètement incompatible même s'il est clairement possible d'avoir des chemins infaisable pour un sous cas fonctionnel.
Suivant mon expérience (mais je ne suis pas forcément une réf !), tous tests répondent à ce que tu appelles "tests fonctionnels" : en effet, le test vérifie un (ou des) requirement(s) de la spécification / du design / du SOW / ... (une fonction). Je prends un exemple, si une application doit s'installer sur MS Windows, Mac et Linux, il devrait y avoir quelque part un Req qui le demande (soit une contrainte dans le cahier des charges, soit le chef de projet ou le commercial qui se dit qu'il y aurait du business à faire, et qui arrive un matin en ajoutant une contrainte aux équipes de dev, soit ...). Donc ce que l'on pourrait appeler les tests d'installations, c'est un test fonctionnel qui correspond à ce requirement de compatibilité des OS (Req écrit ou pas).
Pour la définition des tests Boites Noires, Rien à dire, je suis du même avis que toi (et que ce que l'on trouve sur internet). Pour les tests boites blanches, mon expérience est un peu déviante de ce que tu affiches (et sur ce que je viens de lire sur wiki). Pour moi, ta définition des tests Boites Blanches, c'est ce que j'appelle les tests Boites Grises : On regarde comment est écrit le SW pour faire de nouveaux cas de tests, afin d'augmenter la couverture des tests. Pour moi, un test Boites Blanche, c'est quand tu utilises des variables internes ou des points d'arrêt à l'intérieur de la procédure que tu testes, pour la sanction dans le résultat du test. Par exemple, pour les "machines à état fini", quand tu traces toutes les modifications de la variable qui représente cet état, au cours d'un test. Le problème, c'est que si le code change, les tests ne sont plus valables. J'ai fait cette erreur dans ma jeunesse !
Ksass`Peuk a écrit :
Pour le critère d'arrêt des tests c'est très dépendant des domaines. Le risque principal de s'arrêter à la couverture atteinte est que le testeur se focalise sur le fait de couvrir et pas vraiment de trouver les problèmes.
Oui, bien sûr, je suis d'accord ! quand on est stressé par le temps, on s'en sort comme on peut. Cependant, et j'en reviens à ce que je connais : On fait toujours les tests pour valider un Req (formalisé ou non, principale ou déduit, fonctionnel ou de robustesse ou de performance ou de contrainte ou ...). Mais la couverture, ce n'est que la mesure d'une suite de tests / Le résultat du test, c'est la compliance aux requirements (On peut avoir 100% de couverture, avec des tests qui ont des résultats "KO"). C'est en ce sens que pour moi, parler de "Tests Structurels", c'est un non-sens : ça n'a pas de sens de dire qu'on fait 2 types de tests, des "tests fonctionnels" et des "tests structurels". La couverture structurelle des tests est obtenue par une suite de tests fonctionnels ! Enfin, c'est ma vision.
Ksass`Peuk a écrit :
Dedeun a écrit:
Mais il faut réaliser la couverture structurelle, en testant les "Low Level Requirements", et là ce n'est pas de l'outillage mais de la procédure de test.
La mesure de couverture outillée est quand même un gain de confiance significatif par rapport à une review des tests effectués en se demandant si la couverture structurelle est bien atteinte.
En effet, la vérification de la couverture par un outil est la solution. Cependant, pour l'écriture des procédures de tests (même en ce que tu appelles, Boites Blanches"), le résultat attendu est défini par un réquirement (Low Level Req, Robusness Req, ...), et pas par l'outil de mesure de couverture (*). Donc, en effet, c'est un outil qui dit que la couverture est atteinte ou pas. Mais, si la couverture n'est pas atteinte, c'est à partir des Req que l'on ajoute des tests. Et donc ce n'est pas (seulement) la traçabilité qui est la preuve de couverture.
(*) Je pars du principe qu'il faut savoir qu'elle est le résultat attendu du test, avant de le lancer, pour savoir si le résultat est OK ou pas.
Ksass`Peuk a écrit :
Le suivi de projet c'est AMHA en dehors d'un cours sur la vérification de logiciels, sinon le périmètre devient rapidement trop large, j'ai pas 200h pour ce cours.
C'est quoi l'AMHA ?
Ksass`Peuk a écrit :
Dans le contexte de la vérification de logiciels, je dois dire que je n'aime vraiment pas l'usage qui est fait du mot "formel" dans les normes. Pour moi (et pour Wikipedia aussi visiblement), la vérification formelle, c'est la vérification basée sur des méthodes formelles (et donc mathématiques), et pas la mise en documentation. La vérification formelle a un sens très fort au sujet des propriétés qu'elle considère, si l'outil répond "OK", on a une preuve mathématique de correction du logiciel pour toute entrée, ce qui est plus fort qu'une couverture par des tests.
Je comprends, (J'irai même à penser que c'est légitime…) Cependant, je fais la différence entre "Vérification Formelle" / "Preuve Formelle" et "Formalisation d'une procédure de tests" (C'est-à-dire "Écriture de la procédure de tests, en respectant un modèle").
Néanmoins, pour moi, les méthodes formelles, ce n'est pas forcément la panacée : Le client te demande des fonctions qui sont parfois ambiguës, contradictoire... Pour traduire ça en spécifications formelles, il y a du travail ! Et il n'y a pas de garantie que le résultat soit ce qui est attendu ! Avec les "preuves formelles", le logiciel sera conforme à la spécification, mais forcément du besoin.
J'espère faire avancer le schmilblick. Si je raconte trop de conneries, dite le moi.
Pour le reste, c'est le problème de definitions dont je parlais, c'est pas forcément clair pour tous. La page wiki que j'ai donné permet de "formaliser" les definitions, par exemple pour "test fonctionnel" https://en.wikipedia.org/wiki/Software_testing#Functional_vs_non-functional_testing. Idem pour les definitions de white, black et grey boxes.
Pour ca que j'aime bien donner des liens vers des organismes officiels comme le NIST. On peut ne pas être d'accord avec des definitions retenues, mais ca donne quand même un point de depart pour discuter des definitions.
Pour moi, un test Boites Blanche, c'est quand tu utilises des variables internes ou des points d'arrêt à l'intérieur de la procédure que tu testes, pour la sanction dans le résultat du test. Par exemple, pour les "machines à état fini", quand tu traces toutes les modifications de la variable qui représente cet état, au cours d'un test. Le problème, c'est que si le code change, les tests ne sont plus valables. J'ai fait cette erreur dans ma jeunesse !
Pour moi ces éléments sont surtout de l'outillage supplémentaire et permet surtout de définir ce qu'on veut vérifier dans le test en question. Par exemple le bon usage d'une API. Et ça se relie au choix du type de doublure de test qu'on prend (Dummy, Stub, Spy, Mock, Fake, ...).
Dedeun a écrit:
Cependant, et j'en reviens à ce que je connais : On fait toujours les tests pour valider un Req (formalisé ou non, principale ou déduit, fonctionnel ou de robustesse ou de performance ou de contrainte ou ...). Mais la couverture, ce n'est que la mesure d'une suite de tests / Le résultat du test, c'est la compliance aux requirements (On peut avoir 100% de couverture, avec des tests qui ont des résultats "KO"). C'est en ce sens que pour moi, parler de "Tests Structurels", c'est un non-sens : ça n'a pas de sens de dire qu'on fait 2 types de tests, des "tests fonctionnels" et des "tests structurels". La couverture structurelle des tests est obtenue par une suite de tests fonctionnels ! Enfin, c'est ma vision.
Le problème de ce choix drastique est qu'il est moins adapté à la détection de défauts fins de programmation. Certes l'oracle est bien déterminé par la spec fonctionnelle, mais ça n'empêche pas de créer des tests avec l'objectif d'exercer des comportements purement programmatiques sans prendre en compte le découpage en fonctionnalités. Par exemple en essayant de couvrir des critères dataflow (tous les chemins définition-utilisation par exemple). C'est moins représentatif des fonctionnalités mais plus représentatif du comportement du code.
Dedeun a écrit:
Néanmoins, pour moi, les méthodes formelles, ce n'est pas forcément la panacée : (1) Le client te demande des fonctions qui sont parfois ambiguës, contradictoire... Pour traduire ça en spécifications formelles, il y a du travail ! Et il n'y a pas de garantie que le résultat soit ce qui est attendu ! (2) Avec les "preuves formelles", le logiciel sera conforme à la spécification, mais forcément du besoin.
Il n'y a aucune méthode de vérification parfaite, les méthodes formelles n'y échappent pas. (1) Par contre le fait que le client demande des fonctions qui sont ambiguës et contradictoire est précisément un argument en faveur des méthodes formelles. Et ça semble être un sentiment partagé avec les gens qui utilisent les outils sur lesquels je bosse. La rédaction des specs formelles leur permet justement de détecter ce genre de problèmes et de demander immédiatement une clarification.
(2) Sur ce point les tests ne sont pas mieux lotis, si les tests ne correspondent pas à l'expression du besoin la situation sera la même.
gbdivers a écrit:
Pour ca que j'aime bien donner des liens vers des organismes officiels comme le NIST. On peut ne pas être d'accord avec des definitions retenues, mais ca donne quand même un point de depart pour discuter des definitions.
Ma biblio actuelle :
Glenford J. Myers. The Art of Software Testing
Boris Beizer. Software Testing Techniques
S. Xanthakis, M. Maurice, A. de Amescua, O. Houri, L. Griffet. Test & Contrôle des Logiciels
S. Xanthakis, P. Régnier, C. Karapoulios. Le test des logiciels
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.