diff --git a/rapport.latex b/rapport.latex index 1349449..c773679 100644 --- a/rapport.latex +++ b/rapport.latex @@ -27,10 +27,7 @@ \newpage{} \section{Introduction} \paragraph{} - ISTerre est un laboratoire universitaire à Grenoble dont le but est l'étude de le sismologie. Un des services qui compose ce laboratoire est RÉSIF. Son objectif est de désservir les données sismologiques récoltées par le noeud A à qui le demande grace à différents web services gérés par le noeud B. - L'objectif de mon stage était donc de construir des tests comportemental sur plusieurs de ces web services, à savoir les services \href{https://ws.resif.fr/fdsnws/station/1}{'station'}, \href{https://ws.resif.fr/fdsnws/dataselect/1}{'dataselect'} et \href{https://ws.resif.fr/fdsnws/availability/1}{'availability'}. - En effet, dans le cadre de l'optimisation de ces services, les tests que j'ai implémenté auront pour untilité de comparrer les performances entre les nouvelles et anciennnes version de ces web services. - La problematique de ce stage est donc comment trouver tout les scénarios possibles et comment les implémentés. \textbf{ANNONCE DU PLAN} + La sismologie est une dicipline scientifique visant à étudier le comportement de la Terre. Il est donc important pour les chercheur\textperiodcentered euse\textperiodcentered s d'avoir accèes rappidement et facilement au données mesurées et aux conditions de récolte des données. C'est donc dans l'horizon d'une distribition parfaite des données que s'inscrit mon stage à ISTerre. ISTerre est un laboratoire universitaire à Grenoble dont le but est l'étude de le sismologie. Il y a aussi un service informatique dont l'objectif est de développer et maintenir le centre de donnée RÉSIF. Le centre de donnée se doit de désservir les données sismologiques récoltées par les noeuds A du réseau RÉSIF, à qui le demande grace à différents web services gérés par le centre de donnée RÉSIF (noeud B). L'objectif de mon stage était donc de construir des tests comportementaux sur plusieurs de ces web services, à savoir les services \href{https://ws.resif.fr/fdsnws/station/1}{'station'}, \href{https://ws.resif.fr/fdsnws/dataselect/1}{'dataselect'} et \href{https://ws.resif.fr/fdsnws/availability/1}{'availability'}. En effet, dans le cadre de l'optimisation de ces services, les tests que j'ai implémenté auront pour untilité de comparrer les performances entre les nouvelles et anciennnes version de ces web services. La problematique de ce stage est donc comment trouver tout les scénarios possibles et comment les implémenter pour que l'identification de bugs soit facile et que l'écriture de nouveau tests soit rapide. \textbf{ANNONCE DU PLAN} \section{Mon stage} \subsection{Le Laboratoire} @@ -128,31 +125,67 @@ \item \textbf{Les exemples} de parametres 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 mais il y a quand même des mots clefs qui sont écrit en anglais. J'ai donc rédigé les scénarios en anglais pour permettre une meilleur fuidité de lecture. + Le format du ficher de scénario permet d'utiliser un langage naturel quelqu'il soit mais il y a quand même des mots clefs qui sont écrit en anglais. J'ai donc rédigé les scénarios en anglais pour permettre une meilleur fuidité de lecture ainsi que pour internationaliser mes scénario dans un contontexte polylingue tel qu'au laboratoire ISTerre. \paragraph{} La principale dificulté lors de ces étapes est qu'il est important de penser aux cas d'utilisations qui pourai mettre en danger l'éxecution d'une requete, sachant que je ne connais pas l'implémentation des web services. + \subsubsection{Les tags} + \paragraph{} + Dans behave, il existe une notion de tag qui permet de labéliser des scénarios. Ainsi, j'ai pu diférentié plusieurs types de scénarios: + \begin{itemize} + \item Ceux qui test le code de retour de la requete: \textit{@HTTPStatus} + \item Ceux qui test que le web service retourne une réponse correcte (cas particulier du tag précédent (code de retour égale à 200)): \textit{@200} + \item Ceux qui test le contenu de la requete: \textit{@content} + \item Ceux qui test que le web service est bien en état de marche: \textit{@healthcheck} + \item Ceux qui devrai passer mais qui ne passent pas: \textit{@failling} + \end{itemize} + \paragraph{} + Le tag \textit{@failling} met souvent en évidence un bug. \subsubsection{Exemples de scénarios} \subsection{L'implémenation des tests} \paragraph{} - Pour implementer mes tests, j'ai du reprendre chaque phrase du scénario (\textit{Given, When, Then, And, But}) et coder leurs sens. Par exemple, pour un \textit{Given}, la plupars du temps, je devais initialiser le contexte, pour les \textit{Then}, je devais comparer les résultat des \textit{When}. Ainsi, il était important de bien factoriser les différents cas pour pouvoir réutiliser le code déjà produit. + Pour implementer mes tests, j'ai du reprendre chaque phrase du scénario (\textit{Given, When, Then, And, But}) et coder leurs sens. Par exemple, pour un \textit{Given}, la plupars du temps, je devais initialiser le contexte, pour les \textit{Then}, je devais comparer les résultat des \textit{When}. Ainsi, il était important de bien factoriser les différents cas pour pouvoir réutiliser le code déjà produit. Aussi, toujours pour les même raisons évoqué plus haut, le code est écris en anglais. \subsubsection{Conception} Lors de la réalisation des tests du deuxième web service, \textit{availability}, je commençais à reprendre des fonctionalités du premier, \textit{station}, comme l'envoi de requette au web service, la verification de format de la réponse. À ce moment là, j'ai resenti le besoin de metre en commun certaine partie de code et d'en spécialiser d'autres. Ainsi, j'ai commancé un travail de factorisation de code. \subsubsection{Factorisation de code} \paragraph{} - Pour éviter de dupliquer du code, j'ai dût créer different objet ayant diférant types de relation entre eux (association dirigée, héritage, \dots). Une des difficutltés non négligable est qu'en python, le principe de classe abstraite n'éxiste pas. Cela m'a notament posé problème lors de l'implémentation des sous classes de Query. En effet, le comportement des sous classes dépendait de plusieurs parametres: la methode HTTP et le webservice intérogé). Ainsi, un objet Query n'a pas de sens si is est instancié. Pour palier a ce problème, j'ai simuler le comportement d'une classe abstraite grace à la valeur \textit{NotImplemeted}. C'est valeur est retourné à chaque fois qu'une methode sensé être abstraite est appeler. Toute fois, je n'ai pas interdit l'instentiation de ces objet car cela complexifirai le code juste pour introduire une notion étrangère à python. Ainsi, j'ai pu obtenir plusieurs points d'extensiblilité (Query, Response, Validator, \dots), ce qui permetra une maintnabilité plus simple pour les développeurs et dévelopeuses qui seron sucéptible de reprendre mon code. Ainsi, pour permetre au modele de pouvoir tester de nouveau web services, il sufit de créer une nouvelle classe qui hérite de Query et une nouvelle classe qui hérite de Response et implementer les methodes \textit{abstraites}.\textbf{Ajouter des bouts d'UML} - \subsubsection{Documentation de ma production} - \paragraph{} + Pour éviter de dupliquer du code, j'ai dût créer differents objets ayant diférrants types de relations entre eux (association dirigée, héritage, \dots). Une des difficutltés non négligable est qu'en python, le principe de classe abstraite n'éxiste pas. Cela m'a notament posé problème lors de l'implémentation des sous classes de Query. En effet, le comportement des sous classes dépendait de plusieurs parametres: la methode HTTP et le webservice intérogé. Ainsi, un objet Query n'a pas de sens si is est instancié. Pour palier a ce problème, j'ai simuler le comportement d'une classe abstraite grace à la valeur \textit{NotImplemeted}. C'est valeur est retourné à chaque fois qu'une methode sensé être abstraite est appeler. Toute fois, je n'ai pas interdit l'instentiation de ces objet car cela complexifirai le code juste pour introduire une notion étrangère à python. Ainsi, j'ai pu obtenir plusieurs points d'extensiblilité (Query, Response, Validator, \dots), ce qui permetra une maintnabilité plus simple pour les développeurs et dévelopeuses qui seron sucéptible de reprendre mon code. Ainsi, pour permetre au modele de pouvoir tester de nouveau web services, il sufit de créer une nouvelle classe qui hérite de Query et une nouvelle classe qui hérite de Response et implementer les methodes \textit{abstraites}.\textbf{Ajouter des bouts d'UML} + \subsubsection{Description du modele de classes} + \paragraph{} + Dans mon modele de classes, j'ai pu faire un point d'entrée qui permet un simple utilisiation depuis l'éxterieur, dans mon cas, depuis les tests behave. En effet, la classe \textit{QeryGenerator} agit comme une \textit{factory}, c'est à dire, une classe qui permet de créer d'autre types de classes en foction de divers parametres. Par exemple ici, \textit{QueryGenerator} vas créer des classes filles de \textit{Query} en fonction du web service que l'on veut requeter. En effet, une requette, modéliser par la classe \textit{Query} doit être spécialisée en fonction du web service intérogé (cf. Figure~\ref{fig:QueryClassDiag}). Une fois que le web service en question est intérogé, la classe \textit{Query} se créer une \textit{Response}, elle aussi spécialisée en fonction du web service intérogé mais aussi en fonction du format attendu (cf. Figure~\ref{fig:ResponseClassDiag}). Aussi, chaque \textit{Response} doit pouvoir verifier que son contenu coresponde au format attendu. Ainsi, chaque \textit{Response} utilise un \textit{Validator} spécialisé a cet effet(cf. Figure~\ref{fig:ValidatorClassDiag}). + \begin{figure}[h] + \caption{Diagramme de classe pour les classes Query} + \includegraphics[width=\textwidth]{query} + \label{fig:QueryClassDiag} + \end{figure} + \subsubsection{Transmition du savoir} + \paragraph{Documentation de ma production} Pour pouvoir avoir une vision globale du projet ainsi que pour la transmission de ma production, j'ai du la documenter. Pour cela, j'ai utiliser plusieurs outils. Tout d'abord, pour avoir une documentation de mon code en lui même, éxpliquer le rôle de chaque classe, chaque methode, j'ai utiliser l'outil pydoc, qui permet de generer une documentation HTML en lisant les \textit{docstings} de mon code. Une \textit{docstring} est espece de paragraph, placé en haut de l'item à documenter (classe, methode, \dots) expliquant l'utilité et le fonctionement de ce dérnier. Cependant, je n'ai pas commencer à documenter mon code dès le début de sa production, donc j'ai donc pris une journée pour écrire la documentation, à la fin de l'implémentation des tests sur le deuxieme web service que j'ai traiter, c'est à dire, vers le début du moi de mai. - \paragraph{} + \subparagraph{} Pour donner une explication sur les relations entres les classes, j'ai réaliser plusieurs diagrames de classes avec l'outil \textit{plantuml}. Cette outil permet de generer un diagrame UML à partir d'un fichier texte formaté qui explique les relations entre classes. L'avantage d'un tel outil est qu'il est facile à versioner par rapport à un fichier binnaire. J'ai comencé la réalisation du fichier plantuml dès que j'ai eu plus d'une classe à implémenter. \textbf{AJOUTER UN BOUT DE .PLANTUML} + \paragraph{Réunions} + En mi chemain de mon stage, j'ai réaliser une présentation de mon travail dans le cadre d'une transmition de savoir au reste de l'équipe. Suite à cela, il y eu de nouveaux échanges et cela à permis d'enrichir le contenu de mes tests. En effet, cette échange à permis de déffinir un plan d'acction pour les semaines qui suivit ainsi que mettre en lumière de nouveau scénario tel que la cohérance des web services entres eux. \subsubsection{Problèmes rencontrés} \paragraph{} Une des principales dificultés que j'ai pu rencontré lors de ce stage est le comportement de \textit{behave}. En effet, quand on execute un scenario, behave va le faire échouer seulement si une exception est levée, c'est à dire, qu'une erreur a été rencontré ou qu'un test de nature spécifique (assertion). Aussi, certains tests peuvent passer sans que le web service ce soit comporté comme souhaité. Par example, si je veux tester un code de retour HTTP égale à 400 en voulant tester un paramètre, ce code peut être renvoyer à cause d'un autre paramètre déféctueu. Ainsi, le test passra mais n'aura pas valider le comportement attendu. Pour palier à ce problème, à la fin de chaque implémentation, je verifiais à la main que le test passé coraissponde bien au comportement souhaité. \subsection{Au delà du stage} \paragraph{} Tout au long de mon stage, je devais avoir à l'espris que mon code sera repris et que le logiciel produit devra être utiliser le plus simplement possible. Ainsi, J'ai pu pensé à des amélioration tel que la mise en cache de certaines requettes pour accélérer les test, l'écriture d'un script qui permet de simplifier le lancement des tests, un model de classes qui permet une genericité maxiamle. Certaines de ces idées ont dût être écarter par manque de temps. C'est donc un piste pour continuer l'implémentation des tests. + \section{Bilan} + \paragraph{} + À la fin de mon stage, j'ai pu réaliser toute une panoplie de tests sur six web services differents: + \begin{itemize} + \item \href{https://ws.resif.fr/fdsnws/station/1}{station} + \item \href{https://ws.resif.fr/fdsnws/availability/1}{availabililty} en mode \textit{query} + \item \href{https://ws.resif.fr/fdsnws/availability/1}{availabililty} en mode \textit{extent} + \item \href{https://ws.resif.fr/fdsnws/dataselect/1}{dataselect} + \item \href{https://ph5ws.resif.fr/fdsnws/dataselect/1}{ph5-dataelect} + \item \href{https://ph5ws.resif.fr/resifws/availability/1}{ph5-availability} + \end{itemize} + + \paragraph{} + J'ai donc pu relever plusieurs bugs, par exemple, une divergence dans le comportement du web service \textit{station} en fonction de la methode utilisée (GET et POST) si on demende une date à la limite éxterieur de ce qui existe (par exemple le 21 novembre 2020 à 12h\textit{60}). Ainsi le travail que j'ai produit à pu servir à mettre en lumière des problèmes qui n'ont pas étés repéré jusqu'à présent. Aussi, dans le cadre d'une réecriture d'un web service, mes test permettent de verifier qu'il n'y a pas eu de régression par rapport à l'implémentation précédente. Ces tests peuvent aussi être lancer de manière automatique dans le cadre d'une verification routinière du bon fonctionement des web services. J'ai aussi documenter mon code pour une transmition du savoir plus facile. \section{Anex} \begin{figure}[h] \caption{exemple de scénario} @@ -163,7 +196,7 @@ Then the XML format must be errorless Examples: of request | network | station | location | channel | - | FR | CIEL | 00 | HHZ | + | FR | CIEL | 00 | HHZ | | XG | A002 | 00 | GPE | Scenario: latitude under -90 @@ -172,10 +205,16 @@ Then the HTTP code returned must be '400' \end{verbatim} \end{figure} - \begin{figure} - \caption{Diagrame de classes des classes Query} - \label{fig:QueryClassDiag} - \end{figure} + \begin{figure}[h] + \caption{Diagramme de classe pour les classes Validator} + \includegraphics[width=\textwidth]{validator} + \label{fig:ValidatorClassDiag} + \end{figure} + \begin{figure}[h] + \caption{Diagramme de classe pour les classes Response} + \includegraphics[angle=90, scale=0.5]{response} + \label{fig:ResponseClassDiag} + \end{figure} \section{Lexique} \begin{itemize}