IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++Builder Discussion :

Lancer des tests / simulation [Débat]


Sujet :

C++Builder

  1. #21
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 50
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par Neilos
    Je me rend de plus en plus compte que les tests c'est une grosse "science" dans le domaine de l'informatique...trop souvent négligée (et je suis le premier à le faire), surtout dans le domaine "amateur".
    Tu veux dire carrément ignorée dans le domaine amateur... ;-)

    De toutes façons, un soft sans bugs, ça n'existe pas : le but des tests est de garantir que les bugs les plus critiques (les "évènements redoutés") ont une probabilité d'apparition acceptable (genre <10e-13) sur la durée d'utilisation du système. Ni plus, ni moins.

    Prenons le cas d'une pompe médicale (genre pompe à morphine) : un évènement redouté peut être "non-délivrance d'une dose". C'est triste pour le patient, mais (heureusement ou hélas, suivant le point de vue) il peut toujours crier et se manifester, et donc avoir son médicament. Bref, c'est grave, mais non critique. Si ça arrive mettons une fois sur 10.000 demandes, c'est "acceptable", car ça ne met pas la vie du patient en jeu même si ça a d'autres effets néfastes. N'oublions pas que ce genre de pompe est utilisée par des patients conscients.

    Par contre, un autre évènement redouté est "délivrance d'une dose trop forte" : là, c'est critique, car le patient peut en mourir ! Si le risque est d'une fois sur un milliard, c'est tolérable s'il n'existe qu'une seule pompe : si l'on délivre au maximum une dose par heure, ça revient à un accident tous les 1000 siècles d'utilisation. Mais avec l'augmentation du nombre de pompes en service, ça devient inacceptable : si 1 million de pompes sont en service, il y a un risque d'accident tous les 1,2 mois !!

    Citation Envoyé par say
    C'est étonnant, c'est très pointu et pourtant j'ai jamais étendu de formation spécifique.
    Tu vois quelques bases en génie logiciel, puis le reste, c'est sur le tas. C'est la preuve aussi que ce n'est pas encore vraiment "implanté" dans les moeurs...

    Citation Envoyé par say
    Dès ce cas, faut-il aussi planifier le développement de tests dans la conduite du projet?
    Bien sûr ! En découpant "à la louche", tu as 1/3 du dev en specs, 1/3 en codage, 1/3 en tests. Suivant la criticité du projet, les tests peuvent même être beaucoup plus importants que les specs et le codage réunis !!

    Citation Envoyé par say
    De plus, qu'est ce qu'une analyse Boite Blanche?
    Ca consiste à tester en connaissant l'implémentation, et en vérifiant tous les flux d'exécution possibles d'une fonction/module donné(e).
    En gros, si ta fonction possède 3 cas d'exécution, ça fait 3 jeux de test à dérouler, chaque jeu déclenchant une branche d'exécution particulière. Ca permet également d'éliminer des cas de tests inutiles (ex : branche déclenchée sur une intervalle de valeurs).
    Ce n'est en général applicable que sur des fonctions plus ou moins élémentaires, et ça peut être complété par d'autres éléments de test supplémentaires.
    En analyse boîte noire, tu ne sais pas COMMENT est codée la fonction ou le module, et tu t'en moques (d'ailleurs, la personne écrivant les tests boite noire ne doit JAMAIS avoir vu le code). Tu testes suivant les spécifications prévues, y compris les cas dégradés connus.

  2. #22
    Membre éprouvé Avatar de Caine
    Inscrit en
    Mai 2004
    Messages
    1 028
    Détails du profil
    Informations personnelles :
    Âge : 52

    Informations forums :
    Inscription : Mai 2004
    Messages : 1 028
    Points : 1 122
    Points
    1 122
    Par défaut
    La phase de tests (ou validation) dans des projets professionnels doit suivre un processus établi et rigoureux.

    Il est important dès le cahier des charges et au long de la conception de lancer l'analyse, la faisabilité et le codage des outils/modules de test.

    Si un projet prend 6 mois de développement, il est très problématique de s'apercevoir à deux mois de sa fin qu'il faut 4 mois pour développer les modules/outils de tests, les délais sont alors définitivement morts.

    Pire, dans certains cas, il se peut que certains tests soient remis en question car infaisables.

    L'analyse en boîte blanche permet aussi de garantir la cohérence des cas aux limites.

    Imagines que ton application SGBD compte ses connexions, qu'elle doit en accepter au maximum jusqu'à 65535. Vu la complexité de ce test, il est évident qu'on se limitera à un sous ensemble de connexion, par exemple jusqu'à 249 connexions.

    Maintenant dans le code, il y a un problème de perte de chiffre significatif sur la variable de MaxConnected.

    En argument on la passe en "unsigned int", pour la stoquer dans un "unsigned char", les options de warnings étant désactivés par accident.

    Le test jusqu'à 249 donne un comportement correct. Un anayse en boîte blanche conclut de rajouter un test à 65536 connexions => il ne passera pas.

    Enfin, les programmes de tests doivent aussi être vérifiés, c'est pourquoi je préconise qu'ils soient le plus simple possible, pour que leur preuve soit simple. Attention, ce n'est pas toujours faisable, comme dans le cas de test multithread, multiprocess ...

    Enfin, j'ai de quoi écrire un livre sur le sujet (avis aux éditeurs ).

  3. #23
    Membre éprouvé

    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    1 163
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 1 163
    Points : 1 148
    Points
    1 148
    Par défaut
    Citation Envoyé par Caine
    Enfin, j'ai de quoi écrire un livre sur le sujet (avis aux éditeurs ).
    GOOO ! Si tu le fais je serais un des premiers à l'acheter !
    Je suis pour l'instant étudiant et passionné. J'ai appris l'informatique sur le tas et je commence seulement à prendre conscience de l'importance des tests et surtout de la tache monumentale qu'ils représentent...bref un sujet qui va mériter de la réflexion !

  4. #24
    say
    say est déconnecté
    Membre éprouvé
    Avatar de say
    Profil pro
    Inscrit en
    Août 2002
    Messages
    1 176
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Août 2002
    Messages : 1 176
    Points : 1 258
    Points
    1 258
    Par défaut
    re..
    sans aller jusqu' à un livre...un tuto ou une première approche pour developpez, ça le fairait grave.

  5. #25
    Membre éprouvé Avatar de Caine
    Inscrit en
    Mai 2004
    Messages
    1 028
    Détails du profil
    Informations personnelles :
    Âge : 52

    Informations forums :
    Inscription : Mai 2004
    Messages : 1 028
    Points : 1 122
    Points
    1 122
    Par défaut
    Il faudrait que je prenne le temps, vu votre motivation, ça peut se faire.

    Mais ne soyez pas préssés, vu ma charge de travail et mes horaires, ce ne sera pas pour demain non plus

    Il serait utile dans un premier temps de borner ce que vous souhaitez y trouver.

    Après, ça dépendra de mon emploi du temps.

  6. #26
    Membre éprouvé

    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    1 163
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 1 163
    Points : 1 148
    Points
    1 148
    Par défaut
    Oui c'est sûr que écrire ne serait-ce qu'un simple tuto ça prend du temps.
    Pour ma part ce qui m'intéresserait le plus :
    les différents types de tests, au cours du post on a parlé des traditionnels cas aux limites, mais aussi les tests où l'on peut tester toutes les valeurs, etc
    la prévision des tests dès le début du cahier des charges et la façon dont ils évoluent
    les cas à prévoir les plus classiques. Ce qui a été évoqué dans ce post : l'algorithme du singe, une panne réseau...

    Ce serait très intéressant, pour ma part l'idée d'un outil assistant la création de programme de test m'a effleuré. Pour l'instant je n'en ai pas le temps et peut être pas le niveau...à étudier.

  7. #27
    Membre éprouvé Avatar de Caine
    Inscrit en
    Mai 2004
    Messages
    1 028
    Détails du profil
    Informations personnelles :
    Âge : 52

    Informations forums :
    Inscription : Mai 2004
    Messages : 1 028
    Points : 1 122
    Points
    1 122
    Par défaut
    Les outils de générations de programme de test sont difficiles à rendre génériques.

    Mais il existe des moyens d'avoir des programmes simples surtout pour les tests unitaires.

    Voici une ébauche du sommaire:
    Les objectifs de la validation
    Homme ou machine
    Les problèmes liés à l'environement de validation.
    Tests unitaires
    Tests d'intégration
    Tests de charge
    Tests de déploiement.
    ça évoluera bien sûr.

  8. #28
    Membre éprouvé

    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    1 163
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 1 163
    Points : 1 148
    Points
    1 148
    Par défaut
    Ton sommaire constitue un excellent début !

    Pour ce qui est de l'écriture d'un outil de test j'ai une petite idée, mais ce n'est vraiment qu'une idée sur laquelle il faudrait que je réfléchisse !

  9. #29
    Membre éprouvé Avatar de Caine
    Inscrit en
    Mai 2004
    Messages
    1 028
    Détails du profil
    Informations personnelles :
    Âge : 52

    Informations forums :
    Inscription : Mai 2004
    Messages : 1 028
    Points : 1 122
    Points
    1 122
    Par défaut
    Moi aussi j'ai quelques idées sur le sujet, mais il faut comprendre que ce genre d'outil sera souvent limiter à tester des modules indépendants.

    Voici ce qui d'expérience me parait utile:
    > L'outil possède une interface graphique. Un edit au milieu permet de visualiser le code source du module à tester (coloration syntaxique)
    > Il possède un une vue arborescente qui remonte toute les fonctions privées comme publiques définies dans le module.
    >Il permet de définir pour chacune des fonctions un domaine d'entrée de chaque argument et un résultat correct attendu.
    >L'outil génère dans le langage cible le code correspondant aux tests définis branche par branche.
    Chaque test de fonction consiste à donné aux arguments l'ensemble des valeurs définis et à afficher chaque appels. Egalement afficher le résultat ("Correct" ou "Incorrect") du test.

    Par exemple, soit le fonction void Swap(int X, int Y);

    L'opérateur peut définir comme domaine de test :
    X:10,Y:20 => Correct: X:20, Y:10
    X:0,Y:0 => Correct X:0,Y:0
    X:65536,Y:50 =>Correct X:50, Y:65535

    L'outil génère ceci (en C)

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
     
    #include <stdlib.h>
     
    int main (void) {
     
    const char KO[]="Incorrect";
    const char OK[]="Correct";
    char *Verbose = NULL;
     
    int X=0,Y=0;
     
    X=10;Y=20;
    Swap(X, Y);
    if ((X==20)&&(Y==10))
       Verbose = OK;
    else
      Verbose = KO;
     
    printf("Call to Swap(int X, int Y); X:10,Y:20 \n=> %s with result X:20, Y:10\n", Verbose);
     
    X=0;Y=0;
    Swap(X, Y);
    if ((X==0)&&(Y==0))
       Verbose = OK;
    else
      Verbose = KO;
     
    printf("Call to Swap(int X, int Y); X:0,Y:0 \n=> %s with result X:0, Y:0\n", Verbose);
     
    X=65536;Y=50;
    Swap(X, Y);
    if ((X==50)&&(Y==65536))
       Verbose = OK;
    else
      Verbose = KO;
     
    printf("Call to Swap(int X, int Y); X:65536,Y:50\n=> %s with result X:50, Y:65535\n", Verbose);
    }
    Penche toi sur la problématique de générer le code, rien que pour cet exemple simple. Puis prend tes fichiers sources, regarde quel code il faudrait générer pour les tester.

    La difficulté de rendre totalement générique et intelligent ce genre d'outil va te venir à l'esprit.

    AU passage, voilà un cahier de charge miniature, comment tu testerais ces exigences ?

    Mais ça constitue un projet intéressant tout de même. Si j'avais plus de temps, il y a longtemps que je me serais amusé avec

  10. #30
    Membre éprouvé

    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    1 163
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 1 163
    Points : 1 148
    Points
    1 148
    Par défaut
    Oui je pensais à la même chose que toi (interface graph, domaine des paramètres, vue arborescente) et effectivement c'est très long et dur à mettre en place mais aussi très intéressant.
    J'ai quelques projets en cours et une fois ceux-ci bien avancé je me pencherais sur un tel programme

Discussions similaires

  1. Maven - lancer des tests junit spécifiques
    Par don'de dans le forum Maven
    Réponses: 1
    Dernier message: 24/11/2009, 23h26
  2. FYI: Lancer des tests Nunit sous Mono 2.2
    Par nattygeneral dans le forum Mono
    Réponses: 0
    Dernier message: 26/01/2009, 14h18
  3. [JUnit] Lancer des tests JUnit depuis une classe de test
    Par naglafar dans le forum Tests et Performance
    Réponses: 1
    Dernier message: 29/07/2008, 15h51
  4. Lancer des tests nocturnes avec Maven2
    Par Dev_info dans le forum Maven
    Réponses: 6
    Dernier message: 19/03/2008, 12h11
  5. Réponses: 1
    Dernier message: 11/10/2006, 11h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo