\HRule \\[0.4cm]{ \huge \bfseries Rapport de stage à ISTerre\\[0.15cm] }
\HRule \\[0.4cm]{ \huge \bfseries Rapport de stage\\[0.30cm] }
{ \Large \bfseries Réalisation d’une suite de tests comportementauxautour de l’infrastructure logicielle de Résif-DC dédiée à la livraison de données et métadonnées sismologiques\\[0.15cm] }
\HRule \\[1.5cm]
\includegraphics[scale=0.4]{isterre} \\[1cm]
\includegraphics[scale=1]{resif} \\[1cm]
@ -46,37 +52,38 @@
\vspace*{\fill}
\framebox{J'autorise la diffusion de mon rapport sur l'intranet de l'IUT}
\vspace*{\fill}
\doclicenseThis
\end{center}
\newpage{}
\textbf{\huge Remerciements}
\paragraph{}
Je souhaite remercier tout les membres de ISTerre pour avoir pu m'acceuillir dans les meilleurs conditions ainsi que toutes le personnes m'ayant aidé ou ayant proposé leur aide à la réalisation de ce rapport.
Je souhaite remercier tout les membres de ISTerre pour avoir pu m'acceuillir dans les meilleures conditions ainsi que toutes le personnes m'ayant aidé ou ayant proposé leur aide à la réalisation de ce rapport.
\paragraph{}
Je souhaite remercier toute l'équipe RÉSIF-DC avec qui j'ai pu travailler.
\paragraph{}
Je souhaite aussi remercier mon tuteur de stage, \textit{Phillipe BOLLARD}, pour avoir su m'encadrer et m'aider dans les défficultés que j'ai pu rencontrer lors du stage.
Je souhaite aussi remercier mon tuteur de stage, \textit{Philippe BOLLARD}, pour avoir su m'encadrer et m'aider dans les dfficultés que j'ai pu rencontrer lors du stage.
\newpage
\tableofcontents
\newpage{}
\section{Introduction}
\paragraph{}
La sismologie est une dicipline scientifique visant à étudier le comportement de la Terre lors de séismes ainsi que la propagation des ondes élastiques (sismiques) à l'interieur la planète\cite{sismo}. En effet, la Terre est constament en train de trembler Il est donc important pour les chercheur\textperiodcentered euse\textperiodcentered s d'avoir accès rapidement et facilement aux données mesurant l'activité sismique de la Terre et aux conditions de récolte de ces données pour créer de nouvelles connaissances sur la structure de la Terre mais aussi pour pouvoir anticiper l'arrivée de catastophes dût au séisme. C'est pour cela que de nombreux capteurs, mesurant diversses unitées physique tel que la vitesse ou l'accélération, sont installés un peu partout autour du globe, surveillent en permanence le comportement de la Terre. Ansi, c'est donc dans l'horizon d'une distribition parfaite des données que s'inscrit mon stage à ISTerre.
La sismologie est une dicipline scientifique visant à étudier le comportement de la Terre lors de séismes ainsi que la propagation des ondes élastiques (sismiques) à l'interieur la planète\cite{sismo}. En effet, la Terre est constament en train de trembler. Il est donc important pour les chercheur\textperiodcentered euse\textperiodcentered s d'avoir accès rapidement et facilement aux données mesurant l'activité sismique de la Terre et aux conditions de récolte de ces données pour créer de nouvelles connaissances sur la structure de la Terre mais aussi pour pouvoir anticiper l'arrivée de catastophes dues au séisme. C'est pour cela que de nombreux capteurs, mesurant diverses unités physique telles que la vitesse ou l'accélération, sont installés un peu partout autour du globe, surveillent en permanence le comportement de la Terre. Ansi, c'est donc dans l'horizon d'une distribution 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\cite{isterrePlaquette}. Ce laboratoire héberge une équipe d'informaticien\textperiodcentered ne\textperiodcentered s, nommé RÉSIF-DC, dont l'objectif est de développer et maintenir le centre de donnée RÉSIF en s'appuiyant sur les ressources de l'Universitée Grenoble Alpes (UGA)\cite{resifSI}.
ISTerre est un laboratoire universitaire à Grenoble dont le but est l'étude de la sismologie\cite{isterrePlaquette}. Ce laboratoire héberge une équipe d'informaticien\textperiodcentered ne\textperiodcentered s, nommée RÉSIF-DC, dont l'objectif est de développer et maintenir le centre de donnée RÉSIF en s'appuiyant sur les ressources de l'Université Grenoble Alpes (UGA)\cite{resifSI}.
\paragraph{}
Résif est une Infrastructure de Recherche (IR) qui déploie en France métropolitaine une instrumentation moderne (parcs de sismomètres, stations GNSS et gravimètres) qui mesure la déformation de la surface terrestre\cite{resifHome}.
\paragraph{}
J'ai donc pu effectuer mon stage dans ce contexte, dans le cadre d'une optimisation des \textit{web services} RÉSIF.
\paragraph{}
L'objectif de mon stage était donc de construir des tests comportementaux sur plusieurs de ces \textit{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, les tests que j'ai implémenté auront pour utilité de comparer les performances, la non-régréssion entre les nouvelles et anciennnes versions de ces \textit{web services} ainsi que la conformité de ces \textit{web services} face aux spécifications établies par la communauté scientifique. La problematique de ce stage est donc comment réaliser des tests exhaustifs qui permettent de mettre en lumière les problemes des \textit{web services} de résif.
L'objectif de mon stage était donc de construir des tests comportementaux sur plusieurs de ces \textit{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, les tests que j'ai implémenté auront pour utilité de comparer les performances, la non-régréssion entre les nouvelles et anciennnes versions de ces \textit{web services} ainsi que la conformité de ces \textit{web services} face aux spécifications établies par la communauté scientifique. La problématique de ce stage est donc comment réaliser des tests exhaustifs qui permettent de mettre en lumière les problemes des \textit{web services} de résif.
\paragraph{}
Dans ce rapport, j'exposerai d'abord les structures qui m'ont acceuilli et entouré lors de la réalisation de mon stage. Ensuite, je décrirai le contexte dans le quel j'ai baigné pendant 10 semaines. C'est après cela que je détaillerai le déroulement de ce stage, depuis la gestion de projet jusqu'à la réalisation finale en passant par les problèmes rencontrés. Enfin, je ferai un bilan sur ce que j'ai pu réaliser avant de conclure.
Dans ce rapport, j'exposerai d'abord les structures qui m'ont acceuilli et entouré lors de la réalisation de mon stage. Ensuite, je décrirai le contexte dans le quel j'ai baigné pendant 10 semaines. Après cela que je détaillerai le déroulement de ce stage, depuis la gestion de projet jusqu'à la réalisation finale en passant par les problèmes rencontrés. Enfin, je ferai un bilan sur ce que j'ai pu réaliser avant de conclure.
\newpage{}
\section{Les structures d'acceuil}
\section{Structures d'acceuil}
\subsection{Présentation des structures d'accueil}
\paragraph{}
RÉSIF-DC est géré par différents organismes qui sont sous la tutelle du ministère de la transition écologique ainsi que par le ministère de l'enseignement supperieur, de la recherche et de l'inovation\cite{resifOrga}. Quand j'ai signé ma convention, je l'ai fait avec l'Unitée Mixte de Recherche (UMR) ISTerre. En effet, le bureau dans lequel je travaillais se situait dans les locaux de cette UMR. Toutefois, le personnel travaillant dans l'équipe RÉSIF-DC est sous la direction de l'OSUG et de RÉSIF-EPOS. Ainsi, j'ai été amené a integrer une équipe d'ingénieurs OSUG (cf. Figure~\ref{fig:orgaResifDC}).
RÉSIF-DC est géré par différents organismes qui sont sous la tutelle du ministère de la transition écologique ainsi que par le ministère de l'enseignement supperieur, de la recherche et de l'inovation\cite{resifOrga}. Quand j'ai signé ma convention, je l'ai fait avec l'Unitée Mixte de Recherche (UMR) ISTerre. En effet, le bureau dans lequel je travaillais se situait dans les locaux de cette UMR. Toutefois, le personnel travaillant dans l'équipe RÉSIF-DC est sous la direction de l'OSUG et de RÉSIF-EPOS. Ainsi, j'ai été amené a integrer une équipe d'ingénieurs OSUG (cf. Figure~\ref{fig:orgaResifDC}).
\begin{figure}[H]
\caption{Répartition des organismes contribuant à RÉSIF-DC}
\includegraphics[width=\textwidth]{organigrame}
@ -88,44 +95,44 @@
\paragraph{}
L'infrastructure est née d'un besoin de prévention dans le cadre de secousses sismiques. Historiquement, c'est le séisme de Teil (2019), près de Castres, qui a confirmé la vulnérabilité de la France faces aux aléas sismiques de par son impact social et éconimique\cite{resifPres}.
\paragraph{}
Ainsi, RÉSIF contribut
à l'évaluation des aléas et des risques liès à une activité sismique,
Ainsi, RÉSIF contribue
à l'évaluation des aléas et des risques liés à une activité sismique,
à l'évaluation rapide des dégâts,
à la gestion de crises,
aux normes de construction des bâtiments,
à l'établissement d'un lien entre les dégâts sur un immeuble et la sismicité,
à l'évaluation des secousses induitent par l’activité humaine, etcetera\cite{resifPres}.
à l'évaluation des secousses induites par l’activité humaine, etc.\cite{resifPres}.
\subsubsection{RÉSIF-SI}
\paragraph{}
RÉSIF-SI est une acction transverse, impliquant ingénieur\textperiodcentered e \textperiodcentered s et scientifiques provenant de plusieurs laboratoirs et observatoirs tel que l'Institut de Physique du Globe de Paris(IPGP), l'Observatoir des Sciences de l'Univers de Grenoble (OSUG), ISTerre et bien d'autres \cite{resifSI}. Sont but est la collecte, le fomratage, la validation et la qualifiquation de données sismiques, la génération de méta-données, l'archivage des données/méta-données ainsi que leurs distribution. Ainsi, un ensemble de capteurs géophysiques implentés partout en France est maintenu par RÉSIF-SI. Ces capteurs sont répartis en plusieurs réseaux tel que le \href{https://rap.resif.fr}{Réseau d'acelerométrie Permanant} (RAP) ou le \href{https://sismob.resif.fr}{parc national Sismologique Mobile} (SisMob)\cite{resifSI}. Ces capteurs permettent d’alimenter, en partie, l’infrastructure EPOS (European Plate Observing System). RÉSIF-SI, c'est l'organisme majeur qui contibut à cette alimentation. Ainsi les données colléctées par RÉSIF sont disponible via plusieurs \textit{web services} qui sont standardisés par plusieurs organismes tel que EIDA, FDSN et RÉSIF même.\cite{resifSI}
RÉSIF-SI est une action transverse, impliquant ingénieur\textperiodcentered e \textperiodcentered s et scientifiques provenant de plusieurs laboratoires et observatoires tel que l'Institut de Physique du Globe de Paris(IPGP), l'Observatoire des Sciences de l'Univers de Grenoble (OSUG), ISTerre et bien d'autres \cite{resifSI}. Sont but est la collecte, le formatage, la validation et la qualifiquation de données sismiques, la génération de méta-données, l'archivage des données/méta-données ainsi que leurs distribution. Ainsi, un ensemble de capteurs géophysiques implantés partout en France est maintenu par RÉSIF-SI. Ces capteurs sont répartis en plusieurs réseaux tel que le \href{https://rap.resif.fr}{Réseau d'acelerométrie Permanant} (RAP) ou le \href{https://sismob.resif.fr}{parc national Sismologique Mobile} (SisMob)\cite{resifSI}. Ces capteurs permettent d’alimenter, en partie, l’infrastructure EPOS (European Plate Observing System). RÉSIF-SI, c'est l'organisme majeur qui contibue à cette alimentation. Ainsi les données collectées par RÉSIF sont disponible via plusieurs \textit{web services} qui sont standardisés par plusieurs organismes tel que EIDA, FDSN et RÉSIF même.\cite{resifSI}
\subsection{L'OSUG}
\paragraph{}
L'Observatoir des Sciences de l'Univers de Grenoble fédére des laboratoires pour permettre à la recherche dans les sciences de l'Univers, de la Terre et de l'environement, une communication plus facile, une répartition des tâches éfficace et une collaboration favorisée\cite{osugHome}.
L'Observatoire des Sciences de l'Univers de Grenoble fédère des laboratoires pour permettre à la recherche dans les sciences de l'Univers, de la Terre et de l'environnement, une communication plus facile, une répartition des tâches efficace et une collaboration favorisée\cite{osugHome}.
\paragraph{}
Ainsi, l'OSUG permet aux insitituts d'avoir du personel qualifié pour pouvoir assurer une mission d'observation grâce à ces Unités d'Appui et de Recherche (UAR) dont fait partit l'OSUG-DC\cite{osugOrga}.
Ainsi, l'OSUG permet aux insitituts d'avoir du personnel qualifié pour pouvoir assurer une mission d'observation grâce à ces Unités d'Appui et de Recherche (UAR) dont fait partie l'OSUG-DC\cite{osugOrga}.
\subsubsection{OSUG-DC}
\paragraph{}
L'OSUG-DC est une équipe formée principalement d'ingénieur\textperiodcentered e \textperiodcentered s en informatiques s'assurant du traitement et de la diffusion de données d'observations. L'équipe a aussi pour mission de concevoir et développer des logiciels qui seront mis à disposition de la communauté scientifique\cite{osugDC}.
\subsubsection{RÉSIF-DC}
\paragraph{}
Ainsi, des membres de l'OSUG-DC forment l'équipe RÉSIF-DC, chargé de développer et maintenir les \textit{web services} RÉSIF. C'est dans ce cadre s'inscrit mon stage et c'est dans ce contexte que j'ai interagi avec les membres de l'équipe.
Ainsi, des membres de l'OSUG-DC forment l'équipe RÉSIF-DC, chargée de développer et maintenir les \textit{web services} RÉSIF. C'est dans ce cadre que s'inscrit mon stage et c'est dans ce contexte que j'ai interagi avec les membres de l'équipe.
\subsection{ISTerre}
\paragraph{}
ISTerre (Instutu des Sciences de la Terre) est un laboratoire crée en 2011, fédéré par l'OSUG\cite{isterreEnBref}, dont l’objectif scientifique est l’étude physique et chimique de notre planète\cite{isterrePlaquette}. Le laboratoire est réparti sur deux villes, Chambery et Grenoble. Le nombre de personnes travaillant pour ce laboratoire 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’action du laboratoire, celui-ci a un budget annuel d’envirion 15 millions d’euros\cite{isterrePlaquette}.
ISTerre (Instutut des Sciences de la Terre) est un laboratoire créé en 2011, fédéré par l'OSUG\cite{isterreEnBref}, dont l’objectif scientifique est l’étude physique et chimique de notre planète\cite{isterrePlaquette}. Le laboratoire est réparti sur deux villes, Chambery et Grenoble. Le nombre de personnes travaillant pour ce laboratoire est assez important: près de 300 personnes en additionant les 2 sites dont la pluparts sont scientifiques (20\% du personnel sont des technicien·ne·s). Pour donner une idée du pourvoir d’action du laboratoire, celui-ci a un budget annuel d’environ 15 millions d’euros\cite{isterrePlaquette}.
\paragraph{}
ISTerre travaille en collaboration avec plusieurs pays, notamment 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\cite{isterrePlaquette}. Le travail scientifique du laboratoire ce retrouve chaque année dans près de 250 articles de recherches et dans de nombreuses actions de vulgarisations scentifiques\cite{isterrePlaquette}. Ces connaissances on put être récoltées grâce aux différentes actions menées comme des déplacements dans des lieux sismiques, la récolte et la distribution de données aquisent par différents réseaux d’instruments géophysiques, l’analyse d’échentillons naturels, et grâce à de nouvelles modelisations et expérimentations\cite{isterrePlaquette}. La récolte et le traitement des données s’articule autour de 3 grand axes pour ISTerre\cite{isterreScientifics}:
ISTerre travaille en collaboration avec plusieurs pays, notamment 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\cite{isterrePlaquette}. Le travail scientifique du laboratoire ce retrouve chaque année dans près de 250 articles de recherche et dans de nombreuses actions de vulgarisations scientifique\cite{isterrePlaquette}. Ces connaissances on put être récoltées grâce aux différentes actions menées comme des déplacements dans des lieux sismiques, la récolte et la distribution de données aquises par différents réseaux d’instruments géophysiques, l’analyse d’échantillons naturels, et grâce à de nouvelles modélisations et expérimentations\cite{isterrePlaquette}. La récolte et le traitement des données s’articule autour de trois grands axes pour ISTerre\cite{isterreScientifics}:
\begin{enumerate}
\item Peuton 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?
\item Peut-on identifier des précurseurs aux grands événements qui boulverssent notre planète? Quels sont les processus physiques qui gouvernent les séismes, les mouvements de terrain, les éruptions volcaniques, les varuations du champ magnétique terrestre?
\item Comment la surface de la Terre est-elle façonnée par les interactions entre les processus profonds et les processus de surface?
\item Comment roches et sols enregistrent les perturbations physico-chimique naturelles ou anthropique de leur environnement? Quelles sont les mécanismes qui gouvernent la croissance, la sorption et l’alteration des minéraux? Comment les processus hydrothermaux et magnétiques concernent-ils les ressources minérales? Comment produire de l’hydrogène? La carbonatation minérale, une voie pour le stockage du CO2?
\end{enumerate}
\newpage{}
\section{Présetation du stage}
\section{Présentation du stage}
\subsection{Gestion de projet}
\subsubsection{Ce que j'ai fait}
\subsubsection{Réalisé}
\paragraph{}
Sachant que j'étais sur un projet seul, le besoin de planification ne c'est pas vraiment fait ressentir. En effet, ce genre de methode est très util dans les projets de groupes ou les acteur\textperiodcentered ice\textperiodcentered s ont besoin de communiquer leurs avancées ainsi que le plans d'actions. Ainsi, je n'ai pas réalisé de diagramme de GANTT et c'est seuelement a posteriori que j'en ai construit un (cf. Figure \ref{fig:GANTT}). Cepandant, j'ai quand même organisé mon travail en différentes tâches qui respectent un certain patern. En effet, pour chaque \textit{web services}, je faisais une tâche \textit{Scénario} et une tâche \textit{Implémentation}. Chaqu'une de ces tâches était elle même divisée en sous-tâches. Par exemple, la tache \textit{Station Implementation} avait une sous-tâche nommé \textit{given the paramerter value from start to end on the level "level" [STATION]} ou encore \textit{Make xml validator computes str and not etree}.
Sachant que j'étais sur un projet seul, le besoin de planification au long terme ne s'est pas vraiment fait ressentir. En effet, ce genre de methode est très utile dans les projets de groupes ou les acteur\textperiodcentered ice\textperiodcentered s ont besoin de communiquer leurs avancées ainsi que le plans d'actions. Ainsi, je n'ai pas réalisé de diagramme de GANTT et c'est seuelment a posteriori que j'en ai construit un (cf. Figure \ref{fig:GANTT}). Cependant, j'ai quand même organisé mon travail en différentes tâches qui respectent un certain schéma. En effet, pour chaque \textit{web services}, je faisais une tâche \textit{Scénario} et une tâche \textit{Implémentation}. Chacune de ces tâches était elle-même divisée en sous-tâches. Par exemple, la tache \textit{Station Implementation} avait une sous-tâche nommée \textit{given the paramerter value from start to end on the level "level" [STATION]} ou encore \textit{Make xml validator computes str and not etree}.
\begin{figure}[H]
\label{fig:GANTT}
\caption{Réalisation du travail}
@ -139,33 +146,33 @@
\includegraphics[scale=0.5, frame]{taskGitlab}
\label{fig:task}
\end{figure}
\subsubsection{L'organisation de l'équipe}
\subsubsection{Organisation de l'équipe}
\paragraph{}
La manière dont l'équipe s'organisait était structurée de la sorte:
\begin{itemize}
\item \textbf{Tout les matins}: \textit{Point avec mon tutereur de stage}: définition des objectifs du jours
\item \textbf{Lundi matin à 11h}: \textit{Réunion ticket}: Point sur les réalisations de la semaine précédante + explication du travail à fournir pour la semaine qui vient par et pour chaque membre de l'équipe.
\item \textbf{Le reste du temps}: \textit{travail individuel}: Chaque membre de l'équipe travail sur ses tâches (seul\textperiodcentered e ou en groupe)
\item \textbf{Tous les matins}: \textit{Point avec mon tuteur de stage}: définition des objectifs du jour
\item \textbf{Lundi matin à 11h}: \textit{Réunion ticket}: Point sur les réalisations de la semaine précédente et explication du travail à fournir pour la semaine qui vient par et pour chaque membre de l'équipe.
\item \textbf{Le reste du temps}: \textit{travail individuel}: Chaque membre de l'équipe travaille sur ses tâches (seul\textperiodcentered e ou en groupe)
\end{itemize}
\subsection{Environement}
\subsection{Environnement}
\paragraph{}
Le laboratore est pricipalement constitué de chercheur\textperiodcentered euse\textperiodcentered s dans diférrents dommaines, ce qui donne un environement très riche où les interactions entre les membre des differents services sont assez édifantes.
Cependant, durant mon stage, j'étais la pluspars du temps dans un bureau avec une équipe de 4 personnes.
Le laboratore est pricipalement constitué de chercheur\textperiodcentered euse\textperiodcentered s dans différents domaines, ce qui donne un environnement très riche où les interactions entre les membres des différents services sont assez édifantes.
Cependant, durant mon stage, j'étais la pluspart du temps dans un bureau avec une équipe de 4 personnes.
\begin{itemize}
\item \textbf{Jonathan Schaeffer}: responsable infrastructure et coordinateur de l'équipe Résif-DC
\item \textbf{David Wolyniec}: ingénieur expert données et responsable de l'intégration des donnés des noeuds A \textit{RAP} et \textit{SISMOB}
\item \textbf{David Wolyniec}: ingénieur expert données et responsable de l'intégration des données des noeuds A \textit{RAP} et \textit{SISMOB}
\end{itemize}
\subsection{L'existant}
\subsection{Existant}
\paragraph{}
Quand je suis arrivé, les differents \textit{web services} que j'avais à tester été terminés et déployés par une ancienne équipe. Il existait déjà une suite de tests développée par cette même équipe. Cependant, les tests étaient effectués sans bibliothèque ou \textit{framework} de test, ce qui rendait difficile son maintient.
\paragraph{}
L'équipe RESIF-DC, dans laquelle je me trouvais, avait déjà effectué quelques tests avec la bibliothèque \textit{behave} pour decider quelle bibliothèque utiliser pour le faire ces derniers.
Cependant, pour ne pas brider ma créativité, il a été décidé que je parte de zéro et que seulement une fois que j'aurai fini d'écrire mes scénarios, je regarde les différents scénarios définit par l'équipe.
\subsection{Les objectifs}
En vue d'une refonte de cette suite de tests, l'équipe RÉSIF-DC avait déjà essayé différents frameworks avant de sélectionner Behave et de démarrer une première ébauche de tests autour du \textit{web service} station.
Cependant, pour ne pas brider ma créativité, il a été décidé que je parte de zéro et que seulement une fois que j'aurais fini d'écrire mes scénarios, je regarde les différents scénarios définis par l'équipe.
\subsection{Objectifs}
\paragraph{}
Les objectifs de mon stage étaient multiples. En effet, je devais développer une suite de tests capable de vérifier le comportement des \textit{web services} dans des cas de mise en difficulté ainsi que de vérifier le simple fonctionement de ces derniers. Un des effet de bord de cela est que j'ai pu détecter des bugs des \textit{web services}.
\paragraph{}
@ -176,39 +183,39 @@
\paragraph{}
Lors de ma première semaine de stage, mon principal objectif été de prendre en main le contexte dans lequel j'allais travailler. En effet, j'ai principalement lu de la documentation sur les termes techniques (glossaire), sur la sismologie, sur les standards FDSN, \dots
\paragraph{}
Ensuite, j'ai pu commencer à prendre en main l'outil \textit{behave} et me rafraîchir la mémoire au niveau du langage \textit{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 parallèle de ca, j'ai pu prendre en main d'autre bibliothèque tel que \textit{lxml} ou \textit{requests}.
\subsubsection{La FDSN}
Ensuite, j'ai pu commencer à prendre en main l'outil \textit{behave} et me rafraîchir la mémoire au niveau du langage \textit{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 parallèle de ca, j'ai pu prendre en main d'autre bibliothèque telles que \textit{lxml} ou \textit{requests}.
\subsubsection{FDSN}
\paragraph{}
La \textit{Federation of Digital Seismograph Networks} (FDSN) est une organisation qui fedère des laboratoires de sismologie dont le but est d'installer et maintenir des stations sismologiques ausi bien nationalement qu'internationalement. La FDSN a notament normalisé la diffusion de données et méta-données par des formats tel que le \textit{MiniSEED} ou le \textit{StationXML}\cite{fdsnAbout, wikiFDSN}.
\subsection{Les outils utilisés}
\subsubsection{Python}
\paragraph{}
\textit{Python}\cite{wikiPython} est un langage de programmation orienté objet qui est accessible à un large publique. Cette accessibilité apporte certaines contraintes, notamment au niveau objet. En effet, des notions importantes du paradigme objet ne sont pas présentes, ce qui peut géner lors de la conception du logiciel.
\textit{Python}\cite{wikiPython} est un langage de programmation orienté objet qui est accessible à un large public. Cette accessibilité apporte certaines contraintes, notamment au niveau objet. En effet, des notions importantes du paradigme objet ne sont pas présentes, ce qui peut géner lors de la conception du logiciel.
\subsubsection{Pipenv}
\paragraph{}
\textit{Pipenv}\cite{pipenvReedme} est un outil de gestion d'environement virtuel. Un environement virtuel est un ensemble de programmes qui viennent s'ajouter ou remplacer une version du même programme. En \textit{python}, cela sert principalement à importer la verssion de \textit{python} avec laquellz a été implémentés le code et les bibliothèques utilisés par celui-ci. Ainsi, \textit{pipenv} permet d'ajouter des bibliothèque et framework à un environement virtuel. Ainsi, lors du déploiment du projet, il n'y aura pas de conflit de versions ou de bibliothèques manquantes grâce à l'environement virtuel. Autrement dit, c'est comme si la machine qui éxécute le projet avais la même configuration que la machine qui a servi à développer.
\textit{Pipenv}\cite{pipenvReedme} est un outil de gestion d'environement virtuel. Un environement virtuel est un ensemble de programmes qui viennent s'ajouter ou remplacer une version du même programme. En \textit{python}, cela sert principalement à importer la verssion de \textit{python} avec laquelle ont été implémentés le code et les bibliothèques utilisés par celui-ci. Ainsi, \textit{pipenv} permet d'ajouter des bibliothèques et frameworks à un environnement virtuel. Ainsi, lors du déploiement du projet, il n'y aura pas de conflit de versions ou de bibliothèques manquantes grâce à l'environnement virtuel. Autrement dit, c'est comme si la machine qui éxécute le projet avait la même configuration que la machine qui a servi à développer.
\subsubsection{Behave}
\paragraph{}
\textit{Behave}\cite{behavePypi, behaveHome} est une implementation en \textit{python} de \textit{cucumber}, un framework de test comportemental. Cela permet de tester le comportement d'un logiciel sans rentrer dans le code, contrairement à d'autres types de tests tels que les tests unitaires ou les tests fonctionels. Cela possède son lot d'avantages et d'inconvénient. Pour ce qui est des aventages, je n'ai pas eu besoin d'entrer dans le détail des \textit{web services}, d'autant plus que ces codes sont dificiles à comprendre car ils n'ont pas été codés dans un langage de programmation mais en SQL. Un des inconvéniant de ce type de test est qu'il est plus difficile de repérer le morceau de code qui provoque un bug détécté par les tests comportementeaux.
\textit{Behave}\cite{behavePypi, behaveHome} est une implementation en \textit{python} de \textit{cucumber}, un framework de test comportemental. Cela permet de tester le comportement d'un logiciel sans rentrer dans le code, contrairement à d'autres types de tests tels que les tests unitaires ou les tests fonctionnels. Cela possède son lot d'avantages et d'inconvénients. Pour ce qui est des avantages, je n'ai pas eu besoin d'entrer dans le détail des \textit{web services}, d'autant plus que ces codes sont difficiles à comprendre car ils n'ont pas été codés dans un langage de programmation mais en SQL. Un des inconvénients de ce type de test est qu'il est plus difficile de repérer le morceau de code qui provoque un bug détécté par les tests comportementeaux.
\paragraph{}
Le fontionement du framework est assez simple. Il faut faire des fichiers de \textit{feature} écris en langage naturel (français, anglais, mandarin, \dots). Ensuite, chaque ligne est associée à un morceau de code qui vas faire les tests. Par example, une ligne "Étant donné le parametre network égale à FR" est associée à un bout de code qui vas dire au contexte du test que le réseau à utilisé est FR.
Le fonctionnement du framework est assez simple. Il faut faire des fichiers de \textit{feature} écrits en langage naturel (français, anglais, mandarin, \dots). Ensuite, chaque ligne est associée à un morceau de code qui va faire les tests. Par exemple, une ligne "Étant donné le parametre network égale à FR" est associée à un bout de code qui va dire au contexte du test que le réseau à utilisé est FR.
\subsubsection{Git}
\paragraph{}
Git\cite{gitAbout} est un outil de versionage, principalement utilisé dans le développement. Il permet de pouvoir revenir à tout moment sur une version précédente du code produit pour pouvoir ainsi revenir en arrière en cas de déviation trop importante entre le code et ce qui est attendu. Git permet aussi de diviser un projet en branches, c'est à dire que plusieurs personnes peuvent collaborer sans ce gener si ces personnes se situent sur des branche différentes. Quand le travail sur deux branche est terminé, il est possible de les fusioner (\textit{merge}) pour que le projet continu avec la production des colaborateur\textperiodcentered ice\textperiodcentered s des branches fusionées.
Git\cite{gitAbout} est un outil de gestion de version, principalement utilisé dans le développement. Il permet de pouvoir revenir à tout moment sur une version précédente du code produit pour pouvoir ainsi revenir en arrière en cas de déviation trop importante entre le code et ce qui est attendu. Git permet aussi de diviser un projet en branches, c'est à dire que plusieurs personnes peuvent collaborer sans se gêner si ces personnes se situent sur des branches différentes. Quand le travail sur deux branches est terminé, il est possible de les fusionner (\textit{merge}) pour que le projet continue avec la production des colaborateur\textperiodcentered ice\textperiodcentered s des branches fusionnées.
\paragraph{}
Une extention de git, nommé \textit{git flow}\cite{gitflow} est faite pour avoir une arborescance git optimale pour la collaboration (cf. Figure~\ref{fig:gitflow}). Elle divise le projet en deux branche: \textit{main} et \textit{develop}. La branche \textit{main} correspond au code fonctionnel, prêt à être utilisé et stable. C'est la branche à utiliser pour un\textperiodcentered e utilisateur\textperiodcentered ice lambda. La branche \textit{develop} correspond à la version instable du projet, celle qui tend à être stable. C'est la brache dans laquelle les dévloppeur\textperiodcentered{}euse\textperiodcentered s fusionnent (\textit{merge}) leur travail. Ce travail est produit dans des branches spécifiques appeler \textit{feature} qui coresspond à une fonctinalité du programme. Ainsi, les bugs dût à la progression du code de la fonctinnalité n'affecte pas les autres colaborateur\textperiodcentered ice\textperiodcentered s qui travaillent sur autre chose.
Une extention de git, nommé \textit{git flow}\cite{gitflow} est faite pour avoir une arborescence git optimale pour la collaboration (cf. Figure~\ref{fig:gitflow}). Elle divise le projet en deux branches: \textit{main} et \textit{develop}. La branche \textit{main} correspond au code fonctionnel, prêt à être utilisé et stable. C'est la branche à utiliser pour un\textperiodcentered e utilisateur\textperiodcentered ice lambda. La branche \textit{develop} correspond à la version instable du projet, celle qui tend à être stable. C'est la brache dans laquelle les dévloppeur\textperiodcentered{}euse\textperiodcentered s fusionnent (\textit{merge}) leur travail. Ce travail est produit dans des branches spécifiques appelées \textit{feature} qui corespond à une fonctionnalité du programme. Ainsi, les bugs dus à la progression du code de la fonctionnalité n'affecte pas les autres colaborateur\textperiodcentered ice\textperiodcentered s qui travaillent sur autre chose.
\begin{figure}[H]
\centering
\caption{Schéma du fonctionement de git flow}
\caption{Schéma du fonctionnement de git flow}
\includegraphics[scale=0.4]{gitflow}
\label{fig:gitflow}
\end{figure}
\subsubsection{Gitlab}
\label{chap:gitlab}
\paragraph{}
Gitlab\cite{gitlab} est un logiciel de type serveur permetant de stocker un dêpot git et de le redistribuer ensuite. Il permet la centralisation du code ce qui abouti à une collaboration plus efficace. En effet, Ce qu'apporte gitlab par rapport à un simple serveur de partage de fichiers comme \textit{nfs} ou \textit{ftp}, c'est de pouvoir avoir une version sur sa propre machine, coder sur cette version locale et soumettre ses modifications au dêpot distant (gitlab) avec une gestion intelligente des conflits (quand plusieurs personnes modifient un même fichier au même endoit).
Gitlab\cite{gitlab} est un logiciel de type serveur permettant de stocker un dêpot git et de le redistribuer ensuite. Il permet la centralisation du code ce qui aboutit à une collaboration plus efficace. En effet, ce qu'apporte gitlab par rapport à un simple serveur de partage de fichiers comme \textit{nfs} ou \textit{ftp}, c'est de pouvoir avoir une version sur sa propre machine, coder sur cette version locale et soumettre ses modifications au dépôt distant (gitlab) avec une gestion intelligente des conflits (quand plusieurs personnes modifient un même fichier au même endoit).
\paragraph{}
Gitlab possède aussi une interface web qui permet de faire de la gestion de projet grâce à la section \textit{issue} et \textit{tableau}(cf. Figure~\ref{fig:gitlabBoard}). En effet, pour une tâche donnée, il fallait faire une \textit{issue} qui y correspondait. On peut voir une \textit{issue} comme un \textit{post it} qui peut être détaillé et commenté. Alors, chaque \textit{issue} était labbelisé par un ou plusieurs tags qui permettent d'identifier les différente categories à laquelle correspondait la tâche. Parmis ces tags, on peu retrouver les tags: \textit{TODO}, \textit{IN PROGRESS} et \textit{DONE}. C'est la que là section tableau de gitlab intervient. En effet, cet outil permet de visualiser les \textit{issues} par tags. Si l'on met les 3 tags précédants en collones du tableau, alors, on simuler un tableau \textit{scrum} et suivre cette methode de travail.
Gitlab possède aussi une interface web qui permet de faire de la gestion de projet grâce à la section \textit{issue} et \textit{tableau}(cf. Figure~\ref{fig:gitlabBoard}). En effet, pour une tâche donnée, il fallait faire une \textit{issue} qui y correspondait. On peut voir une \textit{issue} comme un \textit{post it} qui peut être détaillé et commenté. Alors, chaque \textit{issue} était étiqueté par un ou plusieurs tags qui permettent d'identifier les différentes categories à laquelle correspondait la tâche. Parmi ces tags, on peut retrouver les tags: \textit{TODO}, \textit{IN PROGRESS} et \textit{DONE}. C'est là que la section tableau de gitlab intervient. En effet, cet outil permet de visualiser les \textit{issues} par tags. Si l'on met les 3 tags précédants en colonnes du tableau, alors, on simule un tableau \textit{scrum} et suit cette methode de travail.
\begin{figure}[H]
\centering
\caption{Capture d'écran du tableau de gitlab}
@ -218,38 +225,38 @@
\subsection{Les données}
\paragraph{}
Les données sont réparties en plusieurs entités: le réseau, la station et le canal. Elle sont répartis de la manière suivante:
Les données sont réparties en plusieurs entités: le réseau, la station et le canal. Elle sont réparties de la manière suivante:
Le \textit{Network} corré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 opperations faisant intervenir plusieurs pays différent, il est possible de décentraliser les données et de les retrouver facielement.
Le \textit{Network} correspond à 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 opérations faisant intervenir plusieurs pays différents, il est possible de décentraliser les données et de les retrouver facilement.
\subsubsection{La station}
\paragraph{}
Une \textit{Station} est une représentation abstaite du lieu où sont placés différents capteurs. Elle est aussi identifiée par un code alphanumérique (exemple: 'CFF'). Les stations sont réparties dans les différents réseaux en fonction du cadre de l'opération dont elle fait partie.
\subsubsection{Le canal}
\paragraph{}
Un \textit{Channel} correspond à 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.
Un \textit{Channel} correspond à 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 veut dire qu'il y a eu une interruption 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.
\caption{Parcours de la donnée depuis l'aquisition jusqu'à la distribution\cite{articleResif}}
\caption{Parcours de la donnée depuis l'acquisition jusqu'à la distribution\cite{articleResif}}
\label{fig:parcourDonnee}
\end{figure}
\paragraph{}
Comme on peut le voir sur la figure~\ref{fig:parcourDonnee}, la donnée récoltée par les stations RÉSIF est directement 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 a pour mission de la distribuer aux utilisateur\textperiodcentered ice\textperiodcentered s, notament au Commissariat à l’Énergie Atomique (CEA) qui peux lancer des alertes aux populations en cas de données montrant un séisme dangereux. Pour palier à cette mission, le \textit{noeud B} met à disposition plusieus \textit{web services} pour tout\textperiodcentered se\textperiodcentered s.
Comme on peut le voir sur la figure~\ref{fig:parcourDonnee}, la donnée récoltée par les stations RÉSIF est directement 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 a pour mission de la distribuer aux utilisateur\textperiodcentered ice\textperiodcentered s, notamment au Commissariat à l’Énergie Atomique (CEA) qui peut lancer des alertes aux populations en cas de données montrant un séisme dangereux. Pour palier à cette mission, le \textit{noeud B} met à disposition plusieus \textit{web services} pour tout\textperiodcentered se\textperiodcentered s.
\subsection{Les differents web services}
\subsubsection{Comment utiliser un web service ?}
\label{txt:explicationURL}
Durant mon stage, j'ai dût travailler sur différents \textit{web services}.
Durant mon stage, j'ai dû travailler sur différents \textit{web services}.
Chaque \textit{web service} est interrogeable via URL. L'URL est composée en différentes parties
\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 contexte de production. Il en exist d'autres pour d'autres contextes.
\item \textit{le chemin vers le web service}: /fdsnws/station/1/query. Ce chemin permet d'identifier le \textit{web service} que l'on veut interroger. Il est composé en 4 parties: la norme (fdsnws), le \textit{web service} (station), la version (1), et le mode d'inerrogation (query).
\item \textit{les parametres}: ?net=FR\&sta=CFF\&level=channel. Le début de la liste de paramètres doit commencer par un "?". Ensuite, chaque paramètre doit être séparé par un "\&". Enfin, la forme que prend la définition d'un paramètre est: $<$paramètre$>$=$<$valeur$>$
\item \textit{le nom de domaine}: ws.resif.fr. Ce nom de domaine est variable selon le contexte. En effet, celui-ci est le nom de domaine pour le contexte de production. Il en existe d'autres pour d'autres contextes.
\item \textit{le chemin vers le web service}: /fdsnws/station/1/query. Ce chemin permet d'identifier le \textit{web service} que l'on veut interroger. Il est composé en 4 parties: la norme (fdsnws), le \textit{web service} (station), la version (1), et le mode d'interrogation (query).
\item \textit{les paramètres}: ?net=FR\&sta=CFF\&level=channel. Le début de la liste de paramètres doit commencer par un "?". Ensuite, chaque paramètre doit être séparé par un "\&". Enfin, la forme que prend la définition d'un paramètre est: $<$paramètre$>$=$<$valeur$>$
Pour accéder aux données, il faut interroger le bon \textit{web service} avec une URL structurée. Voici les différents \textit{web services} que j'ai testé.
\subsubsection{Station}
\paragraph{}
Le \textit{web service} \textbf{\textit{\href{https://ws.resif.fr/fdsnws/station/1}{station}}} permet de récupérer les méta-données des stations de mesure. C'est à dire, leur nom, leur position, les cannaux disponible, etcétéra. Bien qu'il soit possible de récuperer ces méta-données sous forme de texte, le principal format pour ce genre de requête 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 requêtes, \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 même requête sous le format text} (liens cliquables).
Le \textit{web service} \textbf{\textit{\href{https://ws.resif.fr/fdsnws/station/1}{station}}} permet de récupérer les méta-données des stations de mesure. C'est à dire, leur nom, leur position, les cannaux disponibles, etc.. Bien qu'il soit possible de récupérer ces méta-données sous forme de texte, le principal format pour ce genre de requête est le StationXML, un dérivé du XML. Ce format permet un traitement numérique plus facile ainsi qu'une plus grande capacité à contenir des informations qu'un format texte habituel. Voici deux exemples de requêtes, \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 même requête sous le format text} (liens cliquables, cf. Figure~\ref{fig:URLstationXML}, Figure~\ref{fig:URLstationText} pour la version papier).
\begin{figure}[H]
\caption{Exemple d'une requête \textit{station} demandant du StationXML pour la station FR.CFF }
Le \textit{web service} \textbf{\textit{\href{https://ws.resif.fr/fdsnws/availability/1}{availability}}} permet aux chercheur\textperiodcentered euse\textperiodcentered s de pouvoir connaître les périodes dans lesquelles il y a des données étant donné des réseaux, des stations ou des canneaux.
Le \textit{web service} \textbf{\textit{\href{https://ws.resif.fr/fdsnws/availability/1}{availability}}} permet aux chercheur\textperiodcentered euse\textperiodcentered s de pouvoir connaître les périodes dans lesquelles il y a des données étant donné des réseaux, des stations ou des canaux.
\paragraph{}
Ce \textit{web service} est décomposé en deux points d'entrées qui donnent des résultat différent car la nature de ce que l'on demande est différente. Dans le cas du point d'entrée \textit{query}, on veux savoir les plages temporelles \textbf{continue} disponibles. 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}.
Ce \textit{web service} est décomposé en deux points d'entrée qui donnent des résultats différents car la nature de ce que l'on demande est différente. Dans le cas du point d'entrée \textit{query}, on veut savoir les plages temporelles \textbf{continue} disponibles. Pour le point d'entrée \textit{extent}, on demande aussi les plages temporelles disponibles à 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 matérialisera par le changement de chemin vers le \textit{web service} (cf. explication de l'url \ref{txt:explicationURL}). En effet, les chemins ressembleront à cela:
\begin{itemize}
@ -275,7 +282,7 @@
\item \textit{fdnsws/availability/1/extent} pour \textit{extent}.
\end{itemize}
\paragraph{}
Voici des exemples de requêtes \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}.
Voici des exemples de requêtes \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}(cf. Figure~\ref{fig:URLavailabilityText}, Figure~\ref{fig:URLavailabilityJson}, Figure~\ref{fig:URLavailabilityCsv} pour la version papier).
\begin{figure}[H]
\caption{Exemple d'une requête \textit{availability} demandant du texte pour la station FR.CFF }
Le \textit{web service} \textbf{\textit{\href{https://ws.resif.fr/fdsnws/dataselect/1}{dataselect}}} permet de sélectionner des données en fonction des réseaux, stations et canneaux sur une periode de temps. Le format de la réponse est un fichier binaire sour le format \textit{MiniSEED}. Il est donc néscaissaire d'avoir un outil pour lire ce type de fichier.
Le \textit{web service} \textbf{\textit{\href{https://ws.resif.fr/fdsnws/dataselect/1}{dataselect}}} permet de sélectionner des données en fonction des réseaux, stations et canaux sur une periode de temps. Le format de la réponse est un fichier binaire sous le format \textit{MiniSEED}. Il est donc nécessaire d'avoir un outil pour lire ce type de fichier.
\subsubsection{PH5}
Les \textit{web services} \textbf{\textit{\href{https://ph5ws.resif.fr/fdsnws/dataselect/1}{dataselect}}} et \textbf{\textit{\href{https://ph5ws.resif.fr/resifws/availability/1}{availability}}} ont aussi leur version en PH5. C'est à dire que ce sont des gros fichiers stockés sous le format PH5 et délivrés sous les formats disponibles mentionnés plus haut.
\subsection{Réflexion sur les sénarios}
@ -291,13 +298,13 @@
\paragraph{}
Pour établir un scénario, il me fallait prendre un temps de réflexion pour comprendre le \textit{web service} que je m'apprêtais à tester. Pour cela, j'ai pu avoir une approche pour cerner les cas intéressants.
\paragraph{}
Tout d'abord, je lisais la documentation des \textit{web services} pour bien comprendre leurs utilités. Ensuite, je devais comprendre l'utilisation des paramètres qui permettent de restraindre la donnée. Une fois cette étape réalisée, je faisais varier les paramètres entre des valeurs normales, des valeurs improbables et des valeurs aux limites de ce que le \textit{web service} autorisait (par exemple, une latitude 181°).
Tout d'abord, je lisais la documentation des \textit{web services} pour bien comprendre leur utilité. Ensuite, je devais comprendre l'utilisation des paramètres qui permettent de restreindre la donnée. Une fois cette étape réalisée, je faisais varier les paramètres entre des valeurs normales, des valeurs improbables et des valeurs aux limites de ce que le \textit{web service} autorisait (par exemple, une latitude 181°).
\paragraph{}
Ainsi, en combinant les paramètres, je créais des URL et les testais pour voir le comportement du \textit{web service}. C'est ici que se situait la pricnipale difficulté dans le processus de réflexion. En effet, c'est dans ces moment là qu'il fallait déterminer si le \textit{web service} se comportait normalement. Aussi, il est possible que j'eu oublié des cas du fait de cette methode. Cependant, c'est la meilleur que j'ai pu trouvé pour avoir des idées de scénarios.
Ainsi, en combinant les paramètres, je créais des URL et les testais pour voir le comportement du \textit{web service}. C'est ici que se situait la princnipale difficulté dans le processus de réflexion. En effet, c'est dans ces moment là qu'il fallait déterminer si le \textit{web service} se comportait normalement. Aussi, il est possible que j'eu oublié des cas du fait de cette methode. Cependant, c'est la meilleure que j'ai pu trouver pour avoir des idées de scénarios.
\subsection{L'écriture des scénarios}
\subsection{Écriture des scénarios}
\paragraph{}
Pour pouvoir tester le fonctionement des differents \textit{web services}, j'ai du écrire des scénarios. Ceux-ci sont la traduction en mots de la période de réflexion expliquée plus haut (cf. Chapitre ~\ref{chap:scenarReflexion}). Ces scénarios sont décomposés en plusieurs éléments appelés \textit{steps}:
Pour pouvoir tester le fonctionnement des differents \textit{web services}, j'ai du écrire des scénarios. Ceux-ci sont la traduction en mots de la période de réflexion expliquée plus haut (cf. Chapitre ~\ref{chap:scenarReflexion}). Ces scénarios sont décomposés en plusieurs éléments appelés \textit{steps}:
\begin{itemize}
\item Le type de \textbf{scénario (outline/inline)} et son titre (ex. \textit{Scenario Outline:} S'abonner à des chaines Peertube)
\item \textbf{L'initialisation} du contexte en fonction du comportement souhaité (ex. \textit{Étant donné} que je suis connécté·e avec mon compte)
@ -306,12 +313,12 @@
\item \textbf{Les exemples} de paramètres qui vont être testés si on est \textbf{dans un scénario outline} (ex. \textit{Par exemple}, si je m'abonne à 'Hygiene mental', à 'Politikon', à 'Tzitzimitl')
\end{itemize}
\paragraph{}
Le format du ficher de scénario permet d'utiliser un langage naturel quelqu'il soit. Cependant, il y a quand même des mots clefs qui sont écrits en anglais. J'ai donc rédigé les scénarios en anglais pour permettre une meilleure fuidité de lecture ainsi que pour internationaliser mes scénarios dans un contexte polylingue tel qu'au laboratoire ISTerre.
Le format du ficher de scénario permet d'utiliser un langage naturel quelqu'il soit. Cependant, il y a quand même des mots clefs qui sont écrits en anglais. J'ai donc rédigé les scénarios en anglais pour permettre une meilleure fuidité de lecture ainsi que pour internationaliser mes scénarios dans un contexte polylingue tel qu'au laboratoire ISTerre.
\paragraph{}
Pour ne pas répéter de code inutilement, j'essayais à chaque fois de réutiliser les mêmes \textit{steps}. C'est ainsi que dans touts mes scénarios, je réalise le même \textit{step}: \textit{When the web service is "GET|POST" requested}. En effet, ce \textit{step} me permet de faire une requête au \textit{web service} qui était paramétré. Ainsi, j'évite de faire un \textit{step} par \textit{web service}, ce qui facilite l'écriture de scénario pour le futur.
\subsubsection{Les tags}
Pour ne pas répéter de code inutilement, j'essayais à chaque fois de réutiliser les mêmes \textit{steps}. C'est ainsi que dans tout mes scénarios, je réalise le même \textit{step}: \textit{When the web service is "GET|POST" requested}. En effet, ce \textit{step} me permet de faire une requête au \textit{web service} qui était paramétré. Ainsi, j'évite de faire un \textit{step} par \textit{web service}, ce qui facilite l'écriture de scénario pour le futur.
\subsubsection{Tags}
\paragraph{}
Dans behave, il existe une notion de tag qui permet de labéliser des scénarios. Ainsi, j'ai pu différencier plusieurs types de scénarios:
Dans behave, il existe une notion de tag qui permet d'étiqueter des scénarios. Ainsi, j'ai pu différencier plusieurs types de scénarios:
\begin{itemize}
\item Ceux qui testent le code de retour de la requête: \textit{@HTTPStatus}
\item Ceux qui testent que le \textit{web service} retourne une réponse correcte (cas particulier du tag précédent (code de retour égale à 200)): \textit{@200}
@ -322,14 +329,14 @@
\paragraph{}
Le tag \textit{@failling} met souvent en évidence un bug.
\subsection{L'implémenation des tests}
\subsection{Implémenation des tests}
\paragraph{}
Pour implementer mes tests, j'ai dût reprendre chaque \textit{step} 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ésultats des \textit{When} avec ce qui était attendu. Aussi, toujours pour les mêmes raisons évoquées plus haut, le code est écrit en anglais.
\subsubsection{Exemples de scénarios}
Pour implementer mes tests, j'ai dû reprendre chaque \textit{step} du scénario (\textit{Given, When, Then, And, But}) et coder leurs sens. Par exemple, pour un \textit{Given}, la plupart du temps, je devais initialiser le contexte, pour les \textit{Then}, je devais comparer les résultats des \textit{When} avec ce qui était attendu. Aussi, toujours pour les mêmes raisons évoquées plus haut, le code est écrit en anglais.
\subsubsection{Exemples}
\paragraph{}
Voici un exemple de scénario qui illustre le travail depuis l'écriture de ce dernier, jusqu'à son implémentation.
\paragraph{}
Sur la figure~\ref{fig:scenarioLatitudeFeature}, on demande à \textit{behave} d'exécuter trois \textit{steps} différents: un pour initialiser le paramètre \textit{latitude} avec la valeur \textit{-100} (la latitude minimale sur Terre est de -90°, au dela, les coordonées décrivent un point dans l'espace), un pour transmettre la requête au \textit{web service} et enfin, un pour vérifier que le code de retour du \textit{web service} est bien égale à 400 (le code 400 signifit que l'utilisateur\textperiodcentered ice a fait une erreur dans sa requête).
Sur la figure~\ref{fig:scenarioLatitudeFeature}, on demande à \textit{behave} d'exécuter trois \textit{steps} différents: un pour initialiser le paramètre \textit{latitude} avec la valeur \textit{-100} (la latitude minimale sur Terre est de -90°, au dela, les coordonnées décrivent un point dans l'espace), un pour transmettre la requête au \textit{web service} et enfin, un pour vérifier que le code de retour du \textit{web service} est bien égale à 400 (le code 400 signifie que l'utilisateur\textperiodcentered ice a fait une erreur dans sa requête).
\begin{figure}[H]
\caption{Exemple d'un scénario}
\begin{verbatim}
@ -351,22 +358,22 @@
@when("le web service est interogé via une URL")
fonction faire une requête au web service:
url <= construir l'URL avec les paramètres initalisés avants
réponse <= interoger le web service
url <= construire l'URL avec les paramètres initalisés avant
réponse <= interroger le web service
@then("le code de retour du web service doit être '{code}'")
fonction comparer le code de retour:
si le code de retour de réponse est différent de 'code':
dire à behave que le test à échoué
dire à behave que le test a échoué
sinon
ne rien faire car tout se passe bien
\end{verbatim}
\label{fig:implementationScenario}
\end{figure}
Pour chaque \textit{step}, \textit{behave} ira chercher et exécuter la bonne fonction grâce au préfix \textit{@given}, \textit{@when} et \textit{@then}. Ainsi, le nom de la fonction n'est pas important pour \textit{behave}. Les variables peuvent être transmises de fonction en fonction grâce à la notion de \textit{context}. Concrètement, c'est un objet qui est passé en paramètre de chaque fonction et qui est capable de stocker des variables sous la forme de propriétés.
Pour chaque \textit{step}, \textit{behave} ira chercher et exécuter la bonne fonction grâce au préfixe \textit{@given}, \textit{@when} et \textit{@then}. Ainsi, le nom de la fonction n'est pas important pour \textit{behave}. Les variables peuvent être transmises de fonction en fonction grâce à la notion de \textit{context}. Concrètement, c'est un objet qui est passé en paramètre de chaque fonction et qui est capable de stocker des variables sous la forme de propriétés.
\subsubsection{Détail d'un step}
\paragraph{}
La complexité d'un step peux varier en fonction de sa nature. En effet, les steps \textit{given} son assez simples à implémenter (cf. Figure.~\ref{fig:given}). Les autres \textit{steps} sont en général plus complexes.
La complexité d'un step peut varier en fonction de sa nature. En effet, les steps \textit{given} sont assez simples à implémenter (cf. Figure.~\ref{fig:given}). Les autres \textit{steps} sont en général plus complexes.
Je vais maintenant décrir son fonctionement. Dans un premier lieu, je sélectionne les méthodes d'intérogations du \textit{web service} définit dans le scénario. Il est possible de faire un requête POST, une requête GET ou les deux. En suite, j'initie des variables pour les utiliser plus tard. Cependant, à ce moment là, la variable \textit{args} sert juste à initaliser la propriété (sorte de variable) \textit{context.queries}. Ensuite, on rentre dans une boucle \textit{for}, qui va permetre de lancer autant de requêtes au \textit{web service} qu'il y en a de définit dans le contexte. Une requête est modélisé dans le contexte par une liste de dictionaires d'arguments. Par exemple, la liste [{net: FR, sta: CIEL}, {net: FR, sta: CFF}] possède deux requêtes. Ainsi,il est possible de forger plusieurs requêtes dans les steps \textit{given}. Ainsi, chaque requêtes est envoyé autant de fois qu'il y a de méthodes HTTP demendé par le step. Par exemple, si on demende du GET et du POST, mon programe intérogera 4 fois le \textit{web service} si l'on reprend l'exemple précédent. C'est la raison d'être de la deuxieme boucle \textit{for}.
Je vais maintenant décrire son fonctionnement. Dans un premier lieu, je sélectionne les méthodes d'intérrogations du \textit{web service} défini dans le scénario. Il est possible de faire un requête POST, une requête GET ou les deux. En suite, j'initie des variables pour les utiliser plus tard. Cependant, à ce moment là, la variable \textit{args} sert juste à initaliser la propriété (sorte de variable) \textit{context.queries}. Ensuite, on rentre dans une boucle \textit{for}, qui va permettre de lancer autant de requêtes au \textit{web service} qu'il y en a de définies dans le contexte. Une requête est modélisée dans le contexte par une liste de dictionaires d'arguments. Par exemple, la liste [{net: FR, sta: CIEL}, {net: FR, sta: CFF}] possède deux requêtes. Ainsi,il est possible de forger plusieurs requêtes dans les steps \textit{given}. Ainsi, chaque requêtes est envoyée autant de fois qu'il y a de méthodes HTTP demendées par le step. Par exemple, si on demande du GET et du POST, mon programe interrogera quatres fois le \textit{web service} si l'on reprend l'exemple précédent. C'est la raison d'être de la deuxieme boucle \textit{for}.
\paragraph{}
Je vais maintenant détailler le contenu des boucles \textit{for}. Donc, pour chaque requête, je créer un objet \textit{Query} (cf. Chapitre~\ref{chap:modelDeClasse}) grâce à un générateur de \textit{Query}. L'objet \textit{Query} est stocké dans le contexte dans une liste. Ainsi, en fonction de la methode HTTP, la methode de \textit{Query} \textit{get} ou \textit{post} est appelée.
Je vais maintenant détailler le contenu des boucles \textit{for}. Donc, pour chaque requête, je crée un objet \textit{Query} (cf. Chapitre~\ref{chap:modelDeClasse}) grâce à un générateur de \textit{Query}. L'objet \textit{Query} est stocké dans le contexte dans une liste. Ainsi, en fonction de la méthode HTTP, la methode de \textit{Query} \textit{get} ou \textit{post} est appelée.
\paragraph{}
À la fin de la boucle, il y a donc un liste de \textit{Query} dans le contexte. Aussi, chaque \textit{Query} possède un objet \textit{Response}. Enfin, le test échoue si la méthode demendée n'éxiste pas, si le \textit{web service} n'est pas joignable ou si l'URL est mal écrite.
\subsection{Environement}
\subsubsection{Environement behave}
\textit{Behave} est capable de généré un environement entre chacun des \textit{items} composant les tests (\textit{feature}, \textit{scénario}, \textit{tag}, \dots). Pour ça, il faut définir des fonctions avec des noms prédéfinis par \textit{behave} dans un fichier nommé \textit{environment.py}.
À la fin de la boucle, il y a donc un liste de \textit{Query} dans le contexte. Aussi, chaque \textit{Query} possède un objet \textit{Response}. Enfin, le test échoue si la méthode demendée n'existe pas, si le \textit{web service} n'est pas joignable ou si l'URL est mal écrite.
\subsection{Environnement}
\subsubsection{Environnement behave}
\textit{Behave} est capable de générer un environnement entre chacun des \textit{items} composant les tests (\textit{feature}, \textit{scénario}, \textit{tag}, \dots). Pour cela, il faut définir des fonctions avec des noms prédéfinis par \textit{behave} dans un fichier nommé \textit{environment.py}.
\paragraph{}
Les noms des fonctions sont composés de la manière suivante: $<$before/after$>$\_$<$\textit{element}$>$ (exemple: before\_feature, after\_scenario, before\_all, \dots). J'ai pu me servir de certaines de ces fonctions, notament pour la configuration des tests par des éléments externes tel que des variables d'environements ou des fichiers de configurations. Ainsi, avant tout, je configure le protocole utilisé (http ou https) et le couple loggin/mot de passe pour l'accès aux données réstraintes. Avant chaque \textit{feature}, je sélectionne le \textit{web service} adéquat.
\subsubsection{Configuration par l'environement}
Les noms des fonctions sont composés de la manière suivante: $<$before/after$>$\_$<$\textit{element}$>$ (exemple: before\_feature, after\_scenario, before\_all, \dots). J'ai pu me servir de certaines de ces fonctions, notamment pour la configuration des tests par des éléments externes tel que des variables d'environnements ou des fichiers de configuration. Ainsi, avant tout, je configure le protocole utilisé (http ou https) et le couple loggin/mot de passe pour l'accès aux données réstreintes. Avant chaque \textit{feature}, je sélectionne le \textit{web service} adéquat.
\subsubsection{Configuration par l'environnement}
\paragraph{}
Pour plus de souplesse à l'utilisation, j'ai fait en sorte que les tests soit configurable sans que le code source soit modifié. En effet, il existe plusieurs contexte de déploiment pour les différent: le contexte de production, celui de développement et celui de stage. Chaque contexte a son utilité et sont accessible par des noms de domaines (début de l'URL) différents. Ainsi, pour définir le contexte depuis l'exterieur du programme, il suffit de définir la vairable d'environement \textit{BEHAVE\_TEST\_CONTEXT} avec les valeurs \textit{PROD}, \textit{DEV} ou \textit{STAGING}.
Pour plus de souplesse à l'utilisation, j'ai fait en sorte que les tests soient configurables sans que le code source soit modifié. En effet, il existe plusieurs contextes de déploiment pour les différent \textit{web services}: le contexte de production, celui de développement et celui de stage. Chaque contexte a son utilité et est accessible par un nom de domaines (début de l'URL) différent. Ainsi, pour définir le contexte depuis l'extérieur du programme, il suffit de définir la vairable d'environement \textit{BEHAVE\_TEST\_CONTEXT} avec les valeurs \textit{PROD}, \textit{DEV} ou \textit{STAGING}.
\paragraph{}
Les URL sont ensuite récupéré depuis un fichier de configuration au format YAML. Ces URL contiènent à la fois le contexte (ws.resif.fr, ws-dev.resif.fr et ws-staging.resif.fr) ainsi que le chemin vers chaque \textit{web service}. En effet, celui-ci est variable en fonction du contexte. Par exemple pour ph5-availability, les URL sont: \textit{ph5ws.resif.fr/resifws/availability/1/query}, \textit{ws-dev.resif.fr/resifws/ph5-availability/1/query} et \textit{ph5ws-staging.resif.fr/resifws/availability/1/query}. La hiérarchie des informations du fichier fait qu'il est facile de modifier ou ajouter des URL. En effet, le premier niveau de hiérarchisation est le nom du \textit{web service} et le deuxième, le nom du contexte (cf. Figure~\ref{fig:yamlOK}). C'est ici que ce situe l'URL. Ainsi, pour ajouter un \textit{web service} dans la configuration, il sufit d'ajouter son nom et de décrire chaque contexte. Si cette hierarchie était inverssée (cf Figure~\ref{fig:yamlKO}), il serait plus compliqué de retrouver les informations. Imaginon que je veuille modifier les URL \textit{web service} \textit{station}. Pour cela, il faudrai que je prenne chaque contexte et que je trouve parmis tous les \textit{web services} le bon, le modifier et répéter l'oppération autant de fois qu'il y a de contexte.
Les URL sont ensuite récupérées depuis un fichier de configuration au format YAML. Ces URL contiennent à la fois le contexte (ws.resif.fr, ws-dev.resif.fr et ws-staging.resif.fr) ainsi que le chemin vers chaque \textit{web service}. En effet, celui-ci est variable en fonction du contexte. Par exemple pour ph5-availability, les URL sont: \textit{ph5ws.resif.fr/resifws/availability/1/query}, \textit{ws-dev.resif.fr/resifws/ph5-availability/1/query} et \textit{ph5ws-staging.resif.fr/resifws/availability/1/query}. La hiérarchie des informations du fichier fait qu'il est facile de modifier ou ajouter des URL. En effet, le premier niveau de hiérarchisation est le nom du \textit{web service} et le deuxième, le nom du contexte (cf. Figure~\ref{fig:yamlOK}). C'est ici que ce situe l'URL. Ainsi, pour ajouter un \textit{web service} dans la configuration, il sufit d'ajouter son nom et de décrire chaque contexte. Si cette hierarchie était inversée (cf Figure~\ref{fig:yamlKO}), il serait plus compliqué de retrouver les informations. Imaginons que je veuille modifier les URL \textit{web service} \textit{station}. Pour cela, il faudrait que je prenne chaque contexte et que je trouve parmi tous les \textit{web services} le bon, le modifier et répéter l'opération autant de fois qu'il y a de contexte.
\paragraph{}
Ainsi, j'ai pu faire en sorte que la customisation des tests soit maximale grâce aux variables d'environements. En effet, il y a quatres variables d'environemnts avec lesquelles il est possible de spécialiser les tests:
Ainsi, j'ai pu faire en sorte que la personnalisation des tests soit maximale grâce aux variables d'environnements. En effet, il y a quatre variables d'environnemnts avec lesquelles il est possible de spécialiser les tests:
\begin{itemize}
\item \textbf{BEHAVE\_TEST\_PROTOCOLE}: pour définir le protocole utilisé: http ou https (https par défaut)
\item \textbf{BEHAVE\_TEST\_CONTEXT}: pour définir le contexte (PROD par défaut)
\item \textbf{BEHAVE\_TEST\_LOGGIN}: pour définir l'utilisateur\textperiodcentered ice et ainsi garantir le respect des droits vis à vis de la visibilité des données (rien par defaut)
\item \textbf{BEHAVE\_TEST\_LOGGIN}: pour définir l'utilisateur\textperiodcentered ice et ainsi garantir le respect des droits vis-à-vis de la visibilité des données (rien par defaut)
\item \textbf{BEHAVE\_TEST\_PASSWORD}: pour authentifier l'utilisateur\textperiodcentered ice (rien par défaut)
\end{itemize}
\begin{figure}[H]
\caption{Éxtrait du fichier de configuration des contextes}
\caption{Extrait du fichier de configuration des contextes}
Pour implémenter les \textit{steps}, ma démarche était empirique. C'est à dire que je l'implémentais, vérifiais son comportement et l'amélorais en suite. Ainsi, j'étais dans l'espris de la methode \textit{agile}. En effet, avec les ticket gitlab, je pouvais facilement avoir une tache pour reprendre un code précédament écris.
Pour implémenter les \textit{steps}, ma démarche était empirique. C'est à dire que je l'implémentais, vérifiais son comportement et l'améliorais ensuite. Ainsi, j'étais dans l'esprit de la methode \textit{agile}. En effet, avec les tickets gitlab, je pouvais facilement avoir une tache pour reprendre un code précédemment écrit.
\subsubsection{Factorisation de code}
\paragraph{}
C'est dans cet espris que, 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 requête au \textit{web service} ou la verification de format de la réponse. À ce moment là, j'ai ressenti le besoin de mettre en commun certaines parties de codes et d'en spécialiser d'autres. Ainsi, j'ai commencé un travail de refactorisation de code qui à depuis toujours était présent jusqu'à la fin de mon stage.
C'est dans cet esprit que, 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 requête au \textit{web service} ou la verification de format de la réponse. À ce moment là, j'ai ressenti le besoin de mettre en commun certaines parties de code et d'en spécialiser d'autres. Ainsi, j'ai commencé un travail de refactorisation de code qui à depuis toujours était présent jusqu'à la fin de mon stage.
\paragraph{}
En effet, dupliquer du code, c'est pouvoir introuduire le même bug à plusieurs endrois différents ou bien même une impossibilité de reprendre le code par une autre personne car ce genre de code est assez difficile à lire et comprendre. Refactoriser le code permet donc une meilleurre stabilité ainsi qu'une plus grande facilité à le corriger.
En effet, dupliquer du code, c'est pouvoir introduire le même bug à plusieurs endroits différents ou bien même une impossibilité de reprendre le code par une autre personne car ce genre de code est assez difficile à lire et comprendre. Refactoriser le code permet donc une meilleure stabilité ainsi qu'une plus grande facilité à le corriger.
\paragraph{}
Pour éviter de dupliquer du code, j'ai dût créer differentes classes ayant diférrants types de relations entre elles (associations dirigées, héritages, \dots). Une des difficutltés non négligable est qu'en \textit{python}, le principe de classe abstraite ou d'interface n'éxiste pas. Cela m'a notament posé problème lors de l'implémentation des sous classes de \textit{Query}. En effet, le comportement des sous classes dépendait de plusieurs paramètres: la méthode HTTP (GET ou POST) et le \textit{web service} intérogé. Ainsi, un objet \textit{Query} n'a pas de sens si is est instancié.
Pour éviter de dupliquer du code, j'ai dû créer differentes classes ayant différrents types de relation entre elles (associations dirigées, héritages, \dots). Une des difficutltés non négligable est qu'en \textit{python}, le principe de classe abstraite ou d'interface n'existe pas. Cela m'a notamment posé problème lors de l'implémentation des sous-classes de \textit{Query}. En effet, le comportement des sous classes dépendait de plusieurs paramètres: la méthode HTTP (GET ou POST) et le \textit{web service} intérrogé. Ainsi, un objet \textit{Query} n'a pas de sens s'il est instancié.
\paragraph{}
Le fait d'avoir des classes abstraites ou des interfaces permet aussi de créer ce qu'on appelle des points d'extentions. Un point d'extention, c'est une entité qui permet de garantir des fonctionalitées lors cequ'une classe hérite de cette entité. Par exemple, si j'hérite d'une interface \textit{Conteneur}, les classes qui l'implémentent, comme \textit{Liste}, \textit{Fille} ou \textit{Queue}, sont obligées de pouvoir contenir des données. Ainsi, la personne qui utilise ces classes n'a pas à ce demander si elle peut contenir des données.
Le fait d'avoir des classes abstraites ou des interfaces permet aussi de créer ce qu'on appelle des points d'extensions. Un point d'extension, c'est une entité qui permet de garantir des fonctionnalités lorsequ'une classe hérite de cette entité. Par exemple, si j'hérite d'une interface \textit{Conteneur}, les classes qui l'implémentent, comme \textit{Liste}, \textit{Fille} ou \textit{Queue}, sont obligées de pouvoir contenir des données. Ainsi, la personne qui utilise ces classes n'a pas à se demander si elle peut contenir des données.
\paragraph{}
Pour palier à ce problème, j'ai simuler le comportement d'une classe abstraite grâce à la valeur \textit{NotImplemeted}. Cette valeur est retournée à chaque fois qu'une méthode censé être abstraite est appelée. Toute fois, je n'ai pas interdit l'instentiation de ces objets car cela complexifirait le code, simplement pour introduire une notion étrangère à \textit{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 suceptibles de reprendre mon code. Ainsi, pour permettre au modèle de pouvoir tester de nouveaux \textit{web services}, il suffit de créer une nouvelle classe qui hérite de \textit{Query} et une nouvelle classe qui hérite de \textit{Response} et implementer les méthodes \textit{abstraites} (cf. Figure~\ref{fig:QueryClassDiag}, Figure~\ref{fig:ResponseClassDiag}).
Pour palier à ce problème, j'ai simulé le comportement d'une classe abstraite grâce à la valeur \textit{NotImplemeted}. Cette valeur est retournée à chaque fois qu'une méthode censée être abstraite est appelée. Toute fois, je n'ai pas interdit l'instanciation de ces objets car cela complexifirait le code, simplement pour introduire une notion étrangère à \textit{python}. Ainsi, j'ai pu obtenir plusieurs points d'extensiblilités (Query, Response, Validator, \dots), ce qui permettra une maintenabilité plus simple pour les développeur\textperiodcentered euse\textperiodcentered s qui seront suceptibles de reprendre mon code. Ainsi, pour permettre au modèle de pouvoir tester de nouveaux \textit{web services}, il suffit de créer une nouvelle classe qui hérite de \textit{Query} et une nouvelle classe qui hérite de \textit{Response} et implementer les méthodes \textit{abstraites} (cf. Figure~\ref{fig:QueryClassDiag}, Figure~\ref{fig:ResponseClassDiag}).
\subsubsection{Déscription du modèle de classes}
\label{chap:modelDeClasse}
\paragraph{}
Dans mon modèle de classes, j'ai pu faire un point d'entrée qui permet une simple utilisiation depuis l'éxterieur, dans mon cas, depuis les tests \textit{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 paramètres. Par exemple ici, \textit{QueryGenerator} vas créer des classes filles de \textit{Query} en fonction du \textit{web service} que l'on veut interroger grâce à une méthode nommé \textit{generateQuery}.
Dans mon modèle de classes, j'ai pu faire un point d'entrée qui permet une simple utilisiation depuis l'éxterieur, dans mon cas, depuis les tests \textit{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 fonction de divers paramètres. Par exemple ici, \textit{QueryGenerator} va créer des classes filles de \textit{Query} en fonction du \textit{web service} que l'on veut interroger grâce à une méthode nommée \textit{generateQuery}.
\paragraph{}
La classe \textit{Query} modélise une requête à passer ou passée à un \textit{web service}. Une \textit{Query} est cappable de construire la requête en fonction de la méthode d'interrogation (GET ou POST). Une fois que les requêtte étaient construites, il était possible d'intérroger le serveur dont l'URL et les arguments sont attributs de \textit{Query}(cf. Figure~\ref{fig:ValidatorClassDiag}).
La classe \textit{Query} modélise une requête à passer ou passée à un \textit{web service}. Une \textit{Query} est capable de construire la requête en fonction de la méthode d'interrogation (GET ou POST). Une fois que les requêtes étaient construites, il était possible d'interroger le serveur dont l'URL et les arguments sont attributs de \textit{Query}(cf. Figure~\ref{fig:ValidatorClassDiag}).
\paragraph{}
Cependant, une requête doit être spécialisée en fonction du \textit{web service} intérogé (cf. Figure~\ref{fig:QueryClassDiag}). Cela permet de spécialiser le comportement de la réponse lors de sa création dans la méthode \textit{buildResponse}. Par exemple, pour le \textit{web service} \textit{station}, il a fallu créer une classe \textit{StationQuery} qui implémente la méthode abstraite de \textit{Query} nommé \textit{buildResponse} qui est appelée lors ce qu'on intrérroge le \textit{web service} et que l'on a une réponse. La structure de ce genre de méthode est décrite sur la figure~\ref{fig:buildResponse}.
Cependant, une requête doit être spécialisée en fonction du \textit{web service} interogé (cf. Figure~\ref{fig:QueryClassDiag}). Cela permet de spécialiser le comportement de la réponse lors de sa création dans la méthode \textit{buildResponse}. Par exemple, pour le \textit{web service} \textit{station}, il a fallu créer une classe \textit{StationQuery} qui implémente la méthode abstraite de \textit{Query} nommé \textit{buildResponse} qui est appelée lors ce qu'on intrérroge le \textit{web service} et que l'on a une réponse. La structure de ce genre de méthode est décrite sur la figure~\ref{fig:buildResponse}.
\begin{figure}[H]
\caption{Structure de la méthode \textit{buildResponse}}
La classe \textit{Response} est aussi un point d'éxtensibilité qui garantit qu'une réponse sait dire si sont contenu est bien formaté. Les classes qui héritent diréctement de \textit{Response} sont aussi des classes abstraites. Elles permettent de spécialiser le comportement des classes filles en fonction des \textit{web services} intérrogés. Par exemple, il existe une classe abstraite \textit{ResponseAvailability}. C'est à l'étage du dessous que sont implémentées les classes concrètes qui permettent de traiter un format (par exemple la classe \textit{ResponseDataselectMiniSeed}). Ce découpage est ainsi fait car deux \textit{web services} peuvent renvoyer un même format mais avec un contenu complétement différent. Par exemple, \textit{availability} peut renvoyer des valeurs au format \textit{text} (les valeurs son séparé par des espaces) ainsi que \textit{station} (les valeurs sont séparées par un pipe) (cf. Figure~\ref{fig:respAvaText}, Figure \ref{fig:respStaText}). Ainsi, le traitement de la réponse est différente et c'est pour répondre à cette contrainte que j'ai dût faire une si grosse arboréscence(cf. Figure~\ref{fig:ResponseClassDiag}).
La classe \textit{Response} est aussi un point d'extensibilité qui garantit qu'une réponse sait dire si son contenu est bien formaté. Les classes qui héritent directement de \textit{Response} sont aussi des classes abstraites. Elles permettent de spécialiser le comportement des classes filles en fonction des \textit{web services} interrogés. Par exemple, il existe une classe abstraite \textit{ResponseAvailability}. C'est à l'étage du dessous que sont implémentées les classes concrètes qui permettent de traiter un format (par exemple la classe \textit{ResponseDataselectMiniSeed}). Ce découpage est ainsi fait car deux \textit{web services} peuvent renvoyer un même format mais avec un contenu complétement différent. Par exemple, \textit{availability} peut renvoyer des valeurs au format \textit{text} (les valeurs son séparées par des espaces) ainsi que \textit{station} (les valeurs sont séparées par un pipe) (cf. Figure~\ref{fig:respAvaText}, Figure \ref{fig:respStaText}). Ainsi, le traitement de la réponse est différente et c'est pour répondre à cette contrainte que j'ai dû faire une si grosse arborescence(cf. Figure~\ref{fig:ResponseClassDiag}).
\begin{figure}[H]
\caption{Extrait de réponse au format \textit{text} de \textit{availability}}
Dans le paragraph précédent, j'ai dit qu'un objet \textit{Response} devait être capable de vérifier si le format de son contenu était correcte sans en expliquer les détails. C'est ce que vais donc faire ici. Pour pouvoir faire ça, la classe \textit{Response} doit utiliser un \textit{Validator}. C'est une classe qui permet de dire si une condition complexe est réspéctée. Il existe deux sortes de validateurs pour le moment: les \textit{HTTPValidator} et les \textit{FormatValidator}. Ici ce sont des \textit{FormatValidator} qui sont utilisés par les objets \textit{Response}. Chaque format possède sa manière d'être vérifié. Par exemple, pour un format CSV, il faut vérifier que chaque ligne correspond au pattern "valeur séparateur" grâce à une expression régulière. J'avais essayé de faire cette verification avec la bibliothèque CSV mais l'objet qui permet de lire un CSV ne lève pas d'erreur lors ce que le contenu n'est pas bien formaté. Pour continuer l'exemple, le format \textit{MiniSEED} peu être lu grâce à la bibliothèque \textit{obspy}\cite{obspy}. Ainsi, si l'objet qui lit le contenu lève une erreur lors de la lecture du contenu, c'est qu'il est mal formaté. Cepandant, il y a des formats particulier comme le format ZIP qui en fait contient un fichier CSV à l'interieur. C'est pour ça que je l'ai fait hériter de CSV. Ansi, la méthode \textit{validate} de \textit{ZipValidator} extrait le fichier CSV à l'interieur et appèle ensuite la même méthode de son parent avec le contenu du fichier(cf. Figure~\ref{fig:ValidatorClassDiag}).
Dans le paragraphe précédent, j'ai dit qu'un objet \textit{Response} devait être capable de vérifier si le format de son contenu était correct sans en expliquer les détails. C'est ce que vais donc faire ici. Pour pouvoir faire ça, la classe \textit{Response} doit utiliser un \textit{Validator}. C'est une classe qui permet de dire si une condition complexe est respéctée. Il existe deux sortes de validateurs pour le moment: les \textit{HTTPValidator} et les \textit{FormatValidator}. Ici ce sont des \textit{FormatValidator} qui sont utilisés par les objets \textit{Response}. Chaque format possède sa manière d'être vérifié. Par exemple, pour un format CSV, il faut vérifier que chaque ligne correspond au pattern "valeur séparateur" grâce à une expression régulière. J'avais essayé de faire cette verification avec la bibliothèque CSV mais l'objet qui permet de lire un CSV ne lève pas d'erreur lors ce que le contenu n'est pas bien formaté. Pour continuer l'exemple, le format \textit{MiniSEED} peut être lu grâce à la bibliothèque \textit{obspy}\cite{obspy}. Ainsi, si l'objet qui lit le contenu lève une erreur lors de la lecture du contenu, c'est qu'il est mal formaté. Cependant, il y a des formats particuliers comme le format ZIP qui en fait contient un fichier CSV à l'interieur. C'est pour ça que je l'ai fait hériter de CSV. Ansi, la méthode \textit{validate} de \textit{ZipValidator} extrait le fichier CSV à l'interieur et appelle ensuite la même méthode de son parent avec le contenu du fichier(cf. Figure~\ref{fig:ValidatorClassDiag}).
\begin{figure}[H]
\caption{Diagramme de classe pour les classes \textit{Validator}}
Pour pouvoir avoir une vision globale du projet ainsi que pour la transmission de ma production, j'ai dût la documenter. Pour cela, j'ai utilisé plusieurs outils. Tout d'abord, pour avoir une documentation de mon code en lui même, expliquer le rôle de chaque classe, chaque methode, j'ai utilisé l'outil \textit{pydoc}, qui permet de generer une documentation HTML en lisant les \textit{docstings} de mon code. Une \textit{docstring} est un espèce de paragraphe, placé en haut de l'item à documenter (classe, methode, \dots) expliquant l'utilité et le fonctionement de ce dernier. Cependant, je n'ai pas commencer à documenter mon code dès le début de sa production, j'ai donc pris une journée pour l'écrire, à la fin de l'implémentation des tests sur le deuxieme \textit{web service} que j'ai traité, c'est à dire, vers le début du mois de mai.
Pour pouvoir avoir une vision globale du projet ainsi que pour la transmission de ma production, j'ai dû la documenter. Pour cela, j'ai utilisé plusieurs outils. Tout d'abord, pour avoir une documentation de mon code en lui même, expliquer le rôle de chaque classe, chaque methode, j'ai utilisé l'outil \textit{pydoc}, qui permet de générer une documentation HTML en lisant les \textit{docstings} de mon code. Une \textit{docstring} est une sorte de paragraphe, placé en haut de l'item à documenter (classe, methode, \dots) expliquant l'utilité et le fonctionement de ce dernier. Cependant, je n'ai pas commencer à documenter mon code dès le début de sa production, j'ai donc pris une journée pour l'écrire, à la fin de l'implémentation des tests sur le deuxieme \textit{web service} que j'ai traité, c'est-à-dire, vers le début du mois de mai.
\begin{figure}
\caption{Extrais de la classe \textit{Query} comportent des docstrings}
\begin{verbatim}
@ -605,7 +612,7 @@ class Query:
\end{verbatim}
\end{figure}
\subparagraph{}
Pour donner une explication sur les relations entres les classes, j'ai réalisé plusieurs diagrammes de classes avec l'outil \textit{plantuml}. Cette outil permet de générer un diagramme UML à partir d'un fichier texte formaté qui décris les relations entre classes (cf. Figure~\ref{fig:plantuml}). L'avantage d'un tel outil est qu'il est facile à versionner par rapport à un fichier binaire. En effet, si il y a un conflit entre deux versions du dépôt, il sera difficile à résoudre si c'est un fichier binnaire car illisible. Pour résoudre un conflit, il faut fusioner à la main le contenu des fichiers. J'ai donc commencé la réalisation du fichier plantuml dès que j'ai eu plus d'une classe à implémenter.
Pour donner une explication sur les relations entres les classes, j'ai réalisé plusieurs diagrammes de classes avec l'outil \textit{plantuml}. Cette outil permet de générer un diagramme UML à partir d'un fichier texte formaté qui décrit les relations entre classes (cf. Figure~\ref{fig:plantuml}). L'avantage d'un tel outil est qu'il est facile à versionner par rapport à un fichier binaire. En effet, si il y a un conflit entre deux versions du dépôt, il sera difficile à résoudre si c'est un fichier binnaire car illisible. Pour résoudre un conflit, il faut fusionner à la main le contenu des fichiers. J'ai donc commencé la réalisation du fichier plantuml dès que j'ai eu plus d'une classe à implémenter.
En mi chemain de mon stage, j'ai réalisé une présentation de mon travail dans le cadre d'une transmission 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, ces échanges ont permis de déffinir un plan d'action pour les semaines qui suivit ainsi que mettre en lumière de nouveaux scénarios tel que la cohérance des \textit{web services} entres eux.
À mi-chemin de mon stage, j'ai réalisé une présentation de mon travail dans le cadre d'une transmission de savoir au reste de l'équipe. Suite à cela, il y eu de nouveaux échanges et cela a permis d'enrichir le contenu de mes tests. En effet, ces échanges ont permis de déffinir un plan d'action pour les semaines qui ont suivi ainsi que mettre en lumière de nouveaux scénarios tel que la cohérence des \textit{web services} entres eux.
\subsubsection{Problèmes rencontrés}
\paragraph{}
Une des principales dificultés que j'ai pu rencontrer lors de ce stage est le comportement de \textit{behave}. En effet, quand on exécute un scenario, \textit{behave} va le faire échouer seulement si une exception est levée, c'est à dire, qu'une erreur a été rencontrée ou qu'un test de nature spécifique (assertion) n'est pas passé. Aussi, certains tests peuvent passer sans que le \textit{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 renvoyé à 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 requêtes que je faisait étaient identiques et donc, les résultats étaient eux aussi identiques (tout les 2 au format XML) et je ne l'ai remarqué que lors ceque je l'ai vu dans le code par hasard car \textit{behave} ne s'en rendait pas compte (cf. Figure~\ref{fig:behaveOK}).
Par exemple, si je veux tester un code de retour HTTP égale à 400 en voulant tester un paramètre, ce code peut être renvoyé à cause d'un autre paramètre défectueux. Ainsi, le test passra mais n'aura pas validé le comportement attendu. Un autre exemple est quand par exemple je devais tester que le format texte était cohérent avec le format XML. Ici, j'avais un problème de code qui faisait que les deux requêtes que je faisait étaient identiques et donc, les résultats étaient eux aussi identiques (tous les deux au format XML) et je ne l'ai remarqué que lorseque je l'ai vu dans le code par hasard car \textit{behave} ne s'en rendait pas compte (cf. Figure~\ref{fig:behaveOK}).
\paragraph{}
Pour palier à ce problème, à la fin de chaque implémentation, je verifiais à la main que le test passé corespond bien au comportement souhaité grâce à l'argument no-capture (cf. Figure~\ref{fig:behaveNoCapture}). Mais la limite de cette méthode est que, si il y a une régréssion dans le code, les tests qui fonctinnaient correctement avant peuvent ne plus fonctioner après.
Pour palier à ce problème, à la fin de chaque implémentation, je verifiais à la main que le test passé corespond bien au comportement souhaité grâce à l'argument no-capture (cf. Figure~\ref{fig:behaveNoCapture}). Mais la limite de cette méthode est que, si il y a une régression dans le code, les tests qui fonctionnaient correctement avant peuvent ne plus fonctionner après.
\begin{figure}[H]
\centering
\caption{Capture d'écran du test d'équivalence entre le format XML et texte}
@ -653,9 +660,9 @@ Query <|-- DataselectPh5Query
\end{figure}
\subsection{Au-delà du stage}
\paragraph{}
Tout au long de mon stage, je devais avoir à l'espris que mon code serai repris et que le logiciel produit devra être utilisé le plus simplement possible.
Tout au long de mon stage, je devais avoir à l'esprit que mon code serait repris et que le logiciel produit devra être utilisé le plus simplement possible.
\paragraph{}
Ainsi, J'ai pu penser à des amélioration tel que la mise en cache de certaines requêtes pour accélérer les tests, l'écriture d'un script permettant de simplifier le lancement des tests, un modèle de classes qui permet une genericité maxiamle. Certaines de ces idées ont dût être écartées par manque de temps et du fait de le trop grande complexité par rapport au contexte. C'est donc un piste pour continuer l'implémentation des tests.
Ainsi, j'ai pu penser à des améliorations telles que la mise en cache de certaines requêtes pour accélérer les tests, l'écriture d'un script permettant de simplifier le lancement des tests, un modèle de classes qui permet une génericité maximale. Certaines de ces idées ont dû être écartées par manque de temps et du fait de le trop grande complexité par rapport au contexte. C'est donc un piste pour continuer l'implémentation des tests.
\paragraph{}
J'ai donc réalisé une documentation sur l'utilisation de ma production. Pour qu'elle soit facilement accessible et lisible, je l'ai faite en \textit{markdown}, un langage de mise en forme de texte, et l'ai mise dans le fichier \textit{REEDME.md}. Ce fichier est affiché automatiquement par gitlab dans l'onglet \textit{Files} (cf. Figure\ref{fig:reedme}).
\begin{figure}[H]
@ -664,7 +671,7 @@ Query <|-- DataselectPh5Query
\label{fig:reedme}
\end{figure}
\paragraph{}
Pour que l'utilisateur\textperiodcentered ice des tests puisse facilement voir ce qui ce passe lors ce qu'un test échou, j'ai travaillé la sortie standard (cf. Figure~\ref{fig:behaveKO}) des ces dérniers (grossièrement ce qu'ils écrivent sur la console). En effet, le comportement de \textit{behave} est d'afficher les éléments que j'écris dans la sortie standard seuelement si un \textit{step} échoue. Ainsi, j'ai détaillé à chaque requête effecuée, l'URL (pour GET) et le corps de cette requête (pour POST) pour pouvoir la reproduir en dehors de mes tests. J'affiche aussi le loggin utilisé si il a été configuré. Aussi, en fonction des \textit{steps} effectués, il peut y avoir des sorties différentes. Par exemple, pour le step \textit{Then the HTTP code returned must be 'code'}, le code d'erreur est écris dans la sortie standard.
Pour que l'utilisateur\textperiodcentered ice des tests puisse facilement voir ce qui ce passe lors ce qu'un test échoue, j'ai travaillé la sortie standard (cf. Figure~\ref{fig:behaveKO}) des ces derniers (grossièrement ce qu'ils écrivent sur la console). En effet, le comportement de \textit{behave} est d'afficher les éléments que j'écris dans la sortie standard seuelment si un \textit{step} échoue. Ainsi, j'ai détaillé à chaque requête effecuée, l'URL (pour GET) et le corps de cette requête (pour POST) pour pouvoir la reproduire en dehors de mes tests. J'affiche aussi le loggin utilisé s'il a été configuré. Aussi, en fonction des \textit{steps} effectués, il peut y avoir des sorties différentes. Par exemple, pour le step \textit{Then the HTTP code returned must be 'code'}, le code d'erreur est écrit dans la sortie standard.
A diverses oxcasions j'ai pu participer à des activités organisé avec l'équipe RÉSIF-DC. Ainsi, j'ai pu assister à une réunion du commité technique (\textit{comtec}). Ces réunions on pour but de se mettres d'accord entre différents laboratoires au niveau des problèmes techniques communs entre ces instances. Par exemple, si une information n'était pas délivrée et qu'il a été jugée nécaissaire de l'introduire dans les réponses d'un \textit{web service}, le \textit{comtec} décide de la manière de le faire.
A diverses occasions j'ai pu participer à des activités organisées avec l'équipe RÉSIF-DC. Ainsi, j'ai pu assister à une réunion du commité technique de RÉSIF-SI(\textit{comtec}). Ces réunions ont pour but de se mettre d'accord entre différents laboratoires au niveau des problèmes techniques communs entre ces instances. Par exemple, si une information n'était pas délivrée et qu'il a été jugée nécessaire de l'introduire dans les réponses d'un \textit{web service}, le \textit{comtec} décide de la manière de le faire.
\paragraph{}
J'ai aussi pu participer à une réunion \textit{créativité} avec les membres de l'équipe RÉSIF-DC et deux invité\textperiodcentered e\textperiodcentered s. Le but de cette réunion était de définir les besoins du centre de données dans le cadre du développement d'un outils de gestion de cycle de vie des données. La particularité de cette réunion était sa forme. En effet, cette réunion était découpée en plusieurs parties spécifiques pour ainsi maximiser la créativité et la productivité des intervenant\textperiodcentered e\textperiodcentered s.
J'ai aussi pu participer à une réunion \textit{créativité} avec les membres de l'équipe RÉSIF-DC et deux invité\textperiodcentered e\textperiodcentered s. Le but de cette réunion était de définir les besoins du centre de données dans le cadre du développement d'un outil de gestion de cycle de vie des données. La particularité de cette réunion était sa forme. En effet, cette réunion était découpée en plusieurs parties spécifiques pour ainsi maximiser la créativité et la productivité des intervenant\textperiodcentered e\textperiodcentered s.
J'ai pu relever plusieurs bugs, par exemple, une divergence dans le comportement du \textit{web service} \textit{station} en fonction de la méthode HTTP utilisée (GET et POST) si on demande une date à la limite éxterieur de ce qui est autorisé (par exemple le 21 novembre 2020 à 12h\textbf{60}). Ainsi le travail que j'ai produit a pu servir à mettre en lumière des problèmes qui n'ont pas étés repérés jusqu'à présent. Aussi, dans le cadre d'une réecriture d'un \textit{web service}, mes test permettent de verifier qu'il n'y a pas eu de régressions par rapport à l'implémentation précédente. Ces tests peuvent aussi être lancés de manière automatique dans le cadre d'une vérification routinière du bon fonctionement des \textit{web services}. J'ai aussi documenter mon code pour une transmission du savoir plus facile.
J'ai pu relever plusieurs bugs, par exemple, une divergence dans le comportement du \textit{web service} \textit{station} en fonction de la méthode HTTP utilisée (GET et POST) si on demande une date à la limite exterieur de ce qui est autorisé (par exemple le 21 novembre 2020 à 12h\textbf{60}). Ainsi le travail que j'ai produit a pu servir à mettre en lumière des problèmes qui n'ont pas étés repérés jusqu'à présent. Aussi, dans le cadre d'une réecriture d'un \textit{web service}, mes tests permettent de verifier qu'il n'y a pas eu de régressions par rapport à l'implémentation précédente. Ces tests peuvent aussi être lancés de manière automatique dans le cadre d'une vérification routinière du bon fonctionement des \textit{web services}. J'ai aussi documenté mon code pour une transmission du savoir plus facile.
\newpage{}
\section{Conclusion}
\paragraph{}
J'ai pu lors de ce stage, développer des tests comportementaux pour différents \textit{web services} de RÉSIF. Ainsi, j'ai pu interagir avec les membres de mon équipe pour mieux cerner les problèmatiques que ce stage comprenait. J'ai donc pu travailler ma capacitée d'écoute ainsi que de communication. En effet, J'ai aussi du m'exprimer pour expliquer quels étaient les problèmles que je rencontrais, quels bugs j'avais relevé au niveau des \textit{web services} ou encore quel était l'état d'avancement de mon projet.
J'ai pu lors de ce stage, développer des tests comportementaux pour différents \textit{web services} de RÉSIF. Ainsi, j'ai pu interagir avec les membres de mon équipe pour mieux cerner les problématiques que ce stage comprenait. J'ai donc pu travailler ma capacité d'écoute ainsi que de communication. En effet, J'ai aussi dû m'exprimer pour expliquer quels étaient les problèmes que je rencontrais, quels bugs j'avais relevé au niveau des \textit{web services} ou encore quel était l'état d'avancement de mon projet.
\paragraph{}
Hélas, j'étais la seule personne à travailler sur ce projet. En effet, travailler à plusieurq sur un même projet apporte et améliore cette capacité à travailler en équipe. Toutefois, cela reste à relativiser dans mon cas car je devais quand même faire un rapport quotidien au près de mon tuteur ainsi qu'un rapport hébdomadaire pour l'ensemble de l'équipe RÉSIF-DC.
Hélas, j'étais la seule personne à travailler sur ce projet. En effet, travailler à plusieurs sur un même projet apporte et améliore cette capacité à travailler en équipe. Toutefois, cela reste à relativiser dans mon cas car je devais quand même faire un rapport quotidien au près de mon tuteur ainsi qu'un rapport hebdomadaire pour l'ensemble de l'équipe RÉSIF-DC.
\paragraph{}
Cependant, j'ai quand même pu me sentir à l'aise au sein de l'équipe. En effet, l'ambiance de travail était bonne, les personnes s'entraidaient en cas de besoins, etcétéra.
Cependant, j'ai quand même pu me sentir à l'aise au sein de l'équipe. En effet, l'ambiance de travail était bonne, les personnes s'entraidaient en cas de besoin, etc..
\newpage{}
\section{Recap}
\section*{Recap}
\paragraph{}
During my internship in ISTerre, I had to realize behavior tests. Those types of tests check the behavior of a software from the outside. The pieces of software I was testing were web services. The goal of those applications is to give data depending on parameters, usualy defined and affected in a URL. There were three web services that I had to test: \textit{station}, \textit{availability} and \textit{dataselect}. Those web services give different types of data:
To be able to use my code several times, I had to design my code. The result of this work is that I wrote a class named \textit{Query} and a class named \textit{Response}. Thoses two classes are the most important ones of my model. With a \textit{Querry} object, you can ask a web sevice, but only if there is a subclass specilized for that (ex. \textit{StationQuery}). With a \textit{Response} object, you can access and do opperations to the response of the web service. In the same way as \textit{Query}, \textit{Response} must be specialized.
\newpage{}
\section{Lexique}
\section*{Lexique}
\begin{itemize}
\item \textbf{Test de comportement (behavior test)} : Test informatique permettant de vérifier le comportement du logiciel testé sur la base de différents scénarios
\item \textbf{Nœud A}: Équipe de sismologues charchée de placer des sondes, de récolter et traiter les données et métadonnées, et de les transmetre au nœud B
\item \textbf{Nœud B}: Équipe de sysmologues chargée de stocker et distribuer les données et méta-données récoltées par les differents nœud A.
\item \textbf{Classe}: Concept informatique permetant de regrouper des données et des fonctionalitées liés à ces données.
\item \textbf{Nœud A}: Équipe de sismologues chargée de placer des sondes, de récolter et traiter les données et métadonnées, et de les transmetre au nœud B
\item \textbf{Nœud B}: Équipe de sismologues chargée de stocker et distribuer les données et méta-données récoltées par les différents nœuds A.
\item \textbf{Classe}: Concept informatique permettant de regrouper des données et des fonctionnalités liés à ces données.
\item \textbf{Objet}: Représentation en mémoire d'une classe.
\item \textbf{UMR}: Une Unité Mixte de Recherche est le résultat d'une collaboration entres un ou plusieurs laboratoires de recherche d'un établissement d'enseignement supérieur\cite{umr}.
\item \textbf{OSU}: Un Observatoire des Sciences de l'Univers est un regroupement de laboratoires chargé de conduire des observations de longue durée dans le domaine des sciences de l’univers\cite{osu}.
\item \textbf{IR}: Une Infrastructure de Recherche premet au chercheur\textperiodcentered euse\textperiodcentered s de mener des recherches de grandes ampleurs dans des domaines de pointes. \cite{ir}
\item \textbf{IR}: Une Infrastructure de Recherche premet au chercheur\textperiodcentered euse\textperiodcentered s de mener des recherches de grandes ampleurs dans des domaines de pointe. \cite{ir}
Érina Point
3 years ago