Archive for novembre, 2009

Les bonnes pratiques du test.

samedi, novembre 28th, 2009

Avoir un environnement de test « propre » est un pré requis à une campagne de test. Mais quand monter un environnement de test prend du temps et est complexe, la tentation est grande de ne pas tout faire dans les règles. Pourquoi ne pas prendre l’ancien environnement et le bidouiller un peu pour la prochaine campagne car c’est moins couteux en temps?

Quels sont les risques:

  • J’ai rajouté manuellement un champ dans une table de la base de données et j’ai également mis les données  dans cette base. Tout fonctionne correctement. Malheureusement le dba a oublié de rajouter ce champ ou n’a pas mis exactement les mêmes données. Conclusion en production rien ne fonctionne.
  • La structure d’un fichier de configuration a évolué, je l’ai modifié manuellement. Tout fonctionne correctement lors de mes tests, malheureusement l’installation n’a pas été modifiée, uniquement le code pour s’adapter à cette nouvelle structure. Conclusion une fois en production il y a une erreur au lancement du programme.

D’un coté les tests sont faits plus rapidement car on a gagné du temps sur la mise en place de l’environnement de test, mais en final on en a perdu beaucoup à chercher l’erreur en production sans compter les problèmes de confiance par la suite. Là l’équipe de test peut ruiner son image: « Ce logiciel n’a jamais été testé! ».

En conclusion:

  • Avant de livrer les tests doivent être effectués sur un environnement propre (tout réinstaller). C’est la garantie d’une livraison saine.
  • Un programme d’installation simple et rapide incitera les testeurs à ne pas prendre de risques.
  • Ne jamais oublier qu’une erreur est vite arrivée (oubli, manque de coordination …) même quand il s’agit de modifications à priori simples.

Définition du test de stress logiciel

vendredi, novembre 6th, 2009

Après de vives discussions sur la définition du test de stress dans ma société je vous fait part de ce que j’ai glané sur le net:

Sur un site proposant des services de test:

« Stabilité et stress: Un test de stress est l’analyse du comportement d’un logiciel lorsqu’il est soumis à des cas de non conformité des applications.  …
Le test de stress permet de révéler le comportement de l’application et prévoir les causes afin de fiabiliser votre logiciel.  »

Sur un pdf  de Raymond Rivest
Conseiller, spécialiste de test, CRIM Centre de tests du logiciel:

Tests de charge, de stress et de configuration
Afin de déterminer les goulots d’étranglement et la stabilité du système, des tests de charge et de stress sont exécutés. La principale différence entre ces deux types de test est la suivante :

  • Un test de charge comporte un scénario de base, pour lequel le volume de transaction et d’usager sera augmenté de manière graduelle.
  • Un test de stress consiste à exécuter un scénario de charge maximale du système sur une période maximale.

Pour le test de charge, il s’agit de déterminer à quel moment le système ne sera plus conforme aux performances requises ou que des erreurs surviendront. Pour le test de stress, il s’agit de déterminer combien de temps le système peut supporter la charge maximale sans entraîner de corruption de données ou cesser complètement de fonctionner.
Une fois les goulots identifiés, on procède au dimensionnement du système en fonction des objectifs de performance requis. Les composantes du système seront ajustées, ainsi que les configurations, de façon à obtenir le meilleur rendement. »

Autre définition sur un site web www.qualitelogicielle.com:

« Tests conçus pour déterminer si le système peut fonctionner avec un large volume -plus large que normalement attendu.
–Les zones de stress incluent : transactions, tables internes, espace disque, données de sorties, données d’entrées, communication, capacités de l’ordinateur, interaction avec les ressources, etc.
–On assure de pouvoir traiter x transactions par minute, mais jusqu’où le système peut-il en accepter? Documenter le point de rupture.  »

Définition trouvée sur wikipédia:

« Test de stress : il s’agit d’un test au cours duquel on va simuler l’activité maximale attendue tous scénarios fonctionnels confondus en heures de pointe de l’application, pour voir comment le système réagit au maximum de l’activité attendue des utilisateurs. La durée du palier en pleine charge, en général de 2 heures, doit tenir compte du remplissage des différents caches applicatifs et clients, ainsi que de la stabilisation de la plateforme de test suite à l’éventuel effet de pic-rebond consécutif à la montée en charge. Dans le cadre de ces tests, il est possible de pousser le stress jusqu’à simuler des défaillances systèmes ou applicatives afin d’effectuer des tests de récupération sur incident (Fail-over) ou pour vérifier le niveau de service en cas de défaillance. »

Définition de l’ISTQB:

« Test de stress : Un type de test de performance mené pour évaluer un système ou composant à ou au-delà des limites de sa charge de travail anticipées ou spécifiées, ou avec une disponibilité réduites de ressources telles que l’accès mémoire ou serveurs [d’après IEEE 610]. »

Toutes ses définitions se ressemblent et sont assez différentes en fonction du point de vue performance ou stabilité.

Conditions de test:

  • Charge au delà de la normale
  • Multi scénario.
  • Ressources réduites, conditions anormales.

Objectifs:

  • Stabilité et fiabilité du logiciel.
  • Point de rupture du logiciel, goulot d’étranglement.
  • Mesures pour réaliser le tuning de l’application.
  • Niveau de service en cas de défaillance.
  • Mesure du temps de récupération après défaillance.

Finalement quelque soit le nom l’important est de vérifier tous les points précédemment cités.