O RANGE M AROC

D IRECTION S ERVICES ET S YSTÈME D ’I NFORMATION DSSI

Rapport de stage PFF

Test automatisé d’une application de e-paiement

Encadré par:
Réalisé par:
Mme. EL MAAZOUZI Qamar
ESSAIH Douha
M. EL IDRISSI Mouhsin
CHEGGAR Houda

13 Novembre 2023 - 13 Janvier 2024

1
Cette page a été laissée intentionnellement vide.
 Remerciements

Nous souhaitons exprimer notre profonde reconnaissance envers nos encadrants,

Mme Qamar EL MAAZOUZI et M. Mouhsine EL IDRISSI, pour leur
accompagnement et soutien tout au long de ce stage. Leur patience, assistance, et
surtout leurs conseils précieux et leur générosité dans le partage de leurs
connaissances.

Nos remerciements s’adressent aussi à toute l’équipe de Orange Maroc et du

direction DSSI pour leur aimable accueil, ainsi qu’à nos chers professeurs de
l’Ecole Mohammadia d’Ingénieures, Mme RETBI Asmaa et Mme EL KASSIRI
Asmae pour leur engagement et leur investissement sans faille.

Un merci tout particulier à tous les amis rencontrés sur le chemin.

— ¢ —

3
 Abstract

This report provides an overview of payment gateways within telecommunication operator Orange
Morocco, emphasizing their crucial role in facilitating electronic financial transactions. These
platforms are instrumental in enabling seamless and secure payments for users, often integrated with
mobile telecommunication services.
Within this framework, the report focuses on the specific payment gateway application, OMAPAY.
Our efforts primarily centered on conducting automated tests to ensure the quality, reliability, and
performance of the application across various operational scenarios.
Test scenarios covered diverse aspects of the application, from user navigation to transaction
management, with the aim of delivering an optimal user experience. The results obtained identified
strengths and specific improvement opportunities, guiding recommendations to enhance code
quality and optimize key functionalities of the OMAPAY application.
This report offers a comprehensive exploration of payment gateways within telecommunications
operators, followed by a detailed analysis of the automated tests conducted on the OMAPAY
application. These insights will inform future developments of the platform, ensuring a reliable and
efficient electronic payment experience for end users.

4
 Résumé

Ce rapport offre une vue d’ensemble sur les gateways de paiement au sein de l’opérateur de
télécommunication Orange Maroc, mettant en lumière leur rôle crucial dans la facilitation des
transactions financières électroniques. Ces plateformes jouent un rôle essentiel en permettant des
paiements fluides et sécurisés pour les utilisateurs, souvent intégrées aux services de téléphonie
mobile.
Dans ce contexte, le rapport se concentre sur l’application OMAPAY, une gateway de paiement
particulière. Notre travail a principalement porté sur la réalisation de tests automatisés visant à
garantir la qualité, la fiabilité, et la performance de l’application dans divers scénarios opérationnels.
Les scénarios de tests ont abordé des aspects variés de l’application, de la navigation utilisateur à la
gestion des transactions, dans le but de fournir une expérience utilisateur optimale. Les résultats
obtenus ont permis d’identifier des forces et des opportunités d’amélioration spécifiques, orientant
ainsi des recommandations pour renforcer la qualité du logiciel et optimiser les fonctionnalités clés
de l’application OMAPAY.
Ce rapport offre une exploration approfondie du paysage des gateways de paiement chez les
opérateurs de télécommunications, suivi d’une analyse détaillée des tests automatisés effectués sur
l’application OMAPAY. Ces informations guideront les futures évolutions de la plateforme,
garantissant une expérience de paiement électronique fiable et efficiente pour les utilisateurs finaux.

5
Contents

1 Contexte général 12
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Orange Maroc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.1 Dates Importantes à Retenir . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.2 Secteurs d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Organigramme de l’entreprise: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4 Contexte général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5 Contexte général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6 Problématiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.7 La méthodologie du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.8 Les objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Identification et planification des tests 20

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1 Identification et description des acteurs . . . . . . . . . . . . . . . . . . . . 20
2.2.2 Diagramme de contexte statique . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Réalisation des tests 23

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Méthodologie de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6
3.3 Identification des Scénarios de Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Présentation des test effectuée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.1 Test1: Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.2 Test2: Ajouter un partenaire . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5.3 Test3: Modifier un partenaire . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.4 Test4: Ajouter un sous partenaire . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.5 Test5: Rechercher un partenaire . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.6 Test6: Rechercher une commande . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.7 Test7: Recherche avancée d’une commande . . . . . . . . . . . . . . . . . . 31
3.6 Test d’API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6.1 API1: Catalogue de recharge BIM . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.2 API2: Activation de recharge . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6.3 API3: Paiement des factures par Msisdn . . . . . . . . . . . . . . . . . . . . 33
3.6.4 API4: Récupération de facture par msisdn . . . . . . . . . . . . . . . . . . . 34
3.7 Avantages des tests automatisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.8 - Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
.1 Annexe A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
.2 Annexe B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
.3 Annexe C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
.4 Annexe D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7
List of Figures

1.1 Logo de l’entreprise Orange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2 Logo de l’entreprise Méditel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Méditel devient Orange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Organigramme de ’Orange Maroc’ . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5 Gateway de paiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 Diagramme de contexte statique du OMAPAY . . . . . . . . . . . . . . . . . . . . 21

3.1 Logo du Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Logo du Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Logo du ChromeDriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Fontionnement de selenium avec python . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Test d’authentification avec un nom d’utilisateur correct et un mot de passe incorrect 26
3.6 Test d’ajout d’un partenaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7 Test de modification de partenaire avec des données mises à jour . . . . . . . . . . . 28
3.8 Test d’ajout de sous-partenaire avec des données valides . . . . . . . . . . . . . . . 29
3.9 Test d’ajout de sous-partenaire avec des données valides . . . . . . . . . . . . . . . 30
3.10 Test de la recherche d’une commande . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.11 Test du recherche avancée d’une commande . . . . . . . . . . . . . . . . . . . . . . 31
3.12 Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.13 Test d’API de Catalogue de recharge BIM . . . . . . . . . . . . . . . . . . . . . . . 32
3.14 Test d’API d’activation de recharge . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.15 Test d’API de Paiement des factures par Msisdn . . . . . . . . . . . . . . . . . . . . 34
3.16 Test d’API du Récupération de facture par msisdn . . . . . . . . . . . . . . . . . . . 35
17 Script du test d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8
18 Script du test d’ajout un sous partenaire . . . . . . . . . . . . . . . . . . . . . . . . 40
19 Script du test de modification d’un partenaire . . . . . . . . . . . . . . . . . . . . . 41
20 Script du test de recherche d’un partenaire . . . . . . . . . . . . . . . . . . . . . . . 42

9
 List of Abbreviations

API: Application Programming Interface

ADSL: Asymmetric Digital Subscriber Line

VDSL: Very High Digital Subscriber Line

SSL: Secure Sockets Layer

UI: User Interface

HTTP: Hypertext Transfer Protocol

10
 Introduction générale

Dans le monde dynamique des télécommunications, l’évolution constante des technologies nécessite
des systèmes robustes et fiables pour répondre aux besoins croissants des utilisateurs. En tant que
stagiaire au sein de la socièté Orange Maroc, j’ai eu l’opportunité passionnante d’explorer en pro-
fondeur le domaine des tests automatisés dans le contexte des services de télécommunication. Ce
rapport vise à documenter mon parcours au sein de l’équipe chargée des tests, mettant en lumière
l’importance cruciale des tests dans la garantie de la qualité et de la performance des solutions web.
La gateway de paiement, en particulier, émerge comme un élément central dans le paysage fi-
nancier des opérateurs télécoms, facilitant les transactions monétaires associées aux services pro-
posés. Dans ce contexte, la nécessité de tests exhaustifs devient impérative pour s’assurer que chaque
aspect du système fonctionne de manière optimale, offrant une expérience utilisateur sans faille.
Ce rapport se penchera sur les défis inhérents aux tests dans le secteur des télécommunications,
explorant les différentes facettes du processus de test et soulignant l’importance de garantir la fiabilité
des systèmes face à des exigences toujours plus complexes. De la simulation de transactions réelles
à l’évaluation de la sécurité des données financières, chaque étape du processus de test contribue à
assurer la qualité des services de télécommunication offerts.

11
Chapter 1
Contexte général

1.1 Introduction

L’évolution rapide des technologies de paiement électronique a engendré un besoin croissant d’évaluer
la robustesse et l’efficacité des applications de e-paiement. Ce chapitre vise à présenter l’organisme
d’acceuil Orange Maroc, le contexte général du projet, la problématique, la méthodologie du travail,
les objectifs et les conclusions tirées de ce chapitre.

1.2 Orange Maroc

Orange Maroc est l’un des trois principaux opérateurs de télécommunications agréés au Maroc.
L’opérateur multi-services opérant dans les activités mobile, fixe, cybersécurité et mobile money.
L’opérateur déploie des réseaux très haut débit fixe et mobile, avec la 4G et le FTTH (Fibre to the
Home) pour répondre à l’évolution des usages, aux mutations technologiques ainsi qu’aux attentes
de ses clients.

Figure 1.1: Logo de l’entreprise Orange

1.2.1 Dates Importantes à Retenir

Méditel ou MediTelecom est une entreprise fondée (en partenariat) par Telephonica et Portugal Tele-
com en 1999.
Méditel est le deuxième opérateur principal dans le secteur des télécommunications au Maroc.

12
 Figure 1.2: Logo de l’entreprise Méditel

Médi Télécom est issu d’un partenariat idéal entre des leaders marocains de l’industrie et de
la finance et deux multinationales du secteur des télécommunications. Forts d’expériences interna-
tionales les groupes Telefonica et Portugal Telecom apportent leur maitrise des nouvelles technolo-
gies des télécommunications. Ils sont actionnaires de Méditelecom à hauteur de 32%,18% chacun
et ont réalisé un investissement stratégique dans Méditelecom, découlant d’une politique commune
d’investir dans les marchés émergeants à très forts potentiels (Méditel, 2006).

Leaders de leur activités respectives, les groupes Marocains BMCE Bank, Holdco, et la Caisse
des dépôts et de Gestion investissent dans Méditelecom le champ des NTIC et font entrer le Maroc
dans un secteur dont la croissance soutenue contribue à l’essor de l’économie mondiale. Plus qu’un
simple fournisseur de services, Médi Télécom est un moteur puissant de la "nouvelle économie" au
Maroc.

Facteur clé de la croissance socio-économique, les télécommunications doivent impérativement

être accessibles au plus grand nombre. Engagée 5 à relever ce défi, Médi Télécom met en place une
structure organisationnelle matérielle et humaine destinée à y répondre dans une logique constructive
et de pérennité.

Le début de l’année 2000 a connu le lancement de la marque « Méditel » en se focalisant sur

le prépayé « Médijahiz » et les offres sous forme de forfaits plafonnés pour les abonnements Post
Payés, une stratégie payante qui a permis à l’opérateur de se positionner, dès le départ, en challenger
sérieux sur le marché (Méditel, 2006). D’emblée, Méditel affiche la couleur en mettant sur le marché
deux services complètement révolutionnaires : les forfaits et les Factures plafonnés.

En 2003, L’opérateur a atteint 3,2 millions d’abonnés, réalisant ainsi une augmentation de 25%
pour s’adjuger 43% de la part du marché (Méditel, 2006).

En 2006, Méditel obtient la deuxième licence de la téléphonie fixe et devient ainsi un opérateur
multiservices offrant des services de la voix fixe, mobile et l’Internet et cassant de ce fait le monopole
précédemment tenu par Maroc Telecom (Méditel, 2006).

En 2007, l’opérateur Méditel prouve son succès en dépassant le seuil des six millions de clients
et en lançant le service d’internet 3G sur les mobiles. Le 8 juin 2015, Méditel devient le premier
opérateur à proposer la 4G au Maroc.

En mars 2016, dans le cadre de l’unification sous la marque « Orange » qu’entreprend le groupe,
Stéphane Richard, PDG d’Orange, annonce que Méditel sera renommé « Orange » avant la fin 2016.

13
 Figure 1.3: Méditel devient Orange

Le 29 juillet 2020, Hendrik Kasteel qui occupait jusqu’alors la fonction de Directeur général de
MTN Cameroun, est nommé directeur général d’Orange Maroc et lancement d’orange money.

1.2.2 Secteurs d’activités

Le téléphone mobile:

Orange utilise principalement les réseaux mobiles de 2e, 3e et 4e générations qui sont commer-
cialisés sous la marque Orange. Poste payés Un service mobile payé après l’utilisation. Ce mode de
paiement traditionnel permet à l’abonné de payer après coup la majeure partie des services qu’il a
employés ou le prépayes Un mode de service mobile payé d’avance, et plus précisément d’une quan-
tité déterminée de temps d’antenne que l’abonné paie avant de l’avoir utilisé ou le recharges pour
recharger un compte en unités téléphoniques.

Internet:

Orange propose des offres d’accès internet haut débit, ADSL/VDSL et via la fibre optique, ainsi
que des services et périphériques multimédias via la Livebox, commercialisée dès 2004 par Wanadoo,
produite à l’origine par Invente et actuellement par Sagemcom. Au troisième trimestre de 2021
les connexions en fibre optique ont connu la plus forte augmentation de près de 82, avec 330 185
utilisateurs. Quant aux connexions ADSL, elles se sont stabilisées à 1,6 million d’utilisateurs à la fin
du mois de septembre 2021, avec plus de 43% d’abonnés ayant accès à des vitesses de 10 Mbps ou
plus.

Orange Business Services:

Orange Business Services est, depuis le 1er juin 2006, la marque d’Orange spécialisée dans les
solutions de télécommunications à destination des entreprises et du secteur public (téléphonie fixe
et mobile, transmission de données, Internet, réseaux locaux d’entreprises). Ces services étaient
auparavant fournis, en partie, par Equant et plus anciennement en France par Transpac (filiale ayant
été intégrée à la maison mère en juin 2006).

14
 Boutique orange:
Les « boutiques » ont succédé aux anciennes « Meditelcom ». Orange reçoit son public dans 420
de ces boutiques Orange. Un conseiller sera également apte à vous orienter vers l’offre la plus adaptée
à vos besoins, ainsi qu’à votre budget. Il vous informera également des bons plans du moment, afin
de vous faire réaliser des économies. Tout comme les autres opérateurs, Orange Maroc met à la
disposition de ses clients une grande sélection de smartphones, qu’il est possible de se procurer avec
ou sans forfait. Afin d’être certain de faire le bon choix, il peut être préférable de demander de plus
amples informations sur le téléphone pour lequel vous craquez ; ainsi que de le prendre en main,
pour vous faire une idée plus concrète du nouveau mobile qui vous accompagnera durant les années
à venir.
Orange money:
Orange Money permet à ses utilisateurs de déposer de l’argent sur un compte associé à leur
numéro de mobile, pour ensuite accéder à une gamme de services, notamment transfert d’argent
domestique et international, paiement de factures, paris en ligne et achat de crédit téléphonique.
Les principaux services sont le dépôt et le retrait d’argent, l’achat de crédit téléphonique, le transfert
d’argent domestique et international et le paiement de factures (eau, électricité, télévision, téléphonie,
frais de scolarité). Les professionnels (entreprises ou auto-entrepreneurs) ont également la possibilité
d’accepter les paiements réalisés par Orange Money avec un compte entreprise.

1.3 Organigramme de l’entreprise:

Figure 1.4: Organigramme de ’Orange Maroc’

1.4 Contexte général du projet

1.5 Contexte général du projet

Plongeons dans le cœur battant de l’amélioration continue des services de paiement électronique,
où chaque pulsation résonne dans l’application intégrée à la gateway de paiement de l’opérateur

15
Orange. Cette gateway, fruit d’une collaboration étroite avec les partenaires stratégiques d’Orange,
ne se contente pas d’être une interface technologique ; elle est une force motrice qui propulse les
interactions financières vers de nouveaux horizons. À cet égard, il est impératif de ne pas restreindre
notre perspective aux seuls aspects techniques, mais d’embrasser la complexité des enjeux sociaux,
économiques et sécuritaires qui se tissent dans l’étoffe de cette transformation digitale.
Notre quête consiste à sonder les tréfonds de ce projet, à décortiquer les éléments clés qui con-
stituent son ADN. En scrutant les acteurs centraux, les fonctionnalités intrinsèques de l’application, et
les tendances émergentes dans l’écosystème des paiements électroniques, nous cherchons à dessiner
une cartographie détaillée du terrain sur lequel évolue cette initiative novatrice. Cette exploration ap-
profondie sert de préambule essentiel à la définition d’une méthodologie d’évaluation éclairée, tout
en jetant les fondations pour les objectifs ambitieux que nous avons soigneusement ciselés.
Ainsi, notre engagement ne se limite pas à une simple exposition des faits, mais à une révéla-
tion en trois dimensions, où le contexte, la méthodologie et les objectifs s’entremêlent pour forger
une vision complète. C’est dans cette démarche audacieuse de transcender les apparences que nous
dévoilons la profondeur et la portée de cette initiative, inscrite dans l’ADN du progrès technologique
et de l’innovation.

Figure 1.5: Gateway de paiement

Une gateway de paiement, ou passerelle de paiement, est un service qui permet d’autoriser
les paiements en ligne, facilitant ainsi les transactions entre un site marchand et un client. Cette
passerelle agit comme un intermédiaire sécurisé entre le commerçant en ligne et le processeur de
paiement. Voici comment fonctionne généralement une gateway de paiement :

• Sélection du Produit/Service : L’utilisateur sélectionne les produits ou services qu’il souhaite

acheter sur le site marchand.

• Ajout au Panier : Les articles choisis sont ajoutés au panier d’achat.

• Passage à la Caisse : L’utilisateur est redirigé vers la page de paiement où il fournit les détails
nécessaires.

16
 • Transmission des Informations : Les informations de paiement (numéro de carte de crédit, date
d’expiration, code de sécurité, etc.) sont entrées par l’utilisateur. Ces données sont générale-
ment cryptées pour assurer la sécurité pendant la transmission.

• Traitement des Données : La passerelle de paiement transmet les informations de paiement au

processeur de paiement (par exemple, une banque ou une société de traitement des paiements).

• Autorisation : Le processeur de paiement vérifie la validité des informations fournies et l’existence

de fonds suffisants sur la carte de crédit du client.

• Confirmation de Paiement : Si la transaction est autorisée, la passerelle de paiement renvoie

une confirmation au site marchand et à l’utilisateur.

• Traitement Final : Le site marchand finalise la commande et fournit une confirmation de la

transaction au client.

La sécurité est une préoccupation majeure lorsqu’il s’agit de paiements en ligne, et c’est pourquoi
les gateways de paiement mettent en œuvre des protocoles de sécurité tels que le protocole SSL
(Secure Sockets Layer) pour assurer la confidentialité des informations sensibles.
Certains fournisseurs populaires de services de passerelle de paiement incluent Stripe, PayPal,
Authorize.Net, et bien d’autres. Les commerçants en ligne choisissent généralement la passerelle
de paiement en fonction de leurs besoins spécifiques, des frais associés et de la facilité d’intégration
avec leur plateforme de commerce électronique.

1.6 Problématiques

Face à l’essor constant des services financiers numériques, la problématique qui émerge réside dans
la capacité de cette application à répondre aux exigences croissantes en matière de sécurité, de per-
formance et de convivialité.

• Comment assurer une expérience utilisateur transparente tout en garantissant la robustesse, la

qualité, et la convivialité de l’apllication ?

• Comment assurer l’intégrité et la cohérence des données dans la gestion des partenaires et des
commandes tout en optimisant l’efficacité opérationnelle ?

1.7 La méthodologie du travail

Pour la méthode de travail, nous adopterons la méthodologie du travail par lot, également connue
sous le terme de "travail en lots" ou "travail par lots", est une approche de gestion de projet qui con-
siste à diviser un projet en plusieurs parties distinctes appelées "lots" ou "batches".
Chaque lot représente une portion spécifique du travail à accomplir. Cette méthode est souvent

17
utilisée dans les industries de la production, de la fabrication et du développement logiciel. Voici
quelques éléments clés de la méthodologie du travail par lot :
Décomposition du projet : Le projet global est décomposé en tâches plus petites et plus gérables,
chaque tâche formant un lot. Cette décomposition permet de mieux organiser le travail et de le rendre
plus gérable.
Priorisation : Les lots peuvent être prioritaires en fonction de divers critères tels que l’urgence,
la complexité ou les dépendances entre les tâches. Cela permet de concentrer les ressources sur les
parties les plus critiques ou prioritaires du projet.
Exécution séquentielle ou parallèle : Les lots peuvent être exécutés séquentiellement, où chaque
lot est terminé avant de passer au suivant, ou en parallèle, où plusieurs lots peuvent être en cours en
même temps. Le choix dépend des exigences spécifiques du projet.
Itérations : Certains projets peuvent être organisés en itérations, où chaque itération représente
un ensemble de lots à compléter avant de passer à la suivante. Cela permet d’ajuster et d’améliorer
le travail au fur et à mesure que le projet progresse.
Tests et validation : Chaque lot peut faire l’objet de tests et de validations avant de passer au lot
suivant. Cela permet de détecter et de corriger les erreurs plus tôt dans le processus.
Adaptabilité : La méthodologie du travail par lot offre une certaine flexibilité. Si des change-
ments sont nécessaires en cours de route, ils peuvent être introduits plus facilement entre les lots
plutôt que de perturber l’ensemble du projet.
Communication continue : Une communication régulière et transparente entre les membres de
l’équipe est essentielle pour assurer le bon déroulement du projet. Cela inclut la coordination des
efforts entre les différents lots et la résolution rapide des problèmes éventuels.
Cette méthodologie est particulièrement adaptée à des environnements où les exigences peuvent
évoluer au fil du temps, car elle permet une adaptation plus facile aux changements. Cependant, il est
important de bien planifier et de coordonner les différentes parties du projet pour assurer le succès
global.

1.8 Les objectives

Les objectifs de ce projet de test sont diversifiés, englobant des aspects techniques, fonctionnels, et
expérientiels. Nous visons à valider la fiabilité et la sécurité de l’application, à identifier d’éventuels
points faibles, à évaluer les performances du système, et à garantir une expérience utilisateur sans
faille.
Ces objectifs sont étroitement liés aux attentes des utilisateurs finaux et aux normes de sécurité
établies, soulignant notre engagement envers la fourniture de solutions de paiement électronique
de haute qualité.

1.9 Conclusion

En somme, ce rapport a esquissé un panorama complet du test d’une application de e-paiement

intégrée à la gateway de paiement de l’opérateur Orange et ses partenaires.

18
Du contexte général du projet à la méthodologie adoptée, en passant par les objectifs spécifiques,
cette évaluation a été guidée par la rigueur de la méthodologie travail par lot et une vision globale des
enjeux liés aux transactions électroniques. Les résultats et les enseignements tirés de ce processus
seront discutés dans les sections suivantes, fournissant une base solide pour des recommandations
futures et une amélioration continue.

19
Chapter 2
Identification et planification des tests

2.1 Introduction

Ce chapitre "Résultats et Analyse" constitue le cœur de notre évaluation approfondie des tests effec-
tués sur le système à l’aide de l’outil de test Selenium. Ou on a présenté les différents cas de tests de
notre application "OMAPAY" qu’on a traité, tels l’authentification, ajout de partenaire, modification
de partenaire, recherche de commande...
Ces tests ont été soigneusement conçus pour évaluer la convivialité, la fiabilité et la performance des
fonctionnalités clés de l’application. Chaque section de ce chapitre est dédiée à un aspect spécifique,
détaillant les résultats obtenus lors des différentes phases de test.
L’objectif est de fournir une vision claire et approfondie de la qualité et de la robustesse du système,
tout en soulignant les points forts et en identifiant les domaines potentiels d’amélioration. Ces ré-
sultats sont cruciaux pour orienter les futures étapes de développement et garantir une expérience
utilisateur optimale. Dans ce chapitre on va identifier les besoins fonctionnels et non fonctionnels de
l’application OMAPAY.

2.2 Les besoins fonctionnels

2.2.1 Identification et description des acteurs

Un acteur est une entité extérieure au système modélisé, et qui interagit directement avec lui. Il peut
consulter et/ou modifier directement l’état du système, en émettant et/ou en recevant des messages
éventuellement porteurs de données. Les acteurs qui interagissent avec le système sont ::

• Administrateur :est un acteur clé chargé de la gestion et du contrôle global du système. Il a

le pouvoir d’accéder à toutes les fonctionnalités administratives, de configurer les paramètres
du système, de gérer les utilisateurs, et d’assurer la sécurité et l’intégrité du système. En
outre, l’administrateur est habilité à prendre des décisions stratégiques pour garantir le bon
fonctionnement de l’ensemble du système.

• Partenaire : représente une entité externe qui collabore activement avec le système. Il peut
accéder à des fonctionnalités spécifiques liées à sa collaboration, telles que la gestion de trans-
actions, la consultation de rapports ou d’autres actions définies dans le cadre de sa relation

20
 partenariale avec le système. Les interactions du partenaire sont généralement axées sur la
réalisation des objectifs mutuels convenus entre lui et le système.

2.2.2 Diagramme de contexte statique

Le diagramme de contexte statique délimite le domaine d’étude en précisant ce qui est à la charge du
système et en identifiant l’environnement extérieur au système étudié avec lequel ce dernier commu-
nique.

Figure 2.1: Diagramme de contexte statique du OMAPAY

2.3 Les besoins non fonctionnels

Afin d’assurer un bon fonctionnement de l’application et de garantir la satisfaction de l’utilisateur,

des contraintes doivent être prises en compte tout au long du développement du projet :

• Performance :Afin d’être acceptée par le client, notre application doit respecter ce critère tout
en assurant un temps de réponse minimum et des fonctionnalités rependant aux besoins de
l’utilisateur.

• Sécurité :L’application devra assurer la sécurité des utilisateurs. D’où la nécessité de procéder
à l’authentification de l’administrateur par un login et un mot de passe tout en assurant la

21
 confidentialité de leurs données. Et Comme nous le savons tous, le but d’un mot de passe est
avant tout de rester connu d’une personne ou d’un groupe de personne. Sa divulgation entraine
alors la perte complète de son efficacité et de sa sécurité, c’est pour ça cette application devra
aussi assurer le cryptage des mots de passes avant les mettre dans la base de données.

• Fiabilité :La fiabilité de l’application est essentielle pour assurer un fonctionnement constant
et sans faille. Les utilisateurs doivent pouvoir compter sur la disponibilité du service à tout
moment, minimisant ainsi les interruptions qui pourraient impacter les transactions en cours.

• Portabilité :Le code doit être bien lisible, compréhensible et modulaire pour garantir la soup-
lesse, l’évolution et la maintenance de la solution et ainsi répondre aux changements du marché.

2.4 Conclusion

En résumé, ce chapitre d’identification de l’application OMAPAY a permis de définir clairement les

besoins fonctionnels et non fonctionnels, de préciser les rôles des acteurs principaux (administrateur
et partenaire), et de visualiser les interactions avec le diagramme de contexte statique.
Cette étape cruciale établit les bases essentielles pour les prochaines phases de test, orientant ainsi le
développement de l’application vers une évaluation approfondie de ses fonctionnalités et de sa perfor-
mance. La rigueur dans l’identification des éléments clés prépare le terrain pour des tests significatifs,
consolidant notre compréhension de l’application et jetant les fondations pour son évolution future.

22
Chapter 3
Réalisation des tests

3.1 Introduction

La réalisation d’une étude technique approfondie est cruciale pour évaluer la robustesse et la fiabilité
d’une application de e-paiement telle qu’OMAPAY. Dans ce chapitre, nous explorerons en détail
la méthodologie, les outils et les résultats de l’étude technique effectuée en utilisant Selenium, un
framework d’automatisation des tests, avec le langage de programmation Python.

3.2 Méthodologie de test

La méthodologie de test repose sur l’automatisation des interactions utilisateur au sein de l’application
OMAPAY à l’aide de Selenium. Cette approche permet de simuler les actions d’un utilisateur réel,
de la navigation à la saisie d’informations, afin d’évaluer la réactivité, la convivialité et la stabilité de
l’application dans des scénarios .
Lot 1: Authentification
Tâches:

• Créer 20 combinaisons d’identifiants utilisateur (nom d’utilisateur/mot de passe).

• Écrire un script automatisé pour simuler la connexion de ces 20 utilisateurs.

• Vérifier manuellement que chaque utilisateur est correctement authentifié.

• Documenter les résultats des tests d’authentification.

Lot 2: Interface des Partenaires

Tâches:

• Ajouter 15 partenaires fictifs à la base de données.

23
 • Automatiser les processus d’édition et de désactivation pour 10 partenaires.

• Manuellement, vérifier que les modifications sont correctement enregistrées et que la désacti-
vation empêche l’accès approprié.

• Documenter les résultats des tests liés aux partenaires.

Lot 3: Interface des Commandes

Tâches:

• Générer 10 commandes associées à différents partenaires et sous-partenaires.

• Utiliser des scripts pour effectuer des recherches par ID, partenaire et sous-partenaire.

• Manuellement, assurer que les résultats des recherches correspondent aux critères spécifiés.

• Documenter les résultats des tests liés aux commandes.

3.3 Identification des Scénarios de Test

Avant de commencer les tests, une analyse approfondie de l’application OMAPAY a été effectuée
pour identifier les fonctionnalités clés et les scénarios d’utilisation prioritaires. Ces scénarios incluent
l’ajout d’un partenaire, la connexion, l’ajout d’un sous partenaire, la modification d’un partenaire, la
gestion des informations personnelles et la vérification des paramètres de sécurité.

Voici notre plan de test:lien

3.4 Outils utilisés

L’utilisation de Selenium avec Python offre une combinaison puissante pour automatiser les tests
fonctionnels et assurer une couverture exhaustive. Les bibliothèques Selenium WebDriver et Python
ont été employées pour interagir avec les éléments de l’interface utilisateur d’OMAPAY et vérifier
les résultats attendus.

• Selenium webdriver: est un framework Web qui vous permet d’exécuter des tests multi-
navigateurs. Cet outil est utilisé pour automatiser les tests d’applications Web afin de vérifier
qu’elles fonctionnent comme prévu. Selenium WebDriver vous permet de choisir un langage
de programmation pour créer des scripts de test.

24
 Figure 3.1: Logo du Selenium

• Python: Python est un langage de programmation interprété, orienté objet et de haut niveau
avec une sémantique dynamique. Sa structure de données intégrée de haut niveau, combinée
à une frappe et une liaison dynamiques, le rend très attrayant pour le développement rapide
d’applications, ainsi que pour une utilisation en tant que langage de script ou de collage pour
connecter les composants existants entre eux. La syntaxe simple et facile à apprendre de Python
met l’accent sur la lisibilité et, par conséquent, réduit le coût de la maintenance du programme.
Python prend en charge les modules et les packages, ce qui encourage la modularité du pro-
gramme et la réutilisation du code.

Figure 3.2: Logo du Python

• ChromeDriver: WebDriver est un outil open source permettant de tester automatiquement

les applications Web sur de nombreux navigateurs. Il offre des fonctionnalités de navigation
vers des pages Web, de saisie utilisateur, d’exécution des Script, etc. ChromeDriver est un
serveur autonome qui implémente la norme W3C WebDriver. ChromeDriver est disponible
pour Chrome sur Android et Chrome sur ordinateur de bureau (Mac, Linux, Windows et
ChromeOS).

Figure 3.3: Logo du ChromeDriver

25
La première étape consiste à écrire les tests fonctionnels à l’aide du Selenium Web Driver, après cela,
l’nvoie d’une demande au serveur Selenium, puis les scénarios de test sont exécutés sur le navigateur
Google Chrome.

Figure 3.4: Fontionnement de selenium avec python

3.5 Présentation des test effectuée

3.5.1 Test1: Authentification

Dans cette série de tests, nous avons évalué le processus d’authentification du système en simulant
différentes situations d’entrée utilisateur. La première capture d’écran ci-dessus montre un scénario
où le nom d’utilisateur fourni est correct, mais le mot de passe associé est incorrect.

Figure 3.5: Test d’authentification avec un nom d’utilisateur correct et un mot de passe incorrect

L’image illustre le test automatisé de la partie d’authentification avec un nom d’utilisateur correct
et un mot de passe incorrect utilise Selenium avec Python pour simuler l’interaction d’un utilisateur
sur une page d’authentification.

26
Le script ouvre un navigateur Chrome, accède à l’URL de la page d’authentification spécifiée, rem-
plit les champs d’identifiants avec des données de test, clique sur le bouton de connexion, puis vérifie
la présence d’un message d’erreur correspondant à une authentification incorrecte.
En cas de succès, le script affiche un message d’assertion indiquant que le message d’erreur attendu
est présent, et le navigateur se ferme automatiquement. Ce test automatisé permet de valider le com-
portement de l’application lorsqu’un utilisateur fournit des informations d’identification incorrectes,
contribuant ainsi à assurer la robustesse de la fonction d’authentification.

3.5.2 Test2: Ajouter un partenaire

Dans ce test, nous avons évalué la fonctionnalité d’ajout de partenaire du système en fournissant des
données valides. La capture d’écran ci-dessus montre le résultat positif de l’ajout d’un partenaire
avec des informations correctes.

Figure 3.6: Test d’ajout d’un partenaire

La capture d’écran illustre avec succès le résultat positif du test automatisé d’ajout d’un partenaire
avec des informations correctes.
L’outil Selenium, avec un script en Python, simule le processus d’ajout en ouvrant le navigateur,
accédant à la page d’ajout de partenaires, remplissant les champs requis avec des données valides,
cliquant sur le bouton d’ajout, et capturant ainsi la confirmation visuelle de l’ajout réussi.

27
Cette validation automatisée garantit que le système réagit correctement aux données conformes,
renforçant la fiabilité de la fonctionnalité d’ajout de partenaires.

3.5.3 Test3: Modifier un partenaire

Ce test a évalué la capacité du système à effectuer des modifications sur des partenaires existants.
La capture d’écran ci-dessus montre le résultat positif de la modification réussie d’un partenaire avec
des données mises à jour.

Figure 3.7: Test de modification de partenaire avec des données mises à jour

L’image illustre la confirmation réussie de la modification d’un partenaire existant.

Les champs ont été mis à jour avec des données valides, et le système a répondu par un message de
succès, confirmant la mise à jour réussie des informations du partenaire dans la base de données.
Le test automatisé de modification de partenaire avec des données mises à jour utilise Selenium et un
script en Python pour simuler le processus de mise à jour d’informations d’un partenaire.
La capture d’écran reflète le résultat positif de ce test, montrant une confirmation visuelle du succès
de la modification.
Le script automatisé ouvre le navigateur, accède à la page de modification du partenaire, met à jour
les informations nécessaires, clique sur le bouton de validation, puis vérifie visuellement ou à l’aide
d’une assertion que la modification a été effectuée avec succès.
Ce test contribue à assurer la fonctionnalité robuste de la modification des données des partenaires
dans le système, renforçant ainsi la qualité et la fiabilité de cette fonctionnalité.

28
3.5.4 Test4: Ajouter un sous partenaire

Ce test a évalué la fonctionnalité d’ajout de sous-partenaire du système en fournissant des données

valides. La capture d’écran ci-dessus montre le résultat positif de l’ajout d’un sous-partenaire avec
des informations correctes.

Figure 3.8: Test d’ajout de sous-partenaire avec des données valides

Le test automatisé de modification de partenaire avec des données mises à jour utilise Selenium
et un script en Python pour simuler le processus de mise à jour d’informations d’un partenaire.
La capture d’écran reflète le résultat positif de ce test, montrant probablement une confirmation vi-
suelle du succès de la modification.
Le script automatisé ouvre le navigateur, accède à la page de modification du partenaire, met à jour
les informations nécessaires, clique sur le bouton de validation, puis vérifie visuellement ou à l’aide
d’une assertion que la modification a été effectuée avec succès. Ce test contribue à assurer la fonc-
tionnalité robuste de la modification des données des partenaires dans le système, renforçant ainsi la
qualité et la fiabilité de cette fonctionnalité.

3.5.5 Test5: Rechercher un partenaire

Ce test a évalué la fonctionnalité d’ajout de sous-partenaire du système en fournissant des données

valides. La capture d’écran ci-dessus montre le résultat positif de l’ajout d’un sous-partenaire avec
des informations correctes.

29
 Figure 3.9: Test d’ajout de sous-partenaire avec des données valides

3.5.6 Test6: Rechercher une commande

Ce test a évalué la fonctionnalité d’ajout de sous-partenaire du système en fournissant des données

valides. La capture d’écran ci-dessus montre le résultat positif de l’ajout d’un sous-partenaire avec
des informations correctes.

Figure 3.10: Test de la recherche d’une commande

Le test automatisé de la recherche d’une commande utilise Selenium avec un script en Python
pour reproduire le processus de recherche d’une commande. La capture d’écran affiche probablement

30
un résultat positif, confirmant visuellement le succès de la recherche de commande.
Le script automatisé ouvre le navigateur, accède à la page de recherche de commandes, saisit les
critères de recherche, déclenche la recherche, puis vérifie visuellement ou à l’aide d’une assertion
que les résultats de la recherche correspondent aux attentes.
Ce test contribue à garantir la fiabilité de la fonction de recherche de commandes dans le système,
renforçant ainsi la qualité et l’efficacité de cette fonctionnalité cruciale.

3.5.7 Test7: Recherche avancée d’une commande

Ce test a évalué la fonctionnalité d’ajout de sous-partenaire du système en fournissant des données

valides. La capture d’écran ci-dessus montre le résultat positif de l’ajout d’un sous-partenaire avec
des informations correctes.

Figure 3.11: Test du recherche avancée d’une commande

Le test automatisé de la recherche avancée d’une commande est réalisé à l’aide de Selenium
avec un script en Python pour reproduire le processus de recherche avancée. La capture d’écran
dépeint probablement un résultat positif, confirmant visuellement le succès de la recherche avancée
de commande.
Le script automatisé ouvre le navigateur, accède à la page de recherche avancée de commandes,
spécifie des critères plus détaillés, déclenche la recherche, puis vérifie visuellement ou par assertion
que les résultats correspondent aux attentes. Ce test vise à garantir la robustesse de la fonction de
recherche avancée de commandes dans le système, contribuant ainsi à la qualité et à la précision de
cette fonctionnalité essentielle.

3.6 Test d’API

Le test API est un type de test logiciel qui analyse une interface de programme d’application (API)
pour vérifier qu’elle remplit les fonctionnalités, la sécurité, les performances et la fiabilité attendues.

31
Les tests sont effectués directement sur l’API. Une API est un code qui permet l’échange de don-
nées entre deux logiciels. Une application se compose généralement de plusieurs couches, dont une
couche API. On a utilisé Postman comme outil de test d’api.

Figure 3.12: Postman

Postman est un outil de test et de développement d’API conçu pour envoyer des requêtes du côté
client au serveur Web et recevoir une réponse du backend. Les informations reçues avec la réponse
sont déterminées par les données envoyées avec la demande.
On peut alors se constituer des collections de requêtes HTTP pour tester une API REST spécifique.
Il est également possible de rejouer automatiquement une batterie de tests Postman grâce au paquet
node newmann.

3.6.1 API1: Catalogue de recharge BIM

Ce figure nous montre un test d’API de catalogue de recharge BIM avec des informations spécifiques.

Figure 3.13: Test d’API de Catalogue de recharge BIM

32
3.6.2 API2: Activation de recharge

Ce figure nous montre un test d’API d’activation d’une recharge avec des informations spécifiques.

Figure 3.14: Test d’API d’activation de recharge

3.6.3 API3: Paiement des factures par Msisdn

Ce figure nous montre le test de l’API de Paiement d’une facture par un numéro de téléphone.

33
 Figure 3.15: Test d’API de Paiement des factures par Msisdn

3.6.4 API4: Récupération de facture par msisdn

Ce figure nous montre le test d’API du récupération d’une facture non payée pour un numéro de
téléphone spécifié.

34
 Figure 3.16: Test d’API du Récupération de facture par msisdn

3.7 Avantages des tests automatisés

Les tests automatisés offrent plusieurs avantages, contribuant à l’amélioration de la qualité du logiciel
et à l’efficacité du processus de développement. Voici quelques-uns des principaux avantages des
tests automatisés :

Répétabilité : Les tests automatisés peuvent être exécutés de manière répétée sans fatigue ni
erreur humaine. Cela permet de s’assurer que les fonctionnalités testées demeurent stables au fil du
temps.

Rapidité : Les tests automatisés sont généralement plus rapides que les tests manuels. Ils perme-
ttent une exécution plus rapide des scénarios de test, ce qui est particulièrement important dans des
cycles de développement rapides.

Couverture étendue : Les tests automatisés peuvent couvrir un large éventail de scénarios et de
données, permettant ainsi une meilleure couverture des fonctionnalités et des cas d’utilisation.

Réduction des coûts à long terme : Bien que le développement initial de tests automatisés puisse
nécessiter des investissements importants, ils peuvent réduire les coûts à long terme en diminuant la
nécessité d’une intervention manuelle répétitive.

Détection précoce des défauts : Les tests automatisés peuvent être intégrés dans le processus
de développement, ce qui permet de détecter les défauts plus tôt dans le cycle de vie du logiciel,
facilitant ainsi leur correction.

35
 Meilleure gestion des tests de régression : Les tests automatisés sont particulièrement utiles
pour effectuer rapidement des tests de régression afin de s’assurer que les modifications apportées au
logiciel n’ont pas introduit de nouveaux défauts ou affecté des fonctionnalités existantes.
Exécution non-stop : Les tests automatisés peuvent être programmés pour s’exécuter à tout
moment, y compris en dehors des heures de bureau, permettant ainsi une utilisation efficace des
ressources.
Meilleure précision : Les tests automatisés sont moins susceptibles de commettre des erreurs
humaines, ce qui améliore la précision des résultats des tests.
Documentation des tests : Les scripts de test automatisés servent également de documentation
pour les scénarios de test, ce qui facilite la compréhension et la reproductibilité des tests.

3.8 - Conclusion

En conclusion de cette phase d’évaluation, les tests réalisés ont fourni des informations essentielles
sur la performance du système. Les résultats obtenus révèlent une stabilité générale et une réactivité
satisfaisante aux différentes interactions utilisateur. Les fonctionnalités clés, telles que l’authentification,
l’ajout de partenaires, la modification de partenaires et l’ajout de sous-partenaires, ont été soumises
à des scénarios variés, mettant en lumière leur robustesse et leur adaptabilité.
Cependant, comme toute phase d’évaluation approfondie, des pistes d’amélioration ont été identi-
fiées, notamment dans la gestion des erreurs et la convivialité des messages d’interaction. Ces aspects
seront pris en compte dans le processus d’itération pour optimiser davantage l’expérience utilisateur
et renforcer la sécurité du système.
En somme, ce chapitre de résultats et d’analyse constitue une étape cruciale dans le cycle de
développement, offrant une base solide pour des ajustements futurs. Ces résultats serviront de guide
pour peaufiner et perfectionner le système, assurant ainsi sa conformité aux normes de qualité les
plus élevées.

36
 Conclusion générale

Ce projet dédié au test automatisé d’une application de e-paiement nommé "OMAPAY" au sein de
l’opérateur Orange Maroc a été une étape cruciale dans mon parcours de formation. En suivant une
démarche méthodique, j’ai établi le cadre général du projet en mettant en avant le contexte spécifique
de l’opérateur Orange et en identifiant les interfaces essentielles de l’application de e-paiement.
La planification prévisionnelle a servi de guide tout au long du processus, détaillant les étapes du
test automatisé, tandis que l’analyse et la spécification des besoins ont jeté les bases pour la création
de scénarios de test pertinents. La phase de réalisation a été dédiée à l’exécution méthodique des
tests, à l’analyse approfondie des résultats et à la gestion proactive des incidents.
Sur le plan technique, ce projet a constitué une opportunité enrichissante pour explorer de nou-
veaux outils et technologies, renforçant ainsi mes compétences dans le domaine du test automatisé.
La compréhension des nouvelles tendances de communication et d’hébergement des applications en
ligne a également élargi ma vision professionnelle.
L’aspect humain de ce stage a été tout aussi important, offrant une immersion concrète dans le
monde professionnel et soulignant l’importance de la collaboration au sein d’une équipe. Les com-
pétences en communication, la gestion du temps et l’adaptabilité ont été des aspects clés développés
au cours de ce projet.
En conclusion, la réalisation du test automatisé de l’application de e-paiement pour l’opérateur
Orange a été une étape formatrice. Ce projet a non seulement contribué à l’amélioration de mes
compétences techniques, mais il a également renforcé ma capacité à évoluer avec succès dans des
environnements professionnels exigeants. Ces expériences constituent des chapitres essentiels de ma
formation en test logiciel dans le cadre du projet JobInTech, témoignant de ma préparation aux défis
du monde professionnel en constante évolution.

37
Bibliography

[1] Documentation officielle du selenium: https://www.selenium.dev/documentation/webdriver/

[2] https://www.w3schools.com/

[3] Livre de Anand Hooda, " Sélénium avec Python: Test d’automatisation avec Python", 11 Juin
2020.

[4] Livre de Pallavi R Sharma, " Selenium with Python - A Beginner’s Guide", Juin 2020.

[5] Livre de Pallavi R Sharma, " Selenium with Python - A Beginner’s Guide", Juin 2020.

38
.1 Annexe A

Figure 17: Script du test d’authentification

Cette figure présente le code source qui effectue une vérification automatisée de l’authentification en
utilisant la bibliothèque Selenium avec Python. Ce script explore une gamme de 20 combinaisons de
noms d’utilisateurs et de mots de passe, permettant ainsi de couvrir divers scénarios de test.

39
.2 Annexe B

Figure 18: Script du test d’ajout un sous partenaire

Cette figure présente le code source qui effectue une vérification automatisée de l’ajourt d’un parte-
naire en utilisant la bibliothèque Selenium avec Python. par remplissage de tous les champs de la
formulaires avec des données valides.

40
.3 Annexe C

Figure 19: Script du test de modification d’un partenaire

Cette figure présente le code source qui effectue une vérification automatisée de la modification d’un
partenaire en utilisant la bibliothèque Selenium avec Python. par remplissage de tous les champs de
la formulaires avec des données modifiées et valides.

41
.4 Annexe D

Figure 20: Script du test de recherche d’un partenaire

Cette figure présente le code source qui effectue une vérification automatisée du scénario de la
recherche d’un partenaire en utilisant la bibliothèque Selenium avec Python.

42
43