Vous êtes sur la page 1sur 4

TP 1.

Dfinition des spcifications d'exigences de logiciel


Spcification :
Processus qui dresse la liste de ce qui est attendu du systme, ainsi que les contraintes
sur lexcution du systme et son dveloppement
Requirement = besoin/exigence/spcification
Requirement engineering process :
Etude de faisabilit est-il techniquement et financirement faisable de construire le
systme ?
Elicitation et analyse des exigences quest-ce que les parties prenantes du systme
attendent du systme ?
Spcification des exigences - on dfinit les exigences en dtail.
Validation des exigences on vrifie la validit des exigences.

Fig. 1 Le processus de spcification


Source utile : http://www.exibri.com/blog/121-specification-type-template.html

TP 2. Dfinition des cas de test. Elaboration des scenarii de test.


BUT
Identifier les conditions de test et concevoir des cas de test
OBJECTIFS
- Raliser adquatement la planification, la conception et le suivi de toutes les activits de tests
logiciels dun projet ;
- Dvelopper et raliser les diffrentes phases de test ;
- Etre sensibilis aux rles et responsabilits respectives des acteurs dun projet informatique
- Connatre les principaux outils de test.
INTGRATION ET MISE EN PRATIQUE
- ralisation dun plan complet de test logiciel au dpart des documents relatifs la gestion
de projet ainsi qu lanalyse complte dun systme documentaire.
laboration dune stratgie de tests complte, en regard du planning et de lanalyse du projet.

TP 3. Vrification et Validation Test fonctionnel.


Apres la ralisation des cas de test, implementez-les et faites des conclusions
concernant ce qui marche et ce qui ne marche pas.
TP 4. Tests de logiciel avant de la livraison
Ces tests peuvent tre de plusieurs types, notamment :

Test de charge : il s'agit d'un test au cours duquel on va simuler un nombre d'utilisateurs
virtuels prdfinis, afin de valider l'application pour une charge attendue d'utilisateurs. Ce
type de test permet de mettre en vidence les points sensibles et critiques de larchitecture
technique. Il permet en outre de mesurer le dimensionnement des serveurs, de la bande
passante ncessaire sur le rseau, etc.

Test de performance : proche du Test de Charge, il s'agit d'un test au cours duquel on va
mesurer les performances de l'application soumise une charge d'utilisateurs. Les
informations recueillies concernent les temps de rponse utilisateurs, les temps de rponse
rseau et les temps de traitement dune requte sur le(s) serveur(s). La nuance avec le type
prcdent rside dans le fait qu'on ne cherche pas ici valider les performances pour la
charge attendue en production, mais plutt vrifier les performances intrinsques diffrents
niveaux de charge d'utilisateurs.

Test de dgradations des transactions : il s'agit d'un test technique primordial au cours
duquel on ne va simuler que l'activit transactionnelle d'un seul scnario fonctionnel parmi
tous les scnarios du primtre des tests, de manire dterminer quelle charge le systme
est capable de supporter pour chaque scnario fonctionnel et d'isoler ventuellement les
transactions qui dgradent le plus l'ensemble du systme. Ce test peut tenir compte ou non de
la cadence des itrations, la reprsentativit en termes d'utilisateurs simultans vs. sessions
simultanes n'tant pas ici un objectif obligatoire, s'agissant ici plutt de dterminer les
points de contention gnrs par chaque scnario fonctionnel. La dmarche utilise est
d'effectuer une monte en charge linaire jusqu'au premier point de blocage ou d'inflexion.
Pour dpasser celui-ci, il faut paramtrer mthodiquement les composants systmes ou
applicatifs afin d'identifier les paramtres pertinents, ce jusqu' obtention des rsultats
satisfaisants. Mthodologiquement, ce test est effectu avant les autres types de tests tels que
performance, robustesse, etc. o tous les scnarios fonctionnels sont impliqus.

Test de stress : il s'agit d'un test au cours duquel on va simuler l'activit maximale attendue
tous scnarios fonctionnels confondus en heure de pointe de l'application, pour voir comment
le systme ragit au maximum de l'activit attendue des utilisateurs. La dure du palier en
pleine charge, en gnral de 2 heures, doit tenir compte du remplissage des diffrents caches

applicatifs et clients, ainsi que de la stabilisation de la plateforme de test suite l'ventuel


effet de pic-rebond conscutif la monte en charge. Dans le cadre de ces tests, il est
possible de pousser le stress jusqu' simuler des dfaillances systmes ou applicatives afin
d'effectuer des tests de rcupration sur incident (Fail-over) ou pour vrifier le niveau de
service en cas de dfaillance.

Test de robustesse, d'endurance, de fiabilit : il s'agit de tests au cours desquels on va


simuler une charge importante d'utilisateurs sur une dure relativement longue, pour voir si
le systme test est capable de supporter une activit intense sur une longue priode sans
dgradations des performances et des ressources applicatives ou systme. Le rsultat est
satisfaisant lorsque l'application a support une charge suprieure la moiti de la capacit
maximale du systme, ou lorsque l'application a support l'activit d'une journe ou plusieurs
jours/mois/annes, pendant 8 10 heures, sans dgradation de performance (temps, erreurs),
ni perte de ressources systmes.

Test de capacit, test de monte en charge : il s'agit d'un test au cours duquel on va simuler
un nombre d'utilisateurs sans cesse croissant de manire dterminer quelle charge limite le
systme est capable de supporter. ventuellement, des paramtrages peuvent tre effectus,
dans la mme logique que lors des tests de dgradation, l'objectif du test tant nanmoins ici
de dterminer la capacit maximale de l'ensemble systme-applicatif dans une optique
prvisionnelle (cf.Capacity planning, Gestion de la capacit en franais).

Test aux limites : il s'agit d'un test au cours duquel on va simuler en gnral une activit
bien suprieure l'activit normale, pour voir comment le systme ragit aux limites du
modle d'usage de l'application. Proche du test de capacit, il ne recouvre pas seulement
l'augmentation d'un nombre d'utilisateurs simultans qui se limite ici un pourcentage en
principe prdfini, mais aussi les possibilits d'augmentation du nombre de processus mtier
raliss dans une plage de temps ou en simultan, en jouant sur les cadences d'excutions, les
temps d'attente, mais aussi les configurations de la plateforme de test dans le cadre
d'architectures redondes (Crash Tests).

Il existe d'autres types de tests, plus cibls et fonction des objectifs atteindre dans la
campagne de tests : Test de Benchmark (comparaisons de logiciel, matriels,
architectures...), Tests de non-rgression des performances, Tests de Composants, Tests
de Volumtrie des donnes, etc. tant entendu qu'en principe un type de test correspond
un type d'objectif, et que dans une matrice de couverture des tests les rsultats se recoupent
obligatoirement, il est rare (et coteux) de raliser lensemble de ces tests pour une
application donne.

Si l'application est dj en production, ou en phase pilote, on peut aussi, afin de connatre les
performances du systme, raliser une mtrologie, qualifie de surveillance de la production, qui
permettra d'observer dans le dtail le fonctionnement du systme sur la base d'actions relles des
utilisateurs. Les rsultats d'une telle campagne de mtrologie permettant de connatre les

fonctionnalits rellement utilises, et leur frquence d'utilisation, ils peuvent ensuite servir de
base pour orienter les tests raliser dans des simulations futures, ou servir de base une
solution de supervision de la production.

TP 5. Automatisation des tests (avec Selenium):


1. Prparez un plan de tests automatiques fonctionnels;
2. Gnrez les scnarios ;
3. Paramtrez les tests.

TP6. Utilitaire de rsolution des problmes lis la maintenance des logiciels


ou progiciels
Le dpannage et maintenance informatique : cherchez des solutions !