Soutenance mémoire
Caractéristiques des systèmes ayant un niveau de mobilité élevé
Un système informatique peut être considéré comme mobile à partir du moment où l’application s’exécute sur un dispositif pouvant être déplacé tel qu’un lecteur audio, un appareil photo, un téléphone portable ou même un robot. Les principales différences par rapport aux systèmes traditionnels selon [Satyanarayanan 1996] sont classées en quatre contraintes : les ressources limitées, la sécurité et la vulnérabilité, les performances et la fiabilité et une ressource en énergie finie. Dans le cadre de systèmes mobiles composés de plusieurs dispositifs mobiles communicants entre eux, les communications sont impactées par ces quatre contraintes. Les liens de communication sont très souvent des liens sans fil et la structure du réseau évolue en fonction des déplacements des dispositifs mobiles. Les communications sans fil sont aussi caractérisées par la possibilité de communiquer avec des dispositifs inconnus par exemple dans le cadre de diffusion dans le voisinage appelé broadcast. Nous allons détailler ces deux caractéristiques dans les paragraphes suivants.
Topologie réseau dynamique Les systèmes mobiles sont composés d’un ensemble de dispositifs mobiles communicants entre eux appelés nœuds. La topologie du réseau formée par cet ensemble de nœuds est donc dynamique. Elle évolue au fur et à mesure des déplacements [Macker 1999], des liens radios peuvent être interrompus, d’autres peuvent être établis. La topologie du réseau est donc fortement liée aux déplacements des nœuds. En plus de la mobilité physique, les nœuds peuvent aussi êtres activés ou désactivés à la suite d’actions de la part de l’utilisateur par exemple éteindre ou allumer un équipement. Dans le cadre des systèmes ubiquitaires, le système peut aussi réagir de façon autonome par exemple grâce aux informations contextuelles à sa disposition.
Communication avec des partenaires inconnus dans le voisinage Dans un réseau de type ad-hoc, l’envoi de message par diffusion auprès du voisinage est un mode de communication courant [Baumann 1997]. Il est principalement utilisé pour la découverte du voisinage. N’importe quel nœud se trouvant à proximité d’un autre nœud, peut recevoir et répondre à un message diffusé par celui-ci. Lors de l’envoi du message, l’émetteur ne sait pas quels sont les nœuds qui vont pouvoir recevoir et répondre au message. La communication avec des partenaires dans le voisinage repose sur la découverte de ce dernier. Ces mécanismes de découverte peuvent être une source de surcharge et de collisions dans le réseau. Pour résoudre ces problèmes, il existe des protocoles de diffusion efficaces [Winstanley 2012].
Le test
L’activité de test vise à évaluer la qualité d’un logiciel. Pour cela il existe différentes techniques permettant de mettre en évidence d’éventuelles erreurs. Avec le test, on ne peut que vérifier qu’un système se comporte de la manière attendue. Une faute est détectée lorsque le résultat d’une exécution du test ne correspond pas au résultat attendu [Ammann 2008]. Comme nous l’avons vu dans la Figure 2.2, le test est une technique de vérification dynamique, c’est-à-dire qu’elle nécessite l’exécution du système. Le test consiste à stimuler les interfaces du système avec des valeurs particulières contrairement à la vérification statique qui est, elle, focalisée sur la structure du code et ne nécessite pas l’exécution du système. Contrairement à d’autres méthodes de vérification, le test n’apporte aucune garantie sur l’absence de faute. Il n’est pas possible de tester toutes les valuations possibles de l’ensemble des paramètres d’entrée du système. Le test permet donc de mettre en évidence des fautes mais ne permet en aucun cas de garantir l’absence de fautes dans le système. Observer les sorties de test et décider si elles satisfont les conditions de vérification est généralement connu sous le nom de problème de l’oracle [Adrion 1982], ou comment décider de l’exactitude des résultats observés, fournis par le programme en réponse aux entrées de test ? [Weyuker 1982]. Dans le cadre d’applications mobiles, il peut y avoir des cas où les entrées sont non contrôlables et les sorties non observables. Par exemple, si un dispositif est testé dans un environnement réel, les dispositifs avoisinants peuvent rejoindre et quitter le réseau de manière imprévisible. Les entrées du dispositif cible ne peuvent donc pas être déterminées et les sorties attendues ne peuvent pas être prévues. La méthode de création de test la plus couramment utilisée reste l’écriture manuelle des cas de tests. Cette tâche s’avère de plus en plus délicate à réaliser avec la complexité des systèmes actuels et demande l’expérience d’un ingénieur de test. Pour cela, la création de test est de plus en plus intégrée au processus de développement d’un logiciel. Par exemple, il existe des outils de génération de tests à partir des spécifications en UML [Offutt 1999]. Ce type de test permet de travailler en faisant abstraction du code source, puisque les propriétés à vérifier sont extraites de la spécification et non pas du code du système sous test, on ne sait pas comment ont été implémentées les spécifications. Il existe aussi une extension au langage UML dédiée au test, il s’agit d’UML Testing Profile [Schieferdecker 2003]. Cette extension permet de créer des tests directement grâce à des diagrammes de séquences, cela permet un lien fort entre la spécification et le test. L’UML Testing Profile peut très bien être mis en œuvre pourtester des systèmes mobiles. Par exemple, il a été utilisé dans le cadre du test d’un algorithme d’itinérance de dispositifs bluetooth mobiles [Dai 2004]. Elle permet de détailler les différents types de tests qui existent. Un premier axe Support de conception représente le support à partir duquel sont construits les tests. En effet les tests peuvent être construits en se basant sur le code source de l’application à tester, on parlera de test en boite blanche ou à partir des spécifications de l’application, on parlera alors de test en boite noire. Le deuxième axe correspond à la taille du système et permet de classer le niveau de détail du système testé. Le troisième axe quant à lui correspond au type de test correspondant à la caractéristique à vérifier du système.
Interactions utilisateur
La majorité des dispositifs mobiles n’est pas équipée de souris voire même de clavier contrairement à ce que l’on retrouve sur la majorité des systèmes classiques. Ils sont plutôt équipés d’écrans tactiles voire même de reconnaissance vocale, ce qui oblige à revoir la gestion des interactions entre l’utilisateur et l’application. Par exemple une saisie grâce à un écran tactile peut être impactée par le niveau d’utilisation des ressources du dispositif qui fait varier le temps de réponse. De plus en plus d’interfaces tactiles détectent en même temps plusieurs points de pression, ce qui implique une multitude de scénarios possibles dans la saisie d’une information. Toutes ces spécificités des interfaces d’entrées et sorties des systèmes mobiles demandent des techniques de test adaptées. En plus des contraintes provenant des dispositifs d’entrées et sorties des systèmes mobiles, la plupart des applications ayant une interface utilisateur doivent appliquer des règles de mise en page spécifique au système d’exploitation mobile utilisé. Malgré cela, sur des dispositifs différents, l’application peut ne pas avoir le même rendu et se comporter de manière différente [Hu 2011], ce qui oblige à tester une même application sur un ensemble représentatif de plate-formes d’exécution. Pour chacune des plate-formes, il faut aussi tester dans différentes circonstances de charges système et mémoire par exemple.
Simulation réseau
Une méthode est de simuler le réseau. Dans le cas de systèmes mobiles les réseaux de type Ad-hoc sont très utilisés. Un outil de simulation de réseau permet de gérer la perte de paquets et la puissance du signal radio de façon transparente pour le nœud testé. Ce type de simulation a été expérimenté dans [Teodosiu 2010]. La mobilité rend extrêmement complexe le test de systèmes car la modification de leurs positions et de la connectivité réseau peut entraîner des changements imprévisibles dans les informations contextuelles.
|
Table des matières
1 Introduction : contexte et problématique
1.1 Contexte
1.2 Problématique
1.3 Contributions
1.4 Présentation du plan
2 État de l’art
2.1 Systèmes mobiles et ubiquitaires
2.1.1 Définitions
2.1.2 Caractéristiques des systèmes ayant un niveau de mobilité élevé
2.1.3 Caractéristiques des systèmes ayant un niveau d’instrumentation de l’environnement élevé
2.2 Vérification et Validation
2.2.1 Techniques de vérification
2.2.2 Le test
2.3 Test de systèmes informatiques mobiles et ubiquitaires
2.3.1 Les particularités des systèmes mobiles et leurs implications sur le test
2.3.2 Simulation de systèmes mobiles
2.3.3 Différentes approches du test de systèmes mobiles
2.3.4 Description de scénarios de Test
2.4 Conclusion
3 TERMOS : un langage de scénario pour les systèmes mobiles
3.1 Une approche de test fondée sur la description de scénarios
3.1.1 Définitions préliminaires
3.1.2 Approche de test
3.2 Spécificités de la modélisation de systèmes mobiles
3.3 Objectifs de TERMOS
3.3.1 Représentation des scénarios mobiles avec TERMOS
3.3.2 Analyse d’un scénario TERMOS
3.4 Syntaxe du langage
3.4.1 Syntaxe de la vue spatiale
3.4.2 Formalisation de la vue événementielle
3.4.3 Intégration de la vue spatiale dans la vue événementielle
3.5 Analyse de l’ordre des événements
3.5.1 Sémantique
3.5.2 Construction de l’automate
3.5.3 Vues spatiale et événementielle combinées
3.6 Conclusion
4 Conception et architecture
4.1 Architecture générale
4.1.1 Spécification du scénario
4.1.2 Collecte de traces
4.1.3 Vérification du scénario
4.2 Validation de l’outillage
4.2.1 GraphSeq
4.2.2 Grammaire des prédicats
4.2.3 Vérification syntaxique
4.3 Choix de représentations des données
4.3.1 Représentation des automates
4.3.2 Représentation des traces d’exécution
4.4 Choix de l’environnement de mise en œuvre du langage
4.5 Conclusion
5 Spécifier un scénario
5.1 Définition de la vue spatiale
5.2 Définition de la vue événementielle
5.2.1 Représentation d’éléments non standards
5.2.2 Contraintes syntaxiques sur les opérateurs standard
5.3 Une grammaire pour écrire des prédicats
5.3.1 Syntaxe
5.3.2 Mise en œuvre
5.3.3 Vérification
5.4 Transformation du scénario
5.4.1 Création de la séquence de configurations spatiales
5.4.2 Création de l’automate
5.4.3 Vérification de la forme du scénario
5.4.4 Rapport de génération
5.5 Conclusion
6 Analyser un scénario
6.1 GraphSeq pour l’analyse de la vue spatiale
6.1.1 Principes de fonctionnement
6.1.2 Amélioration de la gestion des ressources
6.1.3 Évaluation de l’efficacité de l’appariement et amélioration des performances
6.2 Validation des traces
6.2.1 Vérification d’un automate sur une trace
6.2.2 Prise en compte des prédicats
6.3 Aide à l’analyse par visualisation graphique
6.3.1 Vue générale
6.3.2 Visualisation des transitions franchies
6.3.3 Visualisation des événements déclencheurs
6.4 Conclusion
7 Démonstrateur
7.1 Plate-forme d’exécution
7.1.1 Architecture générale
7.1.2 Gestionnaire de contexte
7.1.3 Simulateur réseau
7.1.4 Support d’exécution de l’application
7.2 Étude d’un protocole d’appartenance de groupe : le GMP
7.2.1 Principe
7.2.2 Propriétés
7.3 Scénarios TERMOS des propriétés du GMP
7.4 Scénarios illustrant des comportements particuliers
7.5 Expérimentation
7.5.1 Plate-forme de l’étude de cas
7.5.2 Résultats des tests
7.6 Conclusion
8 Conclusion et perspectives
A Construction de l’automate
A.1 Analyse du diagramme
A.2 Construction de l’automate
Bibliographie
Télécharger le rapport complet
