Les tests de performance (2/3)

test

Dans cet article et le prochain, nous allons détailler chaque axe défini dans l’article précédent (Sauf ceux qui me paraissent assez clairs).

Les acteurs, rôles et responsabilités

Cette phase dépend, en grande partie, de la structure dans laquelle vous vous trouvez, de la complexité et de la taille du projet. En effet, sur un projet de grande taille, nous pourrons identifier au moins six acteurs :

  • L’intégrateur ou la MOE en charge de la réalisation du projet ;
  • L’info-gérant en charge de la fourniture des environnements d’exécution de l’application en adéquation avec l’architecture technique cible. Il aura aussi à sa charge la mise en place des différentes souches (exemple : Apache, Weblogic, …) ;
  • L’équipe technique, dédiée au projet ou transverse à un département mais dont la finalité est d’être proche des équipes projet pour accélérer les traitements, dont le rôle est d’assurer les installations, les réinstallations, les remises à 0 des plateformes dédiées aux tirs de performance ;
  • Les personnes chargées de dérouler les tirs à partir de scripts établis ;
  • Un représentant de l’équipe AMOA qui garantit que les scénarios définis sont conformes à de qui est attendu ;
  • La personne chargée du pilotage des différentes phases et qui coordonne toutes les actions avec les différents acteurs.

Définition des exigences

Les temps peuvent être déterminés par l’équipe Projet, plus précisément par l’AMOA, suite à un état des lieux des usages faits par l’application. Mais ils peuvent également être exigés par le métier. Par exemple, suite à la création d’un nouvel outil qui reprend des fonctionnalités existantes depuis un autre outil qui est en fin de vie, il est inconcevable pour les utilisateurs finaux que le nouvel outil offre des performances dégradées par rapport à l’ancien.

Il doit offrir, à minima, des temps de réponses équivalents à savoir meilleurs. (Même si le nouvel outil pourrait bien évidemment embarquer pour la même fonctionnalité une intelligence qui n’existait pas dans l’ancien).

Identification des scénarios impactant les principaux scénarios

Il s’agit de bien s’assurer, d’un point de vue fonctionnel mais aussi technique, de bien identifier tous les scénarios impactant d’autres scénarios mais dont l’exécution unitaire n’aurait pas permis d’identifier des problèmes de performance. Par exemple, un accès concurrent à une table d’une base de données par deux scénarios, existence de lock sur des tables…

Et voilà ! Nous verrons dans le prochain, et dernier article, l’identification du plan de charge, la définition des campagnes de tirs souhaitées ou encore le scripting des scénarios.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

9 + = dix