Cerberus est une application web open-source développée pour automatiser les tests dans des environnements variés et dans plusieurs langages, contribuant à maintenir une couverture fonctionnelle adéquate. Elle vise à intégrer des processus de test dès les phases de développement afin d'accélérer la qualification des livraisons et de limiter les risques liés aux mises en production. Des fonctionnalités avancées telles que l'automatisation, le pilotage de la recette, et l'intégration avec d'autres outils sont également mises en avant.

1. Cerberus

2. Qu’est-ce que c’est ?
Application web.
Développée à La Redoute en 2011 puis portée en Open source.
Code source et documentation disponible sur github et sourceforge :
https://github.com/cerberustesting
Près de 3900 commits par 15 contributeurs
Base des tests centralisées.
Automate multi-technologies
(Web, Application Mobile, Client Lourd, HTTP, SOAP, Rest, SQL…)
Multi-environnements (DEV, QA, UAT, PROD….)
Multi-langages (FR, UK, RU, IT, PL, …)

3. Présentation

4. D’où ça vient ?
• De la nécessité d’accélérer la qualification des livraisons
temps
risque
tempsItérations courtes
Itérations longues
 L’automatisation des tests est nécessaire dans une organisation qui tend à être agile.
Oui mais : Pas de tests automatisés = Pas de retour rapide = Risque accru à chaque MEP.
Evolution du risque de régression vs le nombre de mise en production
La méthodologie DevOps est une démarche visant à créer de la valeur
business en impliquant tous les acteurs du développement logiciel au
travers de courtes itérations et reconnais la valeur en étroite
collaboration, constitué d’expérimentation et de retour rapide.

5. D’où ça vient ?
• De l’expérience acquise lors de l’automatisation des premiers tests.
Le gain de productivité dû à l’automatisation peut rapidement se transformer en perte à cause de la maintenabilité
des tests.
La duplication des étapes de tests rend le maintien des tests long et fastidieux
 Mise en place de librairie de fonction de test, réutilisable par d’autres tests.
Le jeu de données se périme d’un projet à l’autre
 Définition des données centralisées et jeu de donnée récupéré dynamiquement.

6. D’où ça vient ?
• De l’apprentissage des échecs des premières mise en production.
Avec des tests réalisés uniquement côté développeurs, il y a un risque d’augmenter le nombre de tests sans
améliorer la couverture fonctionnelle.
Nombre de tests importants Mais les fonctions principale non couvertes
La couverture fonctionnelle vue par le développeur peut être limité.
 La définition de la couverture fonctionnelle doit être apportée par le métier.
100%
OK 404

7. D’où ça vient ?
• Du constat des limites d’une organisation classique dite « en silo ».
Habituellement rédigés après le démarrage des développements, les tests ne servent pas à la compréhension de ce
qui est attendu .
D’où un nombre important d’aller retour
Les tests rédigés après le démarrage du développement sont bien souvent inutiles aux développeurs.
 Les tests doivent être rédigé au plus tôt, idéalement en parallèle et en appui de la spécification
fonctionnelle.
Les tests doivent être utilisables dès leur rédaction, avant même d’être automatisé.
 Les tests peuvent être exécutés manuellement ou automatiquement et peuvent faire partir du
même rapport.

8. Pourquoi faire ?
Référentiel de test commun aux
différents acteurs du
développement.
Description en langage métier
Factorisation des librairies de tests
par les utilisateurs métiers
Standardisation de la rédaction des
tests
Automatiser les tests, quelque
soit la technologie.
Web (via Selenium)
Application mobile (via Appium)
Applis lourdes (sikuli)
Web-services (xml unit)
Databases (connecteurs sql - jdbc)
Constituer une librairie de
données de tests.
Création de jeux de test
centralisés
Automatisation de la génération
de la donnée de test
Piloter la recette
Tableaux de bord de suivi
d’exécution d’une campagne.
Analyse et diagnostique
Lien avec différents outils de
ticketing.

9. Métier / AMOA
Définition des cas de tests.
Exécution de tests manuels.
Pilotage de la recette.
Développement
Automatisation des tests.
Qualification / Recette
Automatisation des tests.
Animation de la démarche.
Exécution des tests.
Data management
Définition du jeu de données.
Validation de la gouvernance des
données.
Intégration / Production
Exécution des tests de non
regression.
Pourquoi faire ?
Les échanges autour des tests et des jeux de données se font au travers de Cerberus

10. Comment l’utiliser ?

11. Comment faire ?
La définition des cas de tests.
• Qui ?
Le métier, la maîtrise d’ouvrage.
• Où ?
Dans les champs « description » des cas de
test
• Comment ?
Suivant le cadre défini (Actions/Contrôles).
En utilisant les Données et Etapes de Libraires.
• Quand ?
Au plus tôt dans le projet.
Idéalement parallèlement à la spécification fonctionnelle.

12. Comment faire ?
L’automatisation des tests.
• Qui ?
Les développeurs, l’équipe de qualification.
• Où ?
Dans les champs « script » des cas de test
• Comment ?
Suivant le cadre défini
• Quand ?
Durant la phase de développement.
Au moment où l’on défini les interfaces utilisateurs.

13. Comment faire ?
La définition du jeu de données.
• Qui ?
Les développeurs, l’équipe IT.
• Où ?
Dans la librairie de donnée
• Comment ?
En définissant les règles de récupération de
la donnée.
Le jeu de données peut être fixe ou récupéré via SQL, WebService, CSV, HTTP….
• Quand ?
Durant la phase de développement.

14. Comment faire ?
L’exécution manuelle des tests.
• Qui ?
Tous les acteurs du projet.
• Où ?
Dans la page d’exécution de
Cerberus.
• Comment ?
Possibilité de définir le statut à chaque action
• Quand ?
Durant la recette.

15. Comment faire ?
L’exécution automatique des tests.
• Qui ?
Tous les acteurs du projet.
• Où ?
Depuis la page d’exécution de
Cerberus.
Ou via une API Rest
• Comment ?
Lancé depuis l’interface, ou depuis la chaine d’intégration.
• Quand ?
Durant la recette.

16. Comment faire ?
Le pilotage de la recette.
• Qui ?
Les développeurs, l’équipe de qualification, le métier.
Tous les acteurs du projet
• Où ?
Dans la page de rapport de Cerberus
• Comment ?
Suivi des statuts d’exécution.
Interfaçage avec les outils de ticketing (ouverture
automatique de ticket).
• Quand ?
Durant la phase de recette.

17. Et ça marche ?
La Redoute :
Sur le périmètre www.laredoute.xx (sur 10 pays) :
 4500Tests lancés 2x par jours.
 4 Mises en production par semaine pour chacune des applications.
Vélocité de création grandissante avec le temps (de part l’utilisation de librairie)
Evolution du périmètre des TNRs
Aout 2014
Démarrage du
nouveau site
180 Tests
Aout 2015
2000 Tests
Janvier 2016
2900 Tests
Janvier
2017
4500 Tests

18. Un autre usage
Le monitoring fonctionnel

19. Un autre usage : Le monitoring fonctionnel
Exécution de tests
fonctionnels
•(Exemple : 10 scenarii toutes les 5 minutes)
Capture des
données
techniques
•Temps de réponse par action
•Network Trafic au format HAR pour les application web
Exploitation des
données
•Exposition de service permettant d’alerter sur un status
KO
•Publication des données possible dans Elastic Search
/Kibana
•Business Activity Monitoring

20. Un autre usage : Le monitoring fonctionnel
Mettre sous contrôle les scenarii clés :
Homepage / Authentification / Creation de compte / Accès aux page principales / Page List / Page Produit /
Comparaison / Panier / Delivery / Paiement
A une fréquence pertinente :
Toutes les 5 minutes durant 21h
>> Soit environ 24.000.000 étapes annuelles pour 1 application
 Décorréler les coûts de mise en place du monitoring de la fréquence d’exécution permet d’éviter le
compromis coût versus qualité nécessaire.

21. Intégration de Cerberus dans le SI

22. Intégration de Cerberus dans le SI
Cerberus est capable d’interagir avec de nombreux outils du SI;
Oracle SQL
MySQL
PostGreSQL
DB2
Microsoft SQLServer
SSAS
Peut être déclenché par n’importe quel Scheduler.
• Via 1 api REST
• $U, cron, Jenkins….
• Exécution d’un test ou d’une campagne
Push vers Jenkins le statut d’exécution d’une campagne.
• OK/KO pour go/no go
Push vers ES/Kibana
Ouverture de ticket automatique.
• Dans Mantis ou Redmine
• Transmission des information du cas de test
S’interface à Centreon
Permet de lire et d’écrire dans tous type de base de données

23. Intégration de Cerberus dans le SI
Architecture
1 à n serveurs d’application
Actif / Actif
(Glassfish / Tomcat / Jboss)
Base de données
Actif/Passif
(MySQL / MariaDB)
1 à n robots
Selenium / Sikuli
(Pour les tests de GUI)

24. Intégration de Cerberus dans le SI
Architecture : Pour un bon POC
Caractéristiques technique :
1 VM (Linux)
8 vCPU
16 GB RAM
200 Go Espace disque
Applicatif :
MySQL (v5.6.xx)
Glassfish 4.1.1
Caractéristiques technique :
3 VM (Linux)
2 vCPU
4 GB RAM
10 Go Espace disque
Applicatif :
Selenium server
Firefox

25. Intégration de Cerberus dans le SI
Installation
Manuelle
Classique, un composant à la fois
Scripts disponibles dans le projet.
Automatisée
Grâce aux images et compositions Docker disponibles
https://github.com/cerberustesting/cerberus-docker

26. A venir…

27. Road Map 2017
https://github.com/cerberustesting/cerberus-source/issues
• Refactoring de l’interface graphique (95% Fait)
• Bootstrap
• Internationalisation
• « Pluginisation » des modules métiers et techniques
• Généricité
• Modularité
• Interfaçage avec Jmeter
• Centralisation des tests de charge
• Génération des JMX
• Pilotage des exécutions
• Gestion du versionning des Cas deTests
• Extensions des images et compositions Docker
• Déjà fait : ELK, Cerberus, Selenium
• A venir : Guacamole

28. Les contributeurs et utilisateurs
• Aujourd’hui, de multiples optimisations sont proposées par des contributeurs de plus en plus
nombreux.
Et parmi eux :