Vous êtes sur la page 1sur 67

1

Dédicaces
A dieu, pour m’avoir donné la force de mettre à terme ce travail,

À mes chers parents,

Aucune dédicace ne saurait exprimer mon respect, mon amour éternel et ma considération
pour les sacrifices que vous avez consenti pour mon instruction et mon bien être.

Que mon travail soit l’exaucement de vos vœux tant formulés, le fruit de vos innombrables
sacrifices, bien que ne vous en acquitterais jamais assez.

A mon cher frère Amen et mes chères sœurs Imene et Fatima

Pour avoir été toujours à mes côtés avec ton amour et ton sourire.

Que Dieu te gratifie le succès et le bonheur.

Que Dieu nous garde unis.

A tous mes ami(e)s

En souvenir de notre sincère et profonde amitié

Veuillez trouver dans ce travail l’expression de mon respect le plus profond et mon affection
la plus sincère.

A toutes les personnes qui ont participé à l’élaboration de ce travail,

Je dédie ce travail,

Naceur Ayadi

2
Remerciements
C'est parce que nous avons beaucoup estimé tous ceux qui nous ont écouté, conseillé et
encadré que nous tenons à leur faire part de toute notre gratitude, et plus particulièrement,
nous tenons à remercier à travers ces courtes lignes :

En effet, j’ai une vive dette de gratitude envers la société ARDIA pour m’avoir acceptée au
sein de son personnel pendant la période de quatre mois.

Je présente notamment ma profonde gratitude à mon encadrant M. NAJDI BEN HASSINE


pour l’expérience enrichissante et pleine d’intérêt qu’elle m’a fait vivre durant ces quatre
mois. Ainsi que pour son assistance, sa disponibilité et son encouragement. Je le remercie
pour ses prestigieux conseils qu’elle n’a cessé de me fournir tout au long de ce stage, pour
l’aide et la confiance qu’elle m’a accordé.

Je tiens à remercier tout particulièrement et à témoigner toute ma reconnaissance à Mme.


IMEN TRABELSI pour m’avoir acceptée dans son honorable établissement et m’avoir
permis d’effectuer ce travail.

J’aimerais aussi présenter mes remerciements à Mme. MOUFIDA GHARBI mon encadrante
à l’ENSIT pour son suivi, ses précieux conseils, sa compréhension et ses encouragements.

Enfin, je remercie l’ensemble du personnel d’ARDIA avec qui j’ai été amené à travailler,
pour avoir fait preuve de disponibilité et d’attention à mon égard tout au long de mon stage.

3
Table des matières
Liste des tableaux........................................................................................................................7

Table des figures.........................................................................................................................8

Acronymes................................................................................................................................10

Introduction générale................................................................................................................11

Chapitre 1 : Présentation de la société et cadre du projet.........................................................12

I. Introduction :.....................................................................................................................13

II. Organisme d’accueil :.......................................................................................................13

II.1 Présentation du groupe ACTIA :....................................................................................13

II.2 Présentation de l’organisme d’accueil :.........................................................................14

II.2.1 Secteur d’activité :...................................................................................................14

II.2.2 Départements et services :.......................................................................................15

II.2.3 Département d’accueil :..........................................................................................15

III. Cadre du projet :.............................................................................................................16

III.1 Présentation du projet :.................................................................................................16

III.2 Méthodologie adoptée :.................................................................................................18

IV. CONCLUSION :............................................................................................................20

Chapitre 2 : État de l’Art et étude de l’existant........................................................................21

I. Introduction :.....................................................................................................................22

II. Etude du domaine de l’existant :.......................................................................................22

II.1 Types de tests :...............................................................................................................22

II.1.1 Intérêts des tests fonctionnels :....................................................................................22

II.1.2 Test automatisé :..........................................................................................................22

II.1.3 Plan du test :................................................................................................................22

II.1.4 Cas du test :.................................................................................................................23

II.1.5 Scénario du test :.........................................................................................................23

II.1.6 Les spécifications fonctionnelles :..............................................................................23

4
II.2 Les méthodes des tests :.................................................................................................23

II.2.1 Test boite noire :..........................................................................................................23

II.2.2 Test boite blanche :.....................................................................................................24

II.2.3 Test boite grise :..........................................................................................................24

II.2.4 Comparaison entre les méthodes de test :...................................................................25

II.3 Les logiciels utilisés :.....................................................................................................26

II.3.1 IBM Rational DOORS :..............................................................................................26

II.3.2 CANoe :.......................................................................................................................27

II.4 Processus d’automatisation de test :...............................................................................27

II.4.1 ICAN :.........................................................................................................................28

II.4.2 BNS :...........................................................................................................................29

II.4.3 Véhicule Electrique :...................................................................................................29

II.4.3 Gestion des exigences :...............................................................................................31

II.4.4 Avantages de l’automatisation de tests :.....................................................................31

III. Etude de l’existant :.......................................................................................................32

III.1 Procédure de validation actuelle :.................................................................................32

III.2 Problématique :.............................................................................................................32

III.3 Solution proposée :.......................................................................................................33

III.3.1 Analyse du plan de tests :...........................................................................................33

III.3.2 L’analyse automatique des scripts de tests :..............................................................34

III.3.3 La création d’une base de données :..........................................................................34

III.4 Conclusion :..................................................................................................................34

Chapitre 3 : Analyse et spécification des besoins.....................................................................35

I. Introduction :.....................................................................................................................36

II. Analyse des besoins :........................................................................................................36

II.1 Définition d’un diagramme des cas d’utilisations :........................................................36

II. 2. Identification des acteurs :............................................................................................36

5
II.3 Diagramme de cas d’utilisation global :.........................................................................36

II.4 Raffinement de cas d’utilisation pour la création de la base de données :.....................37

II.5 Raffinement de cas d’utilisation pour vérifier la conformité :.......................................37

II.6 Description textuelle des cas d’utilisation pour la création de la base de données :......38

II.7 Description textuelle des cas d’utilisation pour vérifier la conformité :........................38

III. Diagramme de séquences :..................................................................................................39

III.1 Définition d’un diagramme de séquences :...................................................................39

III.2 Quelques diagrammes de séquences :...........................................................................40

III.3 Diagramme de séquence de « programme principal » :................................................43

IV. Diagramme d’activités globales :...................................................................................44

V. Conclusion :......................................................................................................................46

Chapitre 4 : Réalisation.............................................................................................................47

I. Introduction :.....................................................................................................................48

II. Environnement de travail :................................................................................................48

II.1 Environnement matériel :...............................................................................................48

II.2 Environnement logiciel :................................................................................................49

II.3 Langages de programmation :........................................................................................51

II.4 Bibliothèques logicielles :..............................................................................................52

III. Principales interfaces graphiques :.................................................................................53

IV. Conclusion :...................................................................................................................63

Conclusion générale et perspectives.........................................................................................64

Nétographie...............................................................................................................................65

6
Liste des tableaux
Tableau 1:Test boîte noire........................................................................................................24
Tableau 2: Test boite blanche...................................................................................................25
Tableau 3: Test boite grise........................................................................................................25
Tableau 4: Comparaison entre les méthodes de test.................................................................26
Tableau 5: Les scénarios de la base..........................................................................................39
Tableau 6: les scénarios du rapport...........................................................................................40

7
Table des figures
Figure 1:L’implantation du groupe ACTIA/ACTIELEC Technologies dans le monde...........14
Figure 2: Plan exporter du DOORS sous format .csv...............................................................16
Figure 3: La partie du test ID 14073.........................................................................................17
Figure 4: Script du test ID 14073..............................................................................................17
Figure 5: une fonction CAPL du même test 14073..................................................................17
Figure 6: La procédure du passage de même test 14073..........................................................17
Figure 7: Les contraintes du projet...........................................................................................18
Figure 8: Cycle en V.................................................................................................................19
Figure 9: DOORS.....................................................................................................................26
Figure 10: Scripts écrit sur CANoe...........................................................................................27
Figure 11: ICAN.......................................................................................................................28
Figure 12:Bluebus_150-200 KW..............................................................................................29
Figure 13:Gruau_70KW...........................................................................................................30
Figure 14:Bolloré_50KW.........................................................................................................30
Figure 15: Les outils des tests automatiques.............................................................................30
Figure 16: Extrait d'un plan DOORS........................................................................................31
Figure 17: Exemple d'un plan exporter .csv..............................................................................33
Figure 18: Le diagramme de cas d'utilisation global................................................................36
Figure 19: Cas d'utilisation de base de données........................................................................37
Figure 20: Cas d'utilisation de la conformité............................................................................38
Figure 21: Diagramme de séquences général...........................................................................40
Figure 22: Diagramme de séquences de la création d'une base de données.............................41
Figure 23: Diagramme de séquences de la vérification de la conformité.................................42
Figure 24: Diagramme de séquence de « programme principal »............................................43
Figure 25: Une partie de la base de données.............................................................................44
Figure 26: Diagramme d'activités globales...............................................................................45
Figure 27: L'unité centrale........................................................................................................48
Figure 28: CAPL interfaces......................................................................................................51
Figure 29: L'interface d'accueil.................................................................................................53
Figure 30: Bouton infos............................................................................................................54
Figure 31: Fenêtre 2..................................................................................................................54

8
Figure 32: Fichier .txt « script » de la base de données............................................................55
Figure 33: Fichier .txt "Procedure Passage".............................................................................56
Figure 34: Fenêtre 2..................................................................................................................56
Figure 35: Fenêtre des projets existants....................................................................................57
Figure 36: Fenêtre d’un projet..................................................................................................58
Figure 37: Sélectionner un dossier............................................................................................59
Figure 38: Interface de "click for files"....................................................................................59
Figure 39: Exécution du programme........................................................................................60
Figure 40: Graphe de la conformité..........................................................................................61
Figure 41: Zoom IN..................................................................................................................61
Figure 42: Rapport .txt..............................................................................................................62
Figure 43: Rapport Excel..........................................................................................................63

9
Acronymes
ARDIA= Actia Recherche et Developpement en Informatique Appliquée

UML= Unified Modeling Language

IQCP = Ingénierie, qualification et certification produit)

IBM = International Business Machines

DXL = DOORS eXtension Language

ECU = Unités de Commande Electroniques

DTC = Dynamic Traction Control

OTA = Over the Air

CSV = Comma-separated values

PIL = Python Imaging Library

10
Introduction générale
Certains problèmes des véhicules peuvent avoir plusieurs origines (mécanique, informatique,
électrique et climatique). C’est ainsi qu’un système diagnostic capable de fournir une
indication sur l’état des composants du véhicule. Ces systèmes offrent de possibilités
notamment en termes de cout de production et de maintenance.

La fiabilité de ces systèmes, joue un rôle très important dans l’industrie. Il est donc nécessaire
de prévoir des méthodes techniques permettant de livrer sur le marché un système de bon état
et qui réponds aux exigences du marché. C’est dans ce contexte que l’entreprise ACTIA à
décider d’utiliser des outils d’automatisations de ces tests, qui permet de dévoiler et expliciter
les anomalies qui peuvent altérer le fonctionnement de ces systèmes.

Ainsi, la phase de validation est une exigence critique dans ce domaine, c’est dans cette
optique que s’aligne ce projet de fin d’études qui consiste à mettre en place une solution de
vérification des scripts écrit sur CANoe par rapport aux tests en face sur Doors, réalisé au sein
de la société ACTIA du 22 Février au 18 juin 2019, dans le département Validation Software
avec l’équipe ICAN, puis avec les deux équipes BNS et véhicules électriques.

Ce projet est constitué de 4 chapitres, Le premier présente le cadre général de notre projet
ainsi que la problématique et la méthodologie adoptée. Le 2 ème chapitre présente une étude de
l’existant et la solution proposée. Le 3ème chapitre décrit la spécification des besoins et expose
les différents cas d’utilisation. Dans le dernier chapitre, nous décrivons l’environnement de la
réalisation du projet, les outils de conduite de projet ainsi un aperçu des résultats obtenus.
Enfin, nous clôturons par une conclusion et certaines perspectives.

11
Chapitre 1 : Présentation
de la société et cadre du
projet

12
I. Introduction :

Afin de situer le projet dans son cadre, ce premier chapitre sera consacré à la présentation
de l’entreprise d’accueil au sein de laquelle le travail a été effectué. En deuxième lieu, il va
décrire le cadre général du projet et du plan à suivre pour le réaliser.

II. Organisme d’accueil :

II.1 Présentation du groupe ACTIA :

Le groupe ACTIA [1] fut fondé, à Toulouse en 1986, par les familles PECH, CALMELS et
CHABRERIE suite à la scission du département « petite série » de BENDIX. A l’origine, les
principales activités du groupe ACTIA étaient la conception et la fabrication des cartes
électroniques en petites séries au profit des industries. Sa naissance coïncide avec l’avènement
de l’électronique dans le domaine automobile. Suite à cela, les dirigeants décidaient d’investir
dans ce nouveau créneau, à savoir : le diagnostic automobile, l’électronique embarquée pour
véhicules industriels et le diagnostic électronique automobile constituent, jusqu’à nos jours,
les principaux axes stratégiques du groupe ACTIA. Afin de renforcer sa capacité de
production et de maîtriser la qualité de fabrication des produits conçus jusqu’à lors par le
Bureau d’Etudes de Toulouse, ACTIA acquiert, en 1988, le groupe ALCYON (composé de
deux usines). Au début des années 90, ACTIA opte pour une diversification dans le domaine
de la Télécommunication en rachetant la société SODIELEC. L’union des deux sociétés était
fructueuse et a donné naissance à ACTIELEC. Fusionnant à son tour avec la société MORS,
ACTIELEC devient ACTIELEC Technologies en 2000. Afin de soutenir la croissance du
groupe dans les activités informatiques et électroniques automobiles, les dirigeants d’ACTIA
prennent la décision de créer, en 2005, la société ARDIA à Tunis. Avec 21 sociétés
implantées dans 15 pays partout dans le monde, et des représentants dans plus de 140 pays, la
dimension internationale du groupe ACTIA est une force. ACTIA s’est construite autour
d’une culture internationale orientée clients. L’objectif premier des sociétés du groupe est de
proposer aux clients internationaux un support local tout en permettant l’accès à l’ensemble
des compétences, expertises et ressources du groupe.

13
Figure 1:L’implantation du groupe ACTIA/ACTIELEC Technologies dans le monde.

II.2 Présentation de l’organisme d’accueil :

ARDIA ou bien ACTIA Engineering Services acronyme d’ACTIA group, est une société de
services et de conseil en ingénierie implantée au Technopôle EL-Ghazala. Elle constitue une
filiale très importante localisée dans le territoire Nord-Africain.

En septembre 2005, ACTIA recrute cinq ingénieurs, et ils sont partis à ACTIA Toulouse pour
la formation et le transfert du know-how. En janvier 2006, ACTIA commence ses activités à
l’annexe CIPI par les équipes MultiDiag et services, et pendant ce premier semestre du 2006,
d’autres projets ont été démarrés, en particulier : Systèmes embarqués, Diagnostiques,
Mécanique, etc... En novembre 2006, ACTIA déménage au parc technologique El-Ghazala, et
c’était en septembre de l’année suivante qu’elle a embauché son 50 ème salarié. En septembre
2008, elle a créé un Annexe sur le parc El-Ghazala. Et durant le mois de novembre de la
même année, elle recrute son 100ème salarié. En avril 2014, la société ARDIA recrute son
200ème salarié, et ceci prouve bien l’évolution rapide de cette entreprise. Enfin en Février
2017, ARDIA recrute son 300ème salarié.

II.2.1 Secteur d’activité :


Depuis sa création ACTIA accompagne ses clients dans le développement et l’intégration de
l’électronique embarquée communicante et des logiciels ou progiciels liés ce qui lui a permis
de développer un savoir-faire notable dans divers domaines tels que :

14
 Le diagnostic électronique automobile.
 Le développement de logiciels de diagnostique pour l’après-vente.
 Le développement de logiciels de diagnostique multimarque.
 La validation embarquée et Software.
 L’Electronique embarquée pour véhicules industriels.
 Le développement de logiciels embarqués pour calculateurs électroniques.
 Le développement de cartes électroniques pour applications temps réel embarqué.
 Le Support manufacturier.
 Le développement d’outils de fabrication de cartes électroniques.
 La Conception mécanique.

II.2.2 Départements et services :


Concernant les départements au sein d’ACTIA, on peut les classer comme suit :

 Département IQCP c’est un laboratoire de qualification dont le rôle est de vérifier la


conformité des produits aux normes et réglementations internationales.
 Département développements matériels : constitué par le service conception
mécanique, le support industriel, le support manufacturier, le test fonctionnel et la
pérennisation.
 Département Systèmes Embarqués : propose des services de Conception, et de
développement des logiciels embarqués sur des différents plateformes hardware.
 Département Développements logiciels : S’occupe de la conception, la réalisation et la
maintenance des logiciels spécifiques.
 Département Diagnostic Automobile : développe les outils de diagnostic automobile
pour des grandes marques automobiles.
 Département Validation : C’est un département comportant deux services : validation
embarquée et Software qui appliquent les techniques de vérification et de validation
pour les logiciels et les matériels développés.

II.2.3 Département d’accueil :
Notre stage de fin d’études a été réalisé au sein du service « Validation Software » du
département « Validation ». Cette division est composée d’ingénieurs et d’experts techniques
capables d’intervenir sur les étapes de validation suivantes :

 Validation fonctionnelle.
 Tests de non régression.

15
 Tests de robustesses.
 Tests de performance.

Le service « Validation Software » comporte plusieurs projets : comme ICAN et Véhicule


électrique. Son activité est de réaliser des tests automatiques ou manuels en se basant sur des
différentes techniques :

 Outil de gestion des exigences et d’écriture des plans de validation


 Bancs de tests manuels ou automatiques.
 Outil de gestion de version des applications.
 Outil de lancement des campagnes de tests.
 Outil de gestion et archivages des anomalies.

III. Cadre du projet :

III.1 Présentation du projet :

L’ingénieur de validation écrit les plans de validation sur l’outil Doors de IBM. Dans lequel
chaque test de ce plan décrit les procédures de passages, les conditions initiales, les contextes
et les résultats attendus de ce test.

Ces tests sont automatisés pour certains projets avec l’outil CANoe en langage CAPL, donc
pour chaque test on trouvera un script en CAPL.

Sur les figures suivantes, un exemple qui montre bien le script CAPL et son test en DOORS :

Figure 2: Plan exporter du DOORS sous format .csv

16
Figure 3: La partie du test ID 14073

Figure 4: Script du test ID 14073

Figure 5: une fonction CAPL du même test 14073

Figure 6: La procédure du passage de même test 14073

 On voit ici la correspondance dans cet exemple entre les fonctions écrient sur chaque
script du test et son plan en DOORS.

17
C’est ainsi que le besoin de ce sujet du projet de fin d’études est devenu nécessaire, Les
objectifs à atteindre visent à réaliser :

 Un outil qui permet de reconnaitre les différentes étapes de vérification dans un script,
de même cet outil devrait faire le même travail sur le test en face sur Doors.
 L’outil devra être capable de comparer les étapes et les vérifications à faire au niveau
du test écrit et du script correspondant.
 L’outil devra faire ce travail pour l’ensemble des tests du plan de validation, par
conséquent il serait nécessaire de pouvoir sélectionner une partie des tests du plan ou
bien l’intégralité de ces tests.
 A la fin de la comparaison, l’outil devra générer un rapport permettant une détection
plus facile et plus rapide des incohérences.

18
III.2 Méthodologie adoptée :

Afin de décrire les phases et les processus utilisés lors de la création d’une application, une
méthodologie bien spécifique est mise en place. Généralement le processus de création est
composé de quatre étapes qui sont, la spécification des besoins, la conception,
l’implémentation et la validation. Un système est jugé viable et digne de confiance s'il répond
aux trois critères suivants : la qualité, le délai et le coût, comme illustré sur la figure suivante.

Qualité

Satisfaction
Client

délai Coût

Figure 7: Les contraintes du projet

Le module du cycle en V est le processus de développement le plus utilisé et adaptable à nos


besoins. Ce modèle a été conçu suite au problème de réactivité du module en cascade, Ainsi,
il limite le retour aux étapes précédentes en cas d’anomalies. En cas d’implémentation correct
les phases de la partie montante envoient des informations sur les phases en vis-à-vis si
défauts sont détectés, afin de toujours améliorer le logiciel en question. Ce système est
désormais introduit aujourd’hui comme les standards ou la norme de tous les domaines de
l’ingénierie du système. La figure suivante montre le modèle de cycle en V :

19
Analyse des besoins et
Recette
faisabilité

Spécifications Tests de validation

Conception Architecturale Tests d’intégration

Conception détaillée Tests unitaires

Codage

Figure 8: Cycle en V

Le modèle du cycle en V comporte 9 étapes :

_ L’analyse des besoins : le client exprime sa demande, après une analyse est faite par
l’équipe, dans le but de présenter une solution intéressante au client.

_ Les spécifications fonctionnelles : Un cahier rassemblant les spécificités du produit de ces


différents cas d’utilisation et ses différentes fonctionnalités.

_ La conception générale : se présente sous forme des maquettes, qui vont présenter
l’interface graphique, ce dernier sera développée et sera l’interface client ou utilisateur final.

_ La conception détaillée : une présentation détaillée du produit final (composé de maquettes)


permettant au client de visualiser les promesses du logiciel avant le début de développement.

_ Le codage : une équipe commence par développer les fonctionnalités du produit, respectant
les spécifications détaillées, tout en respectant le contrat avec le client et surtout réaliser la
demande du client.

_ Les tests unitaires : après la phase du développement des fonctionnalités du produit, les tests
unitaires sont réalisés, ce qui veut dire, les tests de chaque méthode qui fait un traitement
spécifique.

_ Les tests fonctionnels : une succession de tests vérifiant la fonctionnalité du programme, ces
tests peuvent passer par plusieurs méthodes pour assurer le bon résultat.

20
_ Les tests de validation : cette phase permette la vérification de toutes les exigences client
décrites dans le document de spécification d’un logiciel.

_ La recette et la maintenance : l’équipe utilise un cahier de recette pour tester ces


fonctionnalités sur le produit, pour pouvoir détecter les bugs et pour les corriger, afin
d’assurer que le produit est conforme aux spécifications.

Nous avons basés notre modélisation sur UML qui offre une base solide à l’approche d’objet
et constitue un standard respecté dans le domaine. En effet, UML support plusieurs outils et
s’adapte à notre méthode de développement.

IV. CONCLUSION :

Dans ce chapitre, nous avons présenté l'entreprise d'accueil ACTIA en décrivant son histoire.
Dans la deuxième partie, nous avons décrit la problématique et les objectifs à réaliser.

Chapitre 2 : État de


l’Art et étude de
l’existant

21
I. Introduction :

Ce chapitre décrit l’environnement matériel et logiciel utilisé pour atteindre les principaux
objectifs de notre projet, en plus, L’étude de l’existant est une phase importante pour bien
comprendre le système actuel.

II. Etude du domaine de l’existant :

22
II.1 Types de tests :

Un test fonctionnel permet de vérifier automatiquement les fonctionnalités de notre


application demandées par le client dans le cahier des charges. Par exemple, vous pourrez
avoir à tester qu’un membre peut bien s’abonner, se désabonner… Nous pouvons aussi bien
créer un scénario imaginaire et voir tous les résultats possibles. De telle manière toute
correction ou changement pourra être effectuée avant le développement.

II.1.1 Intérêts des tests fonctionnels :

L'écriture de tests fonctionnels permette d’identifier fonctionnement d'une application. Au-


delà de la connaissance du code, vous devrez connaître le contenu attendu.

II.1.2 Test automatisé :

Contrairement aux tests fonctionnels, le test automatisé ne nécessite pas l’intervention d’un
humain. En effet, à travers des solutions informatiques tels que les outils d’automatisations,
un test peut être exécuté grâce à un navigateur web, soit plus généralement au niveau du
système d’exploitation. Ces tests ne laissent pas de place à l’appréciation humaine (parfois
des anomalies sont vues par les valideurs (ingénieur validation) mais ces derniers pensent
qu’il s’agit d’un comportement normal). Les risques de louper des anomalies par inattention
ou manque de concentration sont éliminés aussi par l’automatisation des tests.

II.1.3 Plan du test :

Le plan de tests fait partie du processus d’une campagne de test. Il contient la liste des cas de
test à effectuer, son but est de définir ce qui sera testé, pourquoi tester, comment les tests
s’effectueront, quand et qui teste. Le but est d’établir l’ordre dans lequel chaque composant
est complété, testé individuellement, et intégré avec les autres composants du système.

II.1.4 Cas du test :

Un cas de test (test case) est l’instanciation d’un cas d’utilisation dans un contexte défini, cela
permet de concrétiser le cas d’utilisation, sur des données concrètes, réelles. Chacun des cas
d’utilisation constituera un scénario de test.

23
II.1.5 Scénario du test :

Un scénario du test est une procédure à suivre par le testeur pour exécuter le cas de test :
manipulations à effectuer, dialogue homme/machine... Le même scénario peut être utilisé
dans plusieurs cas de test. Pour chaque scénario de tests, il faut que toutes les étapes qui se
déroulement soient identifiées à partir des spécifications et sans redondances, il faut aussi que
les préconditions et les post-conditions soient identifiées et faut finalement choisir les données
de tests. Un scénario de test permet de contrôler l’enchainement des étapes qui sont prévues
de façon formelle ou implicite dans les spécifications fonctionnelles.

II.1.6 Les spécifications fonctionnelles :

Les spécifications fonctionnelles sont une section du cahier des charges ou un document à
part entière qui spécifie, décrit, précise les fonctionnalités du logiciel en question dont le but
est de décrire de façon détaillée comment les exigences fonctionnelles vont être implémentée,
et donc permettre le développement du logiciel.

II.2 Les méthodes des tests :

II.2.1 Test boite noire :

On pourvoit à cette méthode où le test se déroule sans avoir aucune connaissance du


fonctionnement intérieur de l'application c’est-à-dire sans percevoir son code. Le testeur est
inconscient de la conception interne du système et n'a pas accès au code source.
Spécifiquement, en effectuant un test de boîte noire, un testeur détient trois aspirations : les
données en entrée, l'objet à tester et les observations attendues.

Le tableau suivant présente les avantages et les inconvénients des tests boîte noire :

Avantages Inconvénients
Efficacité : Satisfaisant pour les bouts de code. Restriction : La couverture des tests est
limitée.

Simplicité : Perception du code source n’est Superficialité : En cas d’erreur, le testeur ne

24
pas essentielle. peut pas préciser les parties du code qui sont
en cause.

Rapidité : Peu de connaissances nécessaires Redondance : un test peut perdre son intérêt si
sur le système et le langage de d’autres tests sont effectués, car son champ
programmation. d’action a tendance à être inclus dans celui
d’autres tests.

Tableau 1: Test boîte noire

II.2.2 Test boite blanche :

Les tests en « boîte blanche » consistent à vérifier le bon agissement d’une application et son
architecture interne, son mécanisme, ses processus, plutôt que ses fonctionnalités. Par
l’intermédiaire du code source de l’application, le testeur vise à analyser un programme
informatique dont on connait la logique interne.

Le tableau suivant présente les avantages et les inconvénients des tests de boîte blanche :

Avantages Inconvénients
Optimisation : perfectionner le code source du Complexité : les tests nécessitent des
programme compétences en programmation.
Agilité : vu la connaissance du code source, on Durée : Vu l’étendue du code source étudié,
peut tester rapidement. ces tests peuvent être longs.
Tableau 2: Test boite blanche

II.2.3 Test boite grise :

Cette méthode du test demande certaines connaissances sur le mécanisme interne de


l’application à tester, c’est-à-dire elle sollicite à la fois ses fonctionnalités et son
fonctionnement. Le testeur connaît le rôle du système et de ses propriétés, et a également un
acquis, bien que relativement limitée, de ses particularités internes comme la structure des
données internes et les algorithmes et les modèles utilisés. Contrairement aux tests boîte noire
où le testeur ne vérifie que l'interface du l’application, dans les tests boîte grise le testeur a
accès aux documents de conception et à la base de données. Ayant cette connaissance, un
testeur peut préparer les meilleurs données et scénarios des tests lorsqu’il vise à établir leurs
plans. Le tableau suivant présente les avantages et les inconvénients des tests boîte grise :

25
Avantages Inconvénients

Hybride : Offre les avantages du test boite Durée : la capacité de couvrir tous les cas de
blanche et boite noire. tests est limitée.

Disponibilité de l’information : le testeur peut Redondance : chevauchement des champs


concevoir scénarios de test efficaces. d’actions des tests.

Intelligence : le testeur peut créer des scénarios Exigence : une parfaite connaissance de la
plus variés et ingénieux. partie du code testé.

Tableau 3: Test boite grise

II.2.4 Comparaison entre les méthodes de test :

Pour réaliser ces tests, plusieurs méthodes sont possibles : les tests en « boîte noire », en «
boîte blanche » et en « boîte grise ». Le tableau suivant présente la liste des différences entre
ces méthodes de tests.

Méthode de Test Simplicité Code Source Agilité


Test boîte noire

Test boîte grise Limité Moyenne

Test boîte blanche

Tableau 4: Comparaison entre les méthodes de test

II.3 Les logiciels utilisés :

II.3.1 IBM Rational DOORS :

Plus communément appelé DOORS, est un logiciel propriétaire de gestion pour les systèmes et


les applications informatiques avancées. Il possède un environnement complet de gestion des
exigences qui permet de :

 décrire de façon hiérarchisée un ensemble d'exigences caractérisé par un ensemble


d'attributs personnalisables.
 établir une traçabilité entre ces exigences selon un principe de lien directionnel.
 travailler de manière collaborative en permettant des accès partagés et des moyens
intégrés de collaboration (discussion et propositions de modification).
 développer des scripts personnalisés sur la base du langage propriétaire DXL.

26
IBM Rational DOORS fonctionne sur aune architecture client/serveur. Un serveur central
(sous Windows, Linux ou UNIX) gère les données et les accès concurrents. Chaque utilisateur
possède son propre client qui se connecte au serveur pour accéder aux données. Le format de
stockage de données est de type Système de fichiers propriétaires.

Figure 9: DOORS

II.3.2 CANoe :

CANoe est un logiciel de test et développement de VECTORPINFORMATIK GmbH. Le


logiciel est principalement utilisé par les constructeurs automobiles et les fournisseurs d’ECU
pour le développement, l'analyse, la simulation, les tests, le diagnostic et la mise en service de
réseaux d'ECU et d'ECU individuels. Son utilisation répandue et son grand nombre de
systèmes de bus pour véhicules pris en charge le rendent particulièrement bien adapté au
développement de calculateurs dans les véhicules classiques, ainsi que les véhicules hybrides
et les véhicules électriques. Les installations de simulation et d’essai dans CANoe sont
réalisées avec CAPL, un langage de programmation.

27
Figure 10: Scripts écrit sur CANoe

II.4 Processus d’automatisation de test :

Dans cette partie, nous décrivons les différentes étapes du processus d’automation de test pour
ICAN, BNS et Véhicule Electrique avec une présentation de chaque projet.
Ainsi que la gestion des exigences.

II.4.1 ICAN :

Figure 11: ICAN

ACTIA iCAN est à la fois un boitier télématique et une petite valise de diagnostic embarquée
pour VL, VUL et Poids Lourds.

28
Conçu pour être « plug & play » et sans montage sur tout type de véhicule, ACTIA iCAN est
capable de restituer aussi bien des informations de gestion de flotte (km exact, trajet, position,
mode de conduite ...) que l’état technique complet d’un véhicule (intervalles de maintenance,
alertes tableau de bord, niveaux, paramètres de fonctionnement du véhicule ou défauts OBD
et constructeur sur tous types de systèmes du véhicule). Pour cela, ACTIA s’est appuyé sur un
savoir-faire unique de concepteur et fabricant de valise de diagnostic « multimarque » depuis
plus de 15 ans.

Primé aux Grands Prix de l’Innovation Equip’Auto 2015 et après un an de tests approfondis
sur les grandes marques de véhicule, ACTIA iCAN poursuit son déploiement en masse sur
d’importants parcs automobiles. Plusieurs grands clients ont déjà fait confiance à ACTIA,
comme RENAULT, PEUGEOT, VOLKSWAGEN, BMW.

Ce produit permet le :

 Tracking et gestion des flottes (positions GPS, Events, Eco-conduite)


 ECU Diagnostic (Alarme véhicule DTC, Suivi maintenance, consommation,
informations véhicule)
 SPY (écoute les trames dans le bus CAN)
 Reconnaissance de la marque d’un véhicule.
 Mise à jour FW et configuration OTA.

Dans ce projet il existe deux versions : ICAN 1 et ICAN2

II.4.2 BNS :

Le contrôleur BNS est un calculateur complexe qui nécessite un ou plusieurs


microprocesseurs pour faire fonctionner le véhicule. Il fournit l’interface requise pour mesurer
les signaux d’entrée et piloter les signaux de sortie pour des fonctions spécifiques du véhicule.

Le BNS est composé de plusieurs couches, notre travail est de valider un des modules de la
couche BSP qui permet au système d’exploitation de dialoguer avec la couche Hardware en
faisant abstraction de son architecture. Elle permet aussi d’offrir les services dont le
microcontrôleur a besoin pour fonctionner.

La couche BSP comporte plusieurs modules :

29
 LIN & CAN : Protocoles de communication série assurant la communication avec les
autres calculateurs.
 FILES : Assure la gestion de la mémoire.
 CORE : Le microprocesseur.
 INPUTS : Les entrées du calculateur.
 OUTPUTS : Les sorties du calculateur et on a deux types LS (Low Side) et HS (High
Side).

II.4.3 Véhicule Electrique :

Ce projet d’Actia est divisé sur 3 clients, Bluebus, Gruau et Bolloré, selon le Watts.

Figure 12:Bluebus_150-200 KW

Figure 13:Gruau_70KW

Figure 14:Bolloré_50KW

30
Le périmètre de ce projet c’est entre le calculateur et l’inverteur qui fait la liaison entre les
batteries et le moteur.

Le test automatique se fait entre le SST, VTsystem, une interface de communication


CAN/LIN et le pc.

Figure 15: Les outils des tests automatiques

II.4.3 Gestion des exigences :

Les tests fonctionnels vérifient les exigences exprimées par les utilisateurs et formalisées dans
le document de spécification fonctionnelle. Les cas de tests à vérifier composant le plan de
tests découlent naturellement de l’expression des exigences. Pour la gestion des exigences, les
équipes des projets utilisent IBM Rational DOORS.

La figure suivante représente un extrait du plan de tests des fonctions générales d’ICAN :

31
Figure 16: Extrait d'un plan DOORS

Dans ce plan, l’équipe écrit ID du test (un numéro unique) ainsi que son type, il peut être
automatique ou manuel. Ensuite, dans la colonne d’« Init cond » ils écrivent les conditions
initiales du test (exemple : APC ON). La colonne d’après « Proc Passage » permet d’écrire les
procédures de passage de ce test. A la fin, « Predicted result », ils notent les résultats attendus
après l’exécution du test.

Ces scénarios de tests sont ensuite transformés en des scripts. Des milliers de lignes de codes
pour un seul plan avec CANoe, De même pour les deux autres projets.

II.4.4 Avantages de l’automatisation de tests :

L’automatisation présente de nombreux avantages :

 Le gain de temps dû à un allègement de la charge de travail des équipes.


 L’augmentation de la productivité.
 La fiabilité et la qualité des tests effectués.
 L’accroissement du niveau de complétude des tests réalisés.
 La démobilisation des équipes sur les tâches répétitives au profit de tâches à plus
grande valeur ajoutée (Analyse des résultats, définition des cas de tests,
Planification…).

III. Etude de l’existant :

32
III.1 Procédure de validation actuelle :

Actuellement, l’ingénieur validation contrôle manuellement les scripts par rapport à leurs tests
rédigés, et ça après avoir écrit des centaines de lignes, comme tout être humain, il peut oublier
quelques lignes ou même écrire le mauvais script, il arrive parfois d’écrire le test avec le
mauvais ID.

Le programme semble être correct et n’affiche pas d’erreurs. Relire les scripts n’est pas
toujours possible.

III.2 Problématique :

Les projets d’ICAN, BNS et véhicules électriques sont fabriqués pour le domaine
d’automobile, qui est très critique.

Le contrôle manuel de la correspondance de chaque script développé avec le test écrit est
compliqué à faire, voire impossible dans certains cas, puisque les plans de validations
contiennent des centaines, parfois des milliers de tests. Chaque script peut contenir des
dizaines ou des centaines de lignes de codes or sans contrôle on ne peut pas savoir si un script
correspond vraiment au cas de test en face ou non, s’il effectue toutes les étapes de ce test et
s’il vérifie tous les résultats attendus.

Un simple script développé de la mauvaise façon peut avoir un dégât grave, surtout que les
calculateurs des véhicules sont mis en question. Et ce script semble être correct en le testant.

L’inconvénient le plus important que peut relever la validation automatique des scripts, c’est
qu’ils ne sont pas conforme à 100% avec les cas des tests, d’où les erreurs de validation.

On constate aussi que, la contrainte majeure pour l’automatisation des tests qui est le temps,
puisque l’ingénieur de test doit effectuer tous les tests nécessaires dans un temps très restreint.

III.3 Solution proposée :

En se basant sur l’étude de l’existant ci-avant, l’idée majeure est de simplifier la tâche de
vérifier la conformité des tests et de permettre aux testeurs d’avoir un rapport de cette
conformité.

En conséquence, le développement d’une application capable de gérer les tests automatisés


avec une architecture évolutive sera un besoin primordial. C’est dans cette perspective qu’il

33
est important de proposer un système qui va répondre aux impératifs de flexibilité et de
réactivité.

Les critères de l’application à développer sont :

_ La compatibilité avec tous les outils de processus de test existant.

_ Une performance et faillibilité élevée.

_ La capabilité d’être modifiée aisément et obéissant au besoin.

_ La possibilité de gérer plusieurs plans de tests sous différents formats.

III.3.1 Analyse du plan de tests :

La solution proposée consiste à analyser le plan de tests exporté à partir de DOORS sous
format .CSV et extraire les données nécessaires de chaque plan.

Figure 17: Exemple d'un plan exporter .csv

Il faut aussi :

o Identifier l’ID du test.


o Identifier le type du test s’il est automatique ou manuel
o Dans le cas où le test est automatique, le programme passe à ça procédure de passage
et INIT Cond pour extraire les données de ces colonnes.
o Laisser ces données à coter, les séparer par un retour à la ligne, puis passer à CANoe
pour vérifier la conformité de ce test.
o Après que ce travail finisse, le programme passe au test suivant et fait la même tache.

34
III.3.2 L’analyse automatique des scripts de tests :

Il s’agit de développer un module permettant de parcourir les scripts de tests automatiques


développés avec CANoe et exporté sous format .CAN . Dans ce module, il faut créer une
boucle qui peut :

o Chercher et extraire la partie du même Identifiant que le test du DOORS.


o Effacer les commentaires de cette partie.
o Manipuler le test d’une façon à extraire les données nécessaires pour vérifier la
conformité, vu la différence d’écriture de chaque ingénieur validation.

III.3.3 La création d’une base de données :

Il s’agit de créer un outil qui sera le lien entre DOORS et CANoe. Chaque ligne d’un scénario
de test contient une information nécessaire qui définira une fonction en script.

Commençons par cette idée, On crée une base de données capable de contenir toutes les
fonctions nécessaires du même projet, qui sera une référence pour la conformité.

III.4 Conclusion :

Dans ce chapitre, nous avons expliqué la terminologie et les mots clés de l’automatisation des
tests, ainsi, nous avons présenté notre solution proposée. Nous pouvons donc aborder l’étape
de spécification des besoins.

35
Chapitre 3 : Analyse et
spécification des
besoins

36
I. Introduction :

Cette phase consiste à comprendre le contexte du système. Il s’agit de déterminer les


fonctionnalités et les acteurs les plus pertinents, de préciser les risques les plus critiques et
d’identifier les cas d’utilisation. Nous utilisons le langage UML comme un moyen simple et
compréhensible afin de décrire les principaux cas d’utilisation.

II. Analyse des besoins :

II.1 Définition d’un diagramme des cas d’utilisations :

Le diagramme des cas d’utilisation est un diagramme UML utilisé pour donner une vision
globale du comportement fonctionnel d’un système logiciel. Un cas d’utilisation représente
une unité discrète d’interaction entre un utilisateur (humain ou non humain) et un système.

II. 2. Identification des acteurs :

Ingénieur de validation : C’est l’acteur principal intervenant dans le jeu du test logiciel. Ce
dernier est chargé d’imaginer le scénario du test automatique, d’écrire son script, d’assurer
son exécution correcte et enfin d’interpréter le rapport de test généré en fin de chaque
exécution.

II.3 Diagramme de cas d’utilisation global :

La figure suivante représente le diagramme de cas d’utilisation global de notre application.

Figure 18: Le diagramme de cas d'utilisation global

37
II.4 Raffinement de cas d’utilisation pour la création de la base de données :

A travers ce cas, l’ingénieur validation sera capable de créer des documents texte qui
l’aideront à créer la base de données, ces documents contiennent la colonne de la « PROC
Passage » incluant toutes les phrases et ces nombres de répétition. De même pour la « COND
Init », « Predicted result ». Pour le fichier .can des scripts, il y aura une autre base de données
basée sur le même principe.

L’idée est de mettre en évidence toutes les fonctions écrient pour qu’on puisse créer la base de
données. Donc on a créé ces fichiers textes qui montrent la totalité des fonctions en affichant
leurs nombre de répétition on ordre décroissant, ainsi, on pourra après comparer ses résultats
et extraire les données dont on a besoin.

Figure 19: Cas d'utilisation de base de données

II.5 Raffinement de cas d’utilisation pour vérifier la conformité :

A travers ce cas, l’ingénieur validation sera capable de générer le rapport final après le
passage par quelques étapes.

38
Figure 20: Cas d'utilisation de la conformité

II.6 Description textuelle des cas d’utilisation pour la création de la base de données :

Titre : Aide à la création de la base de données.

Résumé : Permettre à l’utilisateur de créer des fichiers texte qui l’aidera à créer une base de
données.

Acteur : L’ingénieur validation.

Scénario nominal 1. L’ingénieur choisit l’emplacement


des fichiers qui vont être créés.
2. L’ingénieur choisit un fichier .Can
ou .csv .
3. Les fichiers sont créés.
Scénario alternatif A1 l’ingénieur choisit le mauvais fichier.
2. Le système affiche un message à
l’indicateur en lui indiquant que ces dossiers
sont de mauvais type.
Tableau 5: Scénarios de la base de donéées

II.7 Description textuelle des cas d’utilisation pour vérifier la conformité :

Titre : Conformité.

Résumé : Permettre la génération du rapport final.

Acteur : L’ingénieur validation.

Scénario nominal 1. L’ingénieur choisit l’emplacement


des fichiers qui vont être créés.
2. L’ingénieur choisit un fichier .Can .

39
3. L’ingénieur choisit un fichier .csv .
4. L’ingénieur lance l’analyse de la
conformité.
5. L’ingénieur choisit de créer un
fichier Excel pour le rapport.

Scénario alternatif A1 l’ingénieur choisit le mauvais fichier.


2. Le système affiche un message à
l’indicateur en lui indiquant que ces dossiers
sont de mauvais type.
3. Le système crée un fichier texte pour le
rapport.
4. Le système affiche un graphe de
conformité.

Tableau 6: Scénarios du rapport

III. Diagramme de séquences :

III.1 Définition d’un diagramme de séquences :

Un diagramme de séquences est un diagramme comportemental ou dynamique et plus


précisément c’est un diagramme d’interaction. Il illustre un diagramme des cas d’utilisations
en montrant les interactions entre les acteurs et le système de l’application selon un ordre
chronologique.

Dans ce paragraphe, on présente les diagrammes de séquences pour illustrer les interactions
entre l’acteur principal qui est l’ingénieur de validation.

III.2 Quelques diagrammes de séquences :

La figure suivante montre les choix du testeur en ouvrant l’interface.

40
Figure 21: Diagramme de séquences général

La figure suivante est une explication détaillée de la partie création d’une base de données :

41
Figure 22: Diagramme de séquences de la création d'une base de données

 Cette dernière figure montre les étapes de la vérification de la conformité.

42
Figure 23: Diagramme de séquences de la vérification de la conformité

43
III.3 Diagramme de séquence de « programme principal » :

Ce diagramme représente la partie interne du programme principal et sa fonctionnalité avec la


base de données MySQL.

Figure 24: Diagramme de séquence de « programme principal »

La première action « voir si la phrase existe dans la base de données » est basée sur deux
actions :

 sklearn.feature_extraction.text.CountVectorizer : c’est un module de la bibliothèque


Sklearn, cette action permet de convertir le texte à une matrice de comptes de jetons,
ça veut dire que chaque mot de la phrase devient un nombre.

44
 Sklearn.metrics.pairwise.euclidean_distances :C’est aussi un module de la
bibliothèque Sklearn, en considérant les lignes de X (et Y = X) comme vecteurs,
calculez la matrice de distance entre chaque paire de vecteurs. Pour des raisons
d'efficacité, la distance euclidienne entre une paire de vecteurs de rangée x et y est
calculée comme suit :

dist(x, y) = sqrt(dot(x, x) - 2 * dot(x, y) + dot(y, y))

Ce qui permet de calculer la distance euclidienne de la phrase avec les lignes de la base de
données de la première colonne, si la distance est <= 1, alors on considère la phrase existante
dans la base de données ce qui nous mène à la 4éme action.

Figure 25: Une partie de la base de données.

La 4ème action permet de passer à la deuxième colonne de la base de données ainsi que la
troisième ainsi de suite, elle prend la phrase existante et passe à la 5 ème action. Ensuite, le
programme cherche cette fonction dans le script du même test (contient le même ID) et utilise
les mêmes bibliothèques de calcul de la 2ème action.

IV. Diagramme d’activités globales :

Le diagramme d'activité est le diagramme comportemental d'UML, permettant de


représenter le déclenchement d'événements en fonction des états du système et de
modéliser des comportements parallélisables. 

45
Le diagramme suivant représente les différentes étapes du programme qui
permettent à aboutir à un rapport final.

Figure 26: Diagramme d'activités globales

46
V. Conclusion :

À travers ce chapitre, nous avons exposé la stratégie utilisée pour la conception des tests
de validation. Nous avons témoigné cette stratégie par des diagrammes de séquences qui
modélisent le séquencement des actions effectuées par ces tests. Dans le chapitre qui suit,
nous présentons le travail réalisé qui concrétise toutes les phases par lesquelles nous avons
passé dans le cadre de ce projet.

47
Chapitre 4 : Réalisation

48
I. Introduction :

Dans ce chapitre, nous décrivons l’environnement de réalisation de notre projet. Puis, nous
présentons la mise en œuvre de la solution, avant de donner un aperçu sur les résultats obtenus
en présentant les principales interfaces graphiques de notre application et nous finissons par la
description des principales fonctions des divers modules.

II. Environnement de travail :

Cette partie présente les environnements matériels et logiciels qui ont servi pour créer cette
application en détaillant les différentes parties de la solution et en décrivant son
fonctionnement d’une manière plus approfondie. Il s’agit en premier lieu de décrire
l’architecture de nos entités et de présenter finalement une modélisation par étape de la
conception de notre application.

II.1 Environnement matériel :

Ce travail a été réalisé sur un ordinateur de bureau à la propriété d’ACTIA présentant les
caractéristiques suivantes :

Figure 27: L'unité centrale

 Système d’exploitation Windows 10 Entreprise 64 bits

49
 Processeur : Intel® Core™ i7-8700 CPU @3.20 GHz 3.19GHz
 Mémoire installée(RAM) : 8Go
 Disque dur : 1 To
 Ecran : 20 pouces Samsung

II.2 Environnement logiciel :

Les logiciels qui ont été utilisés tout au long de la réalisation du projet sont :

 IBM Rational DOORS : Nous avons utilisé DOORS pour l’écriture des scénarios de
tests.

 CANoe VECTOR : Nous avons utilisé CANoe pour l’écriture des scripts du plan de
tests.

 Microsoft Excel : Les plans de tests DOORS sont exportés en fichiers Excel. Le
rapport final aussi est écrit sur un fichier Excel.

 Anaconda : Anaconda est une distribution libre et open source des langages de


programmation Python et R appliqué au développement d'applications dédiées à la
science des données et à l'apprentissage automatique (traitement de données à grande
échelle, analyse prédictive, calcul scientifique), qui vise à simplifier la gestion des
paquets et de déploiement. [5]

50
 Spyder : est un environnement de développement pour Python. Libre (Licence MIT)
et multiplateforme (Windows, MacOS, GNU/Linux),il intègre de nombreuses
bibliothèques d'usage scientifique : Matplotlib, NumPy, SciPy et IPython.

Nous avons utilisé ce logiciel pour le développement software. [6]

 MySQL Workbench 8.0 CE : nous l’avons utilisé comme serveur de base de données
pour notre application. C’est un logiciel de gestion et d'administration de données
MySQL créé en 2004. Via une interface graphique intuitive. Il permet, entre autres, de
créer, modifier ou supprimer des tables, des comptes utilisateurs, et d'effectuer toutes
les opérations inhérentes à la gestion d'une base de données. Pour ce faire, il doit être
connecté à un serveur MySQL. [7]

 StarUML : nous avons utilisé StarUML pour créer les diagrammes UML.

51
II.3 Langages de programmation :

 Les tests ont été développés en utilisant le langage CAPL :

CAPL [4] : Communication Application Programming Language. Pour les réseaux, modules
et systèmes intégrés distribués basés sur CAN, CAPL, permet de programmer le CANalyzer
pour des applications spécifiques au développeur qui utilisent le CAN protocole. CAPL peut
également être utilisé dans l’outil CANoe pour le développement de produits distribués. Dans
cet environnement de programmation, un utilisateur peut créer, modifier et gérer des
programmes CAPL pouvant s’interfacer avec une grande variété d'entrées, de sorties et
d'autres fonctions. Événements Start-Stop, événements de saisie au clavier, capacité de
transmission et recevoir des messages CAN, l’interaction avec les ports série et parallèle,
l’utilisation de minuteries et la possibilité de l'interconnexion aux DLL spécifiques au client
fait partie des options d'interface disponibles dans la programmation CAPL environnement.

Figure 28: CAPL interfaces

 L’application a été développée en utilisant le langage PYTHON :

52
Python [8] est un langage de programmation interprété, multi-paradigme et multiplateformes. Il
favorise la programmation impérative structurée, fonctionnelle et orientée objet. Il est doté
d'un typage dynamique fort, d'une gestion automatique de la mémoire par ramasse-miettes et
d'un système de gestion d'exceptions.

Python est un langage qui peut s'utiliser dans de nombreux contextes et s'adapter à tout type
d'utilisation grâce à des bibliothèques spécialisées. Il est cependant particulièrement utilisé
comme langage de script pour automatiser des tâches simples mais fastidieuses, comme un
script qui récupérerait la météo sur Internet ou qui s'intégrerait dans un logiciel de conception
assistée par ordinateur afin d'automatiser certains enchaînements d'actions répétitives (voir la
section Adoption). On l'utilise également comme langage de développement de prototype
lorsqu'on a besoin d'une application fonctionnelle avant de l'optimiser avec un langage de plus
bas niveau. Il est particulièrement répandu dans le monde scientifique, et possède de
nombreuses bibliothèques optimisées destinées au calcul numérique.

II.4 Bibliothèques logicielles :

Tkinter : (de l'anglais Tool kit interface) est la bibliothèque graphique libre d'origine pour le


langage Python, permettant la création d'interfaces graphiques.

Matplotlib : est une bibliothèque du langage de programmation Python destinée à tracer et


visualiser des données sous formes de graphiques.

Csv : Le format CSV est le format d'importation et d'exportation le plus courant pour les
feuilles de calcul et les bases de données.

Re : Ce module fournit des opérations de correspondance d'expression régulière similaires à


celles trouvées dans Perl.

Mysql : Python a besoin d’un pilote MySQL pour accéder à la base de données MySQL.
Dans ce cas nous avons utilisé le pilote "MySQL Connector".

Textwrap3 : La mise en forme des paragraphes est nécessaire lorsque nous traitons une
grande quantité de texte et l'amène à un format présentable. Nous pouvons simplement
vouloir imprimer chaque ligne avec une largeur spécifique ou essayer d'augmenter
l'indentation pour chaque ligne suivante lors de l'impression d'un poème. Dans cette
application, nous avons utilisé un module nommé textwrap3 pour formater les paragraphes en
fonction des besoins.

53
PIL : est une bibliothèque de traitement d'images pour le langage de programmation Python.
Elle permet d'ouvrir, de manipuler, et de sauver différents formats de fichiers graphiques.

Sklearn : Scikit-learn est une bibliothèque libre Python destinée à l'apprentissage


automatique. Elle est développée par de nombreux contributeurs  notamment dans le monde
académique.

Numpy: est une extension du langage de programmation Python, destinée à manipuler


des matrices ou tableaux multidimensionnels ainsi que des fonctions mathématiques opérant
sur ces tableaux.

Xlswriter : est un module Python permettant d’écrire du texte, des nombres, des formules et
des hyperliens vers plusieurs feuilles de calcul dans un fichier Excel 2007+ XLSX.

III. Principales interfaces graphiques :

Nous exposons dans ce qui suit quelques interfaces graphiques montrant les différents
modules de notre application afin de donner une vue sur notre travail.

La figure suivante montre l’interface d’accueil permettant d’accéder aux différentes


fonctionnalités offertes par notre application.

Figure 29: L'interface d'accueil

54
Si on clique sur infos une fenêtre s’apparaitra comme la suivante :

Figure 30: Bouton infos

La figure suivante montre l’interface qui permet à l’utilisateur de choisir l’action à faire après
le clic sur NEXT.

55
Figure 31: Fenêtre 2

 Remarque : « New proeject » ouvrira une fenêtre vide qui sera remplie par les futurs
nouveaux projets.

Le clic sur DOORS data base ou CANoe crée des fichiers .txt comme la suivante :

56
Figure 32: Fichier .txt « script » de la base de données

Dans ce projet on a eu un besoin de créer une base de données, la tâche n’était pas facile sans
le développement de cet outil qui nous a permis de parser le plan total et de mettre en
évidence toute les fonctions écrient en calculant le nombre de répétition de chacune et les
mettre en ordre décroissant. Dans ce cas des fichiers textes vont être créés nommé selon la
colonne du plan « Predicted result », « Init cond » et « Proc Passage ». Le même travail est
fait pour les scripts.

57
Figure 33: Fichier .txt "Procedure Passage"

Retour à la fenêtre 2 :

Figure 34: Fenêtre 2

58
Le clic sur « Existing Projects » affiche la fenêtre suivante :

Figure 35: Fenêtre des projets existants

On peut choisir entre les 3 projets existant.

59
Le clic sur l’un des projets affiche la figure suivante :

Figure 36: Fenêtre d’un projet

60
Le clic sur « choose path » affiche la figure suivante :

Figure 37: Sélectionner un dossier

Le clic sur ”click here for CANoe/DOORS file” affiche l’interface suivant:

Figure 38: Interface de "click for files"

61
La figure suivante montre le traitement des fichiers choisis en arrière-plan.

Figure 39: Exécution du programme

« Click here to see result » prend quelque temps puis affiche le résultat final de la conformité
du plan choisi. Un graph de conformité est ensuite affiché et un rapport .txt est produit.

Ce graphe contient la conformité de chaque test du plan sur un pourcentage de 100%, la partie
bleu est le pourcentage conforme et la deuxième partie de la non-conformité.

62
Figure 40: Graphe de la conformité

Figure 41: Zoom IN

63
Le rapport texte contient chaque test du plan avec les informations nécessaires, on trouve ID
de chaque test et les anomalies.

Figure 42: Rapport .txt

Le clic sur « click here to generate an excel report » crée un rapport Excel comme présent
dans la figure suivante, ce rapport contient la conformité totale du plan de tests à la 1ère ligne
et les données de chaque test ainsi que les fonctions qui ne sont pas conformes comme elles
sont écrites sur DOORS (anomalies).

64
Figure 43: Rapport Excel

IV. Conclusion :

Dans ce chapitre, nous avons présenté l’environnement de développement matériel et logiciel


qui nous a permis de concevoir et développer notre solution, ensuite, nous avons montré les
principales interfaces graphiques de notre application réalisée.

65
Conclusion générale et perspectives

L’objectif de notre projet de fin d’étude est la mise en place de solutions pour contrôler
automatiquement la conformité de scripts aux scénarios rédigés pour ICAN en premier lieu,
puis nous avons finis par ajouter deux autres projets BNS et Véhicule Electrique.

Pour mener bien notre projet, nous avons commencé par trouver un plan adéquat au projet
proposé, étudier les données et enfin créer une base de données capable de contenir les toutes
les informations nécessaires. Vu le nombre de tests élevé, la vérification manuelle pose un
problème aux ingénieurs validations. En effet, notre solution présente un moyen simple de
vérifications.

Aujourd’hui nous étions capables de développer une solution destinée à 3 équipes, permettant
d’avoir un taux de conformité de 100%, d’où la qualité des scripts et par ailleurs nous étions
capables aussi d’optimiser la charge horaire occupée par la validation des tests.

Cependant, Le défi majeur a été de proposer une solution qui réalise un compromis entre
sécurité, performance et compatibilité. Cette expérience nous a été constructive, car nous a
permis non seulement d’appliquer les connaissances acquises durant mon cursus académique,
mais, aussi de découvrir le domaine de la validation logicielle, les différents techniques et
outils utilisés pour assurer la qualité d’un logiciel et surtout de créer une application avec le
langage de programmation Python et se familiariser avec ces différents bibliothèques.

Enfin, nous tenons à signaler que ce travail répond aux besoins préalablement fixés mais il
peut être amélioré et y ajoutant de nouveaux projets et de nouvelles fonctionnalités. En effet,
il serait intéressant de créer une base de données automatique générée à partir les plans de
tests. Une chose que sera encore plus intéressante c’est de créer une application capable
d’écrire les scripts du test à partir du plan DOORS.

66
Nétographie

[1]https://openclassrooms.com/fr/courses/4087076-testez-fonctionnellement-votre-
application-symfony/4395706-quest-ce-quun-test-fonctionnel

https://www.ibm.com/fr-fr/marketplace/requirements-management/details

[2] https://en.wikipedia.org/wiki/CANoe

[3] https://www.actia.com/fr/presse/actualites/item/actia-ican-montre-en-puissance

[4] Quick Introduction To CAPL Version 1.1

[5] https://fr.wikipedia.org/wiki/Anaconda_(Python_distribution)

[6] https://fr.wikipedia.org/wiki/Spyder_(logiciel)

[7] https://fr.wikipedia.org/wiki/MySQL_Workbench

[8] https://fr.wikipedia.org/wiki/Python_(langage)

67