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© 2015 nLiive. Tous droits réservés

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


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 !


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 fiablesans « tests en continu »


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


Le cycle du « test en continu »


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


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


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


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.


» Equipe QA (Quality Assurance) » Equipe métiers » Expert UX (User Experience)


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


La différence entre tests unitaires et tests fonctionnels 2

PL = Presentation LayerBLL = Business Logic LayerDAL = Data Access Layer


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.




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




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.


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 !


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.


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 » Expert UX (User Experience) » Marketing


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.


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

Software

Transcript of Avis d'expert : Les Tests Logiciels