| Summary: | La croissance rapide de l'utilisation des systèmes informatisés dans tous les domaines donne une importance cruciale au problème des anomalies informatiques. De nos jours, les ordinateurs aident les humains dans la plupart des aspects de nos vies quotidiennes, et les applications informatiques sont rendues très puissantes et complexes. Tester une application informatique simple n'est pas une tâche très difficile, mais tester un grand logiciel ayant des millions de lignes de code est une tâche très complexe. Un grand logiciel est complexe et ses interfaces avec les systèmes externes élargissent l'ampleur des acticités de test. L'industrie informatique débourse beaucoup d'argent et de temps pour tester de tels logiciels. Elle cherche toujours de nouvelles méthodes pour épargner temps et argent nécessaires à ces tests.
Dans ce mémoire nous allons aborder les difficultés rencontrées lors de test de grands logiciels et les limitations pratiques rencontrées. Nous allons aussi expliquer la nature des anomalies que nous cherchons à débusquer dans le logiciel sous test. Nous montrons comment bâtir un dictionnaire contextuel qui va nous aider dans notre méthode de test afin de trouver les anomalies.
L'objectif principal de ce travail est de présenter une méthode de test pour aider les organisations qui exécutent des tests pour des grands logiciels en tant que tierce partie, c'est-à-dire, une organisation qui n'est pas responsable de la conception de logiciel. Ce qui rend le processus potentiellement complexe impliquant un grand nombre de personnes géographiquement distribuées avec différentes perspectives et compétences. Le processus complet de notre méthode est présenté sous forme détaillée dans ce mémoire.
Ce mémoire présente une méthode et un outil permettant de mieux gérer le processus de test de grands logiciels complexes et de créer des cas de test plus efficaces et reproductibles. Plus important encore, cette méthode va permettre de réduire le temps nécessaire pour élaborer les cas, le plan et la procédure de test. De plus, et contrairement à la méthode de boîte noire, avec cette méthode nous serons en mesure de trouver la raison de l'anomalie trouvée. Toutes les étapes, les difficultés qui peuvent surgir au cours du processus et les livrables à chaque étape seront présentés et détaillés dans ce mémoire.
Une comparaison avec les deux méthodes de test les plus répandues, méthode de boîte noire et méthode de boîte blanche, sera présentée à la fin de ce mémoire pour montrer les avantages de notre méthode. Le type d'anomalies à débusquer dans le cadre de ce mémoire est celui des anomalies informatiques relatives aux problèmes des finitudes de grandeur. Nous recommandons comme travail futur d'appliquer notre méthode pour le problème des
« bombes logiques ». Car le test dans des conditions normales ne révèlera pas une telle bombe. Par contre, si les conditions spéciales requises par la « bombe logique » sont rencontrées, le programme agira d'une façon différente. Un bon dictionnaire relatif au contexte de bombes logiques et l'application de notre méthode va aider à trouver les anomalies recherchées. Un autre travail serait d'appliquer notre méthode pour tester les applications informatiques pour le problème de conversion vers l'Euro, un problème que tous les établissements informatiques cherchent à résoudre pour le début de l'an 2001.
|
|---|
