Atelier 1.

Description des besoins fonctionnels du projet :

o Besoins Fonctionnels :
Gestion des solutions IA :
 Les administrateurs doivent pouvoir créer, modifier, et supprimer des solutions via une
interface d'administration.
 Les utilisateurs doivent pouvoir consulter la liste des solutions disponibles, voir les
détails d'une solution spécifique.
Gestion des blogs :
 Les administrateurs doivent pouvoir créer, modifier, et supprimer des blogs.
 Les utilisateurs doivent pouvoir consulter les blogs publiés et accéder à plus de détails
sur chaque blog.
Gestion des offres d'emploi :
 Les administrateurs doivent pouvoir créer, modifier, et supprimer des offres d'emploi.
 Les utilisateurs doivent pouvoir consulter les offres d'emploi et postuler directement à
une offre via un formulaire de candidature.
Postulation aux offres d'emploi :
 Les utilisateurs doivent pouvoir postuler à une offre d'emploi via un formulaire qui
inclut le téléchargement du CV et des informations personnelles (nom, prénom, email,
description, expérience).

o Besoins Non Fonctionnels :

Performance :
 Le système doit répondre rapidement aux requêtes des utilisateurs (tant pour la
consultation des données que pour la soumission de formulaires).
 Les temps de chargement doivent être optimisés pour offrir une expérience utilisateur
fluide, même avec un grand volume de contenu (blogs, solutions, offres).
Maintenance et support :
 Le code back end et front end doit être bien structuré et documenté pour faciliter les
futures maintenances et évolutions.
 L'application doit supporter des mises à jour sans perturber le fonctionnement en
production.
Disponibilité et fiabilité :
 L'application doit être disponible en permanence (haute disponibilité) avec un
minimum d’interruptions pour maintenance.
 Les données doivent être correctement sauvegardées pour éviter toute perte (offres
d'emploi, solutions, blogs).
 o Outils de test :

Les tests unitaires et fonctionnels de l'API de blogs ont été réalisés à l'aide de deux
outils principaux :

1. Jest :

Est un framework de test JavaScript développé par Facebook. Il offre de nombreuses

fonctionnalités pour faciliter l’écriture et l’exécution des tests, notamment :

 Tests unitaires et d’intégration : Jest permet de tester des fonctions et des

composants individuellement ou en intégration.
 Mocking : Jest facilite le remplacement de fonctions ou de modules pour
isoler les tests.
 Sanpshots : Jest permet de capturer et de comparer l’interface utilisateur ou
l’état d’un composant au fil du temps.
 Rapport de couverture : Jest fournit des statistiques sur le code testé et non
testé.

2. Supertest :

Est une bibliothèque de test pour les applications HTTP, souvent utilisée avec Node.js. Elle
permet de tester les API REST de manière simple et fluide. Ses principales caractéristiques
incluent :
 Tests HTTP : Supertest permet d'émettre des requêtes HTTP et de vérifier les
réponses.
 Syntaxe fluide : Supertest utilise une syntaxe intuitive pour écrire des tests,
facilitant la lecture et la compréhension.
 Intégration avec des frameworks de test : Supertest fonctionne bien avec
Jest et d'autres frameworks de test pour exécuter des tests de bout en bout.

 L'utilisation conjointe de Jest et de Supertest a permis de mettre en place un

environnement robuste pour tester l'API de blogs, garantissant ainsi sa fiabilité et sa
fonctionnalité.
 Atelier 2. Elaboration d’un plan de tests fonctionnels :

Plan de test pour la gestion des solutions :

Niveau de test : Intégration
Type de test : Fonctionnel

Cas de tests Résultats attendus Validé(oui/non) Observations

Créer une solution 201 (Created) Oui La solution a été créée

avec succès
Retourner 400 si les 400(Bad Request) Oui Fonctionne
champs requis sont correctement pour les
manquants champs manquants
Obtenir toutes les 200(Ok) Oui Renvoie toutes les
solutions solutions

Obtenir une solution 200(Ok) Oui Renvoie la solution

par ID correcte.

Retourner 404 si la 404(Not Found) Oui Fonctionne

solution n’est pas correctement pour une
trouvée ID invalide
Mettre à jour une 200(Ok) Oui Mise à jour de la
solution solution réussie.

Supprimer une solution 200(Ok) Oui Suppression réussie.

Gérer les opérations Tous les test devraient Oui Les tests s'arrêtent
asynchrones s’arrêter immédiatement correctement après
après l’exécution l'exécution
EXPLICATION :
Le résultat montre que tous les tests unitaires de l'API des solutions ont été réussis, confirmant
que les différentes fonctionnalités (création, lecture, mise à jour, suppression de solutions)
fonctionnent comme prévu. Cependant, Jest signale un problème : une opération asynchrone,
comme une connexion à la base de données, n'a pas été fermée correctement, empêchant Jest
de s'arrêter automatiquement.
 Ces tests relèvent des *tests d'API* de type *unitaire* qui vérifient individuellement
chaque endpoint de l'API. Leur objectif est de garantir que chaque fonction de l'API
réagit correctement aux requêtes HTTP en retournant les réponses et les
statuts attendus.
EXPLICATION :
Le fait que les tests passent indique que le composant CreateSolution est correctement
configuré pour afficher des alertes appropriées lors de la soumission d'un formulaire vide et
lors de la soumission réussie.
Robustesse : La réussite de ces tests montre que votre composant est robuste et gère les cas
d'erreur de manière appropriée, ce qui est essentiel pour une bonne expérience utilisateur.
 Plan de test pour la Gestion des blogs :

Niveau de test : Intégration

Type de test : Fonctionnel

Cas de tests Résultats attendus Validé (Oui / Non) Observations

Créer un blog avec Le blog est créé Oui Test réussi

toutes les avec succès et un
informations message de
requises confirmation est
renvoyé
Tenter de créer un Erreur 400: Les Oui Test réussi
blog sans le champ champs requis sont
date manquants
Obtenir tous les Retourne une liste Oui Test réussi
blogs de blogs avec un
statut 200
Obtenir un blog par Retourne le blog Oui Test réussi
ID correspondant avec
un statut 200
Mettre à jour un Le blog est mis à Oui Test réussi
blog existant jour avec succès et
un message de
confirmation est
renvoyé
Tenter de supprimer Le blog est Oui Test réussi
un blog supprimé avec
succès et un
message de
confirmation est
renvoyé
Tenter de supprimer Erreur 404: Blog Oui Test réussi
un blog avec un ID non trouvé
inexistant
Vérifier la gestion Messages d'erreur Oui Test réussi
des erreurs pour des appropriés pour
entrées invalides chaque cas
Vérifier que les Les données sont Oui Test réussi
données sont correctement
persistées dans la enregistrées et
base de données récupérées
 Le test "should return 400 if required fields are missing" échoue car les champs requis
ne sont pas spécifiés comme "required".
 Après avoir ajouté le mot-clé "required" pour les champs obligatoires, le test
"should return 400 if required fields are missing" passe.
 Tous les autres tests fonctionnels de l'API de blogs passent également,
indiquant que l'API fonctionne correctement.
 Le message d'avertissement sur les opérations asynchrones n'est plus présent,
ce qui suggère que le problème a été résolu.
 Plan de test pour la Gestion des offres d'emploi :

Niveau de test : Intégration

Type de test : Fonctionnel

Cas de Tests Résultats Attendus Validité Observations

Devrait créer une 201 Created avec un Oui Test réussi , l’offre
offre d'emploi message de succès d’emploi a été
créée.
Devrait retourner 400 400 Bad Request Oui Test réussi , retour
si des champs requis correct pour
sont manquants champs manquants.
Devrait récupérer 200 OK avec une Oui Test réussi, toutes
toutes les offres liste d'emplois les offres d’emploi
d'emploi récupérées.
Devrait récupérer une 200 OK avec les Oui Test réussi , l’offre
offre d'emploi par ID détails de l'offre d’emploi récupérée
par ID.
Devrait retourner 404 404 Not Found Oui Test réussi, retour
si l'offre d'emploi correct pour ID non
n'est pas trouvée existant.
Devrait mettre à jour 200 OK avec un Oui Test réussi, l’offre
une offre d'emploi message de succès d’emploi a été mise
à jour.
Devrait supprimer 200 OK avec un Oui Test réussi, l’offre
une offre d'emploi message de succès d’emploi a été
supprimée.
EXPLICATION :
L'API de gestion des offres d'emploi a réussi à créer, récupérer, mettre à jour et supprimer des
offres avec succès, comme l'indiquent les codes de statut HTTP appropriés. Cependant, le test
de validation des champs requis a échoué, signalant un problème dans la gestion des erreurs
lorsque des données essentielles sont manquantes. Il est nécessaire d'améliorer la logique de
validation pour garantir que l'API renvoie une erreur 400 en cas de champs manquants.

Atelier 3. Travail de recherche : outils de test statique :

o L’outil statique SONARQUBE :

Est une plateforme open-source utilisée pour l'inspection continue de la qualité du code. Elle
aide les développeurs à gérer la qualité de leur code grâce à une analyse statique automatisée.
SonarQube permet d'identifier des code smells (mauvaises pratiques), des bugs, des
vulnérabilités de sécurité, et des duplications de code, tout en s'assurant que le code respecte
certains standards de qualité.
o Caractéristiques principales de SONARQUBE :

1. Analyse statique du code : SonarQube prend en charge de nombreux langages de

programmation (Java, JavaScript, Python, C#, PHP, etc.) et analyse le code source
pour détecter des problèmes comme des bugs, des vulnérabilités de sécurité, et des
code smells.
2. Intégration continue : SonarQube s'intègre facilement avec des pipelines
d'intégration/déploiement continus (CI/CD) comme Jenkins, GitLab CI ou Azure
Pipelines. Cela garantit que la qualité du code est surveillée en continu à chaque
nouveau commit.
3. Quality Gates (portes de qualité) : SonarQube permet de configurer des quality
gates, qui sont des seuils que le code doit franchir avant d'être considéré prêt pour le
déploiement. Les quality gates donnent un statut de validation ou d'échec basé sur des
critères prédéfinis comme le nombre de bugs ou la couverture de tests.
4. Vulnérabilités de sécurité : SonarQube inclut des règles spécifiques pour identifier
des failles de sécurité potentielles (par exemple, injection SQL, cross-site scripting).
La plateforme fournit des recommandations détaillées pour remédier à ces
vulnérabilités.
5. Calcul de la dette technique : SonarQube estime la "dette technique", qui correspond
à l'effort requis pour corriger tous les problèmes identifiés. Cette métrique aide à
prioriser les tâches de maintenance du logiciel.
6. Support étendu des plugins : Il existe une large variété de plugins pour intégrer
SonarQube avec des outils de construction, des environnements de développement
(Eclipse, IntelliJ IDEA) et des systèmes de suivi de problèmes (comme Jira).
7. Tableau de bord et rapports : SonarQube offre un tableau de bord détaillé et des
outils de reporting permettant de suivre la qualité du code au fil du temps, de
visualiser les progrès et de partager les résultats avec les parties prenantes.
EXPLICATION DE RESULTAT DE SONARQUBE :

Les résultats affichés sur SonarQube donnent un aperçu de l'analyse de votre projet React
Node. Voici une explication des différentes sections et des valeurs que vous voyez :
1. Security :
Open issues: 0 : Il n'y a pas de problèmes de sécurité ouverts dans le code de votre projet.
Cela signifie que votre code ne présente pas de vulnérabilités ou de failles de sécurité
identifiées par SonarQube.
Accepted issues: 0 : Il n'y a pas de problèmes de sécurité que vous avez validés comme étant
acceptables.
2. Reliability :
9 Open issues : Il y a 9 problèmes de fiabilité dans votre code. La fiabilité se réfère à la
probabilité que le code fonctionne sans erreurs ni pannes. Ces problèmes peuvent être liés à
des bugs potentiels ou à des pratiques de codage qui réduisent la robustesse de votre
application.
Note : A : Même avec 9 problèmes ouverts, votre code obtient une note "A", ce qui indique
que le niveau global de fiabilité est considéré comme bon.
3. Maintainability :
22 Open issues : Il y a 22 problèmes de maintenabilité. Ces problèmes concernent la
complexité du code, sa lisibilité, ou les bonnes pratiques de développement qui facilitent les
modifications futures.
Note : A : Malgré ces problèmes, votre code est toujours jugé très maintenable, ce qui signifie
que les problèmes détectés ne sont probablement pas critiques.
4. Coverage :
0.0% : Cela indique que le code n’est pas couvert par des tests unitaires ou que SonarQube ne
parvient pas à détecter la couverture des tests. Une couverture de 0% est un indicateur que le
projet pourrait manquer de tests automatisés, ce qui pourrait affecter la fiabilité et la sécurité à
long terme.
579 lines to cover : Il y a 579 lignes de code qui devraient être couvertes par des tests
unitaires, mais aucune ne l’est actuellement.
5. Duplications :
6.8% : Cela signifie que 6,8% de votre code (soit environ 3,9k lignes) est dupliqué. Les
duplications de code peuvent entraîner des problèmes de maintenabilité, car il devient plus
difficile de maintenir plusieurs copies du même code à jour en cas de modification.
La présence de duplications est signalée par un indicateur rouge, ce qui signifie qu'il s'agit
d'un point d'amélioration prioritaire.
6. Security Hotspot :
*Hotspot : Il y a un hotspot de sécurité identifié. Les hotspots sont des sections du code qui
peuvent potentiellement poser un risque de sécurité, mais qui nécessitent une vérification
manuelle pour évaluer s'ils sont réellement vulnérables ou non. L'indicateur "E" montre que
c'est un point critique à vérifier.
Analyse Générale
A dans la sécurité et la fiabilité signifie que ces aspects sont bien gérés dans votre projet.
B pour la maintenabilité indique qu'il y a encore des améliorations possibles, mais la situation
est globalement bonne.
Couverture des tests (0%) et Duplication (6.8%) sont des points d'attention, surtout si vous
souhaitez améliorer la qualité du code à long terme.
Prochaines étapes recommandées
Augmenter la couverture des tests : Ajouter des tests unitaires pour améliorer la couverture et
garantir que les fonctionnalités sont correctement testées.
Réduire les duplications : Refactoriser le code pour minimiser les duplications, en utilisant
des fonctions ou des modules réutilisables.
Vérifier les hotspots de sécurité : Examiner le hotspot de sécurité détecté pour confirmer s'il
s'agit d'un vrai risque et, le cas échéant, y remédier.
En résumé, votre projet a une base solide, mais il y a des domaines (comme la couverture de
tests et la duplication) qui nécessitent de l'attention pour maintenir et améliorer la qualité
globale du code.
EXPLICATION :

*Security Hotspots Reviewed: Le projet a 0.0% des points chauds de sécurité passés en revue.

*Review priority: La priorité de révision est "Medium", ce qui signifie que la révision de ces
points chauds de sécurité a une priorité moyenne.

*Vulnerability détectée: Le point chaud de sécurité détecté est "Denial of Service (DoS)". Ce
problème est lié à l'utilisation d'un regex vulnérable qui pourrait entraîner un déni de service
dû à un backtracking.

* Analyse du code: Le code affiche une fonction "truncateContent" qui tronque le contenu en
fonction de la longueur. Cette fonction est utilisée pour gérer le problème de déni de service
détecté.
EXPLICATION :

*Refactoring recommandé : Le rapport indique qu'il faut refactorer ce code pour ne pas
imbriquer les fonctions plus de 4 niveaux de profondeur, conformément à la règle
"javascript:S2004" de SonarQube.

*Impacts sur la maintenabilité : L'analyse montre que ce problème d'imbrication des fonctions
a un impact sur la maintenabilité du code.

*Localisation du problème : Le problème se trouve dans le fichier

"frontend/../admin/AdminBlogs.js", aux lignes 38 à 50.

*Détails du code : Le code problématique semble gérer la suppression d'un blog, avec des
appels à des fonctions imbriquées.
EXPLICATION :

*Recommandation sur les éléments non interactifs : SonarQube recommande d'éviter d'utiliser
des éléments HTML non natifs pour les interactions, et d'ajouter un rôle et un support pour le
clavier, la souris et les entrées tactiles.

*Problème d'intentionnalité : SonarQube a détecté un problème d'intentionnalité pour deux

règles :

=>Visible, non-interactive elements with click handlers must have at least one keyboard
listener"

=>Do not use Array index in keys"

*Impacts sur la qualité du logiciel :

=>Maintenabilité : Le problème "Do not use Array index in keys" a un impact sur la
maintenabilité.

=>Accessibilité : Les deux problèmes ont un impact sur l'accessibilité de l'application.

*Informations complémentaires :

=>Le problème "Visible, non-interactive elements with click handlers must have at least
one keyboard listener" est de type "Intentionality" et a été introduit il y a 1 mois.

=>Le problème "Do not use Array index in keys" est de type "Intentionality" et a un impact
sur la performance, avec une priorité "Major".
EXPLICATION :

*Problème lié à l'utilisation de l'index de tableau comme clé : SonarQube a détecté un

problème avec l'utilisation de l'index de tableau comme clé dans le fichier
"frontend/src/pages/ScrollToTopButton.js". Cela peut avoir un impact négatif sur la
maintenabilité du code.

*Problème d'accessibilité avec les éléments non interactifs : SonarQube a également identifié
un problème d'accessibilité avec des éléments non interactifs qui ont des gestionnaires de clic.
Ces éléments doivent avoir au moins un écouteur de clavier pour être accessibles.

*Informations complémentaires :

=>Le problème lié à l'utilisation de l'index de tableau comme clé est de type
"Intentionality" et a un impact sur la performance, avec une priorité "Major".

=>Le problème d'accessibilité avec les éléments non interactifs est également de type
"Intentionality" et a un impact sur l'accessibilité, avec une priorité "Minor".

=>Ces deux problèmes ont été introduits il y a 1 mois.

 Atelier 4. Elaboration d’un plan de tests structurels :

Plan de test structurels pour quelques fonctions du projet :

Cas de test Résultats attendus Validité Observations

Couverture globale Déclarations ≥ 80%, Non valide Couverture globale
(Niveau de test : Branches ≥ 80%, des déclarations
Unitaire. Fonctions ≥ 80%, (59.82%), branches
Type de test : Test de Lignes ≥ 80% (57.82%), fonctions
couverture de code ) (50.79%), lignes
(63.06%).
CreateBlog.js Couverture : Non valide Lignes non couvertes :
(Niveau de test : Déclarations 33.78%, 20-30, 45-68, 73-78,
Unitaire. Branches 31.57%, 82-84, 158-208.
Type de test : Test de Fonctions 21.73%,
fonctionnalité ) Lignes 39.06%
CreateJob.js Couverture : Partiellement valide Ligne non couverte :
(Niveau de test : Déclarations 96.29% 32.
Unitaire. Branches 100%
Type de test : Test de Fonctions 87.5%
fonctionnalité ) Lignes 96.29%
CreateSolution.js Couverture : Non valide Lignes non couvertes :
(Niveau de test : Déclarations 36.84%, 55-80, 123-151, 173-
Unitaire. Branches 32.14%, 204.
Type de test : Test de Fonctions 18.18%,
fonctionnalité ) Lignes 37.83%
EditJob.js Couverture : Partiellement valide Lignes non couvertes :
(Niveau de test : Déclarations 85.71%, 21, 43-44, 56-60.
Unitaire. Branches 62.96%,
Type de test : Test de Fonctions 90%, Lignes
fonctionnalité ) 85.71%
EditSolution.js Couverture : Non valide Lignes non couvertes :
(Niveau de test : Déclarations 71.73%, 66-67, 80-98, 156.
Unitaire. Branches 69.56%,
Type de test : Test de Fonctions 81.81%,
fonctionnalité ) Lignes 73.33%
Résultat des suites de 3 suites échouées, 2 Non valide 11 tests échoués sur
tests Jest réussies 19. Nécessite un
(Niveau de test : débogage des tests
Intégration échoués.
Type de
test :Intégration )
Résultat des tests Jest Total de 19 tests Non valide Le seuil global de
(Niveau de test : exécutés (11 échoués, couverture (80%) pour
Unitaire. 8 réussis) les déclarations,
Type de test : Test de branches, fonctions et
régression) lignes n’est pas
atteint.
EXPLICATION :

1.Couverture globale :

 Le seuil de couverture globale pour les instructions (80%) n'est pas atteint, il est à
50,79%.
 Le seuil de couverture globale pour les branches (80%) n'est pas atteint, il est à
57,82%.
 Le seuil de couverture globale pour les lignes (80%) n'est pas atteint, il est à 63,06%.
 Le seuil de couverture globale pour les fonctions (80%) n'est pas atteint, il est à
50,79%.

2. Résultats des tests :

 3 tests ont échoué, 2 ont réussi, pour un total de 5 tests.

 11 tests ont échoué, 8 ont réussi, pour un total de 19 tests.
 0 instantané a été enregistré.

3. Fichiers :

 Le fichier "CreateJob.js" a une couverture de 96,29%.

 Le fichier "CreateSolution.js" a une couverture de 36,84%.
 Le fichier "EditJob.js" a une couverture de 85,71%.
 Le fichier "EditSolution.js" a une couverture de 71,73%.

 Les résultats montrent que la couverture globale des tests unitaires n'atteint pas les seuils
cibles de 80% pour les différentes métriques (instructions, branches, lignes, fonctions).
Certains fichiers, comme "CreateSolution.js", ont une couverture relativement faible. Les
tests ont également révélé des échecs, indiquant la nécessité d'améliorer la qualité et la
couverture des tests.