La qualité logicielle et
l'intégration continue
Cas concret du projet Cytomine
Loïc Rollus (lrollus@ulg.ac.be), 11/09/2013
Présentation
Parcourir les outils d’aide au développement
utilisé pour Cytomine
●
●
●
●
●
●

Logiciel de gestion de versio...
Au commencement...
Au commencement...
Comment
●
●
●
●

synchroniser nos sources?
gérer les conflits entre fichiers?
faciliter et automatiser ...
Logiciel de gestion de versions
Ou VCS (Version Control System)
● Synchroniser le code source
● Résoudre les conflits
● Gé...
Logiciel de gestion de versions
Logiciel de gestion de versions
Comment
●
●
●
●

améliorer la robustesse du
code source?
détecter rapidement les
bugs?
évi...
Tests automatisés
● Code destiné à tester des méthodes, classes ou des
fonctionnalités complètes
● Détecter automatiquemen...
Tests automatisés
● Test unitaire: unité isolée (méthodes, classes,..)
Ex: tester la méthode qui vérifie l’adresse email d...
Tests automatisés
Pour Cytomine (Junit)
● Test unitaire: pour des librairies, dépendances,...
● Test “hybride” intégration...
Tests automatisés
Schéma classique d’un test
1.
2.
3.
4.

Préparation des données
Requête HTTP vers Cytomine
Analyse de la...
Tests automatisés
Schéma classique d’un test
Exemple: Ajout d’une annotation (zone sur l’image)

1. Préparation des donnée...
Tests automatisés
Exemple:
void testAddAnnotationCorrect() {
Annotation annotation = buildAnnotation()
HTTPClient client =...
Tests automatisés
Très utile pour les ACL (sécurité)
Exemple :
● Un utilisateur ne peut ajouter ou lire des annotations qu...
Tests automatisés
Tests automatisés
Comment
●

●

exécuter plusieurs
centaines de tests avant
chaque commit?
éviter d’oublier de les
exécute...
Système d'intégration Continue
●

Bamboo (alternatives: Hudson, Jenkins,...)

●
●
●

Vérifie tous les x temps (ex : 3min) ...
Système d'intégration Continue
Système d'intégration Continue
Système d'intégration Continue
s

Comment
●

évaluer la quantité de code
testé?
Couverture de code
● Cobertura
● Calcul la couverture des tests
Couverture de code
Couverture de code

Comment
●

évaluer la qualité du code (redondance, règles,...)?
Système de gestion qualité du code source
● Sonar (SonarQube)
● Application web
● Mesurer la qualité du code source en con...
Système de gestion qualité du code source
Système de gestion qualité du code source

Click
Système de gestion qualité du code source
Système de gestion qualité du code source
Système de gestion qualité du code source

Comment
● répertorier les bugs (test échoué,
plainte utilisateur,...)?
● assure...
Système de suivi de bugs
● Jira
● Gestion par tickets (bug, feature, task,...)
○ Ouvrir, Assigner, Résoudre, Clôturer, ......
Système de suivi de bugs
Environnement complet
Résumé
●
●
●
●

Logiciel de gestion de versions: Subversion et Git
Tests automatisés: JUnit
Framework d’intégration contin...
Tips
● Commencer dès le début du projet
● Test Driven Development
● Ne pas se focaliser (trop) sur les chiffres
Amélioration
● Améliorer la couverture des tests du serveur
● Tester l’interface web
● Tester les performances automatique...
Fin

?
S

I
T

N
O

U
Q

S
E
Prochain SlideShare
Chargement dans…5
×

La qualité logicielle et l'intégration continue - Cas concret du projet Cytomine

799 vues

Publié le

par Loïc Rollus et Benjamin Stevens, 11 septembre 2013

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
799
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
19
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

La qualité logicielle et l'intégration continue - Cas concret du projet Cytomine

  1. 1. La qualité logicielle et l'intégration continue Cas concret du projet Cytomine Loïc Rollus (lrollus@ulg.ac.be), 11/09/2013
  2. 2. Présentation Parcourir les outils d’aide au développement utilisé pour Cytomine ● ● ● ● ● ● Logiciel de gestion de versions Tests automatisés Framework d’intégration continue Système de gestion qualité du code source Système de suivi de bugs Wiki
  3. 3. Au commencement...
  4. 4. Au commencement... Comment ● ● ● ● synchroniser nos sources? gérer les conflits entre fichiers? faciliter et automatiser les backups? restaurer facilement une version précédente d’un ou plusieurs fichiers?
  5. 5. Logiciel de gestion de versions Ou VCS (Version Control System) ● Synchroniser le code source ● Résoudre les conflits ● Gérer les versions du logiciel ● Subversion (serveur, client web, …) ● Git (clients, scripts,...) Sujet de la précédente réunion des Geek Anonymes: http://geeksanonymes.argenco.ulg.ac.be/sites/default/files/slides% 20subversion%20and%20GIT.pdf
  6. 6. Logiciel de gestion de versions
  7. 7. Logiciel de gestion de versions Comment ● ● ● ● améliorer la robustesse du code source? détecter rapidement les bugs? éviter de tester manuellement? avoir une idée de la qualité du logiciel?
  8. 8. Tests automatisés ● Code destiné à tester des méthodes, classes ou des fonctionnalités complètes ● Détecter automatiquement et rapidement les bugs en les exécutant régulièrement ● Test Driven Development: écrire les tests puis implémenter les fonctionnalités
  9. 9. Tests automatisés ● Test unitaire: unité isolée (méthodes, classes,..) Ex: tester la méthode qui vérifie l’adresse email d’un utilisateur ● Test intégration: plusieurs composantes Ex: tester l’ajout d’un utilisateur dans la base de données ● Test fonctionnel: fonctionnalités complètes Ex: lancer le serveur et tester une fonctionnalité via un client
  10. 10. Tests automatisés Pour Cytomine (Junit) ● Test unitaire: pour des librairies, dépendances,... ● Test “hybride” intégration et fonctionnel ● Test fonctionnalités complètes ● Debug “facile”: même application donc 1 log, exceptions du serveur récupéré dans les tests, … ● Accès aux classes et fonctionnalités du serveur (DB, …)
  11. 11. Tests automatisés Schéma classique d’un test 1. 2. 3. 4. Préparation des données Requête HTTP vers Cytomine Analyse de la réponse HTTP Vérification
  12. 12. Tests automatisés Schéma classique d’un test Exemple: Ajout d’une annotation (zone sur l’image) 1. Préparation des données a. b. Création d’un projet et d’une image Création du JSON de l’annotation 2. Requête HTTP vers Cytomine a. POST HTTP sur l’URL /api/annotation avec le JSON de l’annotation 3. Analyse de la réponse HTTP a. Vérification du code HTTP (200) 4. Vérification a. Vérifier directement dans la DB si l’annotation est bien là
  13. 13. Tests automatisés Exemple: void testAddAnnotationCorrect() { Annotation annotation = buildAnnotation() HTTPClient client = initCytomineConnection() def result = client.post(“/api/annotation”,annotation.toJSON()) assert 200 == result.code int idAnnotation = result.data.id assert Annotation.read(idAnnotation)!=null } ● Tester aussi les listings, les modifications et suppressions. ● Tester aussi les “cas d’échec” (forme non valide, mauvais projet,...).
  14. 14. Tests automatisés Très utile pour les ACL (sécurité) Exemple : ● Un utilisateur ne peut ajouter ou lire des annotations que dans ses projets. ● Il ne peut modifier ou supprimer que ses annotations. ● L’admin cytomine peut tout faire 1. Critique 2. Difficile à tester manuellement a. Nombreuses fonctions : add, update, delete, read pour chaque type de domaine (Annotation, Projet,...) b. Nombreux rôles : Admin, utilisateur d'un projet, utilisateur du projet qui a créé l’annotation, utilisateur qui n'a pas accès au projet, anonyme => Effectuer la requête et vérifier le code HTTP 200 = succès, 401 = non authentifié et 403 = non autorisé
  15. 15. Tests automatisés
  16. 16. Tests automatisés Comment ● ● exécuter plusieurs centaines de tests avant chaque commit? éviter d’oublier de les exécuter?
  17. 17. Système d'intégration Continue ● Bamboo (alternatives: Hudson, Jenkins,...) ● ● ● Vérifie tous les x temps (ex : 3min) si le dépôt a été mis à jour En cas de mise à jour, Bamboo récupère les dernières sources Etapes : ○ Compile+Build+Run Cytomine OK ○ Compile+Run Test Envoyer un mail aux ○ Close Cytomine “responsables”
  18. 18. Système d'intégration Continue
  19. 19. Système d'intégration Continue
  20. 20. Système d'intégration Continue s Comment ● évaluer la quantité de code testé?
  21. 21. Couverture de code ● Cobertura ● Calcul la couverture des tests
  22. 22. Couverture de code
  23. 23. Couverture de code Comment ● évaluer la qualité du code (redondance, règles,...)?
  24. 24. Système de gestion qualité du code source ● Sonar (SonarQube) ● Application web ● Mesurer la qualité du code source en continu ○ ○ ○ ○ ○ Duplications de code Couverture de code par les tests unitaires Mesure le niveau de doc Règles du langage ...
  25. 25. Système de gestion qualité du code source
  26. 26. Système de gestion qualité du code source Click
  27. 27. Système de gestion qualité du code source
  28. 28. Système de gestion qualité du code source
  29. 29. Système de gestion qualité du code source Comment ● répertorier les bugs (test échoué, plainte utilisateur,...)? ● assurer le suivi de la qualité?
  30. 30. Système de suivi de bugs ● Jira ● Gestion par tickets (bug, feature, task,...) ○ Ouvrir, Assigner, Résoudre, Clôturer, ... ○ Organisation et gestion du temps ○ Discussions sur un ticket
  31. 31. Système de suivi de bugs
  32. 32. Environnement complet
  33. 33. Résumé ● ● ● ● Logiciel de gestion de versions: Subversion et Git Tests automatisés: JUnit Framework d’intégration continue: Bamboo Système de gestion qualité du code source: Sonar (Qube) ● Système de suivi de bugs: Jira ● Wiki: Confluence ● Subversion, Git, Junit et Sonar: gratuit ● Bamboo, Jira et Confluence: 10$/an par logiciel si projet non open-source (self-host, max 10 users, charity :-)...)
  34. 34. Tips ● Commencer dès le début du projet ● Test Driven Development ● Ne pas se focaliser (trop) sur les chiffres
  35. 35. Amélioration ● Améliorer la couverture des tests du serveur ● Tester l’interface web ● Tester les performances automatiquement (charge, stress, big data...)
  36. 36. Fin ? S I T N O U Q S E

×