vertigo17 a écrit 7 commentaires

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).

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.

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.

Je connais mal HP QC mais j'ai le sentiment que c'est plus riche en terme de spécification des tests et gestion de campagne mais par contre ça ne permet pas un branchement à Selenium pour une automatisation complète.
Cerberus permet aussi de récupérer des jeux de donnée en dynamique (par SQL ou par appel SOAP) sur l’environnement ciblé de manière automatique pendant l’exécution du test.

Cerberus ne remplace pas les tests unitaires à intégrer dans le code et donc liés dans le même gestionnaire de version que l'application testée.
Mettre des tests dans un gestionnaire de source rend les choses bien plus technique pour des utilisateurs normaux.
L'objectif de cerberus réside plutôt dans des tests globaux fait à un niveau système accessible par des utilisateurs n'ayant pas ou peu de compétences informatiques.
Un site web est généralement constitué d'une multitude d'applications qui discutent entre elles (n couches front basé sur n couches back + plein d'appli tierces). Cerberus va tester de manière globale que tout fonctionne correctement.
Ensuite, malgré tout, dans Cerberus, chaque test peut être lié à une version du système testé. En cas d’évolution de ceux-ci, le test peut-être dupliqué et lié avec la nouvelle version ciblée. Cette notion de versionning est définie avec les utilisateurs de l'application et liée avec les nouvelles spécifications de l'application et donc leur impact sur les cas de tests.
Maintenant, le fait d'avoir les tests en base de donnée avec leur résultat, permet de faire des reporting bien plus propres que des solutions intégrées au code.

Si tu as des soucis sur l'installation, n’hésite pas à envoyer un message sur la mailling list et on t'aidera.
On a pourtant essayé de scripter toute l'installation et ce devrait donc être plutôt simple (lorsque tout va bien ;-)).
On a aussi prevu les mises à jour de structure de la base de donnée pour faciliter le passages aux futures versions.

Dans la section documentation du site, il y a les principaux écrans en capture.
Celui pour définir le test, le lancer et voir son resultat.

L'installation de l'outil est plutôt simple. Lance toi….