De l’eau a coulé sous les ponts pour Cerberus depuis la dernière annonce sur LinuxFr.org (2014). Pour rappel, Cerberus est une application Java/MariaDB en mode Web qui permet de gérer et concevoir des tests automatisés pour des applications sur technologies Web, natives en mode desktop, mais aussi sur mobiles iOS et Android. Cerberus permet également de faire des tests de services Web (SOAP, REST, JSON, mais aussi Apache Kafka sur des opérations de production et recherche d’événements dans des topics).
Cerberus fait partie des logiciels dits de Low code testing (test avec peu de code) et a pour objectif de mettre l’automatisation de tests dans les mains de personnes qui n’ont pas le temps ou les compétences pour écrire des tests dans un langage de programmation.
Pas besoin d’un IDE, d’un compilateur ni même d’une infrastructure de test. Il faut juste l’adresse URL de l’outil avec un identifiant et un mot de passe, et les premiers tests peuvent être créés et lancés simplement.
La version 4.7 ajoute principalement la capacité de contrôler le trafic réseau généré par l’application testée. Elle ajoute sur ce thème de nombreux rapports et tableaux de bord qui facilitent l’analyse des cas de tests.
La seconde partie de la dépêche détaille les fonctionnalités disponibles, mais elle explique également les enjeux et contraintes d’automatisation de tests pour l’analyse et les performances sur un site Web.
Depuis la version 0.9 de la dernière dépêche, de nombreuses versions se sont enchaînées pour arriver à une belle maturité de l’outil. À date, Cerberus permet de gérer son référentiel de tests avec gestion des environnements et variations de navigateurs. Vos tests peuvent être regroupés et structurés par exigence et intégrés dans des campagnes qui peuvent être lancées automatiquement via n’importe outil d’intégration continue (de type Jenkins).
Les notifications d’exécutions sont déclenchables par courriel ou via Slack. Les tests peuvent être « variabilisés » et les données de tests peuvent être récupérées et/ou générées à la volée.
Supporté par de nombreuses grandes entreprises qui l’utilisent massivement pour gérer la non‐régression de leur plate‐forme Web et de leur système d’information (du fait de ses nombreux connecteurs), l’outil a atteint progressivement une grande maturité, que ce soit en termes de fonctionnalités mais aussi en termes de stabilité et performance.
La version 4.7 met l’accent sur des fonctionnalités de contrôle de trafic réseau, de manière à permettre des tests pour l’analyse Web mais aussi la performance Web.
Bon nombre de sites sur Internet intègrent des outils tiers qui collectent des informations sur votre navigation et les transmettent à des tiers via des appels HTTP. Ces sites permettent l’exécution de JavaScript par ces partenaires et mettent à leur disposition des variables JavaScript qui peuvent être utilisées par ces tiers pour transmettre un certain nombre d’informations. Les variables ainsi mises à disposition constituent ce que l’on appelle un datalayer (couche de données).
Le moyen le plus simple pour tester que cette transmission d’informations fonctionne correctement consiste à reproduire le comportement d’un internaute et vérifier que l’ensemble de ces variables JavaScript au sein du datalayer sont correctement initialisées. L’automatisation de ces actions ainsi que la vérification est facilement accessible via Selenium par n’importe quel script ou langage (ou via Cerberus, bien sûr).
Le problème sur cette manière de tester est que l’on ne teste pas, stricto sensu, la transmission de l’information à un site tiers mais plutôt l’ensemble des informations (ou variables JavaScript) nécessaires à sa mise à disposition. C’est certes nécessaire, mais pas suffisant pour vérifier si la transmission d’information est, ou non, effectuée.
Pour permettre le test de l’appel externe (ou non‐appel), un module externe à Cerberus a été créé et intégré à l’outil : le Cerberus Executor.
Au lancement du cas de test, Cerberus va donner l’ordre à l’Executor de créer à la volée un serveur mandataire (proxy) dédié au test. Lors du lancement du navigateur, Cerberus (via Selenium) va demander au navigateur de pointer vers ce serveur mandataire, ce qui permettra d’intercepter l’ensemble des appels effectué par l’application testée. À tout moment pendant le test, l’historique des appels est alors disponible et accessible dans Cerberus via une structure JSON qui contient non seulement l’ensemble des appels dans le format HAR mais aussi une agrégation de ces appels. Cette structure JSON permet très simplement de récupérer par exemple le volume de données transmis, le nombre de requêtes par type de média ou encore par code retour.
Lorsque le test est terminé, Cerberus va sauvegarder et historiser la partie agrégée de ces appels de manière à construire des tableaux de bord dans l’optique de suivre leur performance.
La fermeture du serveur mandataire sera également faite à la fin de l’exécution.
Cette technique a l’avantage de permettre ces contrôles également sur des applications pour mobile de type iOS ou Android.
N’hésitez pas à tester l’outil et faire vos retours à la communauté qui se fera un plaisir de vous aider.
Aller plus loin
- Dépôt du code sur GitHub (88 clics)
- Site Web Officiel (208 clics)
- Démo (216 clics)
- Vidéo du journal des modifications (24 clics)
- Documentation (47 clics)
# Utilisation
Posté par barmic 🦦 . Évalué à 7.
Est-ce qu'il a un intérêt particulier quand on ne parle que d'API REST ? Ou est-ce qu'il n'est pas un peu gros pour cet usage ? Pour un projet sur le quel je travail, on a mis en place un simple petit outil dans nos sources qui prend en paramètre une collection de fichier yaml qui décrivent une requête et les vérifications à faire et une configuration d'environnement. C'est très simple à faire (l'outil n'est qu'une glue entre 3 bibliothèques : http, yaml et jsonpath), la description des cas de tests est simple et le versionnement se fait avec notre code (pour tester un environnement, on utilise la branche liée à cet environnement).
Est-ce que cerberus m'apporterait beaucoup ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Utilisation
Posté par Dring . Évalué à 5.
J'ai le même genre d'interrogation.
Mon expérience : tous les tests maintenus en dehors du code sont condamnés à devenir obsolètes et non maintenus. C'est pareil pour la documentation d'ailleurs. Plusieurs fois j'ai écris une petite application dédiée, et là cela a survécu plus longtemps, voire jusqu'à ce jour.
Autre point d'inquiétude : le passage par interface utilisateur web pour la conception des cas de tests. Cela permet certes à tout le monde d'en faire, mais niveau vitesse de rédaction, c'est l'enfer. Est-ce qu'on peut enregistrer une session utilisateur pour ensuite modifier le scénario là où c'est nécessaire, comme Selenium le permet de base ?
Enfin, même si ce n'est pas du code, on voit très rapidement que les non techniciens ne sont pas capables de générer des tests solides et pérennes. Et ne sont pas autonomes. C'est vrai également avec du Cucumber ; la personne avec la compétence fonctionnelle/métier doit forcément travailler en paire avec un technicien à l'aise avec l'outil de test, qui va le guider sur ce qui est possible/pas possible, lui créer des squelettes de tests, etc.
D'ailleurs, est-ce que Cerberus propose des ponts (import/export) avec d'autres outils de tests ?
[^] # Re: Utilisation
Posté par barmic 🦦 . Évalué à 3.
Je ne suis pas d'accord. Si ces tests font parti de ton flow d'intégration continue, je ne vois pas pourquoi ils ne seraient pas maintenu (puisque cela casserait ton build).
La démarche peut aller jusqu'à 3 amis même. La démarche BDD permet à un fonctionnel de lire et comprendre les cas de tests et donc aide énormément à leur maintiens. Et c'est une documentation plus accessible que le code de test pour le développeur. Enfin la mise à jour ou les ajouts de cas de tests peuvent être suffisamment simple.
Bref ça a du sens surtout dans une optique de DDD (oui ça fait beaucoup de *DD).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Utilisation
Posté par vertigo17 . Évalué à 2.
Je ne pense pas que les 2 s'opposent mais plutôt se complètent. Les tests unitaires dans le code ont effectivement la vertu de structurer le code et forcer les développeurs à développer de manière plus isolée. Ils sont effectivement nécessaires.
Par contre de mon experience, ils sont loin d'être suffisants pour valider le bon fonctionnement d'une application dans chaque environnement. Une mauvaise integration avec une autre application et l'application ne fonctionnera pas. Egalement certains test nécessitent des mock compliqués qui alourdissent les developments. Mieux faut alors se concentrer dans le code sur de l'unitaire et avec des outils de type Cerberus pour faire les tests d'integration.
L'outil est utilisé pour maintenir des campagnes de plusieurs centaines de cas de test lancés tous les jours sur plusieurs environnement par une équipe restreinte de 1 ou 2 personnes. Coté vitesse de redaction, l'interface graphique n'est pas vraiment une contrainte (des steps peuvent être réutilisés et variabilisés, tu peux faire des librairies d'objects également réutilisables dans plusieurs tests). D'experience également, l'enregistrement d'une session généré un scenario qui faute de structure et de commentaire devient effectivement vite incomprehensible. On peut rapidement le relancer certe mais quelques mois plus tard, au moment ou il commence à planter, on ne sais plus trop à quoi servait le test. Mieux vaut passer un peu plus de temps et le structurer et commenter pour garantir sa maintenance sur la durée.
Tu as raisons, comme tout outil et même s'il est plus accessible que la plupart des autres outils il nécessite une période de prise en main. Tout depend du niveau de technicité des fonctionnels mais ce genre d'outil ouvre la porte à pas mal d'entre eux.
Sinon, tu peux exporter/importer des case de tests en format json mais les tests étant exécutables n'ont pas trop d’intérêt à être basculé dans d'autres outils qui n'auraient pas les même capacités.
[^] # Re: Utilisation
Posté par Dring . Évalué à 2.
Les tests intégrés dans le code peuvent être bien plus que des tests unitaires, hein. Je parle d'écrire un programme qui simule des entrées/sorties complètes à une application puis permet de vérifier les résultats et de sortir un rapport d'erreur.
En gros, c'est Cucumber en refaisant l'outillage from scratch, et avec une syntaxe spécifique.
Dans le passé, j'avais même rendu ça accessible depuis l'application elle-même ; ça rajoutait un menu dans les versions hors-production pour tester sur les différentes bases de données.
[^] # Re: Utilisation
Posté par vertigo17 . Évalué à 3.
Disons que si tu n'as qu'un nombre limité de service et que ces services sont assez homogenes et en plus que ton outil simple te suffit pas de raison de chercher ailleurs ;-).
Maintenant dans les fonctionalités que l'outil peut t'apporter en natif tu as :
- gestion de multiples protocoles differents web, appli, service
- notifications slack ou email
- gestion des contraintes d'executions simultannées ou non de certaines executions (les executions peuvent être lancé au rythme que supporte ton application dans l'environnements correspondant par gestion de queue)
- dashboard pour suivre sur la durée le niveau de qualité des dev
- analyser les regression sur une campagne avec de nombreux test.
- Gestion et construction des données de test en dynamique.
et sans doute plein d'autre que j'oublie.
L'outil permet aussi aux non developpeurs de modifier et executer les tests simplements sans compilation, comit et besoin de deploiement.
# vs Selenium
Posté par ComputingFroggy (site web personnel) . Évalué à 1.
Selenium est cité mais j'aimerai en savoir un peu plus pour mieux comprendre ce que fait Cerberus (dont je n'avais jamais entendu parler … honte à moi) : quelles sont les différences entre Selenium et Cerberus ?
[^] # Re: vs Selenium
Posté par vertigo17 . Évalué à 1.
Tu peux considérer Cerberus comme étant une interface graphique en mode web à Selenium.
Le test est défini dans Cerberus qui au moment de l’exécution pilote Selenium (mais également potentiellement Appium ou Sikuli en fonction de la techno utilisée par l'application à tester).
Cerberus a besoin de Selenium pour automatiser des applications Web.
Cerberus en conséquence ajoute un peu d’intelligence à certaines actions Selenium de manière à rendre la lecture des tests plus lisible mais aussi leur exécution plus fiable (ex : retry automatique ou attendre qu'un élément soit visible avant d'interagir avec).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.