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

ALM Discussion :

comment procedez vous pour tester et valider votre programme?


Sujet :

ALM

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    Avril 2008
    Messages
    30
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2008
    Messages : 30
    Points : 19
    Points
    19
    Par défaut comment procedez vous pour tester et valider votre programme?
    Bonjour à tous,

    tout est dans le titre, j'aimerai savoir si vous utilisez une méthode particuliere pour valider un logiciel.

    boite noire pour les fonctions (test de toutes les valeurs possible et analyse des résultats)?

    boite blanche pour les procedures (ex : void toto(void)) ?

    ecrivez vous un code de test par fonction?

    merci

  2. #2
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2007
    Messages
    10 191
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 191
    Points : 28 070
    Points
    28 070
    Par défaut
    Certaines entreprises ont une méthode infaillible pour tester les programmes : ils laissent faire les clients.

    Pour ma part, en l'absence de procédures particulières ou de moyen d'en mettre en place, c'est souvent des tests fonctionnels + tests aux limites + tests des cas particuliers identifiés + quand c'est possible déverminage en situation réelle par un non-développeur et si possible quelqu'un qui n'a pas participer au dossier.

    Ce système a de très grosses limites mais je n'ai pas trouvé mieux du fait que les commerciaux n'arrivaient pas à intégrer que la phase de test devait se vendre dans la partie développement. C'était un combat au quotidien que je n'ai jamais pu gagner. Du coup c'est effectivement souvent le client qui fait les tests à ses dépends.
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  3. #3
    Membre à l'essai
    Profil pro
    Inscrit en
    Avril 2008
    Messages
    30
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2008
    Messages : 30
    Points : 19
    Points
    19
    Par défaut
    merci pour ta reponse.

    la procedure de ton entreprise est je pense utilisé par la majorité.

    debugage chez le client=> non merci

    curieux, pour un sujet si important il n'y a pas foule...

  4. #4
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2007
    Messages
    10 191
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 191
    Points : 28 070
    Points
    28 070
    Par défaut
    Citation Envoyé par morpheus87 Voir le message
    merci pour ta reponse.

    la procedure de ton entreprise est je pense utilisé par la majorité.

    debugage chez le client=> non merci

    curieux, pour un sujet si important il n'y a pas foule...
    Debuggage chez le client, encore. Il y a toujours une phase de mise au point plus ou moins longue chez le client.

    Le problème, à mon avis, c'est quand c'est Debuggage par le client
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  5. #5
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Septembre 2010
    Messages
    22
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : Belgique

    Informations forums :
    Inscription : Septembre 2010
    Messages : 22
    Points : 36
    Points
    36
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    Le problème, à mon avis, c'est quand c'est Debuggage par le client
    Je confirme, c'est une horreur.
    Je suis MOA et je ne suis pas développeur (je touche à ça lors de mes temps libres, parce que j'estime que c'est essentiel de comprendre un minimum le métier du développeur dans mon domaine). En tant que MOA, on vérifie que le programme fonctionne correctement suivant une batterie de tests (en gros, on tente de couvrir l'ensemble des situations possibles connaissant les besoins et activités du client). Dans le secteur bancaire, c'est essentiel, je n'ose pas imaginer la catastrophe si on met un truc plein de bugs en production vu les montants en jeu.

    Et là, on est assez souvent mal : on a l'impression de faire le boulot des développeurs. Et parfois, on a même l'impression de mieux comprendre d'où vient le problème (étant donné qu'on isole le bug et qu'on teste dans tous les sens pour bien décrire le problème) et parfois on imagine la raison pour laquelle ça foire et on se demande comment c'est possible vu que ça implique, par exemple, d'utiliser deux algo différents pour calculer le même type chose mais dans deux endroits différents (expérience vécue, et après avoir réfléchi sur le problème, les deux algos auraient dû être les mêmes).

    Ceci dit, histoire de ne pas paraître pédant, prétentieux, ... (ce que je ne veux pas), il est clair que le progiciel (et donc son développement) est un monstre dans son domaine (gestion des crédits structurés), ensuite ce n'est pas forcément évident de programmer correctement des concepts complexes (parfois, les spec sont mal foutus, et ça, ça vient de chez nous) et enfin, c'est toujours facile de critiquer quand on n'a pas réellement les mains dedans...

  6. #6
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    le problème des tests "boite noire" est qu'il faut avoir toutes les valeurs possibles...

    Mais que les valeurs possibles peuvent être dépassées par la réalité...

    Exemple : on prévoit qu'un champ contiendra 8 caractères..

    Donc on teste les chaînes ASCII de 8 caractères...

    Mais si jamais , au lieu d'un caractère "normal", on entre par exemple une touche de fonction, une flèche, ou je ne sais pas quoi, cela sera peut-être saisi, mais f.utra peut-être le boxon derrière....



    Un excellent conseil que j'ai eu d'un ingénieur-agrément en biomédical (celui qui décidait si un logiciel était correct au niveau de l'Assitance Publique) : avant de vérifier la fonctionalité, faire un test d'environ le double du temps en faisant n'importe quoi, sans regarder l'écran... Cliquer au hasard, taper sur le clavier au hasard, etc etc..

    Si le logiciel marche toujours et n'a pas provoqué de m.rdes un peu partout ailleurs, on a déà passé plus de 70% : c'est robuste et est contenu...


    Ensuite, pour la fonctionalité, il est souvent difficile de fonctionner "boite blanche" (sauf à bas niveau, ou au contraire tout en haut).



    Moi personnelement j'effectue toujours une phase de test "crash" (voir plus haut), et ensuite je prend un "client" expert, et je lui demande d'explorer tous les cas les plus saugrenus... Pas besoin de listes exhaustives... Les cas limites suffisent...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  7. #7
    Candidat au Club
    Inscrit en
    Février 2011
    Messages
    2
    Détails du profil
    Informations forums :
    Inscription : Février 2011
    Messages : 2
    Points : 3
    Points
    3
    Par défaut test intégration
    bjr, je ss etudiant en informatique M2 et j'ai comme PFE les tests d'intégration sur les logiciels oo je doit le faire en java mai je ss bloqué j'ai pa trouvé assez de documentation je sai pa quel stratégie quel sont les outils a utiliser..si vous pouver m'aidez svp au moins par la documentation car j'ai pa trouvé une bon documentation sur sa...merci d'avance

  8. #8
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 241
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 241
    Points : 36 698
    Points
    36 698
    Par défaut
    Salut,

    Le type de tests dépend de la qualité qu'on souhaite/doit atteindre.
    Qualité pouvant se ramener au nombre et à la gravité des défauts que vous ne voudrez pas voir en production. Dit autrement, on teste pour limiter les risques de dysfonctionnement résultant des éventuels défauts.

    De ce fait, le plan de test d'un serveur Web construit pour une petite PME avec un framework où le spécifique se cantonne à la présentation n'aura pas la même teneur que celui du logiciel de contrôle d'une navette spatiale ou d'un Airbus...
    Et que si faire faire les tests par ses clients peut paraître discutable "dans l'absolu" il pourra être "justifié" dans certains cas/contextes.

    -W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

  9. #9
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut


    la voix de la sagesse
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  10. #10
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2007
    Messages
    10 191
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 191
    Points : 28 070
    Points
    28 070
    Par défaut
    Citation Envoyé par wiztricks Voir le message
    Et que si faire faire les tests par ses clients peut paraître discutable "dans l'absolu" il pourra être "justifié" dans certains cas/contextes.
    Une partie des tests peut effectivement être faite par le client. Cela se fait en accord avec celui-ci, accord généralement conclu dès la signature de la commande et qui s'appelle généralement Phase de Validation.

    C'est justifié par l'expérience et les spécificités métier du client qui a des habitudes de travail ou des procédures à suivre au quotidien que le développeur n'est pas forcément censé connaitre ou maitriser.

    Par contre, il est parfaitement discutable et inimaginable (du moins, je ne pouvais l'imaginer avant de l'avoir vécu) de laisser faire Les Tests au sens général par le client et qui-plus-est à l'insu de son plein gré.

    Par exemple, il est parfaitement impensable (là encore c'est du vécu) de faire une modification directement chez le client, un vendredi soir à 19h30, sans que personne soit au courant, sans tester, et que cette modification plante dès le lundi matin, toute la chaine de production de l'usine. La personne ayant fait la modif, n'avait, bien sur, rien noté, et était absente dès le lundi matin pour déplacement à l'étranger pour 2 semaines alors qu'une simple compilation du code lui aurait directement mis en évidence qu'elle avait fait n'importe quoi.
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  11. #11
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 241
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 241
    Points : 36 698
    Points
    36 698
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    Par exemple, il est parfaitement impensable (là encore c'est du vécu) de faire une modification directement chez le client, un vendredi soir à 19h30, sans que personne soit au courant, sans tester, et que cette modification plante dès le lundi matin, toute la chaine de production de l'usine. La personne ayant fait la modif, n'avait, bien sur, rien noté, et était absente dès le lundi matin pour déplacement à l'étranger pour 2 semaines alors qu'une simple compilation du code lui aurait directement mis en évidence qu'elle avait fait n'importe quoi.
    A mon sens, ce n'est peut être pas un problème de personne mais surtout un problème d'une organisation qui à défaut d'avoir su sensibiliser ses troupes sur les dangers de certains raccourcis n'est même pas capable de s'en protéger.
    Et en général la capacité d'une organisation a remplir ses missions est de la responsabilité du patron et non des "personnes" qu'il emploie.

    Notez que lorsque j'écrivais "on teste pour limiter les risques de dysfonctionnement résultant des éventuels défauts", j'ai volontairement omis de dire que les tests ont un coût.

    La décision d'en faire plus ou moins est un arbitrage "politique" et non technique. Le technicien pourra recommander, le politique lui dira "débrouilles toi avec çà" et tant qu'il n'aura pas été viré pour incompétence, il aura la légitimité pour de tels arbitrages.

    Une des difficultés est que la non qualité (pas assez de tests) aura peut être un coût plus tard difficile à tracer: l'équipe d'exploit. croulera petit à petit dans le traitements des bugs et incidents parce que l'accumulation de la dette technique devient ingérable.
    Par contre si on teste trop, çà coûtera tout de suite et sans certitude d'en mesurer une économie plus tard.

    Mettez vous à la place du politique: avec des tests suffisants, il ne pourra réaliser que 5 projets par an et risquer de se mettre les métiers à dos. Par contre, en testant moins, il pourra en faire 10. Mieux, en pleurant un peu, il pourra même convaincre les métiers de faire eux mêmes les tests.
    Comme les vrais dégâts de l'accumulation de la non qualité ne seront visibles que dans 2 ans ou plus, çà lui donne le temps de voir venir.

    - W
    PS: hélas, ce n'est pas de la science fiction.
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

Discussions similaires

  1. Réponses: 11
    Dernier message: 01/04/2010, 18h27
  2. [Configuration] Comment faites-vous pour séparer les paramètres offline/online
    Par robichou dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 4
    Dernier message: 20/02/2007, 03h51
  3. comment faite vous pour comparer 2 classeurs excel ,
    Par melodyyy dans le forum Macros et VBA Excel
    Réponses: 3
    Dernier message: 15/11/2006, 15h44
  4. [Struts]comment faites-vous pour enregistrer..
    Par pouss dans le forum Struts 1
    Réponses: 7
    Dernier message: 30/09/2005, 13h55
  5. Réponses: 22
    Dernier message: 22/04/2005, 16h05

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