3.36 Procédures-test

Ce chapitre contient les procédures de test

3.36.1 - Campagnes de test

Pour tout tester, il est nécessaire de réaliser plusieurs campagnes de test :

  • C1/ La vérification du build
  • C2/ Les tests du système sur le poste local
  • C2/ Les tests du système sur WSL

3.36.2 - C1 La vérification du build

Cette campagne vérifie que tous les éléments de build et de documentation sont présents :

  • 1/ mettre à jour les sources sur votre poste
  • 2/ supprimer le répertoire 1-conception\static\documentationgeneree
  • 3/ recompiler l’ensemble du projet en exécutant, depuis la racine du dépôt, la commande mvn clean install -P qualimetrie (sans skip ni -T 1C)
  • 4/ vérifier la bonne génération du site avec les répertoires : TODO à compléter

3.36.3 - C2 Les tests du système sur le poste local

Cette campagne vérifie le code Java pur à partir des scripts SH présents dans le répertoire 2-code/socle :

  • 0/ prérequis : être en mesure d’appeler les APIs SP
  • 1/ recompiler l’ensemble du code (répertoire 2-code)
  • 2/ démarrer l’ensemble des applications en exécutant, depuis le répertoire 2-code/socle, les commandes
. ./outils.sh PROXY TRUE
. ./demarrerTout.sh
  • 3/ exécuter tous les tests décrits au chapitre §3.36.5
  • 4/ modifier les URLs des APIs dans le code des applicatifs construits :
  • 5/ démarrer un serveur WEB simpliste exposant les applicatifs avec la commande npm run http-start
  • 6/ exécuter tous les tests décrits au chapitre §3.36.6

3.36.4 - C2 Les tests du système sur WSL

Cette campagne vérifie le code Java déployé via le projet IAS :

  • 1/ recompiler l’ensemble du code (répertoire 2-code)
  • 2/ démarrer les machines WSL (cf. §4.2.2)
  • 3/ démarrer tous les applicatifs (cf. §4.2.2)
  • 4/ mettre à jour la documentation des playbooks
    • Créer les images SVG en exécutant, dans la machine UbuntuAnsible, depuis le répertoire 2-code/ias/ansible, la commande for f in *.yml; do ansible-playbook-grapher --include-role-tasks $f; done
    • Copier les images générées dans le répertoire 1-conception\static\documentationgeneree\ias
    • Vérifier leur bon affichage dans la page
  • 5/ exécuter tous les tests décrits au chapitre §3.36.5
  • 6/ charger la base de données MongoDB en déclarant, avec l’application socle-admin toutes les démarches à tester
  • 7/ exécuter tous les tests décrits au chapitre §3.36.6
  • 8/ vérifier que la documentation est bien publiée et protégée par un mot de passe (compte lié au LDAP donc admin1/admin) quand on passe par le [https://admin.dev-psl.guillaumetalbot.com/documentation/](DNS d’administration)

3.36.5 - Tests du socle

Pour tester toutes les fonctionnalités importantes des services, il faut :

  • services et administration (cf. liens) :
    • service-registre :
      • accéder à l’IHM du registre
      • vérifier que 2 services sont présents (SERVICE-CONFIG et SERVICE-GATEWAY)
      • vérifier que 10 socles sont présents (SOCLE-ADMINPSL, SOCLE-DBBROUILLON, SOCLE-DBCONFIGURATION, SOCLE-DBDOCUMENT, SOCLE-DBNOTIFICATION, SOCLE-REFERENTIEL, SOCLE-REFERENTIELEXTERNE, SOCLE-SECURITE, SOCLE-SOUMISSION, SOCLE-TRANSFERT)
      • vérifier que les 12 composants ont un statut UP (colonne de droite)
    • service-admin
      • se connecter au service d’administration avec le compte admin1 (mot de passe admin)
      • vérifier que les 10 instances sont bien UP (si socle-dbnotification est en alerte, vérifier que le serveur de mail est bien démarré)
      • cliquer sur un applicatif socle-* (pas sur l’URL) pour afficher la liste des instances de cet applicatif
      • cliquer sur l’unique instance disponible de cet applicatif pour afficher la page de détails de l’instance
      • vérifier que la page Aperçus > Détails affiche bien la version de l’applicatif et les informations GIT (branche, commit et date)
      • vérifier que les valeurs affichées dans les pages Aperçus > Environnement et Aperçus > Propriétés de configuration sont toutes masquées
      • vérifier que la page Logging > Loggers permet bien de changer les niveaux de log (changer une valeur et vérifier qu’aucun message d’erreur n’apparaît)
      • ouvrir les logs de l’instance sélectionnée (un tail -f par exemple)
      • dans l’écran Aperçus > Environnement, cliquer sur le bouton Raffraîchir le contexte et confirmer
      • attendre quelques secondes pour voir le libellé du bouton changer en Contexte rafraîchi
      • vérifier que l’application a bien rechargé son contexte (logs Fetching config from server puis Discovery Client initialized)
    • service-nosql
      • démarrer MongoDBcompas et se connecter à la base de données NOsql
    • service-redis
      • éditer le fichier de configuration des logs de service-gateway (2-code\socle\services-cloud\service-gateway\src\test\resources\logback.xml dans les sources ou /psl/applicatifs/service-gateway/logback.xml dans WSL)
      • modifier le niveau de log de la classe org.springframework.cloud.gateway.filter.ratelimit.RedisRateLimiter en debug
      • arrêter puis redémarrer le service-gateway pour prendre en compte la modification de la configuration
      • surveiller les logs de la gateway avec la commande suivante tail -f log_service-gateway-1.log
      • depuis une autre ligne de commande, exécuter 30 requêtes HTTPs d’authentification anonyme par paquets de 5 simultannées avec la commande xargs -I % -P 5 curl -k -X 'POST' 'https://localhost:8080/socle/securite/public/authentificationAnonyme' -H 'accept: application/json' -d '' < <(printf '%s\n' {1..30})
      • vérifier, dans les logs, que la valeur X-RateLimit-Remaining fluctue
      • annuler (via git par exemple) la modification dans le fichier de configuration des logs
    • service_gateway
      • accéder à l’UI de swagger
      • vérifier que l’écran s’affiche sans erreur pour chacun des composants sélectionnables depuis la liste déroulante en haut à droite de la page
      • vérifier que la liste contient tous les micro-services du socle
      • sélectionner le composant socle-securite
      • exécuter une authentification anonyme
    • service-config (non testable manuellement mais est testé dans la collection de tests HTTP)
  • API :

3.36.6 - Tests des applications WEB

Pour tester les applicatifs WEB, il faut :

  • administration (cf. liens) :
    • socle-admin :
      • connexion :
        • accéder à l’IHM de l’application d’administration du socle
        • se connecter avec le compte admin1 // admin
      • Configuration démarche :
        • cliquer sur l’onglet Configuration démarche
        • sélectionner une démarche et une version
        • cliquer sur le bouton Modifier
        • modifier le JSON (un espace dans le titre de la démarche par exemple)
        • saisir un commentaire
        • cliquer sur le bouton Enregistrer
        • vérifier la présence d’une nouvelle version avec le commentaire et le nom de l’utilisateur
      • Configuration soumission :
        • cliquer sur l’onglet Configuration soumission
        • sélectionner une démarche, une version et configuration
        • cliquer sur le bouton Modifier
        • modifier le JSON (un x dans _nomFinalDuDocument par exemple)
        • saisir un commentaire
        • cliquer sur le bouton Enregistrer
        • vérifier la présence d’une nouvelle version avec le commentaire et le nom de l’utilisateur
      • transfert
        • cliquer sur l’onglet Transfert
        • vérifier la présence de télédossiers (sauf si l’environnement est vierge)
        • tester les filtres en fonction des données disponibles (à minima, vérifier l’absence d’erreur au clic sur le bouton Rechercher)
      • administration
      • déconnexion :
        • cliquer sur le login en haut à droite pour se déconnecter
    • Applications WEB
      • démarrer l’outil Cypress avec la commande npm run cypress depuis le répertoire 2-code/front
      • dans la fenêtre qui démarre, exécuter chaque campagne de test
    • Pile Elastic TODO

3.36.7 - FAQ

  • Pourquoi l’applicatif service-redis ne démarre pas en local ?
    • si la machine WSL UbuntuTest est démarrée, alors le package RPM Redis installé est déjà démarré (démarrage automatique).