Avis d'expert : Les Tests Logiciels

1
Les tests logiciels
Comment mettre en place un processus de
« tests en continu » en ligne avec son usine logicielle ?
© 2015 nLiive. Tous droits réservés

2
Table des matières
3. Quelques Familiarités
4. Pas d’intégration continue fiable
sans « test en continu »
5. Les différentes typologies de
test
6. Le cycle du « test en continu »
7. Les tests unitaires : Tests au
niveau du code
8. Les tests d’intégration
9. Les tests fonctionnels : Tests au
niveau des composants métiers
10. Les tests d’UI : Tests au niveau
de l’interface graphique
11. La différence entre tests
unitaires et tests fonctionnels 1
12. La différence entre tests
unitaires et tests fonctionnels 2
13. Les tests de performance
14. Les tests de charge
15. Combien ça coûte ?
16. Le bug informatique le plus cher
de l’histoire !
17. La supervision applicative 1
18. La supervision applicative 2
19. Signature

3
Quelques familiarités !
« Avant, ça marchait ce bouton ; pourquoi ça
marche plus maintenant ?! »
« Mais, vous l’aviez pas corrigé ce bug-là ? Je ne
comprends pas ; plus vous codez, moins l’appli
fonctionne ?! »
La régression et les bugs sont catastrophiques
pour un projet, non seulement pour le temps
perdu à corriger, mais surtout pour l’image de
marque vis-à-vis de l’utilisateur final… Prenez-
les devants !

4
L’intégration continue se répand dans la plupart
des organisations aujourd’hui. Les usines
logicielles, qui permettent l’évolution constante
des applicatifs, automatisent
l’intégration de chaque builds
et leur mise en production. Les
tests logiciels doivent s’adapter
et s’intégrer à ces « usines »
afin d’assurer la qualité et
l’efficacité de ce processus.
C’est pourquoi nous parlons
de « tests en continu » ou
« continuous testing ».
Le « continuous testing » est le
fait d’automatiser et orchestrer
l’ensemble des tests logiciels à
tous les niveaux, on parle alors de
« Sofware Quality Assurance ».
La mise en place d’une couverture de tests
performante est un exercice complexe qui
nécessite d’être pris en compte le plus tôt possible.
Pas d’intégration continue fiable
sans « tests en continu »

5
La détection des bugs et des régressions peut avoir lieu à tous les niveaux et pour chaque type
de test :
Test « boite blanche » : une boîte blanche (White Box) est un module d’un système dont on peut
prévoir le fonctionnement interne car on connaît les caractéristiques de fonctionnement de
l’ensemble des éléments qui le composent. Autrement dit une boîte blanche est un module qui
comporte aussi peu de boîtes noires que possible.
Test « boite noire » : une boîte noire (Black Box) est un module d’un système dont on ne connait
pas le fonctionnement interne.
Les différentes typologies de test
*Plus généralement catégorisés dans « tests fonctionnels » au sens large

6
Le cycle du « test en continu »

7
Les tests unitaires :
Tests au niveau du code
• Qu’est-ce que c’est ?
Les tests unitaires ont pour objectif de valider
le code des composants de l’application. Ils ne
font pas appel aux bases de données (Mock).
• Comment sont-ils réalisés ?
Les tests unitaires sont écrits par les
développeurs. Ils sont réalisés avec des
frameworks de tests et sont inclus dans
l’environnement de développement
(IDE – Eclipse/Visual Studio/etc.).
Ils doivent :
»» Etre lancés le plus souvent possible,
idéalement à chaque build
»» Etre indépendants de l’environnement de
production et reproductibles (utilisation de
frameworks de Mock)
Aucune erreur ne doit être détectée avant de
synchroniser le code source : l’intégrité du build
est la priorité absolue.
Les parties-prenantes :
»» Développeurs

8
Les tests d’intégration
Les tests d’intégrations permettent de valider
que l’ensemble des modules développés
séparément interagissent correctement au sein
d’une solution.
Lors d’un déploiement sur un environnement
de « Staging* », ils garantissent l’intégration des
modules entres eux.
*Staging : un environnement de Staging est
un environnement idéalement identique à
l’environnement de Production (ISO-PROD)
mise en place pour des fins de tests (également
souvent nommé PRE-PROD/INTEGRATION/
TEST/etc.)
Les tests d’intégration sont écrits par
des personnes techniques en charge de
l’architecture de production.
»» Développeurs
»» Architectes techniques

9
Les tests fonctionnels :
Tests au niveau des composants métiers
Ils permettent de s’assurer que l’application
répond aux spécifications fonctionnelles et ce
en toutes circonstances.
Les tests fonctionnels sont écrits par des
personnes proches du métier de l’application.
Ils sont réalisés grâce à des outils « non-
techniques », en dehors de l’environnement de
développement.
Ils peuvent être faits directement au niveau des
composants métiers (sans solliciter l’interface
utilisateur) ou peuvent être réalisés dans
l’interface utilisateurs et seront alors couplés
avec les tests d’UI (User Interface).
»» Equipe QA (Quality Assurance)
»» Equipe métiers

10
Les tests d’UI :
Tests au niveau de l’interface graphique
Les tests d’UI sont effectués via l’interface
utilisateur et permettent de tester toute la
chaine d’interaction.
Comme les tests fonctionnels, les tests d’UI sont
écrits par des personnes proches du métier de
l’application.
Ils sont réalisés dans le contexte final
d’exécution (réel navigateur web) par des outils
pilotant la souris et le clavier.
Ce sont les tests les plus efficaces pour détecter
les régressions.
»» Expert UX (User Experience)

11
La différence entre tests unitaires et tests fonctionnels 1
Il est primordial de bien différencier les tests unitaires des tests fonctionnels :
»» Les tests unitaires ciblent les composants un à un et ne font pas intervenir de jeux de
données en bases de données
»» Les tests fonctionnels ciblent le système complet, intégrant l’utilisation de jeux de données en
bases de données

12
La différence entre tests unitaires et tests fonctionnels 2
PL = Presentation Layer
BLL = Business Logic Layer
DAL = Data Access Layer

13
Les tests de performance
Les tests de performance permettent de
mesurer individuellement les temps de réponse
des composants du système dans un contexte
d’usage normal.
Par exemple, dans un contexte Web, ce test
permet de mesurer les temps de réponse
des interactions utilisateur et de détecter les
ralentissements éventuels entre les versions.
Si l’on souhaite étendre les mesures de
performance au contexte particulier d’un grand
nombre d’utilisateurs simultanés, on parle alors
de test de charge.

14
Les tests de montée en charge (TMC)
Les tests de charge sont des tests de
performance particuliers où l’objectif est de
solliciter le système en charge.
Dans un contexte web, ce test va créer un
nombre d’utilisateurs prédéfinis afin de valider
la performance et la fiabilité de l’application lors
d’un pic d’affluence.
Il existe deux types de tests de charge :
»» L’injecteur de requêtes http, qui stresse le
serveur dans un environnement simulé
»» Le pilotage de réels navigateurs web
(Chrome, IE, Firefox), qui reproduit
l’ensemble du contexte et est beaucoup plus
fiable

15
Combien ça coute ?
La détection des bugs et leur correction est une
des activités les plus chères pour les équipes de
développement.
L’amélioration des processus de test se traduit
directement par une réduction de coût global et surtout
une meilleure image auprès des utilisateurs.
Par ce que le coût des tests représente entre 30% et
40% des coûts de développement, l’amélioration des
pratiques est un enjeu majeur.
La mise en place d’un processus de « tests en continu »
est une réponse possible et efficace.
Elle permet :
»» La réduction du temps de recette pour les équipes de
développement
»» La réduction des coûts de correction
»» L’amélioration de l’image pour les utilisateurs finaux
Dans le domaine du Web, des outils innovants arrivent
et simplifient grandement sa mise en place et son
utilisation au quotidien.

16
Le bug informatique le plus cher de l’histoire !
Ariane 5, vol 501, le 4 juin 1996 :
La fusée s’est brisée et a explosé en vol, 40
secondes après le décollage…
Le système de navigation, utilisé depuis
longtemps sur Ariane 4, étant réputé fiable, le
CNES a demandé de ne pas faire de tests pour
Ariane 5, et ainsi économiser 100 000$ ...
Finalement ce sont 370 millions qui partent en
fumée !

17
La supervision applicative 1
La mise en place d’un processus de
« continuous testing » vise à fiabiliser les
« mises en production », mais le cycle de contrôle de
la qualité ne s’arrête pas pour autant. Il est vital de
surveiller en permanence l’applicatif une fois déployé
en production et c’est ici qu’intervient la Supervision
Applicative.
La Supervision Applicative (monitoring actif) est
le fait de lancer continuellement des tests de
parcours utilisateur pour s’assurer de la fiabilité de
l’application en production.
Par opposition à l’utilisation de tags inclus dans les pages du site déclenchés par les internautes
réels (monitoring passif – analytics), la supervision applicative permet de détecter des problèmes
avant que des internautes réels ne les découvrent.
Toutes les mesures étant effectuées dans un contexte identique (même source géographique,
même opérateur, même navigateur, même ordinateur source), elle permet de mesurer de
manière fiable toutes les variations de comportement du site et donc d’anticiper les mesures à
prendre.

18
La supervision applicative 2
La supervision applicative valide le point de vue
de l’utilisateur final et il est donc primordial de
superviser l’application à l’aide de véritables
navigateurs afin de reproduire un contexte réel.
Ceci inclut la surveillance des requêtes externes
vers les « services tiers » (tags analytics, réseaux
sociaux, modules de paiement, Publicités, etc.).
L’impact des services tiers sur la performance
globale d’un site web en production peut être
très significatif et il est important de bien
monitorer tous les liens externes.
• Comment est-elle réalisée ?
A la différence des autres tests détaillés en
amont, la supervision applicative est gérée par
les équipes de production.
Les tests sont lancés directement sur
l’application dans son environnement de
production, et permettent aux équipes métiers
de maîtriser l’expérience utilisateur en continu.
»» Equipe de production
»» Marketing

19
Conclusion
La mise en place d’une réelle stratégie d’assurance qualité logicielle (Software Quality Assurance)
inclus non seulement la mise en place d’un processus de « continuous testing », mais également
un contrôle permanent de l’applicatif une fois déployé en production avec la mise en place d’une
solution de supervision applicative complémentaire.

20
Jean-Baptiste Marcé
Plus de 20 ans d’expérience et d’expertise
dans la conception et l’industrialisation de
développement logiciel.
De formation Ingénieur INSA (également
titulaire d’un Master 2), il a débuté sa carrière
à la DGA puis a évolué chez différents éditeurs
de logiciels (domaine de la santé, Webagencies,
e-business) où il a tenu successivement les
fonctions de chef de projet, d’architecte
technique et de directeur technique. Il a vécu
plus de 7 ans en Allemagne et a une véritable
ouverture sur l’international.
Véritable concepteur d’architectures complexes
évolutives et garant du cycle de vie des logiciels,
il a tissé un réseau professionnel conséquent.

Avis d'expert : Les Tests Logiciels

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Avis d'expert : Les Tests Logiciels

Similaire à Avis d'expert : Les Tests Logiciels (20)

Avis d'expert : Les Tests Logiciels