LoadRunner et Performance Center 11 ?

14 04 2011

LoadRunner et Performance Center 11

Performance Center de la version 10 actuelle :

Des nouveautés concernant de nouveaux protocoles :

  • Microsoft Silverlight virtual users
  • Java over http virtual users

Nouveautés sur les plateformes et environnements :

  • Support pour IE8, Win Server 2008 SP2
  • 64 bit support (32 bit app)

Pas grands chose d’autre à dire pour le moment.

Des nouveautés sur le reporting « Multi-level »

Liens vers les autres articles sur ALM 11 :

Publicités




Comment mettre en oeuvre des tests unitaires ?

18 05 2009

Définition :

« Test Unitaire (TU) (ou test de développement) : un test unitaire est un test mené par le développeur en environnement de développement, il a pour but de démontrer qu’une unité respecte bien les critères définis dans les spécifications techniques ».

Dans le cas d’un langage procédural l’unité est « la procédure », et dans le cas d’un contexte orienté objet l’unité est représentée par « La classe ».

Les tests unitaires sont les premiers tests de type boite blanche devant être pratiqués par des profils de type développeurs.

Dans le cas de ce type de tests la question importante est « Quel est la qualité des unités développés et comment le mesurer ? ».

Ainsi, il s’agit pour le développeur de tester un module, indépendamment du reste du programme, ceci afin de s’assurer qu’il répond aux spécifications (fonctionnelles / techniques) et qu’il fonctionne correctement. Cette vérification s’accompagne couramment d’une vérification de la couverture de code, qui consiste à s’assurer que le test conduit à exécuter l’ensemble (ou une fraction déterminée) des instructions présentes dans le code à tester. ».

Ainsi, il faut comprendre ce que l’unité doit effectuer (ou la parcelle de code) :

  • Vérifier les tâches et rôles de l’unité
  • Tester les frontières de l’unité (bornes : zéro, un, complet. Chercher une collection vide par exemple)

Cela se traduit de manière simple par la création d’une classe de test par classe développée.

Exemple de tests unitaires de base et représenté par une classe de test :

  1. Invoquer la méthode avec des valeurs passées en paramètres
  2. Observer les résultats
  3. Vérifier si les résultats sont ceux attendus

Ainsi il faut sélectionner des valeurs pour lesquelles on peut déterminer les résultats attendus.

Comme on le voit cela peut prendre du temps d’effectuer ces tests de manière manuelle. De même si les classes sont complexes et que l’on doit procéder à tests de non régressions…

Pour aider le développeur des outils existent et Junit est le plus efficace (voir détails dans le paragraphe sur les outils).

Exemples d’autres types de tests unitaires :

  • Audit de code : vérification pas à pas des lignes de codes vis-à-vis d’un standard de développement
  • Bound checking : Outil permettant de vérifier d’éventuelles écritures dans les zones mémoires
  • Documentation : lecture de code source générant automatiquement les descriptions du code
  • Memory leak detectors : ces outils tests l’allocation en mémoire des applications
  • Static code (path) analyzer : il s’agit d’identifier les chemins / structure de code selon les mesures McCabe, etc.


Outillages des tests unitaires :

Outils d’intégration continue :

  • MAVEN : outil logiciel libre pour la gestion et l’automatisation de production des projets logiciels Java. Il fourni un moyen de synchroniser des projets indépendants : publication standardisée d’information, distribution automatique de modules jar. En version de base, MAVEN peut dynamiquement télécharger du matériel sur des entrepôts logiciels connus. Il propose ainsi la synchronisation transparente des modules nécessaires.
  • ANT : idem que MAVEN
  • Continuum
  • CVS Subversion
  • JIRA

Les Framework de tests :

La démarche optimale pour entreprendre les tests unitaires est de mettre en place un « environnement préparé » (ou Framework) qui soit dédié. Dans le cas de développement de type Java, la combinaison parfaite est la synergie des outils ci-dessous :

  • Java : Environnement de développement intégré : Eclipse avec en son sein :
    • Outils de tests unitaires : Junit (Outils écris par le créateur de l’Xtrem programming Kent Beck), il permet de tester les développements de type Java
    • Génération de doc. : Javadoc
  • C# / .Net : NUnit
  • C++ : CPPUnit / CUnit
  • Fortran : fUnit
  • Delphi : DUnit

Les trois concepts de bases de Junit sont :

  1. Verdict : chaque test peut passer en VERT (pass ou OK) ou en ROUGE (fail ou NOK)
  2. Cas de test : détermine si une méthode produit les bons résultats pour un ensemble donné de valeurs passées en paramètres :
    1. Représenté par une méthode dans une classe de test
    2. Il y avoir autant de méthodes que voulu dans une classe de tests
    3. Il existe souvent une class de test correspondant à chaque class à tester (one to one)
  3. Tests suite : elle contient un ensemble de cas de test pour une classe

Les outils d’analyse de couverture des tests :

· Cobertura. Il peut produire :

o Le nombre de classes par paquetage

o Le pourcentage de lignes testées

o Le pourcentage d’expressions testées

o La liste des composants dont le test unitaire est en erreur (liste des anomalies par composant / services d’accès concernés)

· EMMA

· Clover

Outils de contrôle de code :

Checkstyle : Ce contrôle permet d’assurer un niveau bien défini de qualité de code source.

Les outils de reporting

Un reporting hebdomadaire est prévu et généré au travers de l’outil MAVEN.

Rapports à générer 1 : Tests unitaires en erreur

Ce rapport présente une synthèse de l’ensemble des tests et fait ressortir les éléments suivants :

Nombre de tests effectués

Nombres d’erreurs

Pourcentage de réussite

Rapports à générer 2 : Couverture des tests unitaires :

Outils de gestion des anomalies

Chaque anomalie rencontrée doit être remonté au travers d’un outil de gestion des anomalies. Ainsi, les anomalies sont intégrées dans l’outil au fur et à mesure des tests. L’analyse doit conduire à :

· La modification du test unitaire afin d’intégrer une évolution du code. La modification est réalisée développeur pour rejeu des tests

· La modification du code, si une régression est constatée. Le code source corrigé est re-livré pour rejeu des tests et clôture de l’anomalie si le test est validé

Quelques outils :

  • Mantis
  • BugZilla
  • Le module Defects de Quality Center (éditeur HP Mercury)

Rappel des bonnes pratiques dans les tests unitaires :

  • Utiliser absolument un framework
  • Interfacer le framework avec les outils
  • Ecrire les tests avant le code
  • Une classe = un test
  • Mettre les classes de tests dans le même package (et même répertoire) que les classes s’y rapportant
  • Le code des tests unitaires doit évoluer avec l’application et doit donc être maintenu
  • Le nom des classes de tests doivent comporter obligatoirement le mot TEST (pour les différencier facilement et Junit 3 retrouve ses classes ainsi)
  • Comme pour les tests fonctionnels automatisés pensez bien à remettre le système dans le même état que celui d’avant les tests (cette « remise en état » peut faire partie des actions de vos scripts de tests Selenium par exemple)
  • Comment réduire les temps de test :
    • Isoler les tests unitaires identifiés comme gourmand en temps (accès DB, concurrence…) et les exécuter moins souvent qu’à chaque compilation, exemple : avant chaque archivage du code source dans la base de code commune
    • N’exécuter que les tests unitaires concernant l’assemblage qui a été modifié et non pas l’intégralité

Pour rédiger cet article je me suis aidé de mes expériences mais aussi du retour de développeur et de certains sites comme (que je remercie pour leurs articles fort instructifs) :

Je vous conseil de vous y rapporter pour plus de détails sur le sujet.





Que sont les tests d’exploitabilité ?

5 04 2009

Définition des tests d’exploitabilité :
Dans une entreprise (E1), l’entité responsable des applications et SI est à 99,8% nommée « la production ». Sa responsabilité concerne le fait de s’assurer et surveiller que ces applications sont en ligne (pour des sites Web par exemple), soient accessible par les clients et que les commandes effectués par ces mêmes clients puissent arriver et être traitées par les gens de l’entreprise E1.
La plupart du temps les « gens d’la prod’ » sont totalement invisible au commun des mortels que nous sommes. Ils sont présents le jour et la nuit et restent plutôt invisible.
Si un jour vous les croisez vous pourrez les remercier pour leur travail car il n’est pas si facile et vraiment très peu valorisé dans la plupart des sociétés.

« Mais quel rapport avec les tests tonton MAT ? »

Et bien, depuis quelques années déjà, (a long long years ago – façon début de légende), « les gens d’la prod’ » ne sont plus seul ! Un service, se situant juste avant la production, est souvent en charge de TESTER les applications avant de les confier à la production. Ce service est souvent nommé « Exploitation, pré-exploitation ou pré-production » (cela dépend de l’entreprise).
Ce service est donc en charge de vérifier certains aspects des applications qui seront ensuite installées par le service « production ».
Pour comprendre les tests devant être effectués par l’exploitation il faut tenter de comprendre un peu plus le travail journalier des « gens d’la prod’ ».

La « production » est donc focalisée sur la disponibilité et la qualité des services qu’elle doit délivrer, tout en garantissant la capacité à prendre en compte les évolutions du SI. Elle est la garante de la « mise en production » des modules faisant partie du SI de l’entreprise, ainsi que de la surveillance de ces modules. Ceci au niveau, performance, disponibilité, sauvegarde, etc.

Il existe des indicateurs pour mesurer tous ces points à vérifier et surveiller. Ils sont mesurés par rapport à des métriques claires et cohérentes en ligne avec les besoins métier. La plupart du temps ces indicateurs se trouvent réunis dans un document nommé SLA (Service lLevel Agreement) ou OLA (Operation Level Agreement). Il existe des outils dédiés pour mesurer la performance de ces indicateurs, mais j’u reviendrai plus tard.

Pour surveiller ces indicateurs, la production s’appuie donc sur des processus clairement définis et adoptés (espérons le du moins) dont l’objectif est le même pour remplir ses missions. Les missions principales sont :
Maintien de la disponibilité des services

  • Piloter
  • Exploiter et administrer

Maintien de l’intégrité de l’infrastructure

  • Maintenir l’infrastructure
  • Intégrer en production
  • Supporter

Qualité et cohérence des processus

  • Manager
  • Mesurer et améliorer
  • Capitaliser

Assurer la mise en production de nouvelles applications
Ainsi, la préoccupation permanente de la production est la recherche de l’excellence opérationnelle. Pour l’obtenir, elle applique les quatre règles visant à garantir l’intégrité de son périmètre :

  • Tous les outils standards (ou défini comme tel) et uniquement les outils standards sont implémentés et utilisés
  • Tous les projets sont initialisés via un processus formel dans lequel la production intervient pour l’intégration en production
  • Seuls les systèmes testés techniquement sont sous la responsabilité de la Production
  • Faire face aux risques majeurs. Et pour cela établir un Plan de Retour à l’Activité (PRA)

our que ces quatre règles puissent être vraie il faut que le service « exploitation » tests plusieurs points avant que les applications ne passent dans le service « production ». La recette d’exploitation a donc pour rôle, en tant que partie de la recette technique, de vérifier et homologuer l’exploitabilité de la solution à mettre en œuvre et sa conformité aux normes d’exploitation instaurées par la production.

Ci-dessous je développe les différents types de tests d’exploitation. Il en existe surement d’autres ou bien certain de ces tests sont déjà pris en compte par la production. Quoiqu’il en soit ces tests doivent être réalisés. Et ceci, par le service que vous voulez !

Le périmètre des tests d’exploitation concerne les :

Tests de conformité aux normes d’exploitation :

  • Vérification de la conformité aux normes et standards d’exploitation des procédures et documentations
  • Vérification de la prise en compte des consignes d’exploitation et de support (gestion des incidents et gestion des problèmes)

Test du plan de production / plan de bascules :

  • Validation des documentations des plans de production
  • Recette du plan de production
  • Vérification des procédures de mise en production (change management)
  • Validation de l’ordonnancement

Tests des procédures de supervision :

  • Vérification de la conformité des messages d’erreur aux normes et standards
  • Tests de détection et de gestion des anomalies
  • Validation et diffusion des documentations applicatives et systèmes

Tests de robustesse :

  • Tests de charge
  • Crash test
  • Reprise de traitement
  • Mode dégradé

Tests des servitudes de production :

  • Recette des sauvegardes / restauration et procédures
  • Recette des purges, historisation et archivage ainsi que les procédures

Plan de Capacité :

  • Vérification de la mise à jour du plan de capacité
  • Vérification du trafic réseau et des classes de services

Tests du PRA (le plus sympa à tester)

Ci-dessous je détaille plus avant chaque test. Quand je parle de plan de tests je veux signifier que les tests sont tous rédigés et exécutés dans un référentiel de tests (TESTLINK, QUALITY CENTER, etc.). Si cela n’est pas le cas « c’est le mal ! ». Plaisanterie mise à part, TOUS les types de tests doivent être basés dans un référentiel de tests. Au final, tous ces types de tests représentent les exigences devant être pris en compte et à ce titre devenir des exigences de tests dans le référentiel de tests.
Bien entendu une stratégie des tests d’exploitabilité doit être définie (vous n’y échapperez pas bande de canaille !).
Mais voyez plutôt mes autres articles sur le sujet.

Tests de conformité aux normes d’exploitation :
Les normes d’exploitation regroupent les règles et conventions qui régissent :

Les normes d’exploitation regroupent les règles et conventions qui régissent :

  • L’installation d’une application en tant qu’ensemble de programmes permettant d’assurer une tâche ou une fonction particulière
  • Le nommage, la définition et l’installation d’un environnement en tant qu’instance d’une application avec ses différents composants (logiciels, interfaces, traitements, bases de données, etc.) s’inscrivant dans un contexte d’utilisation en relation avec la gestion de cette application : production, développement, intégration, recette, etc.
  • Le nommage et la définition d’un traitement ou d’un job (ou batch) en tant qu’opération automatisée (script, programme, etc.)
  • Les normes d’écriture des scripts (shell) lanceurs ou applicatifs
  • Le nommage et la définition d’une chaîne d’ordonnancement regroupant les traitements dans un ensemble cohérent et interdépendant (Crontable ou ordonnanceurs d’un éditeur)
  • La définition des interfaces en tant que flux entrant ou sortant d’une application
  • Les normes et définitions des sas de transfert en tant que lieu d’échange de fichiers inter-applications

Le plan de tests d’exploitabilité listera donc la conformité des points suivants :

  • Recette du dossier d’exploitation :
    • Schéma d’architecture technique de l’application
    • Nommage et description de l’arborescence applicative (binaires, données, logs, …)
    • Description et nommage des composants de l’application (serveurs, bases de données, logiciels, …)
    • Nommage des tablespaces, schémas et objets Oracle des SGBD de l’application
    • Identification et nommage des users applicatifs
    • Description des flux de l’application
    • Consignes de reprise
    • Description du fonctionnement en mode dégradé
    • Description des répertoires à purger, historiser et archiver (consignes, fréquences, rétention, …)
    • SLA de l’application

Recette du dossier d’ordonnancement :

  • Schémas des chaînes d’ordonnancement applicatifs
  • Description des chaînes job par job (batch ou chaine de batch)
  • Calendriers de planification des chaînes
  • Description des interfaces
  • Liste des codes retour
  • Description des cas d’erreur
  • Procédures de reprises
  • Gestion des logs

Recette du dossier de supervision :

  • Description des processus sensibles de l’application
  • Description et seuils de volumétrie des  tablespaces
  • Description et seuils de volumétrie des filesystems à surveiller
  • Consignes d’exploitation sur anomalies

Recette du dossier de sauvegarde :

  • Noms et description des polices de sauvegarde (arborescence, type, fréquence,  …)
  • Noms et descriptions des chaînes de sauvegardes (type, planning, rétention,…)
  • Schémas des chaînes de sauvegarde

Test du plan de production :
Le plan de production décrit et prépare le déploiement de l’application devant être installée dans le SI de E1. Il comprendra les composants applicatifs packagés sous une forme respectant les normes E1 et permettant un déploiement tel quel, quel que soit l’environnement concerné. La documentation fournie en phase de test d’exploitabilité sera complétée des éléments suivants :

  • Packages fonctionnels
    Check-lists de déploiement
    Dossiers d’installation
    Procédures de mise en œuvre en production
    Procédures et plannings de changements en production (formations, mise à jours contrats maintenance, …)

L’installation des composants cibles applicatif ou techniques de l’application sera réalisée conformément aux guides d’installation applicatifs fourni et / ou aux spécifications d’architecture.

Le plan de test du plan de production comprendra :

  • Validation des documentations de déploiement
  • Recette des check-lists de déploiement
  • Recette de la documentation d’installation
  • Tests des procédures de mise en œuvre en production
  • Validation des ordonnancements batchs (fenêtres de déclenchement, périodicité, temps de traitement, conformité de la gestion des codes erreurs, …)
  • Recette fonctionnelle de l’environnement

Tests des procédures de supervision :
Ils consistent à simuler des cas d’erreur construits selon les composants à superviser identifiés dans la documentation d’exploitation.
Ces tests ont pour but de vérifier la validité de la détection des anomalies et la conformité des messages d’erreur ainsi que la bonne application des consignes de gestion de ces anomalies :

  • Vérification de la conformité des messages d’erreur aux normes et standards
  • Tests de détection et de gestion des anomalies
  • Validation des consignes
  • Validation et diffusion des documentations applicatives et systèmes

Tests de robustesse :
En complément des tests de performance qui valident la conformité de l’application aux exigences de temps de réponse et d’optimisation système, les tests de robustesse doivent permettre de valider la conformité du comportement en charge de l’application aux exigences d’exploitation d’E1.

Les cas de tests permettront la restitution de l’ensemble des attendus recensés :

Tests de charge en mode nominal (utilisation CPU, I/O, volumétrie, …)

  • Reprise de traitement batch sur incident de production
  • Crash test (comportement et stabilité sur arrêt d’un serveur)
  • Temps de bascule sur instance Oracle passive
  • Performances en mode dégradé (max 50% en clustering sur perte d’1 nœud)

Tests des servitudes de production :
Les tests des servitudes de production tests le fonctionnement des sauvegardes/restauration et leur conformité avec les procédures et modalités décrites dans la documentation afférente.

Les cas de tests identifiés restitueront la couverture des exigences suivantes (informations figurants pour exemple – à adapter selon le contexte / projet / SLA de E1) :

  • Sauvegarde des données (schémas Oracle, documents GED, traces, etc.)
    Sauvegarde application (exécutables, fichiers de configuration, briques techniques, etc.)
    Sauvegarde système (création d’images du système d’exploitation vierge d’application, etc.)
    Sauvegarde Oracle à chaud en mode begin backup
    Sauvegardes SAN durée max 15 mm
    Durée de restauration données + application 2h max
    Durée de restauration système complet 8h max
    Validation de l‘intégrité des éléments restaurés

Tests de PRA :
Un Plan de Reprise d’Activité est mis en œuvre après un sinistre majeur (perte de salle machine, incendie, attentats, inondations et autres catastrophe naturelle ou d’origine humaine). Il doit permettre un retour à l’activité dans des délais définis. Souvent, ce retour ce fait en mode dégradé, de manière temporaire jusqu’au retour en mode normal (arrivée de nouveaux serveurs, réplication du SI effective, etc.).
Dans le PRA figure donc le RACI (le qui fais quoi, comment et quand ?) ainsi que les actions devant être mises en œuvres ainsi que leurs ordonnancement clairement définis, approuvés par tous les acteurs du PRA avec les procédures réellement appropriées par tous.

Certes, il n’est pas facile de tester l’intégralité d’un PRA mais néanmoins certaines situations doivent être répétées pour qu’il n’y ai aucune surprise pour aucun des acteurs dans les moments de crise – le PRA est là pour cela, sinon il ne sert à rien. Pour exemple, au moment de l’incendie (et inondation dans la foulée) du Crédit Lyonnais à Paris il y a quelques années, des pertes de données importantes ont été subies car ce type de risques / sinistres majeurs n’avait pas été assez pris en compte (entre autre).

Les cas de tests devront être choisis avec soins en ayant à l’esprit le ratio : risques / coûts / occurrence.

Par expérience, exécuter les tests de PRA quand tous les acteurs sont averties et sur le pont ne sert strictement à rien ! Pour cela, seul le DSI, le responsable de la production et un observateur externe doivent être au courant. Le résultat des tests sera ainsi très représentatifs de l’état de préparation et d’appropriation du PRA par les acteurs impliqués (et au final très amusant à vivre pour un consultant externe ;-).
Pour finir, il faut savoir que c’est souvent le service en charge de l’exploitation qui est en charge de développer et administrer les batchs, chaine de batch et autres ordonnanceurs. Ainsi, ils leurs incombent de développer et tester ces shells. Mais aussi d’administrer certaines plateformes et environnements. Cela dépend surtout de l’organisation de l’entreprise (E1).
Par conséquent, des tests spécifiques sont nécessaires pour vérifier et valider ces activités :
Tests de batch (des jobs et des jobstream) :

  • Tests unitaires – lancement, vérification du traitement désiré, vérification des fichiers log, traces, etc.
  • Tests d’intégration dans les plateformes et environnements

Tests de l’ordonnancement des batchs :

  • Tests unitaires
  • Tests d’intégration dans les plateformes et environnements

Tests des plateformes et environnements :

  • Installations des outils nécessaires
  • Création et paramétrages
Logique exploitation

Logique exploitation