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
Lancer des tests / simulation
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... :-(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 !).
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).
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 ! ;-)
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.
De manière générale, les points suivants sont à vérifier :
- 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.
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!!
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...
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 ?
Dans le domaine des tests, c'est même déjà beaucoup.mais sinon, j'ai confirmation que j'étais sur la bonne voie, c'est cool
Déjà, ça commence par analyser quelques éléments :
- 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
ben on va les faire à la minime les tests alors
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... :-(Plus sérieusement...merci de toutes ces infos. Je pensais qu'il existait des méthodes moins empiriques, plus méthodiques
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
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager