La sismologie est une dicipline scientifique visant à étudier le comportement de la Terre. Il est donc important pour les chercheur\textperiodcentered euse\textperiodcentered s d'avoir accèes rappidement et facilement au données mesurées et aux conditions de récolte des données. C'est donc dans l'horizon d'une distribition parfaite des données que s'inscrit mon stage à ISTerre. ISTerre est un laboratoire universitaire à Grenoble dont le but est l'étude de le sismologie. Il y a aussi un service informatique dont l'objectif est de développer et maintenir le centre de donnée RÉSIF. Le centre de donnée se doit de désservir les données sismologiques récoltées par les noeuds A du réseau RÉSIF, à qui le demande grace à différents web services gérés par le centre de donnée RÉSIF (noeud B). L'objectif de mon stage était donc de construir des tests comportementaux sur plusieurs de ces web services, à savoir les services \href{https://ws.resif.fr/fdsnws/station/1}{'station'}, \href{https://ws.resif.fr/fdsnws/dataselect/1}{'dataselect'} et \href{https://ws.resif.fr/fdsnws/availability/1}{'availability'}. En effet, dans le cadre de l'optimisation de ces services, les tests que j'ai implémenté auront pour untilité de comparrer les performances entre les nouvelles et anciennnes version de ces web services. La problematique de ce stage est donc comment trouver tout les scénarios possibles et comment les implémenter pour que l'identification de bugs soit facile et que l'écriture de nouveau tests soit rapide. \textbf{ANNONCE DU PLAN}
La sismologie est une dicipline scientifique visant à étudier le comportement de la Terre. Il est donc important pour les chercheur\textperiodcentered euse\textperiodcentered s d'avoir accèes rappidement et facilement au données mesurées et aux conditions de récolte des données. C'est donc dans l'horizon d'une distribition parfaite des données que s'inscrit mon stage à ISTerre.
\paragraph{}
ISTerre est un laboratoire universitaire à Grenoble dont le but est l'étude de le sismologie. Il y a aussi un service informatique dont l'objectif est de développer et maintenir le centre de donnée RÉSIF. Le centre de donnée se doit de désservir les données sismologiques récoltées par les noeuds A du réseau RÉSIF, à qui le demande grace à différents web services gérés par le centre de donnée RÉSIF (noeud B).
\paragraph{}
L'objectif de mon stage était donc de construir des tests comportementaux sur plusieurs de ces web services, à savoir les services \href{https://ws.resif.fr/fdsnws/station/1}{'station'}, \href{https://ws.resif.fr/fdsnws/dataselect/1}{'dataselect'} et \href{https://ws.resif.fr/fdsnws/availability/1}{'availability'}. En effet, dans le cadre de l'optimisation de ces services, les tests que j'ai implémenté auront pour untilité de comparrer les performances entre les nouvelles et anciennnes version de ces web services. La problematique de ce stage est donc comment trouver tout les scénarios possibles et comment les implémenter pour que l'identification de bugs soit facile et que l'écriture de nouveau tests soit rapide. \textbf{ANNONCE DU PLAN}
\section{Mon stage}
\subsection{Le Laboratoire}
\paragraph{}
ISTerre (Instutut des Sciences de ta Terre) est un laboratoire créer en 2011 dont l’objectif scientifique est l’étude physique et chimique de notre planette. Le laboratoire est diviser en 2 sections, une à Chambery et l’autre à Grenoble. Le nombre de personne travaillant pour ce laboratoir est assez important: près de 300 personnes en additionant les 2 sites dont la pluparts sont scientifiques (~20\% du personel sont des technicien·ne·s). Pour donner une idée du pourvoir d’acction du laboratoire, celui ci a un budget annuel d’envirion 15 millions d’euros. ISTerre travail en colaboration avec plusieurs pays, notatment du Sud (Équateur, Pérou, Liban, \dots). Cet collaboration est en partie traduite par l’échange de chercheur·euse·s et d’étudiant·e·s. Le travail scientifique du laboratoire se retrouve chaque année dans près de 250 articles de recherche et dans de nombreuses actions de vulgarisation scentifique. Ces connaissance on pu être récoltées grâce au differentes action menées comme des déplacement dans des lieux sismiques, la récolte et la distribution de données aquisent par differents réseau d’instrument géophysique, l’analyse d’échentillons naturels, et grâce à de nouvelles modelisation et expérimentations. La récolte et le traitement des données s’articule autour de 3 grand axes pour ISTerre:
\begin{enumerate}
\item Peut on identifier des précurseurs aux grands événements qui boulverssent notres planète? Quels sont les processus physiques qui gouvernent les séismes, les mouvements de terrain, les éruptions volcaniques, kes varuations du champs magnétique terrestre?
\item Comment la surface de la Terre est-elle façonnée par les interacrions entre les processus profonds et les pocessus de surface?
\item Comment roches et sols engegistrent les perturbations physico-chimique naturelles ou anthropique de leur environement? Quelles sont les mécanismes qui gouvernent la croissance, la sorption et l’alteration des minéreaux? Comment les processus hydrothermaux et magnétiques concernent-ils les ressources minérales? Comment produire de l’hydrogène? La carbonation minéral, une voie pour le stockage du CO2?
\end{enumerate}
\subsection{RÉSIF}
\paragraph{}
Le réseau sismologique et géodésique français (RÉSIF) est un ensmble de capteurs géophysiques implentés partout en France qui permettent d’alimenter, en partie, l’infrastructure EPOS (European Plate Observing System). Ainsi les données colléctées par RÉSIF sont disponible via plusieurs webservices qui sont standardiser par plusieurs organismes tel que EIDA, FDSN et RÉSIF même.
\subsection{Présentation de la structure d'accueil}
\paragraph{}
RÉSIF-DC est géré par différents organismes chapauté par le CNRS. Quand j'ai signé ma convention, je l'ai fait avec l'Unitée Mixte de Recherche ISTERRE. En effet, le bureau dans le quel je travail se situ dans les locaux de cet UMR. Toute fois, le personel travaillant dans l'équipe RÉSIF-DC est sous la diréction de l'OSUG et de RÉSIF. Ainsi, j'ai été amené à integrer une équipe d'ingénieurs OSUG.
\begin{figure}[H]
\caption{Répartition des organismes contribuant à RÉSIF-DC}
\includegraphics[width=\textwidth]{organigrame}
\end{figure}
\subsection{L'OSUG}
\paragraph{}
L'Observatoir des Sciences de l'Univers de Grenoble fédére des ingénieurs pour permetre à la recherche dans les sciences de l'Univers, de la Terre et de l'environement. Ainsi, l'OSUG permet au insititut d'avoir du personel qualifié pour pouvoir assurer une mission d'observation.
\subsection{ISTerre}
\paragraph{}
ISTerre (Instutut des Sciences de ta Terre) est un laboratoire créer en 2011 dont l’objectif scientifique est l’étude physique et chimique de notre planette. Le laboratoire est diviser en 2 sections, une à Chambery et l’autre à Grenoble, toutes deux fédéré par l'OSUG. Le nombre de personne travaillant pour ce laboratoir est assez important: près de 300 personnes en additionant les 2 sites dont la pluparts sont scientifiques (\~20\% du personel sont des technicien·ne·s). Pour donner une idée du pourvoir d’acction du laboratoire, celui ci a un budget annuel d’envirion 15 millions d’euros.
\paragraph{}
ISTerre travail en colaboration avec plusieurs pays, notatment du Sud (Équateur, Pérou, Liban, \dots). Cet collaboration est en partie traduite par l’échange de chercheur·euse·s et d’étudiant·e·s. Le travail scientifique du laboratoire se retrouve chaque année dans près de 250 articles de recherche et dans de nombreuses actions de vulgarisation scentifique. Ces connaissance on pu être récoltées grâce au differentes action menées comme des déplacement dans des lieux sismiques, la récolte et la distribution de données aquisent par differents réseau d’instrument géophysique, l’analyse d’échentillons naturels, et grâce à de nouvelles modelisation et expérimentations. La récolte et le traitement des données s’articule autour de 3 grand axes pour ISTerre:
\begin{enumerate}
\item Peut on identifier des précurseurs aux grands événements qui boulverssent notres planète? Quels sont les processus physiques qui gouvernent les séismes, les mouvements de terrain, les éruptions volcaniques, kes varuations du champs magnétique terrestre?
\item Comment la surface de la Terre est-elle façonnée par les interacrions entre les processus profonds et les pocessus de surface?
\item Comment roches et sols engegistrent les perturbations physico-chimique naturelles ou anthropique de leur environement? Quelles sont les mécanismes qui gouvernent la croissance, la sorption et l’alteration des minéreaux? Comment les processus hydrothermaux et magnétiques concernent-ils les ressources minérales? Comment produire de l’hydrogène? La carbonation minéral, une voie pour le stockage du CO2?
\end{enumerate}
\subsection{RÉSIF}
\paragraph{}
Le réseau sismologique et géodésique français (RÉSIF) est un ensmble de capteurs géophysiques implentés partout en France qui permettent d’alimenter, en partie, l’infrastructure EPOS (European Plate Observing System). Ainsi les données colléctées par RÉSIF sont disponible via plusieurs webservices qui sont standardiser par plusieurs organismes tel que EIDA, FDSN et RÉSIF même. RÉSIF c'est aussi un organisme regroupant des chercheur\textperiodcentered euse\textperiodcentered s qui étudient les données récoltées.
\section{Présetation du stage}
\subsection{Gestion de projet}
\subsubsection{Ce qui était prévu / Ce que j'ai fait}
\begin{figure}[h]
\begin{figure}[H]
\caption{Prévision et réalisation du travail}
\includegraphics[width=\textwidth]{GANTT}
\end{figure}
@ -62,22 +80,24 @@
\subsection{Environement}
\paragraph{}
Le laboratore est pricipallement constitué de chercheurs dans diférrents dommaines ce qui donne un environement très riche où les interaction entre les membre des different services sont assez riches.
Cependant, durant mon stage, j'étais la pluspars du temps dans un bureau avec une équipe de 4 personnes dont un CDD. L'équipe se composait d'un chef de projet, un developpeur logiciel, un administrateur system et un data enginier.
Cependant, durant mon stage, j'étais la pluspars du temps dans un bureau avec une équipe de 4 personnes dont un CDD. L'équipe se composait d'un chef de projet, un developpeur logiciel, un administrateur systeme et un data enginier.
\subsection{L'existant}
\paragraph{}
Quand je suis arrivé, les differents web services que j'avais à tester était terminés et déployés. Il exister déja une suite de tests développée par Catherine Lecompte mais les tests etait effectués sans bibliothèque de test, ce qui rendait difficil son maintien.
L'équipe RESIF-DC, dans la quelle je me trouvé, avait déja effectuer quels test avec la bibliothèque behave pour dessider quelle bibliothèque utiliser.
Cependant, pour ne pas brider ma créativité, il a était déssidé que je parte de 0. Et qu'après je regarde les différents scénarios définit par l'équipe.
Quand je suis arrivé, les differents web services que j'avais à tester était terminés et déployés. Il exister déja une suite de tests développée par Catherine Lecompte mais les tests etait effectués sans bibliothèque de test, ce qui rendait difficile son maintient.
\paragraph{}
L'équipe RESIF-DC, dans la quelle je me trouvé, avait déja effectuer quelques test avec la bibliothèque \textit{behave} pour dessider quelle bibliothèque utiliser.
Cependant, pour ne pas brider ma créativité, il a était déssidé que je parte de 0 et que selement une fois que j'aurai finit d'écrir mes scénarios, je regarde les différents scénarios définit par l'équipe.
\subsection{L'objectif}
\paragraph{}
Les objectif de mon stages était multiples. En effet, je devais développer une suite de test cappable de verifier le comportement des web services dans des cas de mis en difficulté ainsi que de verifier le simple fonctionement de ces derniers.
Ainsi, lors d'une nouvelle implémentation d'un web service, les résultats des requettes peuvent être comparrer. Aussi lors d'un changement d'infrastructure, qui peuvent ammener une migration des serveurs, le fonctionement des web services peuvent être raliser rappidement.
Les objectif de mon stages était multiples. En effet, je devais développer une suite de tests cappable de verifier le comportement des web services dans des cas de mise en difficulté ainsi que de verifier le simple fonctionement de ces derniers.
\paragraph{}
Ainsi, lors d'une nouvelle implémentation d'un web service, les résultats des requettes peuvent être comparés. Aussi lors d'un changement d'infrastructure, qui peuvent ammener une migration des serveurs, le test du fonctionement des web services peuvent être réalisé rappidement.
\section{Le développement des tests}
\subsection{La prise en main du context}
\paragraph{}
Lors de ma première semaine de stage, mon principal objectif était de prendre en main le context dans le quel j'allais travailler. En effet, j'ai principalement lu de la documentation sur les thermes téchniques (glossaire), sur la sismologie, sur les standard fdsn, \dots
Ensuite, j'ai pu commencer à prendre en main l'outil behave et me rafraichir la mémoire au niveau du langage python. Après ca, j'ai pu commencer à réfléchir à des scénarios de tests. C'est ce que j'ai principalement fait pendant 3 jours. En paralele de ca, j'ai pu prendre en main d'autre bibliothèque tel que lxml.
\subsection{Les outils utilisé}
\subsection{Les outils utilisés}
\subsubsection{Python}
\paragraph{}
Python est un langage de programation orienté objet qui est accèssible à un large publique. Cette accessibilité apportent certaine contraites, notament au niveau objet. En effet, des notion importantes du paradigme objet ne sont pas présentes, ce qui peut géner lors de la conception du logiciel.
Le \textit{Network} coréspond à un moyen d'identifier la donnée. Un réseau est lui même identifié par un code alphanumérique (de quelques caractères, exemple : 'FR'). Ainsi, pour des opperation faisant inervenir plusieurs pays différent, il est possible de décentraliser les données et de retrouver facielement.
\subsubsection{La station}
\paragraph{}
Une \textit{Station} est une représentation abstaite du lieu ou sont placer différent capteurs. Elle est aussi identifiée par un code alphanumérique (exemple: 'CFF'). Les stations sont répartits dans les différent réseau en fonctions du cadre de l'oppérations dont elle fait partie.
\subsubsection{Le canal}
\paragraph{}
Un \textit{Channel} corespond à un instrument d'une station sur une periode de temps. De ce fait, deux \textit{channels} différents peuvent avoir le même code (exemple: 'HHZ') mais cela veux dire qu'il y a eu une interuption humaine dans l'envoi de données. La fermeture puis réouverture d'un \textit{channel} ne doit pas être confondu avec un \textit{gap}, qui est une interuption de l'envoi de données à un moment où on s'attend à en recevoir.
\subsubsection{Le traitement de la donnée}
\begin{figure}[H]
\caption{Parcours de la donnée depuis l'aquisition jusqu'à la distribution}
Comme on peut le voir sur la Figure~\ref{fig:parcourDonnée}, la donnée récoltée par les stations RÉSIF est diréctement envoyée au \textit{noeud A} qui s'occupe de la valider. Une fois ce travail terminé, Cette donnée est transmise au \textit{noeud B} qui à pour mission de la distribuer aux utilisateur\textperiodcentered ice\textperiodcentered s, notament le Commissariat à l’Énergie Atomique (CEA) qui peux lancer des alerte au population en cas de données montrant un séisme dangereux. Pour palier à cette mission, le noeud B met a dispositions plusieus \textit{web services} à la disposition de tout\textperiodcentered se\textperiodcentered s.
\subsection{Les differents web services}
\label{txt:explicationURL}
Durant mon stage, j'ai du travailler sur différants web services.
Chaque web service est requetable par URL. L'URL est composé en différentes partie
\begin{itemize}
\item \textit{le nom de domaine}: ws.resif.fr. Ce nom de domaine est vairiable selon le contexte. En effet celui ci est le nom de domaine pour le context de production. Il en exist d'autre pour d'autre context.
\item \textit{le chemin vers le web service}: /fdsnws/station/1/query. Ce chemain permet d'identifié le web service que l'on veut requeter. Il est composer en 4 parties: la norme(fdsnws), web service(station), la version(1), et le mode d'inerogation(query).
\item \textit{le chemin vers le web service}: /fdsnws/station/1/query. Ce chemain permet d'identifié le web service que l'on veut requeter. Il est composer en 4 parties: la norme(fdsnws), web service(station), la version(1), et le mode d'inerogation(query).
\item \textit{les parametres}: ?net=FR\&sta=CFF\&level=channel. Le début de la liste de parametre doit commancer par un ?. Ensuite, chaque parametre doit être séparé par un \&. Enfin, la forme que prend la définition d'un parametre est $<$parametre$>$=$<$valeur$>$
\end{itemize}
Ainsi une URL possible peut être \href{https://ws.resif.fr/fdsnws/station/1/query?net=FR&sta=CFF&level=channel}{ws.resif.fr/fdsnws/station/1/query?net=FR\&sta=CFF\&level=channel}
Voici les differents web services que j'ai testé.
\subsubsection{Station}
\paragraph{}
Le web service \textit{\href{https://ws.resif.fr/fdsnws/station/1}{station}} permet de récuperer les méta données des stations de mesure. C'est à dire, leur nom, leurs positions, les cannaux disponible, etcetera. Bien qu'il soit possible de récuperer ces méta données sous forme de text, le principal format pour ce genre de requette est le StationXML, un dérivé du XML. Ce format permet un traitement numerique plus facile ainsi qu'une plus grande capacité à contenir des informations. Voici quelques exemples de requettes, \href{https://ws.resif.fr/fdsnws/station/1/query?net=FR&sta=CFF&cha=HHZ&level=channel&format=xml}{sous le format XML} et \href{https://ws.resif.fr/fdsnws/station/1/query?net=FR&sta=CFF&cha=HHZ&level=channel&format=text}{la meme requete sous le format text}.
Le web service \textit{\href{https://ws.resif.fr/fdsnws/station/1}{station}} permet de récuperer les méta données des stations de mesure. C'est à dire, leur nom, leurs positions, les cannaux disponible, etcetera. Bien qu'il soit possible de récuperer ces méta données sous forme de text, le principal format pour ce genre de requette est le StationXML, un dérivé du XML. Ce format permet un traitement numerique plus facile ainsi qu'une plus grande capacité à contenir des informations qu'un format texte habituel. Voici deux exemples de requettes, \href{https://ws.resif.fr/fdsnws/station/1/query?net=FR&sta=CFF&cha=HHZ&level=channel&format=xml}{une sous le format XML} et \href{https://ws.resif.fr/fdsnws/station/1/query?net=FR&sta=CFF&cha=HHZ&level=channel&format=text}{la meme requete sous le format text}.
\begin{figure}[H]
\caption{Exemple d'une requete \textit{station} demandant du StationXLM pour la station FR.CFF }
Le web service \textit{\href{https://ws.resif.fr/fdsnws/availability/1}{availability}} permet au chercheur\textperiodcentered euse\textperiodcentered s de pouvoir connaire les periodes dans les quelles il y a des données êtant donné des réseaux, des stations ou des canneaux. Voici des exemples de requetes \href{https://ws.resif.fr/fdsnws/availability/1/extent?net=FR&sta=CFF&format=text}{Au format text}, \href{https://ws.resif.fr/fdsnws/availability/1/extent?net=FR&sta=CFF&format=json}{json} et \href{https://ws.resif.fr/fdsnws/availability/1/extent?net=FR&sta=CFF&format=geocsv}{csv}
Le web service \textit{\href{https://ws.resif.fr/fdsnws/availability/1}{availability}} permet au chercheur\textperiodcentered euse\textperiodcentered s de pouvoir connaitre les periodes dans les quelles il y a des données êtant donné des réseaux, des stations ou des canneaux.
\paragraph{}
Ce \textit{web service} est décomposé en deux points d'entrée qui donnent des résultat différent car la nature de ce que l'on demende est différent. Dans le cas du point d'entrée \textit{query}, on veux savoir les plages temporelles continue disponible. Pour le point d'entrée \textit{extent}, on demende aussi les plages temporelles disponible à la différence près que les données qui sont dans la plage peuvent comporter des \textit{gaps}.
\paragraph{}
Dans l'url, cela ce materialisera par le changement de chemain vers le \textit{web service} (cf. explication de l'url \ref{txt:explicationURL}). En effet, les chemains resembleront à cela:
\begin{itemize}
\item \textit{fdsnws/availability/1/query} pour \textit{query}
\item \textit{fdnsws/availability/1/extent} pour \textit{extent}.
\end{itemize}
\paragraph{}
Voici des exemples de requetes \href{https://ws.resif.fr/fdsnws/availability/1/extent?net=FR&sta=CFF&format=text}{Au format text}, \href{https://ws.resif.fr/fdsnws/availability/1/extent?net=FR&sta=CFF&format=json}{json} et \href{https://ws.resif.fr/fdsnws/availability/1/extent?net=FR&sta=CFF&format=geocsv}{csv}.
\begin{figure}[H]
\caption{Exemple d'une requete \textit{availability} demandant du texte pour la station FR.CFF }
Le web service \textit{\href{https://ws.resif.fr/fdsnws/dataselect/1}{dataselect}} permet de selectioner des données pour en fonction des réseaux, station et canneaux sur une periode de temps. Le format de la réponse est un fichier binaire sour le format MiniSEED. Il est donc naissaissaire d'avoir un outils pour lire ce type de fichier.
@ -144,13 +203,15 @@
\subsection{L'implémenation des tests}
\paragraph{}
Pour implementer mes tests, j'ai du reprendre chaque phrase du scénario (\textit{Given, When, Then, And, But}) et coder leurs sens. Par exemple, pour un \textit{Given}, la plupars du temps, je devais initialiser le contexte, pour les \textit{Then}, je devais comparer les résultat des \textit{When}. Ainsi, il était important de bien factoriser les différents cas pour pouvoir réutiliser le code déjà produit. Aussi, toujours pour les même raisons évoqué plus haut, le code est écris en anglais.
Pour implementer mes tests, j'ai du reprendre chaque phrase du scénario (\textit{Given, When, Then, And, But}) et coder leurs sens. Par exemple, pour un \textit{Given}, la plupars du temps, je devais initialiser le contexte, pour les \textit{Then}, je devais comparer les résultat des \textit{When} avec ce qui était attendut. Ainsi, il était important de bien factoriser les différents cas pour pouvoir réutiliser le code déjà produit. Aussi, toujours pour les même raisons évoqué plus haut, le code est écris en anglais.
\subsubsection{Conception}
Lors de la réalisation des tests du deuxième web service, \textit{availability}, je commençais à reprendre des fonctionalités du premier, \textit{station}, comme l'envoi de requette au web service, la verification de format de la réponse. À ce moment là, j'ai resenti le besoin de metre en commun certaine partie de code et d'en spécialiser d'autres. Ainsi, j'ai commancé un travail de factorisation de code.
\subsubsection{Factorisation de code}
\paragraph{}
Pour éviter de dupliquer du code, j'ai dût créer differents objets ayant diférrants types de relations entre eux (association dirigée, héritage, \dots). Une des difficutltés non négligable est qu'en python, le principe de classe abstraite n'éxiste pas. Cela m'a notament posé problème lors de l'implémentation des sous classes de Query. En effet, le comportement des sous classes dépendait de plusieurs parametres: la methode HTTP et le webservice intérogé. Ainsi, un objet Query n'a pas de sens si is est instancié. Pour palier a ce problème, j'ai simuler le comportement d'une classe abstraite grace à la valeur \textit{NotImplemeted}. C'est valeur est retourné à chaque fois qu'une methode sensé être abstraite est appeler. Toute fois, je n'ai pas interdit l'instentiation de ces objet car cela complexifirai le code juste pour introduire une notion étrangère à python. Ainsi, j'ai pu obtenir plusieurs points d'extensiblilité (Query, Response, Validator, \dots), ce qui permetra une maintnabilité plus simple pour les développeurs et dévelopeuses qui seron sucéptible de reprendre mon code. Ainsi, pour permetre au modele de pouvoir tester de nouveau web services, il sufit de créer une nouvelle classe qui hérite de Query et une nouvelle classe qui hérite de Response et implementer les methodes \textit{abstraites}.\textbf{Ajouter des bouts d'UML}
Pour éviter de dupliquer du code, j'ai dût créer differents objets ayant diférrants types de relations entre eux (association dirigée, héritage, \dots). Une des difficutltés non négligable est qu'en python, le principe de classe abstraite n'éxiste pas. Cela m'a notament posé problème lors de l'implémentation des sous classes de Query. En effet, le comportement des sous classes dépendait de plusieurs parametres: la methode HTTP et le webservice intérogé. Ainsi, un objet Query n'a pas de sens si is est instancié.
\paragraph{}
Pour palier a ce problème, j'ai simuler le comportement d'une classe abstraite grace à la valeur \textit{NotImplemeted}. Cette valeur est retourné à chaque fois qu'une methode censé être abstraite est appeler. Toute fois, je n'ai pas interdit l'instentiation de ces objet car cela complexifirai le code juste pour introduire une notion étrangère à python. Ainsi, j'ai pu obtenir plusieurs points d'extensiblilités (Query, Response, Validator, \dots), ce qui permetra une maintnabilité plus simple pour les développeur\textperiodcentered euse\textperiodcentered s qui seront sucéptible de reprendre mon code. Ainsi, pour permetre au modele de pouvoir tester de nouveau web services, il sufit de créer une nouvelle classe qui hérite de Query et une nouvelle classe qui hérite de Response et implementer les methodes \textit{abstraites} (cf. Fig~\ref{fig:QueryClassDiag}, Fig~\ref{fig:ResponseClassDiag}).
\subsubsection{Description du modele de classes}
\paragraph{}
Dans mon modele de classes, j'ai pu faire un point d'entrée qui permet un simple utilisiation depuis l'éxterieur, dans mon cas, depuis les tests behave. En effet, la classe \textit{QeryGenerator} agit comme une \textit{factory}, c'est à dire, une classe qui permet de créer d'autre types de classes en foction de divers parametres. Par exemple ici, \textit{QueryGenerator} vas créer des classes filles de \textit{Query} en fonction du web service que l'on veut requeter. En effet, une requette, modéliser par la classe \textit{Query} doit être spécialisée en fonction du web service intérogé (cf. Figure~\ref{fig:QueryClassDiag}). Une fois que le web service en question est intérogé, la classe \textit{Query} se créer une \textit{Response}, elle aussi spécialisée en fonction du web service intérogé mais aussi en fonction du format attendu (cf. Figure~\ref{fig:ResponseClassDiag}). Aussi, chaque \textit{Response} doit pouvoir verifier que son contenu coresponde au format attendu. Ainsi, chaque \textit{Response} utilise un \textit{Validator} spécialisé a cet effet(cf. Figure~\ref{fig:ValidatorClassDiag}).
@ -161,14 +222,18 @@
\end{figure}
\subsubsection{Transmition du savoir}
\paragraph{Documentation de ma production}
Pour pouvoir avoir une vision globale du projet ainsi que pour la transmission de ma production, j'ai du la documenter. Pour cela, j'ai utiliser plusieurs outils. Tout d'abord, pour avoir une documentation de mon code en lui même, éxpliquer le rôle de chaque classe, chaque methode, j'ai utiliser l'outil pydoc, qui permet de generer une documentation HTML en lisant les \textit{docstings} de mon code. Une \textit{docstring} est espece de paragraph, placé en haut de l'item à documenter (classe, methode, \dots) expliquant l'utilité et le fonctionement de ce dérnier. Cependant, je n'ai pas commencer à documenter mon code dès le début de sa production, donc j'ai donc pris une journée pour écrire la documentation, à la fin de l'implémentation des tests sur le deuxieme web service que j'ai traiter, c'est à dire, vers le début du moi de mai.
Pour pouvoir avoir une vision globale du projet ainsi que pour la transmission de ma production, j'ai du la documenter. Pour cela, j'ai utiliser plusieurs outils. Tout d'abord, pour avoir une documentation de mon code en lui même, éxpliquer le rôle de chaque classe, chaque methode, j'ai utiliser l'outil pydoc, qui permet de generer une documentation HTML en lisant les \textit{docstings} de mon code. Une \textit{docstring} est espece de paragraph, placé en haut de l'item à documenter (classe, methode, \dots) expliquant l'utilité et le fonctionement de ce dérnier. Cependant, je n'ai pas commencer à documenter mon code dès le début de sa production, donc j'ai donc pris une journée pour l'écrire, à la fin de l'implémentation des tests sur le deuxieme web service que j'ai traiter, c'est à dire, vers le début du moi de mai.
\subparagraph{}
Pour donner une explication sur les relations entres les classes, j'ai réaliser plusieurs diagrames de classes avec l'outil \textit{plantuml}. Cette outil permet de generer un diagrame UML à partir d'un fichier texte formaté qui explique les relations entre classes. L'avantage d'un tel outil est qu'il est facile à versioner par rapport à un fichier binnaire. J'ai comencé la réalisation du fichier plantuml dès que j'ai eu plus d'une classe à implémenter. \textbf{AJOUTER UN BOUT DE .PLANTUML}
\paragraph{Réunions}
En mi chemain de mon stage, j'ai réaliser une présentation de mon travail dans le cadre d'une transmition de savoir au reste de l'équipe. Suite à cela, il y eu de nouveaux échanges et cela à permis d'enrichir le contenu de mes tests. En effet, cette échange à permis de déffinir un plan d'acction pour les semaines qui suivit ainsi que mettre en lumière de nouveau scénario tel que la cohérance des web services entres eux.
\subsubsection{Problèmes rencontrés}
\paragraph{}
Une des principales dificultés que j'ai pu rencontré lors de ce stage est le comportement de \textit{behave}. En effet, quand on execute un scenario, behave va le faire échouer seulement si une exception est levée, c'est à dire, qu'une erreur a été rencontré ou qu'un test de nature spécifique (assertion). Aussi, certains tests peuvent passer sans que le web service ce soit comporté comme souhaité. Par example, si je veux tester un code de retour HTTP égale à 400 en voulant tester un paramètre, ce code peut être renvoyer à cause d'un autre paramètre déféctueu. Ainsi, le test passra mais n'aura pas valider le comportement attendu. Pour palier à ce problème, à la fin de chaque implémentation, je verifiais à la main que le test passé coraissponde bien au comportement souhaité.
Une des principales dificultés que j'ai pu rencontré lors de ce stage est le comportement de \textit{behave}. En effet, quand on execute un scenario, behave va le faire échouer seulement si une exception est levée, c'est à dire, qu'une erreur a été rencontré ou qu'un test de nature spécifique (assertion) n'est pas passé. Aussi, certains tests peuvent passer sans que le web service ce soit comporté comme souhaité.
\paragraph{}
Par exemple, si je veux tester un code de retour HTTP égale à 400 en voulant tester un paramètre, ce code peut être renvoyer à cause d'un autre paramètre déféctueu. Ainsi, le test passra mais n'aura pas valider le comportement attendu. Un autre exemple est quand par exemple je devais tester que le format texte était cohérant avec le format XML. Ici, j'avais un problème de code qui faisait que les deux requettes que je faisait était identique et donc, le résultat était lui aussi identique (tout les 2 au format XML).
\paragraph{}
Pour palier à ce problème, à la fin de chaque implémentation, je verifiais à la main que le test passé coraissponde bien au comportement souhaité.
\subsection{Au delà du stage}
\paragraph{}
Tout au long de mon stage, je devais avoir à l'espris que mon code sera repris et que le logiciel produit devra être utiliser le plus simplement possible. Ainsi, J'ai pu pensé à des amélioration tel que la mise en cache de certaines requettes pour accélérer les test, l'écriture d'un script qui permet de simplifier le lancement des tests, un model de classes qui permet une genericité maxiamle. Certaines de ces idées ont dût être écarter par manque de temps. C'est donc un piste pour continuer l'implémentation des tests.
@ -186,6 +251,12 @@
\paragraph{}
J'ai donc pu relever plusieurs bugs, par exemple, une divergence dans le comportement du web service \textit{station} en fonction de la methode utilisée (GET et POST) si on demende une date à la limite éxterieur de ce qui existe (par exemple le 21 novembre 2020 à 12h\textit{60}). Ainsi le travail que j'ai produit à pu servir à mettre en lumière des problèmes qui n'ont pas étés repéré jusqu'à présent. Aussi, dans le cadre d'une réecriture d'un web service, mes test permettent de verifier qu'il n'y a pas eu de régression par rapport à l'implémentation précédente. Ces tests peuvent aussi être lancer de manière automatique dans le cadre d'une verification routinière du bon fonctionement des web services. J'ai aussi documenter mon code pour une transmition du savoir plus facile.
\section{Lexique}
\begin{itemize}
\item Test de comportement (behavior test) : Test informatique permetant de vérifier le comportement du logiciel testé sur la base de différntes scénario
\item Nœud A: Équipe de sismologue charcher de placer des sondes, de récolter les données et métadonnées, et de les transmetre au nœud B
\item Nœud B: Équipe de sysmologue charger de traiter les données et métadonnées récolté par les differents nœud A pour coriger les données.
\end{itemize}
\section{Anex}
\begin{figure}[h]
\caption{exemple de scénario}
@ -216,10 +287,4 @@
\label{fig:ResponseClassDiag}
\end{figure}
\section{Lexique}
\begin{itemize}
\item Test de comportement (behavior test) : Test informatique permetant de vérifier le comportement du logiciel testé sur la base de différntes scénario
\item Nœud A: Équipe de sismologue charcher de placer des sondes, de récolter les données et métadonnées, et de les transmetre au nœud B
\item Nœud B: Équipe de sysmologue charger de traiter les données et métadonnées récolté par les differents nœud A pour coriger les données.
Érina Point
3 years ago
