Version imprimable
Bonjour,
j'ai une appli au bord de la livraison.
Je voudrais pouvoir lancer une batterie de tests.
A savoir, multiplier les connexions au sgbd, et simuler des enchainements d'opérations.
j'ai une idée mais je voudrais savoir s'il n'existe pas des logiciels spécifiques à BCB ou des méthodes de prog pour faire tout ça.
merci d'avance
la société PolySpace ( http://www.polyspace.com/ ) fourni de tels sofwares.
Il en existe d'autres dont je n'ai pas les noms en tête.
Faut voir le prix des softs PolySpace, aussi !! Ils sont géniaux, mais durs à encaisser pour une PME... :-(Citation:
Envoyé par j.p.mignot
De plus, si ma mémoire est bonne, PolySpace se comporte comme un "super-Lint" dynamique (exécution du code en environnement émulé), qui va détecter le code mort, les conditions jamais réalisées, les durées/portées/domaines des variables, etc...
Mais il ne fait que valider le code, il n'est pas capable de simuler une charge ou même une simple contrainte de temps : il vérifie que le code est correct, ni plus, ni moins (même si c'est déjà beaucoup !).
:arrow: say : Mis à part automatiser ton programme (éventuellement en incluant tout ou partie de ses modules dans un programme de test), je ne vois pas comment tu peux simuler ça... Il faut en effet que le SGBD réponde réellement, donc il faut le faire fonctionner "pour de vrai".
Par exemple, pour tester des DLL, j'ai l'habitude de créer un projet parallèle qui utilise les modules de la DLL au sein d'un projet "tentaculaire", qui permet de tester toutes les fonctions de manière unitaire... Ce dernier est, bien entendu, hautement automatisable. Ca permet de valider les fonctions unitaires, et même les fonctions "publiques". Une fois le test concluant dans ce cas d'utilisation, j'utilise la batterie automatique de tests sur l'interface de la DLL, mais en tapant réellement dans la DLL ce coup-ci : bien entendu, les résultats doivent être identiques.
Ne peux-tu pas faire un système similaire avec ton application ? Profites du fait que partager une fiche/module de BCB entre deux projets (via un groupe de projets) soit une opération ultra simple ! ;-)
C'est vrai qu'ils sont chers!!! Mais ils offrent aussi des prestations de service.
Hors mis les points cités, j'ai utilisé ce soft pour émuler les cas de prises de données via des electroniques externes dans des cas que jamais un banc de test n'aurrait pu faire ( trop de cas possible pour des dizaines voir des centaines d'entrées ). Cerains risques potentiels ont été mis en évidence.
Certain cas de variables non prot╬gées ont aussi pu être révélés dans le cas d'interrupt externes assynchrone avec le process.
Il est vrai que je n'ai jamais eu à travailler avec les baques de données.
Bonjour,
merci de vos réponses à vous deux. En effet, le coût de logiciels de tests va être un vrai frein. Mon boss (PME) m'a à peu prèt ouvert les cordons de le bourse mais là, il va tiquer, je préfères me réserver du budget pour d'autres achats (hard ou soft).
Citation:
Envoyé par Mac LAK
en revanche, je pensais bien que modifier le prog en format test pouvait être une solution.je me demandais s'il existait des méthodes particulières, des points clefs à vérifier, en dehors du comportement du sgbd.
merci
Au moins, tu en as la confirmation : c'est non seulement possible, mais en plus, ça marche très bien : du moins avec les compilateurs Borland, c'est parfois un peu moins simple avec Visual C++ par exemple.Citation:
Envoyé par say
De manière générale, les points suivants sont à vérifier :Citation:
Envoyé par say
- Comportement en cas d'absence de ressources critiques (DLL, programmes annexes, version Windows incompatible, version WinSock, etc...) : le programme doit prévenir sans se crasher.
- Initialisation/destruction : toutes les ressources doivent être rendues (fuites mémoire par exemple). Je crois que "MemCheck" est compatible avec BCB, fais une recherche sur cet outil (Delphi à l'origine).
- "Algo du singe" : cliquer n'importe où, n'importe comment et de préférence avec des valeurs débiles. Le programme doit tenir le choc.
- Rupture de câble réseau : détection de timeout impérative (débranche le hub Ethernet, de manière à avoir la liaison mais plus de communication possible avec le serveur).
- Vérification des fonctions unitaires, suivant leurs spécifications.
- Vérification des fonctions exportées/publiques, en fonction des spécifications générales et/ou du CdC.
De manière générale, il ne faut pas tester ce que tu as codé, mais ce qui était prévu. Comme un réseau est en jeu, il te faut aussi simuler toutes les pannes possibles, et tester le cas où plusieurs cartes réseau sont installées et/ou la tentative de connexion via un modem/VPN, ou au travers d'un proxy.
As-tu besoin de plus d'informations ?
Ok, ça me fait déjà une bonne base.
En ce qui concerne les tests de la charge du SGBD...est-ce qu'une classe lançant des requêtes SQL types, et des simultations d'évenements peut coller?
D'expérience la bonne approche d'une procédure de test est la suivante:
- 1) Oublier le code, repartir des spécifications, si la rédaction des cas de test n'a pas été faite en amont.
Qu'est-ce qu'un cas de test: Vérifier une fonctionnalité de manière macorscopique. Par exemple, pour l'exigences suivante d'un éditieur de texte: L'éditeur doit reconaître la syntaxe du langage utilisé sur une statistique de mots clés et non simplement sur type d'extension" donnera les au moins les cas de tests suivants:
a) Cas nominal : Ouverture d'un fichier d'extension C++ contenant un source ADA. Résultat, le langage ADA sera reconnu.
b)Cas dégradé connu: Ouverture d'un fichier d'extension PAS, contenant un mélange de sources ADA, C++ et HTML. Aucun langage n'est reconnu.
c)Cas dégradé connu: Ouverture d'un fichier inexistant, ouverture d'un ficher autre que textuel (Word, binaire...): Détection d'un type non supporté.
Cette étape suit les spécifications des fonctionnalités. Test des valeurs aux limites et des cas dégradés connus.
Une autre étape vient après la conception détaillé, au pire arpès l'analyse des sources, en boîte blanche. Elle vise à garantir que l'intégralité des chemins algorithmique sont passés aux tests.
Enfin, une fois tous les tests unitaires déroulés, bien sûr viennent les tests d'intégration de chaque module entre eux.
Quoi qu'il en soit, il vaut mieux privilégier les test automatiques avec le moins d'intéraction humaine dans un maximum de tests. Si ce n'est pas possible, effectivement, il faut une intervention humaine.
Les tests automatiques doivent être le plus simple possible, pas de futilité dans le code des exécutables de test.
Contre exemple pour tester un module de liste simplement chainée:
Une mauvaise approche consiste à avoir un menu pour choisir le nombre déléments à remplir, chaque champs à renseigner, les éléments à supprimer ... Il y a 80 % de chance qu'un tel exécutables de test rende obscur les cas nominaux, dégradés ... de plus, il peut lui même être bugué.
Plus les tests automatiques sont simple dans leur syntaxe, plus il sera dans l'avenir facile de démontrer la complétude des tests envers les exigences du logiciel.
Le cahier de test doit décrire pour chaque tests, la procédure associées, la spécification en entrée, le résultat attendue et correct.
Parmis les tests:
-Tests unitaires
-Tests d'intégration: Respect des interfaces entre module et des pré et post conditions.
-Tests de charges: Comment le logiciel réagit à une utilisation intensive, qu'elle soit nominale ou erronée ? Les ressources sont-elles libérées et ré-utilisables?...
Très bien.
Merci infiniment pour les infos, je vais m'organiser à partir de tout ça.
Bonne continuation.
Pour répondre à ta question : oui, le but est de "charger" le SGBD, de préférence de la même manière que va le faire ton programme, mais "en pire"...
Ex :
- Si les requêtes sont déclenchées par une opération humaine, à une fréquence maximale de 2 requêtes par seconde, tu fais un test à 20 requêtes/seconde...
- Si ton appli est prévue pour fonctionner sur maximum 3 postes, tu la déploie sur 6 (et tu charges la mule).
- Etc...
Le point important est de voir si tu tiens tes limites : si tu tiens "mieux", sans trop plomber le système, tu peux raisonnablement émettre un verdict favorable sur le comportement de l'application en mode nominal.
Si tu ne les tiens pas, il faut voir le "facteur limitant" (BP réseau ? Charge CPU ? RAM ?), ce qui te permettra normalement de trouver les limites "acceptables", ou de définir les besoins matériels requis (ex : 512 Mo de RAM, réseau 100 Mbits/s, etc...).
oki...mais comment synchroniser tous les progs de test.
je veux dire que par exemple, je soupçonne un problème de BP (because un VPN sur DSL). donc à moins de se mettre des beta-testeurs et de les synchroniser à la voix...je me vois pas développer des sockets de synchro juste pour des tests..
mais sinon, j'ai confirmation que j'étais sur la bonne voie, c'est cool :)
Pour cela tu as aussi CodeGuard intégré à BCB (dans les options de ton projet). Mais seulement à partir de la version 6 Pro je crois.Citation:
Envoyé par Mac LAK
Sinon je suis très intéressé par les tests automatiques. J'ai du écrire des programmes de tests unitaire pour un projet scolaire mais je souhaiterais appliquer ces méthodes à mes développement. Le problème c'est que je ne vois pas trop comment "automatiser" les tests...
Ok, je testes de suite!! :)Citation:
Envoyé par Neilos
Hélas, pas trop le choix... Par contre, tu peux démarrer sur un "top horaire" (début des tests à 10h00 tapantes par exemple), sur apparition d'un fichier réseau/internet (page HTML), réception d'un datagramme UDP (très simple à faire, ça !), etc...Citation:
Envoyé par say
Des solutions, il y en a des milliers : faut juste en choisir une que tu sais faire rapidement, même si ce n'est pas forcément la meilleure ! ;-)
Si t'as besoin qu'un opérateur humain (toi, par exemple) démarre tous les programmes "manuellement", puis que tu doives lancer la synchro manuellement, et alors ? C'est toujours mieux qu'aucun test, non ? :mrgreen:
Dans le domaine des tests, c'est même déjà beaucoup.Citation:
Envoyé par say
Déjà, ça commence par analyser quelques éléments :Citation:
Envoyé par Neilos
- Peux-tu "extraire" la fonction unitairement, ou connaître à l'avance ses dépendances ? Une simple documentation Doxygen te permet de savoir ça, par exemple.
- Peux-tu essayer toutes les combinaisons possibles de paramètres ? Si ta fonction prend au maximum l'équivalent de 16 bits maximum en paramètres, la réponse est "oui". Si elle prend 12 paramètres réels et 23 chaînes de caractères, ça va être dur ! ;-)
- Peux-tu déterminer, d'après les specs, quelles sont les valeurs critiques à tester ? Si non, quelles sont les valeurs critiques liées à l'implémentation ? (cas des chaînes valant NULL, des buffers non-alloués, etc...) Tu vas en déduire un jeu de test nominal (valeurs produisant des résultats connus à l'avance, pouvant être comparés aux résultats de la fonction), et un jeu de test "d'erreur" (valeurs produisant des erreurs connues à l'avance).
- Peux-tu déterminer les compatibilités requises ou interdites de ta fonction ? Par exemple, fonctionnement thread-safe, process-safe ? Si oui, il faudra créer une situation de concurrence pour valider cet aspect (ou, au contraire, prouver qu'il y a incompatibilité).
- Connais-tu des invariants, préconditions et postconditions de ta fonction ? Si oui, ils devront être testés à chaque jeu de test.
Une fois tous ces éléments connus, il "suffit" (!) de créer un programme implémentant tous ces tests, et de consigner le résultat sur un support neutre pour ta fonction (ex : ne pas utiliser un fichier de log si ta fonction manipule les fichiers, ne pas utiliser un "telnet RS-232" pour un objet de communication RS-232, etc...).
De même, en fonction des tests unitaires et des dépendances, tu peux devoir valider tes fonctions dans un certain ordre (de la moins dépendante à la plus dépendante, bien sûr), et surtout t'appuyer sur une validation réussie pour "accélérer" les autres validations : mais ça, par contre, ça dépend beaucoup de ton projet et du découpage fonctionnel que tu as choisi.
Au minimum, en tout cas, toutes les fonctions publiques du module devront être testées. Même les macros "tellement simples qu'elles ne peuvent échouer" : fais quand même un test fonctionnel, par sécurité (test anti-"erreur de frappe").
Est-ce un peu plus clair pour toi ? As-tu besoin d'explications supplémentaires ?
Merci de toutes ces infos. Je pensais qu'il existait des méthodes moins empiriques, plus méthodiques :wink:
ben on va les faire à la minime les tests alors :D
merci encore
De rien. Sinon, oui, il y a des méthodes plus "méthodiques" justement, mais elles sont rarement "à postériori"... Elles sont plutôt intrinsèquement liées au processus de développement dans son ensemble, et le faire après coup, c'est presque impossible... :-(Citation:
Envoyé par say
Bonne chance, pour tes tests comme pour ton retour à Toulouse ! ;-)
Bonjour,
Pour appliquer avec méthode la conception de la phase de test, il faut la commencer dès le cahier des charges, la raffiner au fur et à mesure de la conception détaillée.
L'analyse boite blanche permet surtout de montrer que si une fonctionnalité est testée en nominal, il est possible d'exclure certaines branches algorithmiques qui passent par cette fonctionnalité. On fera simplement un test sur les conditions d'appel.
De manière générale, automatiser des tests est plus simple dans une architecture modulaire et bien pensée. On automatise les modules les plus indépendants pour connaître leurs réponses aux contraintes d'appel et vérifier qu'ils tiennent leur cahier des charges. Puis on augmente d'un niveau, on teste quelques modules qui les utilisent, là encore en commençant par les plus indépendants.
Lorsqu'il y a une forte connexion entre modules, afin de se mettre dans des cas connus, on "stube" le module que l'on ne teste pas.
Exemple: Un programme prend ses trames sur une liaison série RS232, il vérifie la conformité des trames suivant un protocole. On va stuber le driver RS232: La fonction de création renvoie toujours EXIT_SUCCESS, la fonction de lecture d'un octet renvoie un octet définit d'une trame codée en DUR et connue, conforme au protocole à tester. La fonction de fermeture de la com renvoie toujours EXIT_SUCCESS...
Il est alors facile de vérifier que le programme appelant détecte bien les cas nominaux.
Plus vicieux cette fois, on crée un stub paramétrable: Suivant un paramètre toutes les fonction sont dans un cas nominal ou dans un cas dégradé connue. Refus d'ouverture ou de fermeture, réception d'un trame tronquée et Timeout, réception d'un trame dans un autre protocole...
On vérifie que le programme appelant détecte ces cas.
Lors de l'intégration avec le driver RS232, on est sur que le module appelant est correct, s'il y a une erreur, elle est dans le driver.
Evidement, le Stub suit les spécifications exactes du module à stuber.
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".
Il va falloir que je me penche là dessus, merci pour les infos tout le monde et merci pour ton post say qui m'a permis d'apprendre pas mal de choses.
Et bien..on en apprend des choses.C'est étonnant, c'est très pointu et pourtant j'ai jamais étendu de formation spécifique.
D'après vous, (et je vous crois sur paroles), il faut prévoir les tests dès le cahier des charges. Dès ce cas, faut-il aussi planifier le développement de tests dans la conduite du projet?
De plus, qu'est ce qu'une analyse Boite Blanche?
Neilos>> U're welcome, c'était le but :)
Tu veux dire carrément ignorée dans le domaine amateur... ;-)Citation:
Envoyé par Neilos
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 !!
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
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
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).Citation:
Envoyé par say
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.
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 :P ).
GOOO ! Si tu le fais je serais un des premiers à l'acheter !Citation:
Envoyé par Caine
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 !
re..
sans aller jusqu' à un livre...un tuto ou une première approche pour developpez, ça le fairait grave. :D
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.
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 :
:arrow: 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
:arrow: la prévision des tests dès le début du cahier des charges et la façon dont ils évoluent
:arrow: 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.
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:
ça évoluera bien sûr.Citation:
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.
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 !
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)
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.Code:
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
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 :)
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 :)