Discussion :

[The Vandals]

Bonjour,

J'aimerai savoir quel outil et quel techniques vous utilisez pour tester vos requêtes SQL?

Je n'ai jamais fait de test fonctionnel sur des requêtes SQL mais j'aimerai en mettre en place pour m'assuré du resultat et surtout pour la maintenabilité.

J'avais pensé utiliser une base de données vide et sur mon setup de test créer les tables nécessaire ainsi que les données représentant tous les cas possible et ainsi pouvoir prévoir le résultat.

Est-ce une bonne techniique? En existe-t-il des meilleurs? Lequelle utilisé vous et pourquoi?

Merci
Phil

[phili_b]

J'avais pensé utiliser une base de données vide et sur mon setup de test créer les tables nécessaire ainsi que les données représentant tous les cas possible et ainsi pouvoir prévoir le résultat.

excellent.

Mais on n'a souvent malheureusement pas le temps et on ne dispose pas de toutes les bases qu'on voudrait. Mais c'est la bonne méthode.

[The Vandals]

J'ai commencer a faire mes tests et pour les tables, j'ai laissé tombé toutes les clée primaire et foreign key (pour facilité l'entré de donnée lors du setup du test) et je rempli seulement les champs utiles pour mes tests.

D'apres moi les tests restent valide, mais est ce vraiment le cas?

Est ce que cela est une bonne manière de faire?

Merci

[SQLpro]

...j'ai laissé tombé toutes les clée primaire et foreign key...

c'est exactement ce qu'il ne faut pas faire !
Il faut que votre modèle de données soit EXACTEMENT celui de la production et avec le même volume de données.
En effet le moteur SQL utilise les statistiques des index qu'il dispose pour trouver la bonne manière de traiter votre requête. Si vous ne mettez pas les clef les index sous jacents ne seront pas créés et les plan de requêtes seront à chier...

A +

[The Vandals]

Ce que je veux tester c le resultat de mes requetes. Je ne veux pas avoir le meme volume de donnée que le modele déployer sinon c impossible de prévoir le resultat de ma requete.

La technique que j ai utilisé c'est d'ajouter des lignes dans mes tables pour correspondre a tous les cas possible. Ainsi je peux verifier a l'aide de mes tests que ma requete s'execute correctement. Aussi, si jamais quelqu'un modifie une sous-requete, le test s'assure que ma requette donne le même resultat.

Donc pour ce genre de test je crois que je ne doit pas me soucier des statistique et du temps d execution.

Peut-etre devrais je me faire des test pour cela... mais je ne vois pas vraiment l'utilité de tester avec le meme volume de donnée avec les index et statistiques

Merci

[phili_b]

c'est exactement ce qu'il ne faut pas faire !
Il faut que votre modèle de données soit EXACTEMENT celui de la production et avec le même volume de données.
En effet le moteur SQL utilise les statistiques des index qu'il dispose pour trouver la bonne manière de traiter votre requête. Si vous ne mettez pas les clef les index sous jacents ne seront pas créés et les plan de requêtes seront à chier...

Il ne faut certes pas virer les contraintes ni les index, car ça fausserait tout, mais sa question portait sur les tests fonctionnels. Dans ce cas ce n'est ni la performance ni la volumétrie qui l'intéresses mais simplement avoir des cas de test fonctionnels typiques. C'est certes légèrement hors sujet du SQL pur du forum "Langage SQL", mais je pense que la question est intéressante et une réponse non technique peut l'être aussi

Donc ou bien on fait une base quasi vide (mais de structure identiques index, foreign key) avec les cas typiques, pour ne pas perdre son temps à chercher ses cas, ou bien on prends une base à volumétrie réelle mais il faut avoir pris un temps certains pour identifier tout les cas typiques.

Malheureusement je n'ai eu souvent le temps que de faire la 2é méthodes avec toujours un risque de ne pas faire tout les tests fonctionnels voulus car pas suffisamment de temps pour identifier dans un volume énorme tout mes cas typiques. Je ne suis pas un expert en plan de test, il faudrait que quelqu'un connaissant bien le principe des plans de tests intervienne.

edit: le plus souvent par manque de temps, on rajoute à la main des cas typiques à une copie de prod que l'on a en environnement de développement.

[The Vandals]

La technique que j'utilise est la suivante:
J'ai une base de données completement vide (sans vues, tables ou SP).
Je me suis créer des classe contenant la definition de mes tables et de mes vues ainsi que le script sql permettant de les recréer. J'ai appeler ces classes CatalogueVues et CatalogueTables.

Sur le setup de mon test, j'execute une requête qui m'assure que la base de données est completement vide. Ensuite je récupere la vue que je veux tester de mon CatalogueVues. Je met en place l'environement nécessaire pour créer cette vue (tables et sous vue nécessaire) et ensuite je crée la vue.

Sur chacun des tests j'insert les lignes nécessaire pour tester le cas spécifique que mon test vise. L'insertion est faite par un helper qui me permet de recréer certain éléments avec des condition particuliere dans ma bd. Ce helper a aussi des test unitaire et fonctionnel ce qui me permet d'assurer que les données se retrouve bel et bien dans mes tables et que ces données sont conformes.

Pour l'instant j'ai enlever toutes les clées primaire et étrangere de la définition de mes tables (pour des question de manque de temps), mais je me suis appercu que cette pratique oblige le programmeur à avoir une bonne connaissance des liens entre chacuns des objet et que certains tests peuvent etre incorrect s'il y a eu une mauvaise injection des données ce qui fait que les tests ne sont pas à 100% fiables (mais sont tout de meme tres pratiques). Pour ceux qui se trouve dans la meme situation que moi(pressé par le temps), je crois que le mieux est de commencer avec des tables sans les clées et que toutes les insertion soit faite a partir d'une classe externe au tests (helper). Cela permet par la suite de développer un nouveau helper qui tient compte des clées primaire et des clées étrangere sans avoir a modifier les tests déjà en place.


PS: je ne suis pas un pro des test fonctionnel sur les requettes SQL, j'en suis seulement a mes débuts. Je crois que cette technique est bonne (en fait c ce que j'ai trouver de mieux) mais j'aimerais bien avoir vos commentaire sur cette technique (ou si vous avez une meuilleur technique)

Merci
Phil

[bilred]

Bonjour,

j'aimerai en mettre en place pour m'assuré du resultat et surtout pour la maintenabilité.

Je voudrai moi aussi faire des tests sur une BD et Je n'ai jamais fait de test fonctionnel sur des requêtes SQL

J'aimerai savoir quel outil et quelles techniques vous utilisez pour tester vos requêtes SQL ?

Pour la 7em réponse (Je n’est pas bien comprit si quelle qu’un peut m’expliquer)

Merci d’avance.

[bilred]

La technique que j'utilise est la suivante:
J'ai une base de données completement vide (sans vues, tables ou SP).
Je me suis créer des classe contenant la definition de mes tables et de mes vues ainsi que le script sql permettant de les recréer. J'ai appeler ces classes CatalogueVues et CatalogueTables.

Sur le setup de mon test, j'execute une requête qui m'assure que la base de données est completement vide. Ensuite je récupere la vue que je veux tester de mon CatalogueVues. Je met en place l'environement nécessaire pour créer cette vue (tables et sous vue nécessaire) et ensuite je crée la vue.

Sur chacun des tests j'insert les lignes nécessaire pour tester le cas spécifique que mon test vise. L'insertion est faite par un helper qui me permet de recréer certain éléments avec des condition particuliere dans ma bd. Ce helper a aussi des test unitaire et fonctionnel ce qui me permet d'assurer que les données se retrouve bel et bien dans mes tables et que ces données sont conformes.

Pour l'instant j'ai enlever toutes les clées primaire et étrangere de la définition de mes tables (pour des question de manque de temps), mais je me suis appercu que cette pratique oblige le programmeur à avoir une bonne connaissance des liens entre chacuns des objet et que certains tests peuvent etre incorrect s'il y a eu une mauvaise injection des données ce qui fait que les tests ne sont pas à 100% fiables (mais sont tout de meme tres pratiques). Pour ceux qui se trouve dans la meme situation que moi(pressé par le temps), je crois que le mieux est de commencer avec des tables sans les clées et que toutes les insertion soit faite a partir d'une classe externe au tests (helper). Cela permet par la suite de développer un nouveau helper qui tient compte des clées primaire et des clées étrangere sans avoir a modifier les tests déjà en place.

Je pense sa méthode est : (sur ce que dit "The Vandals")

Sur chacun des tests (table ou vu où il applique la requête à tester) il fait entrer les lignes (c.à.d : la liste de valeur en entré) elle doive être connu pour savoir quelle sortie doit être attendu selon la requête SQL tester.

Et pour les CatalogueVues et CatalogueTables c’est pour qu'a chaque fois en démarre du vide et recréé les vus ou tables, seul de la requête à tester (pour être sur que il n y a pas d’influence d’une autre table)

Mais dans ce genre de test il faut toujours garder l’esprit critique ? (alors je voudrais bien une )

[CinePhil]

Quand j'ai une requête complexe, bourrée de jointures et de conditions de restriction, voire de claculs de regroupements, et que je suis un peu étonné du résultat ou pas du tout sûr que celui-ci soit bon, je décompose la requête en éléments vérifiables à l'aide de comptages plus simples sur les tables.

Parfois, c'est aussi un ensemble de requêtes qui permet de vérifier un résultat. Par exemple en comptant des lignes d'une grosse table selon certaines catégories avec des critères complexes, la somme des lignes des différentes catégories doit donner le comptage de lignes de la table.

On peut aussi faire une vérification du résultat obtenu par sondage : on prend des éléments au hasard, on teste les critères de la requête et on vérifie si les éléments figurent ou non dans le résultat.

Une méthode plus rigoureuse consisterait aussi à tester les conditions aux valeurs limites à l'aide d'un jeu de données préparées.
Par exemple, si je dois calculer une prime annuelle en fonction d'une durée travaillée, je vais prendre des exemples :
- d'employés à temps plein n'ayant jamais été absent ;
- d'employés à temps partiel jamais absents ;
- d'employés à temps plein ayant été absents ;
- d'employés à temps partiel ayant été absent ;
- d'employés en CDD ayant fait plusieurs contrats dans l'année ;
- d'employés en CDD ayant des contrats à cheval sur les limites de l'année.

Bref, c'est au cas par cas.

[bilred]

Bonjour,

Donc ma descriptions de ce que à dit «The Vandals » n’est pas convaincante pour toi ? (je cherche une validation de ce que j’ai dit et correct ou pas)

Si non pour ta suggestion « CinePhil » elle marche très bien en Manuel, Alors tu ne connaîtrai pas des outils d’automatisation de c’est tests (pour des requête SQL) ?

Cordialement
bilred

[CinePhil]

Donc ma descriptions de ce que à dit «The Vandals » n’est pas convaincante pour toi ? (je cherche une validation de ce que j’ai dit et correct ou pas)

Grosso modo, ce que tu as dit et ce que j'ai dit se rejoignent.

Si non pour ta suggestion « CinePhil » elle marche très bien en Manuel, Alors tu ne connaîtrai pas des outils d’automatisation de c’est tests (pour des requête SQL) ?

Non. Je n'ai fait ça que manuellement et au cas par cas.

J'ai même fait pire en me fiant à l'avis d'un expert du domaine étudié quant au résultat obtenu sur un découpage par familles selon des critères complexes (une classification de bovins).

[bilred]

Non. Je n'ai fait ça que manuellement et au cas par cas.

J'ai même fait pire en me fiant à l'avis d'un expert du domaine étudié quant au résultat obtenu sur un découpage par familles selon des critères complexes (une classification de bovins).

Bonjour,

D’après ce que tu viens de dire :
C’est que même si en veux développer un outil qui fait des tests automatisés pour une requête SQL c’est impossible ?
Du moins qui ressemble à ça :

Un outil qui à la possibilité d’avoir une liste de valeur en entrai, qui paramétré la requeté SQL et à l’exécution en doit pouvoir s’assurai que c’est bien le résulta de sorti à tendu (c’est nous qui paramétrant sa les entrai et résulta)

cordialement
bilred

[CinePhil]

Tu peux toujours essayer mais ce ne sont pas les requêtes simples qui posent problème mais les requêtes complexes bourrées de jointures (JOIN), de conditions de restriction (WHERE), de calculs(MIN, MAX, SUM, AVG, COUNT), de regroupements (GROUP BY), de restriction sur le résultat du regroupement (HAVING)...

Et là il y a une infinité de possibilités donc un outil standard me semble utopique.

Imaginons que je sois chef de production d'une entreprise d'installations électriques et qu je cherche quels ouvriers qualifiés, habilités à travailler au voisinage de moyenne tension HTA, je vais pouvoir confier à un chantier démarrant dans deux semaines.
Le système doit faire une requête prenant en compte au minimum :
- la table du personnel ;
- la table des qualifications ;
- la table des habilitations ;
- la table associative entre le personnel et les qualifications ;
- la table associative entre le personnel et les habilitations ;
- la table d'affectation du personnel aux chantiers ;
- la table des absences (congés, formations, arrêts de travail ; pour autant que ce soit une seule table, ce qui n'est pas sûr).

Il faudrait donc, pour tester la validité de cette requête, enregistrer au moins :
- du personnel ayant la qualification mais pas l'habilitation ;
- du personnel ayant la qualification et l'habilitation ;
- du personnel ayant l'habilitation mais pas la qualification ;
- du personnel n'ayant ni l'un ni l'autre ;
- du personnel valable mais absent ;
- du personnel valable mais déjà affecté à un autre chantier.

Toujours avec mon même boulot et pour le même chantier, je dois aussi prévoir la disponibilité d'une fourgonnette et d'un petit camion avec grue de déchargement pour le transformateur à remplacer.
Le système doit cette fois avoir une requête, qui est pourtant du même genre que la précédente, mais qui ne porte pas sur les mêmes tables :
- la table des véhicules ;
- la table des types de véhicules ;
- la table associative entre les véhicules et leurs types ;
- la table des équipements de véhicules (grue, haillon...) ;
- la table associative entre les véhicules et les équipements ;
- la table des affectations des véhicules aux chantiers ;
- la table des véhicules indisponibles (réparation, accident, révision, passage aux mines...).

Et pour vérifier que la requête est valable... Bref, un besoin similaire au départ (une ressource ayant certaines caractéristiques disponible pour une certaine date et une certaine durée) mais des tables différentes, des conditions différentes, des données qui n'ont rien à voir.

Tiens j'y pense ! Pour couronner le tout, il faut peut-être aussi qu'au moins un des ouvriers ait l'autorisation de conduite des engins de manutention et qu'au moins un ait plus que le simple permis B de monsieur Toutlemonde. Donc une requête supplémentaire à vérifer un cas parmi des milliers de possibilités.

Ton idée est intéressante mais... bon courage pour la mettre en oeuvre !

[bilred]

Bonjour,

Il faut trouver une méthode pour identifier les cas de test possible pour pouvoir couvrir le maximum de notre système ? (même si en c’est d’avance que on ne peut pas tout couvrir)

Je pense aux cas les plus prioritaires et les plus utiliser…. ! (
Pour avoir une spécification Générique et pouvoir automatiser le maximum de Test (en commencent par les plus simples)


Sinon J’ai aussi trouvé ça sur le net:

Selenium-RC utilise la pleine puissance des langages de programmation pour créer des tests plus complexes comme la lecture et écriture de fichiers, l'interrogation d'une base de données, emailing résultats des tests.

http://seleniumhq.org/docs/05_selenium_rc.html

Je ne c’est pas comment sa marche mais je vais voir sa.

Cordialement
bilred

[bilred]

Bonjour,


J’ai une présentation à faire dans le cadre des Test D’application Web sur des requêtes SQL.
Et voilà, en gruaux ce que je vais présenter.

Méthode manuelle:
Deux catégories de test possible selon le type des requêtes SQL :
1. Langage d’interrogation des données (type: SELECT, WHERE) et modélisation (type INSERT, UPDATE)
2. Langage de définition des données (type: CREATE table, ALTER table, DROP table)

Cas 1 : (Tester l'exactitude des requêtes SQL et les procédures de stockage)
On doit commencer sur une BD complètement vide et crée des classes contenant la définition de nos tables et de nos vues ainsi que le script SQL permettant de les recréer. (Je nommerai ces classes CatalogueVues et CatalogueTables).
Ensuite on exécute une requête qui nous assure que la base de données est complètement vide.
Puis on récupère la vue ou table que l’on veut tester de notre CatalogueVues ou CatalogueTables. Et on met en place l'environnement nécessaire pour créer cette vue ou table (tables et sous vue nécessaires) et ensuite on peut la créer.
Sur chacun des tests (la requête à tester et les tables ou vues qu’elle utilise) il faut entrer des lignes dans la table (c’est à dire: la liste de valeur en entrée) elles doivent être connues pour savoir qu’elle sortie doit être attendue selon la requête SQL tester.
Cas 2 :
Des tests sur requêtes SQL pour des fonctionnalités de type Create, read, update et delete (CRUD) oû il faudra vérifier s’il y a réflexion dans l'interface utilisateur.


Méthode semi automatique : (En utilisant SéléniumIDE et Sélénium-Remote-Control)
En réalité il n'y a rien à spécifier par Sélénium sauf les actions du navigateur.
On peut penser à sélénium comme une bibliothèque où on peut l’importer vers nos applications, qui à la possibilité de conduire un navigateur.

Donc : on doit coder les actions à tests (la partit de l’application que l’on veut tester) sauf la partie de la navigation,
Cela se résume à charger la bibliothèque dans le langage de programmation que nous utilisons et d’ajouter le code de tests que nous écrivons.

Description pratique de ce qui ce produit :
Au lancement du test le navigateur avec le code à tester est lancer c’est la partit navigation (les actions, choix ou click sur un bouton qui est automatiser) et si par exemple la requête à tester ajout un chams sur l’interface qui affiche la table sûr la quel la requête à tester à être appliquer est que le champ n’a pas être rajouter le Test va sortir un message d’erreur puisque il va appliquer une action sur un champ qui n’existe pas.

Je voudrai si possible savoir si c’est Claire pour vous ou qu’il y a des questions ?
ci-jount explication du Cas 1 de la Méthode manuelle.

Merci d’avance pour vos remarques.
Cordialement
bilred

[geforce]

Bonjour,

voilà, des outils de tests sur les données: (que j'ai trouvés, ça peut aider)

1.DBUnit
DBUnit est une extension JUnit pour les bases de donnée.
DbUnit is a JUnit extension (also usable with Ant) targeted for database-driven projects that, among other things, puts your database into a known state between test runs. This is an excellent way to avoid the myriad of problems that can occur when one test case corrupts the database and causes subsequent tests to fail or exacerbate the damage.
DbUnit has the ability to export and import your database data to and from XML datasets. Since version 2.0, DbUnit can works with very large dataset when use in streaming mode. DbUnit can also helps you to verify that your database data match expected set of values.

Télécharger

2.DDSteps
JUnit extension making test cases data driven. Uses external test data (in Excel, XML etc) which is injected into your test case using standard JavaBeans properties. 100% JUnit compatible.
DDSteps integrates best-of-breed toolkits for web and database testing, such as JWebUnit, DbUnit and Spring Framework. By making these toolkits data driven, you can do powerful function testing. Automated end-to-end testing of your website is not only possible - it is easy.

Télécharger

des retours d'expérience, ou d'autre outils seront les bienvenus.

Cordialement
GeForce