Nous sommes heureux d'annoncer la sortie de la version 1.0.0 de Cerberus. Pour mémoire, Cerberus est un outil de test pour les applications web, les applications back office et les tests d'infocentres et outils décisionnels.
Cette version majeure voit le jour suite à l'ajout de trois fonctionnalités :
- la gestion de campagne de tests, lien essentiel entre les cas de tests et la Release ;
- l'intégration de nouveaux frameworks de tests permettant des tester fonctionnellement des web services ;
- l'affichage en temps réel de l'exécution des tests (même lancés sur un serveur distant).
Cerberus entend porter la méthodologie du développement piloté par les tests (Test Driven Development), en mettant à disposition des acteurs du développement (depuis les phases de définition jusqu'à la validation, en passant par la phase de développement elle-même) un socle d'information fonctionnelle et technique commun.
Finie l'utilisation de deux outils distincts pour décrire les tests et automatiser ceux-ci : décrire un cas de tests revient à implémenter celui-ci (de part l'utilisation de bibliothèques de données ou de groupement d'actions). Cette façon de structurer l'information rends les tests bien plus facilement maintenables dans le temps.
Les tests peuvent être lancés par tous via l'application, ou en mode batch pour une campagne de tests par exemple (sur plusieurs queues, plusieurs navigateurs et plusieurs environnements simultanément). Les compte-rendus d'exécution s'accompagnent désormais du code source des pages testées et des logs Selenium (vue serveur et vue navigateur), en plus des captures d'écran pleine page, ainsi que des logs Cerberus sur chaque action. Cela permet l'analyse des résultats par plusieurs personnes et selon différents besoins.
Dans une prochaine version, nous intégrerons notamment une interface à framework de tests d'application mobile (Appuim), poursuivant notre stratégie de centraliser les tests quelques soient les technologies.
Aller plus loin
- Site officiel (1099 clics)
- Téléchargement sur SourceForge (60 clics)
- Sources sur GitHub (72 clics)
- Précédénte dépêche sur la version 0.9.1 (30 clics)
# intéressant !
Posté par maboiteaspam . Évalué à 3. Dernière modification le 16 juillet 2014 à 13:31.
Avoir tout cela out of the box, c'est vraiment cool.
Par contre,
le logo fait vachement entreprise. Moi j'ai cru à de la pub au début.
La doc pique les yeux, je n'arrives pas à lire http://www.cerberus-testing.org/images/testcase1-s.png
Tous les tests case passent forcément par l'interface web ? N'avez pas quelque chose comme le propose codeception ?
https://github.com/maboiteaspam/Codeception
L'interface web c'est bon pour les incapable du clavier, après, je crains que ce ne soit plus un boulet qu'une solution.
Et finalement, vous ne vous interfacez qu'avez selenium ?
[^] # Re: intéressant !
Posté par bcivel . Évalué à 3.
Merci de ton retour,
Tu marques un point pour la doc….Je vais mettre ça à jour prochainement.
L'interface web sert à éviter l'utilisation de plusieurs outils. Aujourd'hui, on à tendance à mettre dans la main du métier des outils pour centraliser les cas de tests fonctionnels. Les developpeurs piochent dans ce référentiel et implémentent les tests dans d'autres outils. Cela fait saisir en double ce qui peut être saisie une seule fois, et le fonctionel fini de toute façon par faire ses tests à la main puisqu'il n'a pas de vue sur les tests.
L'interêt de l'interface web dans ce cas est de partager la même vue (Chef de projet + Dev). De plus, pas besoin de développeur pour créer et utiliser des librairies de groupements d'actions. Un fonctionel un peu curieux à rapidement de quoi automatiser ses propres tests, et à les fournir directement aux developpeurs dans le cadre d'une commande d'un nouveau dev.
L'utilisation de l'interface semble à priori plus lourd d'un point de vue Developpeur mais si tu mets bout à bout toutes les actions de clarification dans le cadre d'une recette, c'est finalement plus efficace pour les deux parties.
Pour les tests de navigation, on ne s'interface qu'a Selenium pour le moment. On est en train de s'interfacer à Appium pour venir completer le scope. Cela sera probablement dans une prochaine release.
[^] # Re: intéressant !
Posté par duf . Évalué à 4.
Bonjour,
Même si mon domaine d'expertise est plutôt le test de performance, je fais parti de ceux qui accueillent avec bienveillance les IHMs web pour gérer des campagnes de tests (fonctionnels, sécurité, performance ou autre). A la manière d'ailleurs de ce qu'HP fait avec ALM. Je ne dis pas ça pour faire genre mais principalement pour donner un peu de sens à ma question. Sur votre site, dans la liste des fonctionnalités, il est indiqué la possibilité de générer des rapports d'exécution. C'est bien, mais dans ton exemple du "chef de projet + dev" il peut y avoir aussi d'autres besoins en terme de rapport.
On peut imaginer que le chef de projet doit présenter de manière hebdomadaire des rapports d'activité, d'avancement des campagnes de tests à un client, qui lui même le rapportera à son management lors d'une réunion mensuelle, ce qui à chaque fois modifie le type de rapport souhaité (on passe d'une vision micro à macro).
Au delà du rapport d'exécution, est-il prévu des rapports couvrant tout un tas de sujets (taux de conformité du code testé, taux de réécriture des cas de tests, taux de réécriture des scénarios de tests, taux de réécriture des livrables, etc.), ce genre de chose étant ce qui coûte du temps et des ressources humaines, donc de l'argent, il est souvent demandé de pouvoir afficher/justifier les durées/coûts des campagnes de tests.
Pour aller un peu plus loin, il est souvent intéressant d'obtenir des rapports généré à la demande sur des périodes données dans un format "statique" (type PDF), mais aussi des rapports plus dynamiques à la façon de tableau de bord (dashboard automatiquement mis à jour suivant les tests réalisés). Ce qui permet au client inquiet de son avancement de suivre à distance mais en temps réel les tests. Cela fait-il parti des choses prévus ?
Dernière question et là je reviens un peu plus à mon domaine (même si depuis le 1er juillet j'ai dit adieu à 11 ans de compétence sur les tests de performance pour faire autre chose :-) ), je vois qu'il est prévu de s'interfacer à Appium après Sélénium. Existe-t-il ou est-il prévu une API qui permette de mettre en place ce type d'interface sans être dépendant de votre intégration ? Concrètement existe-t-il des possibilités pour facilement s'interfacer avec des outils de tests type sécurité (metasploit) ou performance (tsung) pour utiliser votre IHM en tant qu'outil de pilotage/gestion des campagnes de tests/gestion documentaire/génération de rapports/etc. ?
Et vu qu'on est sur linuxfr ;-) : pourquoi la GPL et pas l'AGPL ?
Sinon bon courage pour la suite :-)
[^] # Re: intéressant !
Posté par maboiteaspam . Évalué à 3.
Au sujet de l'UI web, j'ai envie de dire non, de nier, d'être dans la négation ultime. Mon intuition.
Maintenant, je ne le ferais que lorsque j'aurais pu voir l'interface web, autrement se serait injuste.
J'espère que tu reposteras prochainement avec de nouvelles informations, car je dois bien dire que j'ai la flemme d'apprendre Java et ses subtilités pour déployer ta bête et faire un test (…).
Ceci dit, il y a des raisons techniques à ne pas s'interfacer avec phantomjs ?
Je me dit que peut être vous avez creusé la question et que cela m'intéresse.
Appium, je ne connais pas, j'irais regarder, très bientôt.
Merci pour le journal en tout cas.
[^] # Re: intéressant !
Posté par bcivel . Évalué à 1.
@duf
Merci pour tes proposition.
Effectivement, j'ai évoqué les rapports d'execution unitaire (utilisé pour comprendre ce qu'il s'est passé dans le cadre de tel ou tel test) mais il y a aussi des dashboards accessible en temps réel sur l'execution d'une campagne de test. Et l'on a branché un outils de reporting externe pour construire des dashboards plus facilement dans un premier temps. Ainsi, on pilote à la fois la qualité de l'application testée, mais aussi la qualité et la fiabilité des tests executés. On n'a pas pensé utiliser un rapport de "duplication de code de test", ce qu'on peut imaginer faire assez rapidement pour mesurer et forcer l'utilisation de la fonctionalité 'useStep' (utilisation d'une Librairie d'action plutôt que réécrire des tests identiques).
On le fait en popote interne pour le moment et on exposera ensuite les API et la doc pour l'utiliser via n'importe quel outil de reporting, voir on en integrera directement dans l'outil.
Pour ta dernière question, la cible est effectivement de s'interfacer au possible à d'autre outils. On favorise pour le moment un integration forte à Cerberus puisque l'enjeu et de rendre les tests rédigeable (et implementable) par un public fonctionnel. Maintenant, je ne connait pas les outils que tu cites, je commence par regarder et je te fait un retour plus précis si tu veux.
[^] # Re: intéressant !
Posté par bcivel . Évalué à 1.
@Maboiteaspam
Nul besoin de connaitre Java pour utiliser Cerberus, ni pour le déployer.
Ce n'est pas volontairement que l'on ne sait pas interfacé à phantomjs. Pas de raison technique, on n'a pas (encore) regardé.
Essaie de déployer et joues avec, c'est simple de prise en main. Cela ne révolutionera pas ta manière de bosser si tu gères à la fois la définition fonctionelle et le developpement de ton besoin, sur un environnement unique….
Par contre, si tu bosses avec une équipe qui spécifie ses besoins (pour le moment par mail,word ou outil de ticketing), avec tout le "no man's land" que ça implique (les pretexte du genre "j'ai pas pensé à ci", "j'ai oublié ça mais ça coulé de source"…), alors l'utilisation de Cerberus en interface avec eux te simplifiera grandement la vie. Tu l'utilises en complement de spec dans un premier temps, et en les accompagnant, c'est même eux qui implémenteront test tests.
[^] # Re: intéressant !
Posté par maboiteaspam . Évalué à 1.
bcivel, nous ne devons pas avoir les mêmes lunettes de lecture, même si nous donnons la même signification au fichier d'INSTALL de ton projet.
Je ne vois pas d'autres explication raisonnable à tes propos !
[^] # Re: intéressant !
Posté par duf . Évalué à 2.
Merci pour cette réponse. Pour les autres aspects ne t'embêtes pas, comme indiqué depuis le début du mois je suis passé sur un nouveau type de poste où mes compétences en tests de performance et expertise performance n'ont plus trop lieu d'être ni mes compétences en outils type ALM.
Par contre c'est un domaine qui m'a passionné (et nourrit) pendant 11 ans et j'avais commencé à écrire des idées pour une application du type ALM et qui justement ne soit pas limité par un type de tests mais qui puissent être une vraie solution ALM avec tous les aspects (pré-études, études applicatives, test fonctionnels, sécurité, performance, livrables, gestion des livraisons, etc.) de manière modulaire de sorte que ceux qui ne sont intéressés que par une brique puissent n'utiliser que cette brique. C'est donc avec grand intérêt que je regarde vos travaux et vois l'avancement à sa juste valeur (car pour avoir tenter d'écrire un début d'application dans le genre, c'est difficile :-) ).
Je vais donc suivre avec intérêts votre solution surtout que vous avez pour ambition à long terme de vous interfacer avec d'autres outils.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.