Exercices corriges PDF



Les répercutions de l’automatisation des tests dans le génie logiciel.

A2T2 : Automated Audio Test Tool

Présenté par Matthieu Tardivel

Directeurs de recherches :

Ecole   : Nathalie Camus, Laurent Leger

Entreprise : Nisrine Fajaj

Une fausse erreur n'est pas forcément une vraie vérité.

Pierre Dac, Les pensées

Remerciements

J’ai tiré une grande satisfaction de ce stage effectué au sein de Genesys, ceci grâce à la qualité du travail qui m’a été proposé et aux relations humaines constructives que j’ai pu établir.

Je souhaite remercier François Legros de m’avoir accueilli dans son entreprise. Je tiens à remercier Nisrine Fajaj, ma responsable de stage, qui m’a accompagnée tout au long de ce projet.

J’adresse un remerciement tout particulier à Julien Allègre pour l’aide efficace qu’il m’a apportée.

Enfin, mes remerciements s’adressent également à l’ensemble des membres de mon service, particulièrement Fabienne Montgaillard, Nicolas Quoyer, Benoît Matthys, Didier Cellier et Fabrice Richard pour leur soutien et leur sympathie.

Sommaire

Introduction 1

PARTIE I : Présentation de la phase test au sein du génie logiciel 8

1. Le génie logiciel et le test. 9

1.1 Rappel du cycle de développement 9

1.2 Le modèle en V 10

1.3 Le service de test au sein d’une entreprise 12

1.4 Les enjeux de la qualité logicielle 13

1.5 Les critères de qualité 16

1.6 L’externalisation (sous-traitance) 18

2. Les différentes formes de test 20

2.1 Les tests unitaires : 20

2.2 Les tests d’intégration : 20

2.3 Tests de validation 21

2.4 Test de régression 21

3. Les tests automatiques 22

3.1 Présentation 22

3.2 Le test et l’automatisation du test sont différents 22

4. Le service System Engineering and Testing (SET) de Genesys Conferencing 25

PARTIE II : Le processus d’automatisation des tests 31

1. Le choix de l’automatisation 32

1.1 Définition des besoins 32

1.2 Evaluation des coûts et délais 33

2. La démarche de l’automatisation 34

2.1 Construction du test 35

2.2 L’automatisation du test 37

3. Les outils de test 41

4. Les développements spécifiques. 45

4.1 Les conditions du développement spécifique 45

4.2 L’évaluation du budget 46

4.3 Mise en place de l’architecture 47

4.4 Développement de l’applicatif 47

4.5 Cas Pratique : A2T2, ma réalisation au sein de Genesys 48

PARTIE III : Les répercutions de l’automatisation dans le génie logiciel. 64

1. Les métriques de l’automatisation 65

2. Les bénéfices de l’automatisation des tests 67

2.1 Le répercutions sur la qualité 67

2.2 Les répercutions économiques 68

2.3 Les répercutions sur les ressources humaines 69

3. Les problèmes courants liés à l’automatisation des tests 70

3.1 Les répercutions sur la qualité 70

3.2 Les conséquences économiques 71

4. L’avenir de l’automatisation dans le génie logiciel 72

4.1 Une communauté active 72

4.2 Les outils de mesure des performances applicatives 73

4.3 Les répercutions de l’automatisation à Genesys Conferencing 75

4.4 La régression : première motivation de l’automatisation 75

Conclusion 78

Bibliographie 82

Netographie 83

Table des figures 84

Glossaire 85

Annexes Error! Bookmark not defined.

1. Plan de test Access-Disconnection 88

2. Documentation de A2T2 91

3. Extrait des rapports XML et feuille de style XSL 95

Introduction

La réalisation de ce mémoire vient clore mon cursus de formation en ingénierie informatique effectué à l’EPSI. Au cours de mes années d’études, je me suis intéressé plus particulièrement au domaine du génie logiciel. Ce dernier a beaucoup évolué tout au long de son existence et particulièrement ces cinq dernières années. Mes recherches, qui sont rapportées dans ce document, sont centrées sur une composante bien particulière du génie logiciel à savoir le test. L’histoire contemporaine du génie logiciel regorge d’exemples d’erreurs ayant entrainé des incidents majeurs et parfois des catastrophes. Dans les années 60, la NASA avait fait les frais d’une erreur survenue dans le programme de pilotage de la sonde Mariner. En effet un point s’était glissé à la place d’une virgule dans le code du programme et la sonde fut déroutée de sa trajectoire, puis perdue dans l’espace avec les millions de dollars que l’on y avait investi. Plus récemment, la fusée Ariane 5 avait explosée après quelques secondes de vol. Il est apparu que cet incident avait pour origine une simple fonction de conversion défectueuse dans le programme de navigation. Ces exemples ne sont qu’une infime partie de l’énorme quantité de disfonctionnements issus d’erreurs humaines.

L’informatique se positionne dans tous les domaines de nos jours, aussi bien dans le quotidien de tout un chacun que dans des activités très spécifiques. Ce qui sous-entend que les domaines les plus sensibles ont recours aux systèmes informatiques. Or, tout système peut potentiellement être défaillant, et plus le système est complexe plus le risque est grand. On comprend aisément que lorsqu’il s’agit d’une application dédiée au pilotage d’une centrale nucléaire ou à la navigation d’un avion, l’on souhaite minimiser voir essayer de supprimer les défaillances techniques. Pour ce faire, il est nécessaire d’adopter une démarche rigoureuse.

Les démarches relatives à la conception du Système d’Information (SI) sont multiples. Cependant, elles disposent toutes de points communs, notamment une chronologie découpée en phases. Parmi ces dernières on retrouvera la phase d’analyse, de conception, de développement et enfin de test. Pourquoi le test est-il une partie intégrante de ces démarches ? Instinctivement, il paraît évident que lorsque l’on est consommateur final, on ne souhaite pas être des testeurs du produit ou service que l’on a acheté. Prenons l’exemple des attractions dans les parcs de loisirs, qui sont généralement contrôlées par des applications logicielles. Qui souhaiterait s’asseoir à bord de l’une d’elles sachant qu’on ne les a jamais testées ? Cette question permet d’entrevoir un objectif de la phase de test : la fiabilité.

La fiabilité peut se définir par l’absence de défaillance. Pour qu’un logiciel soit correct il ne doit pas être affecté pas des défauts (bugs). Un défaut peut survenir lorsque le concepteur du système y introduit une erreur involontaire. Comme dit le dicton « l’erreur est humaine », on pourrait également ajouter à ce dernier que plus le système est complexe et volumineux plus le risque d’erreur est grand. Réduire ces erreurs permet d’obtenir un produit de qualité.

Qu’est ce que la qualité ? La qualité peut se définir comme « l’Aptitude d'un ensemble de caractéristiques intrinsèques à satisfaire des exigences » (définition ISO 9000, 2000). En effet, la qualité dispose d’une place centrale dans l’ensemble des dispositifs de conception des SI. Elle permet d’assurer un niveau de sécurité minimal et un prix correspondant à ce niveau. Ce qui ne veut pas forcement dire qu’un prix élevé implique obligatoirement un produit de qualité, ni même qu’un produit à faible coût n’est pas de qualité. Commercialement, la qualité est une forme de garantie de la satisfaction des utilisateurs finaux. Ce qui nous amène à la notion d’Assurance qualité, c’est à dire l’ensemble des démarches permettant d’obtenir des produits et services de qualité. Il apparaît à présent évident que les notions de qualité, fiabilité et de test sont étroitement liées

Le test est omniprésent dans l’ensemble du processus informatique de développement. Qu’est que le test ? C’est une activité du génie logiciel ayant pour objectif de déceler pendant toute la durée de vie du système les failles ou anomalies de celui-ci. En effet, le logiciel « zéro défaut » n'existe pas. La présence de fautes logicielles systématiques, introduites à la conception d'un dispositif programmé, doit être considérée avec beaucoup d'attention, en particulier lorsque les conséquences de ces fautes peuvent influer sur la sécurité d'un dispositif complexe. Le test est donc l’activité fer de lance de la qualité, et les entreprises qui investissent dans cette activité observent systématiquement des améliorations quant à la qualité de leurs produits ou services informatiques. Le test a également pour objectif de valider le passage en production d’un produit, ce qui implique une responsabilité importante de l’équipe qui effectue cette activité. Pour ne pas faillir à cette tâche, le test est devenu une démarche rigoureuse s’accompagnant de procédés prédéfinis. Parmi ces derniers on pourra relever l’élaboration d’un Plan de Test, ayant pour but de valider une ou plusieurs fonctionnalités de l’application. Il va de soit que plus un système est vaste plus il paraît difficile, voir impossible, de tester de manière exhaustive l’ensemble des fonctionnalités. C’est d’ailleurs toute la difficulté de l’activité du test au sein d’une entreprise : déterminer le seuil de tolérance pour la validation d’application.

Une enquête publiée fin septembre 2005 par une société de services informatiques de renom (LogicaCMG) met le doigt sur la faiblesse des directions des systèmes d'information (DSI) sur le plan des tests applicatifs. Alors que 76% des responsables informatiques interrogés jugent cet aspect stratégique, 68% considèrent comme beaucoup trop nombreuses les applications déployées sans être passées par cette phase probatoire. Partant de là, 89% déclarent avoir essuyé des problèmes dans les 48 heures suivant la mise en place d'un nouveau système.

Pire encore, selon l'étude financée par le "National Institute of Standards and Technology" (NIST) le manque de qualité (et donc de tests) des logiciels coûterait à l'économie américaine la bagatelle de 59,5 milliards de dollars, soit 0,6% du produit intérieur brut. 21,2 milliards seraient endossés par les développeurs de logiciels eux-mêmes et 38,3 milliards par les utilisateurs. Des coûts qui ont été calculés en évaluant le temps consacré par les utilisateurs et les développeurs à la résolution des problèmes logiciels ainsi que les pertes de productivité qui en découlent.

Assurer le passage en phase opérationnelle d'une application, qu'elle soit développée par un éditeur ou de façon spécifique pour l'entreprise (ou l'un de ses départements), est une tâche pour le moins complexe au vu des impondérables pouvant se révéler lors de cette transition (outils inadaptés, dysfonctionnements, intégrations défectueuses, etc.).

Pour mener à bien cette tâche complexe, différentes démarches sont mises à disposition des chefs de projets informatique. Cependant, les tests étant effectués par des hommes les risques d’erreurs sont là encore bien présents. Pour réduire ces erreurs, on observe ces dernières années l’apparition de nouvelles techniques, principalement axées sur l’automatisation des phases de tests. Cette dernière a pour objectif de se substituer aux tâches opérationnelles répétitives des testeurs, et gagner ainsi en temps d’exécution, lequel sera investi dans l’analyse des erreurs recensées par l’outil. Ce transfert du travail « manuel » de l’homme vers un outil automatisé est un processus largement éprouvé dans l’histoire de l’industrie, et c’est de manière assez naturelle que cette démarche s’inscrit dans les projets informatiques.

La phase de validation des logiciels s’est donc tournée vers l’automatisation des tests logiciels. Beaucoup d’entreprises ont mis à l’essai ce processus. Malheureusement, on ne compte plus le nombre de projets d’automatisation des tests qui se sont soldés par un échec. Aujourd’hui, il est pratiquement passé dans les « mœurs informatiques » que ce type de démarche présente un intérêt relatif. Pourtant quand on observe les bénéfices d’une automatisation réussie, on souhaiterait en faire de même. Pour cela, il faut considérer cette action comme un projet à part entière, avec ses étapes incontournables, ses pré-requis, ses délais de mise en œuvre, et surtout le besoin de compétences spécifiques.

Au cours des mes deux derniers stages j’ai eu l’occasion d’intégrer un projet au sein de la société GENESYS CONFERENCING, qui vise à développer une plateforme de test automatiques pour le service historique de la société à savoir la téléconférence. L’automatisation d’un tel service s’inscrit dans une démarche qualité chère à Genesys. Cependant, l’automatisation des tests reste très marginale au sein du processus de développement de Genesys. Une carence que la direction de la R&D (Recherche et Développement) souhaite voire corrigée à cour terme.

Genesys S.A. est une entreprise d’environ 1100 employés qui est implantée sur quatre continents, dans 21 pays et dont le siège social se situe à Montpellier. Genesys vend des solutions de téléconférence multimédia automatisées qui intègrent l’audio, la web et la vidéo conférence. L’histoire de la société se caractérise depuis sa création en 1986 par des innovations technologiques déterminantes. Ces dernières ont permis de proposer à leurs clients un service de téléconférence mondialement reconnu.

Durant toutes ces années, Genesys a également su faire des acquisitions stratégiques qui lui ont permis : soit d’élargir son marché à l’international, comme en 2001 avec l’acquisition de Vialog Corporation - 1er spécialiste indépendant aux Etats-Unis ; soit d’étendre sa gamme de services avec par exemple l’acquisition en 2001 de la société canadienne Astound, spécialisée dans le développement d’applications de data et de Web conférence.

J’ai intégré, aux cours de mes deux derniers stages (2ème et 3ème année), le service de test de Genesys (SET : System Engineering and Testing) et plus particulièrement l’équipe affectée au test de la plateforme de téléconférence audio. Ces expériences professionnelles m’ont naturellement amené à l’interrogation suivante :

Quels sont les enjeux de l’automatisation des tests dans le monde du génie logiciel ?

En effet, les répercutions d’une telle démarche peuvent se mesurer de plusieurs manières : sur le plan économique, humain, etc. Pour chacune d’elle il y aura un impact positif ou négatif que j’essaierai d’éclairer dans ce document. Implicitement cette problématique en ouvre une autre à savoir : quel sont les enjeux de l’automatisation des tests sur la qualité logiciel ?

En effet, la notion de qualité logiciel et de test son étroitement liés et indissociables. Les entreprises de développement informatique sont à l’heure actuelle face à plusieurs interrogations : doit-on investir dans l’automatisation des tests ? De quelle manière doit-on investir ? La sous-traitance des tests, dans un pays où la main d’œuvre est bon marché, n’est-elle pas une meilleure solution ? Autant d’interrogation auxquelles nous essaierons de répondre de manière objective.

Pour répondre le plus précisément possible à cette problématique, je commencerai dans un premier temps, par présenter le génie logiciel de manière générale. Puis nous entrerons dans le détail de la phase de test dans le cycle de développement informatique, avec les différents aspects qui la caractérisent. Nous essaierons de comprendre également ce qui pousse aujourd’hui les entreprises de développement à automatiser une partie des tests.

Dans un deuxième temps, j’exposerai le processus d’automatisation des tests. Ainsi nous verrons la démarche permettant l’intégration de l’automatisation au sein du processus de test. Il faudra en suite faire un choix entre l’achat d’un outil ou le développement interne. En effet, le marché met à disposition des entreprises de développement un ensemble de produits divers spécialisés dans l’automatisation des tests d’interface. L’objectif, à l’issue de cet exposé, sera d’être capable d’effectuer le choix le plus judicieux parmi l’ensemble des solutions proposées. Enfin, je présenterai une application directe du développement spécifique d’un outil de test avec A2T2 (Automated Audio Test Tool) que j’ai réalisé au cours de mon stage.

Pour finir, je mettrai en avant l’ensemble des répercutions de l’automatisation des tests dans le génie logiciel et particulièrement dans la qualité logiciel. Il apparaît évident qu’une telle démarche à des répercutions sur l’ensemble des composantes d’un service (humain et matériels), et donc peut devenir critique en cas d’erreurs. Nous verrons également l’avenir de l’automatisation et plus particulièrement à Genesys Conferencing.

PARTIE I : Présentation de la phase test au sein du génie logiciel

1 Le génie logiciel et le test.

L’activité de test est une partie intégrante du génie logiciel. Il convient donc de rappeler la place qu’occupe le test dans le cycle de développement ainsi que dans une entreprise d’ingénierie informatique.

1 Rappel du cycle de développement

La maîtrise du génie logiciel est une nécessité pour les ingénieurs travaillant dans des entreprises développant des systèmes incluant du logiciel. Elle est fondamentale si ces systèmes sont de grande taille ou si leur utilisation présente des risques pour la vie humaine, l'équilibre écologique ou encore la propriété.

Le génie logiciel se base sur des principes, propose des méthodes et offre des techniques permettant de développer des logiciels de qualité, de façon économique dans les délais impartis.

Le génie logiciel s'intéresse tout d'abord au processus de développement et propose différents modèles décrivant les étapes à respecter pour ce faire. Les activités y afférant comprennent l'analyse, la spécification, la conception, programmation et la validation. Chacune de ces activités est soutenue par un ensemble de techniques et outillages spécifiques.

Le développement de logiciels est encadré par des processus globaux tels que la gestion des ressources (humaines et autres), la validation et vérification, la documentation, la gestion des versions ainsi que celle des configurations.

Comme tout produit complexe, le cycle de vie du logiciel passe par les phases (ou étapes) suivantes :

• Étude de faisabilité

• Spécifications détaillées

• Production

• Contrôles

• Essais

• Contrôle de la production

• Vente / Utilisation / Entretien

Pour mieux maîtriser le processus développement on se réfère à des modèles de cycle de vie, permettant de prendre en compte, en plus des aspects techniques, l'organisation et les aspects humains.

Il est important de noter qu'une phase, telle que l’étude de faisabilité, peut elle-même se diviser en plusieurs activités, telles que de la spécification de haut niveau, le maquettage et la validation. De même, certaines activités, telles que la documentation doivent intervenir tout au long du cycle de vie du projet.

2 Le modèle en V

Le principe de ce modèle est que toute décomposition doit être décrite avec sa recomposition, et que toute description d'un composant est accompagnée des tests qui permettront de s'assurer qu'il répond bien aux spécifications.

Ceci rend explicite la préparation des dernières phases (validation-vérification) par les premières (construction du logiciel), et permet ainsi d'éviter un écueil bien connu de la spécification du logiciel : énoncer une propriété qu'il est impossible de vérifier objectivement après la réalisation.

[pic]

Figure 1 Modèle en V

Le modèle en V rend explicite le fait que les premières étapes préparent les dernières faisant intervenir, essentiellement, vérification et validation. Il permet également d'identifier et d'anticiper très tôt les éventuelles évolutions des besoins.

Le modèle en V met l'accent sur l'assurance qualité, processus permettant de vérifier en continu la qualité d’un produit à fur et à mesure de sa création. Il confronte les différents niveaux de test avec les phases du projet de même niveau. Ceci permet à chaque étape de définir non seulement les fonctions, mais également les critères de validation.

Une fois l'ensemble des besoins capturés et les spécifications établies, il arrive que dès la phase d'architecture, voire en phase de conception détaillée ou de codage, des difficultés d'ordre, technique, humain ou de cohérence apparaissent. Ceci représentant le principal risque lié à la mise en place de ce modèle.

L’application de ce model à un projet informatique implique obligatoirement un service de test au sein de l’entreprise dont l’objectif sera de vérifier et de valider les applications.

3 Le service de test au sein d’une entreprise

Le service de test opère une approche dynamique de la vérification, destinée à s'assurer que le logiciel ou service informatique possède effectivement les caractéristiques requises pour son contexte d'utilisation. La première action à entreprendre est donc de décrire avec précision ce contexte, en particulier les fonctionnalités attendues, les contraintes d'environnement ou encore les situations dangereuses à considérer.

Le service de test a pour objectifs :

• De détecter d'éventuels écarts entre le comportement attendu et le comportement observé au cours des tests, ce qui élimine un grand nombre de fautes présentes dans le logiciel.

• D'obtenir la confiance nécessaire avant l'utilisation opérationnelle. Il faut cependant noter que le nombre de fautes détectées ne peut pas être considéré comme un critère de réussite des tests. Le retour d'expérience montre en effet qu'à complexité technique et industrielle constante, un grand nombre d'erreurs détectées par rapport à d’autres projets « de référence » peut seulement être interprété comme l'indicateur d'un logiciel peu fiable et non comme l'atteinte d'un bon taux de détection des fautes.

• De garantir un niveau de qualité tout au long du cycle de vie d’un produit.

On peut donc naturellement se poser la question suivante : quels sont les enjeux de la qualité logicielle ?

4 Les enjeux de la qualité logicielle

Pour bien comprendre la les enjeux de la qualité logicielle il faut définir la notion de qualité ainsi que l’assurance qualité.

1 Définition de la qualité

La notion de qualité recouvre deux aspects:

• Conformité avec la définition les spécifications, cette notion est contrôlable en cours de fabrication,

• Réponse aux attentes de l’utilisateur, cette notion est contrôlable à la livraison du produit.

La validation a pour base les besoins que le produit doit satisfaire, et pour fonction la mise en évidence de défauts.

AFNOR (Association Française de Normalisation) donne une définition très générale de la qualité. D'après la norme FD X 50-751, c’est « l'ensemble des caractéristiques d'une entité qui lui confèrent l'aptitude à satisfaire des besoins exprimés et implicites. L'entité peut être : un produit, un service, un processus, un organisme, une personne. »

On peut conclure par la phrase suivante : La qualité n’est pas une destination mais un voyage.

2 L’assurance qualité

Définissons la notion d’assurance qualité ainsi que les moyens dont elle dispose.

1 Définition

D’après l’AFNOR l’assurance qualité correspond à " La mise en œuvre d'un ensemble approprié de dispositions préétablies et systématiques destinées à donner confiance en l'obtention de la qualité requise."

Il s'agit d'assurer et contrôler la qualité, en mettant en évidence le plus grand nombre de défauts. L'assurance qualité trouve sa justification technique et économique dans l'étude des erreurs. Le plan qualité définit dès la phase de spécifications fonctionnelles les moyens à mettre en œuvre pour la qualification et les métriques utilisées pour l’évaluer.

La découverte tardive des erreurs (statistiques: plus de 50% en moyenne découvertes en phase d'exploitation) pose un problème aigu quand on sait que le coût de réparation croît exponentiellement avec l'avancée dans le cycle de vie.

C'est donc tout au long du cycle de vie que les méthodes de validation/vérification doivent être mises en œuvre bien que la phase de qualification soit la seule phase qui lui soit spécifiquement réservée.

L’assurance qualité présente également un intérêt évident du point de vue de la gestion de projet puisqu’elle permet un meilleur contrôle de l’état d’avancement du projet et une meilleure estimation des coûts.

2 Les moyens de l’assurance qualité :

Il existe deux grandes familles de méthodes pour s'assurer de la qualité d'un produit logiciel: les méthodes dynamiques et les méthodes statiques.

Les méthodes reposant sur l'exécution du programme avec des jeux de données préétablis sont aussi vieilles que le développement de logiciel; elles regroupent les différents tests dynamiques réalisés essentiellement pendant les phases de vérification (tests unitaires et tests d'intégration) et de qualification.

En phase de vérification on vérifie la conformité aux spécifications fonctionnelles.

En phase de qualification, le programme est validé sous différents points de vue:

• validation du programme par rapport aux performances requises

• validation par rapport aux besoins

5 Les critères de qualité

Pour une entreprise de développement informatique concevoir des logiciels de qualité est une priorité. Ceci signifie qu’elle cherche à développer des logiciels qui correspondent aux besoins des utilisateurs.

Il existe des critères de qualité qui permettent de définir différentes formes de qualité. Un développement peut être fait pour satisfaire tout ou partie de l’ensemble de ces critères :

• Exactitude : Aptitude d’un logiciel à fournir des résultats voulus dans les conditions normales d’utilisation. C’est le critère de qualité le plus important. C’est la base du processus de développement: on souhaite développer des logiciels qui répondent aux besoins de l’utilisateur.

• Robustesse : Aptitude à bien réagir lorsque l’on s’écarte des conditions normales d’utilisation.

• Extensibilité/ Adaptabilité : Facilité avec laquelle un programme pourra être adapté pour faire face à une évolution des besoins de l’utilisateur.

• Réutilisabilité : Possibilité d’utiliser certaines parties du logiciel pour développer un autre logiciel répondant à d’autres besoins. Cette fonction est souvent rendue possible grâce à un modèle orienté objet où une classe sera facilement réutilisable d’un projet à l’autre.

• Portabilité : Facilité avec laquelle on peut exploiter un logiciel dans un autre environnement matériel et/ou logiciel. Pour rendre portable une application, on utilise un langage standardisé. On rend indépendant le matériel et le système d’exploitation. Exemple : Windows XP ou Linux.

• Efficience : Temps d’exécution, taille mémoire,…

• Facilité de Maintenance : minimiser l’effort pour localiser et corriger les fautes.

• Ergonomie : minimiser l'effort nécessaire pour l'apprentissage, la mise en œuvre des entrées et l'exploitation des sorties.

• Sécurité : surveiller, recenser, protéger et contrôler les accès au code et aux données ou fichiers.

• Testabilité : faciliter les procédures de test permettant de s'assurer la conformité des fonctionnalités.

Ces critères de qualité sont des lignes directrices qu’un utilisateur va spécifier éventuellement dans l’expression de ses besoins. L’utilisation de méthodes de développement permet de faciliter la satisfaction des critères de qualité.

[pic]

Figure 2 :L’arbre de qualité (ISO)

6 L’externalisation (sous-traitance)

L’externalisation (ou sous-traitance) est couramment utilisée dans le monde industriel pour profiter d’un savoir-faire ou se délester d’une charge de travail onéreuse.

1 Généralité

L’externalisation regroupe une vaste palette de services et de prestations. Tout d'abord l'infogérance, qui consiste à sous-traiter partiellement ou complètement l'exploitation d'un système d'information. Puis le BPO (Business Process Outsourcing), où des fonctions "métiers", par exemple la relation client, la gestion des ressources humaines ou le test d’application, sont confiées à des spécialistes. La TMA enfin (Tierce Maintenance Applicative), qui assure la maintenance des applications présentes dans l'entreprise ou développées par cette dernière. Sans oublier des formes plus hybrides (co-sourcing) où clients et prestataires créent une structure commune pour gérer l'externalisation.

« Offshore », « nearshore », « onshore », ces trois termes désignent d'une certaine manière l'éloignement du prestataire par rapport à son client. Avec l'offshore, les prestataires se trouvent dans des pays très éloignés, tel que l'Inde ou la Chine, alors que dans le cas du « nearshore », ils se trouvent à proximité du client : au Maghreb par exemple pour les entreprises françaises voire, selon certaines définitions, en France (en province par rapport à la région parisienne). L' « onshore » est une pratique qui consiste à faire travailler chez le client du personnel venant des pays offshore aux conditions de ces pays.

Les conditions de l’externalisation sont régies par un contrat, il faut en effet prévoir très précisément les critères d'évaluation de la qualité de la prestation ainsi que les modalités de leur évolution. Il faut aussi prendre garde à la dépendance vis-à-vis du prestataire (perte d'expertise, vol de compétence) et, le cas échéant, à la possibilité de faire marche arrière, tout en étant capable de récupérer (développements, savoir-faire) ce qui a été confié pendant des mois ou des années à un tiers.

2 L’externalisation du test

Ce phénomène s’applique également au domaine du test, et de nombreuses entreprises proposent leurs services pour effectuer les différentes phases de tests vues précédemment. En effet, bon nombre de prestataires de service de test proposent l’allocation d’un certain nombre de testeurs humain pendant un temps donné. Ceci sous-entend plusieurs points à prendre en compte. D’une part, la langue des futurs testeurs, car s’il est vrai que la main d’œuvre asiatique est bon marché, il ne faut pas négliger le temps perdu et les erreurs commises par manque de compréhension du produit à tester. D’autre part, sachant que l’entreprise sous-traitante alloue un certain nombre de testeurs pendant une période préétablie, il faut avoir une gestion de projet solide, car en cas de retard de livraison du produit et donc de retard de la phase de test, il se peut que l ‘on rémunère des personnes à ne rien faire…

On peut également observer que l’externalisation s’avère être une réussite lorsqu’il s’agit d’une mise aux normes d’un pays étranger, car l’expertise du personnel local est souvent plus efficace qu’une étude lointaine du territoire visé.

2 Les différentes formes de test

Les tests doivent être menés à différents niveaux du développement d’un logiciel. En suivant le « cycle en V » de développement du logiciel (fig.1), ils se décomposent en trois types distincts :

1 Les tests unitaires :

Ils ont pour objectif de démontrer que chaque module effectue toute la fonction prévue et seulement cette fonction. On peut distinguer dans ces tests unitaires :

• Les tests de logique : recherche d'erreur, vérification de l'enchaînement correct des branches parcourues.

• Les tests de calcul : vérification des résultats des calculs, des performances, de l'exactitude des algorithmes. Typiquement, les tests de calcul comprennent les tests de données dans la limite des spécifications.

Ces tests sont généralement effectués par les développeurs eux-mêmes (et non par le service de test) directement après la phase de codage.

2 Les tests d’intégration :

Ils ont pour objectif de démontrer le bon fonctionnement d'unités fonctionnelles constituées d'un assemblage de modules. Ils portent principalement sur la vérification des enchaînements entre modules, la circulation des données, les aspects dynamiques, les séquences d'événements prévus et les reprises en cas d'interruption.

Ces tests sont généralement effectués par le service de test. Ainsi ils mettent à l’épreuve les procédures et documents, destinés à l’intégration, rédigés par les développeurs sous forme de plans de tests. Ces derniers sont des documents énumérant étape par étape un cas d’utilisation (ou un cas d’intégration) du produit ou service.

3 Tests de validation

Ils ont pour objectif de s’assurer que le logiciel implanté dans le matériel répond aux spécifications fonctionnelles, en vérifiant plus particulièrement les fonctions générales, les interfaces matériel /logiciel, le fonctionnement temps réel, les performances, l'utilisation et l'allocation des ressources.

Ce type de test constitue l’élément essentiel de l’activité d’un service de test. En effet, ce dernier étant le garant de l’adéquation entre les spécifications et le produit fini, il a la responsabilité de valider (ou non) le passage en production (ou pré-production). De la même manière que pour les tests d’intégration ils se matérialisent sous la forme de plans de tests.

4 Test de régression

A la suite de la modification d'un logiciel (ou d'un de ses composants), un test de régression a pour but de montrer que les autres parties du logiciel n'ont pas été affectées par cette modification. C’est à dire qu’il faut alors vérifier que l'application n'a pas perdu de fonctionnalités lors de l'ajout ou la modification de fonctionnalités.

Cette catégorie de test est de loin la plus fastidieuse, en effet, elle oblige au fur et à mesure qu’un logiciel évolue à repasser l’ensemble des plans de tests précédents. C’est pour cette raison que ces tests sont ceux que l’on souhaite automatiser en premier.

3 Les tests automatiques

L’évolution des technologies en matière de test nous a fait découvrir l’automatisation.

1 Présentation

Comme nous l’avons vu précédemment, les logiciels doivent être testés pour s’assurer qu’ils vont fonctionner convenablement. Le test logiciel a besoin d’être efficace pour trouver les défauts, mais l’efficacité est aussi fonction de la capacité à effectuer les tests rapidement et à un faible coût.

L’automatisation du test peut significativement réduire les efforts nécessaires au test, et significativement augmenter la quantité de tests effectués dans un temps limité. Certains tests peuvent être effectués en quelques minutes alors qu’ils auraient pris plusieurs heures s’ils avaient été exécutés manuellement.

Certaines entreprises qui ont automatisé une partie de leur test n’ont pas directement économisé de l’argent ou de l’effort, en revanche ce processus leur a permis d’accroître la qualité et la vitesse de production.

2 Le test et l’automatisation du test sont différents

Le test est une compétence. Quel que soit le système il y a une quantité astronomique de cas de test et généralement on ne peut pas les effectuer tous. Ce qui sous-entend qu’il faut impérativement choisir les plus judicieux pour déceler un maximum de défaillances. C’est précisément ce travail qui constitue la compétence principale de l’activité du test. L’expérience montre que la sélection aléatoire de cas de test ne permet pas d’obtenir les tests les plus efficaces.

Qu’appel-t-on un bon cas de test ? Il y a quatre critères qui définissent le mieux la qualité d’un cas de test :

• L’efficacité de détection des défauts

• La complétude (exemplarité): permettant de réduire le nombre total de cas de test nécessaires.

• Le faible coût général : il ne concerne pas uniquement le temps passé pour l’exécuter, il s’agit également du temps passé à l’analyser.

• L’évolutivité

Ces critères se contrebalancent les uns avec les autres. Par exemple, un cas de test qui couvre beaucoup d’aspects (complet) va vraisemblablement être coûteux en temps d’exécution. Il va également être coûteux en termes de maintenance lorsqu’il sera amené à évoluer.

Ainsi l’aptitude à tester n’est pas seulement le fait de déterminer des cas de test qui vont mettre en évidence un nombre important de défauts, c’est aussi s’assurer que les cas de test sont bien pensés afin d’éviter les coûts excessifs.

L’automatisation des tests est aussi une compétence, mais très différente de celle que je viens de présenter. Beaucoup d’entreprises sont surprises de s’apercevoir qu’il est plus cher d’automatiser un test plutôt que de le réaliser à la main. Pour pouvoir tirer des bénéfices de l’automatisation, les tests pressentis à l’automatisation doivent être sélectionnés avec attention. La qualité de l’automatisation est indépendante de la qualité du test.

Une fois créé, un test automatique est généralement plus économique car son exécution correspond à une fraction de l’effort qu’il faudrait pour l’exécuter manuellement. En revanche, l’automatisation d’un test coûte généralement plus cher que la création d’un plan de test manuel. Plus l’approche pour automatiser les tests est bonne, plus le coût de création est de maintien est faible.

Si aucune précaution envers la maintenance n’a été prise lors de l’automatisation, la mise à jour d’une suite de tests peut coûter aussi cher, si ce n’est plus, que d’effectuer l’ensemble des tests manuellement.

[pic]

Figure 3 : Comparaison test manuel / Automatique

La figure 3 confronte les quatre critères de qualité d’un cas de test dans un diagramme de Keviat. Un cas de test manuel est représenté par les lignes contenues. Lorsque ce même test est automatisé pour la première fois, il devient moins économique et moins évolutif (ceci résultant de l’effort qu’il a fallut pour l’automatiser). Une fois qu’il a été exécuté à plusieurs reprises il devient alors plus économique que lorsqu’il était effectué manuellement.

4 Le service System Engineering and Testing (SET) de Genesys Conferencing

[pic]

Figure 4 : Organigramme du service SET

SET a pour rôle le test de l’ensemble des systèmes et produits de Genesys, pour en certifier la qualité avant la mise en production.

Le rôle du service n’est pas seulement de tester des applications, c’est aussi de s’assurer que le consommateur est satisfait du service (stabilité et performance), des capacités techniques (le mode de fonctionnement) et du support (rapide et efficace). SET se concentre avant tout sur l’assurance qualité pendant les tests. Ainsi il est le garant du passage en production des produits et services.

SET est aussi chargé de vérifier que les procédures d’installations sont convenables, et que la documentation est appropriée.

Le service est réparti sur plusieurs sites :

• le site de Montpellier : il a en charge le test de

o Genesys Meeting center Audio (GenMC Audio) : service fourni par Genesys permettant la téléconférence audio.

o Backoffice : Système d’information interne à Genesys permettant l’enregistrement des clients, leur suivi, et la facturation des services multimédia.

• le site de Toronto : il est responsable du test de:

o Genesys Meeting center Web (GenMC Web): service fourni par Genesys permettant de faire de la dataconference via le Web (présentations ppt), du partage d’applications et de gérer les téléconférences audio via une interface graphique.

Genesys et particulièrement le service SET se préparent à passer la certificationSOX (loi Sarbane-OXley) pour assurer la transparence et la qualité tout au long des cycles de développement /de deploiement /de support et de facturation. Cette certification repose entre autre sur la présence de documents standardisés en entrée et en sortie de chaque processus (exemple de document : plan de test).

Pour effectuer les tests des différentes applications le service SET conçoit des plans de tests (Test plan) et les exécute. Voici un exemple d’échantillon tiré d’un Test Plan :

Lorsqu’au cours de ces plans de tests, le testeur décèle un défaut, il crée un CR (Change Request*) au travers d’un outil de suivi des défaults (bugs). Grâce à cet outil, le développeur concerné par le module défectueux est averti informatiquement (Email) et il se trouve à même, grâce à la description du CR, de constater le défaut puis de le réparer.

Une fois que l’ensemble des plans de tests est passé avec succès et que tous les CR créés entre temps ont été fixés et vérifiés comme tels, les responsables du service peuvent alors valider la version de l’application pour qu’elle parte en production. On peut ainsi entrevoir toute la responsabilité qui incombe au service SET qui se verra reproché de ne pas avoir découvert les défauts qui surviendront en production.

Voici une présentation globale du processus de validation du service SET avec ses différents documents (entée/sortie) et ses tâches :

[pic]

Figure 5 : Processus de validation de SET

PARTIE II : Le processus d’automatisation des tests

1 Le choix de l’automatisation

L’entreprise doit avant tout trouver son intérêt à automatiser le processus de test car c’est un investissement important (Coût, délais, ressources). Il faut évaluer tous les coûts qui touchent de près ou de loin à sa mise en place. Il peut s’agir de l’achat des outils eux-mêmes, de la formation à dispenser ou encore des connaissances à acquérir. Rien ne doit être oublié où laissé au hasard.

1 Définition des besoins

Les outils de tests sont nombreux et ne correspondent pas à tous les besoins, c’est pourquoi il est important de mettre en évidence les critères qui vont permettre la sélection des outils à utiliser. Toutes les phases du processus de test ne sont pas toujours automatisables.

La candidate évidente à l’automatisation est sans conteste la phase de non-régression. Un même scénario de test pourra être répété autant de fois que nécessaire par les outils automatiques et assurer la non-régression d’une version à l’autre de l’application. Les autres phases moins prioritaires, peuvent également s’y prêter, à partir du moment où elles remplissent un critère commun : La reproductibilité des tests.

Les outils de test fonctionnel ne constituent qu’un type d’outils parmi tous ceux disponibles sur le marché. Ils permettent certes d’optimiser l’effort de test, mais ne doivent surtout pas être considérés comme la méthode unique à adopter pour automatiser ses tests. Ils ont en effet des limitations, même lorsque l’on applique les meilleures pratiques. En effet, ce type d’outil se focalise principalement sur les tests effectués via les interfaces graphiques (Tests en boîte noire).

Les tests aléatoires peuvent également être automatisés. L’outil génère alors des flots de données de manière totalement imprévisible afin de tester la stabilité ou les réactions du système. Les tests de volume ou de charge permettent d’exécuter des actions massives ou simultanées pour simuler une utilisation lourde.

Le choix de l’outil doit spécifier les critères qui permettent d’en faire un investissement à long terme. Il faut prendre en considération que dans certains cas, l’automatisation peut avoir des conséquences néfastes sur la structure utilisatrice et sur le déroulement du projet (Délais dépassés, investissements importants). De même, il est important de dresser la liste des types de test que l’entreprise souhaite automatiser et leur donner une priorité.

2 Evaluation des coûts et délais

L’évaluation de l’investissement dédié à l’automatisation est une tâche capitale pour obtenir une bonne gestion de projet. Le retour sur investissement de la mise en place d’un processus d’automatisation ne peut être évalué qu’après plusieurs cycles de tests (plusieurs versions de l’application cible sont testées). L’utilisation d’un outil de test doit être envisagée sur une période suffisamment longue pour permettre ce retour sur investissement. Il ne s’agit pas d’une opération instantanée, mais d’un investissement à long terme.

Il apparaît dans un premier temps que la mise en place de telles solutions, à cour terme, s’avère plus coûteuse que le recrutement de testeurs. Cependant, cette vision change au fur est à mesure que de nouvelles versions ou de nouveaux produits émergent, car l’entreprise n’arrive plus, par manque de temps et de ressources, à effectuer les cycles de test complets. Ainsi les coûts à long terme deviennent rapidement exponentiels. Ces outils sont donc avantageux sur plusieurs cycles. Il est pour cela nécessaire, lors de la réalisation du budget, de fixer des objectifs à moyen voir long terme en chiffrant avec un maximum de précision la partie des tests qui va être automatisée.

2 La démarche de l’automatisation

L’automatisation du test est une réelle démarche comportant différentes étapes. C’est dans cette optique que la communauté du test a élaboré une démarche de test automatisé, indépendante des méthodologies de conception informatique  appelée ATLM (Automated Testing Life-cycle Methodology). Cette méthodologie se propose de structurer et d'ordonner votre démarche d'automatisation. De l'étude d'opportunité à l'exécution des campagnes de tests, elle éclaire et balise chaque étape du processus.

[pic]

Figure 6 : Démarche ATLM

1 Construction du test

Dans l’absolu, l’effort de test (validation, intégration et unitaire) d’un logiciel peut être aussi important que l’on souhaite. La confrontation des données d’entrée, des modes d’utilisation, des modes de fonctionnement, des paramètres d’exploitation, la variété des aspects vérifiables (conformités aux spécifications, aux manuels d’utilisation et d’exploitation, aux exigences de robustesse, de performance, d’ergonomie, comportement nominal, en cas de défaillance, etc.) sont telles qu’une infinité de tests peut être menée sans qu’on soit certain de la conformité totale aux exigences.

En pratique, l’effort de test doit donc être adapté aux enjeux. Il est nécessaire de se fixer des objectifs préalablement à toute définition d’une stratégie, de méthodes et techniques (automatisation), etc., et finalement des tests eux-mêmes.

Définir ces objectifs permet de réaliser les tests avec un maximum d'efficacité en garantissant la couverture des objectifs définis, donc de focaliser les efforts sur les aspects essentiels. Les objectifs de chaque phase de tests seront identifiés et définis en considérant :

• Les exigences fonctionnelles et de performance (en tenant compte aussi des contraintes particulières de l’environnement final d’utilisation du logiciel), exprimées dans les documents de spécification / conception du produit logiciel.

• Les exigences en matière de qualité et de sûreté de fonctionnement (rectitude, robustesse, facilité de maintenance, disponibilité, sécurité, etc., cf. critères de qualité).

• Toutes les contraintes d’environnement identifiées (utilisation d'une base de données, utilisation des nombres réels, langage de programmation, logiciel temps réel, etc.).

• Les exigences légales et réglementaires.

• Les contraintes de coût et de temps de test.

Il en résulte la définition des types de tests à réaliser (chemins structurels, chemins fonctionnels, données d'entrées/sorties aux limites, hors limites, de robustesse, de performance, etc.) et la justification de ces choix.

Quel que soit le niveau d’exigence, les tests doivent être conçus et réalisés sur la base d’une stratégie. Elle constitue un préalable nécessaire à l’élaboration des tests et à la conception des jeux d’essai. La stratégie de test témoigne d'une réflexion sur les tests. Son absence indique un risque d’improvisation dans l’élaboration des tests. La stratégie doit définir comment, globalement, les tests vont être menés pour satisfaire aux objectifs préalablement définis, en relation avec les environnements que le concepteur compte mettre en œuvre. Elle doit organiser les tests en une structure lisible d’étapes, ayant des objectifs clairs ou répondant à des contraintes d’environnement précises (par exemple, relatives à la disponibilité d’un outil). On définit donc les méthodes et les moyens de tests pour y parvenir, puis l'enchaînement - ou planification - des tâches de réalisation des tests. L'ensemble des moyens de tests et de la planification constitue la stratégie de test mise en œuvre.

La définition des tests aboutit à la réalisation des plans de test. L'exécution des plans de test doit se conformer aux procédures et aux conditions définies (activités de préparation, de déroulement des tests, d'enregistrement des anomalies). Tout non-respect de celles-ci doit être argumenté, ce qui permettra, lors de la vérification des tests, de justifier ces divergences.

2 L’automatisation du test

L’automatisation d’un test est une véritable démarche divisée en plusieurs activités distinctes, s’appuyant la plupart du temps sur des plans de tests manuels préalablement élaborés. Généralement ces activités sont reparties de la manière suivante :

[pic]

Figure 7 : La démarche de test automatique

Les deux premières activités sont effectuées lors de la conception des tests manuels, elles ont été déjà largement abordées dans le chapitre précédent. Nous détaillerons donc les trois dernières activités à savoir : l’implémentation, l’exécution et l’analyse.

1 L’implémentation

L’implémentation des cas de test et plus particulièrement des plans de test passe par l’élaboration de scripts de tests (suivant les outils), de scenarii (pour les automates), de jeux d’essai et par la collecte des résultats attendus.

Un script de test se matérialise typiquement par un fichier se composant d’une série d’instructions dans un langage formel, qui va être interprété par un outil de test automatisé. Un même script de test peut représenter une partie ou la totalité d’un plan de test. Les valeurs d’entrées d’un plan de test sont généralement parties intégrantes du script au même titre que les résultats attendus, cependant, il peut arriver que ces valeurs soient contenues dans un fichier séparé.

Les pré-conditions d’un test plan doivent également faire partie du script de telle manière que le test soit exécuté dans de bonnes conditions. Par exemple, si un test nécessite la présence d’un fichier particulier ou de données contenues dans une base de données, il faudra s’assurer que ces derniers sont correctement initialisés pour contenir les informations dont le test a besoin.

Certains tests nécessitent parfois des configurations matérielles ou logicielles spéciales, par exemple une connexion au réseau ou à une imprimante. Ceci fait également partie de l’environnement de test qu’il faudra mettre en place avant que le test automatique soit exécuté.

Les résultats attendus peuvent être organisés dans un fichier qui sera en suite utilisé par l’outil de test automatique. Cependant, la détermination des résultats attendus s’avère être une tache relativement plus complexe que pour les tests manuels. En effet, elle nécessite une finesse dans la description bien plus grande que pour le test manuel, puisqu’un automate ne possède pas l’intelligence du testeur et donc il faut déterminer avec précision les valeurs à vérifier sans en oublier, car il n’y aura pas d’initiative de la part de l’automate pour trouver une erreur qui n’était pas préalablement spécifiée. Il faudra donc observer la plus grande rigueur lors de cette étape.

2 Exécution du test

L’application ou le service informatique sont exécutés par l’intermédiaire de l’outil de test. C’est donc lui qui va assigner les valeurs d’entrée et récupérer les valeurs de sortie, qu’il va mémoriser pour l’étape suivante c’est à dire la comparaison des résultats. Il doit également connaître la marche à suivre en cas d’anomalie rencontrée. En effet, il peut soit stopper immédiatement après avoir rencontré une anomalie, ou bien poursuivre le test. Tout dépend des répercutions d’une anomalie sur le reste du test. Par exemple si le programme n’arrive pas à se connecter à la base de données il est strictement inutile de poursuivre puisque aucune information ne pourra être visualisée.

3 L’Analyse

L'analyse des comptes rendus (rapports) de tests doit être menée de façon systématique et critique, notamment pour la qualification des anomalies. En effet, on peut avoir de fausses anomalies. Après l'exécution d'un scénario, l'équipe de test compare le résultat constaté au résultat attendu. Une procédure en échec ne correspond pas forcément à une erreur dans l'application, il peut notamment s'agir :

• Des modifications dans l'application (sans modification des procédures)

• D’une erreur dans la configuration de l'environnement

• D’une erreur dans la procédure de test

• D’une erreur de logique du scénario (script)

C’est toute la différence qu’il y a entre comparer et vérifier, l’outil peut comparer mais rarement vérifier, ce qui reste une tâche généralement humaine (parce qu’elle nécessite plus d’intelligence).

De la même manière, une exécution sans erreur ne garantit pas totalement contre des incidents après la mise en production. Le problème peut provenir d'un manque de sensibilité de l'outil de test, ou d'une procédure de test pas assez descriptive. C'est pourquoi il est important de mener des revues sur les procédures avant de démarrer l’élaboration de scénarii. Dans cet esprit, un faible taux de non-conformités détectées doit faire s'interroger sur la couverture et la pertinence des procédures.

La détection d'un grand nombre d'erreurs indique que les équipes de développement ont été négligentes dans la conduite des modifications. Lorsqu'un grand nombre d'erreurs est détecté sur une fonctionnalité particulière de l'application, l'équipe de test peut être amenée à augmenter le nombre de procédures de tests qui la couvrent. L’efficacité des campagnes de non-régression dépendent du nombre d’itérations et de la qualité des corrections.

L'analyse des résultats peut confirmer la capacité des procédures de tests à trouver les erreurs. Cette analyse peut également mettre en évidence des problèmes récurrents sur des modules et peut déboucher sur une modification de l'effort de test et une remise en cause du développement de certaines fonctionnalités.

Les tests de non-régression sont terminés quand les critères d'acceptation sont atteints. Une différence entre résultat attendu et résultat actuel, qui ne provient pas de fausses anomalies, donne lieu à la création d’une non-conformité (Change Request).

Pour réaliser ces tests automatiques, il est envisageable d’investir dans un outil de test du marché.

3 Les outils de test

Voici un panorama d’outils de test subdivisé en trois catégories :

• La première concerne les tests sur le code source à proprement parler, que le langage soit du Java, du C, du C++, du Fortran ou tout autre langage actuellement disponible. L'objectif est bien entendu de détecter, de la manière la plus automatisée qui soit, les anomalies du code et de les corriger.

• La deuxième catégorie de solutions concerne les tests fonctionnels. Ces derniers reposent sur l'analyse des spécifications de tout ou partie du logiciel, sans tenir compte de sa programmation intrinsèque. La solution est testée de telle sorte qu'une entrée ("input") dans telle ou telle de ses sections doit renvoyer une réponse conforme au cahier des charges. Cette phase concerne aussi bien les interfaces utilisateurs, les API, la gestion des bases de données, la sécurité, que le réseau. Les tests fonctionnels font partie intégrante de ce que l'on appelle plus globalement les tests "Boîte Noire".

• La troisième et dernière catégorie de solutions est celle relative à la performance des logiciels développés (test de charge), que ces derniers soient des applications Web, intranet ou des Web services.

s

|Tests de code source |

|Editeur |Solutions |Caractéristiques |

|Bullseye Testing Tech. |BullseyeCoverage |Pour C++ et C. Compatibilité étendue avec les mondes Windows, Unix |

| | |et embarqué. |

|IBM |Rational Purify |Proposé en version Windows et Linux/Unix, pour le langage C/C++ |

| | |(détection de corruption en mémoire) et Java, C/C++, Visual C++, C# |

| | |et (détection des fuites mémoire). |

|IPL |Cantata++ |Permet de tester ANSI C, ISO C++ et EC++, en tests unitaires et |

| | |d’intégration, sur systèmes hôtes ou systèmes embarqués. Compatible |

| | |Windows NT, 2000, XP, Solaris (2.x), HP-UX et Linux. |

|Man Machine Systems |JCover, JStyle, JVerify |Société indienne spécialisée dans les outils pour Java. |

|Parasoft |C++Test, .TEST, JTest, |C++Test est un produit de prévention automatique des erreurs pour C |

| |Insure++ 7.0 |et C++ tandis que .TEST s'applique à l'environnement .Net de |

| | |Microsoft et que JTest concerne Java. Insure++ est un outil |

| | |automatique de détection des problèmes de mémoire pour C/C++. |

|Precilog |QuickAnt Test Pro, |Permettent d'automatiser les processus de test en Java. La version |

| |QuickAnt, PreciCode |QuickAnt est allégée par rapport au produit QuickAnt Test Pro. Pour |

| | |C, C++ et C#, la solution PreciCode est adaptée. Compatibilité |

| | |Windows NT, 2000, XP et Linux (sauf Precilog). |

|Programming Research |QA·C, QA·C++, QA·J, |Les solutions permettent de détecter les erreurs de code dans, |

| |QA·FORTRAN |respectivement, les langages C, C++, Java et Fortran. Compatibilité |

| | |plates-formes Windows, Sun, HP, Redhat Linux et Slackware Linux. |

|Testwell |CTA++, CTC++, CMT++, |Société finlandaise. Propose une gamme complète d'outils de test |

| |CMTJava |pour les langages C, C++ et Java, au niveau des classes, librairies |

| | |et sous-systèmes. L'outil CTA++ s'intègre à Visual Studio. |

| | | |

|Tests fonctionnels |

|Editeur |Solution |Caractéristiques |

|AutoTester |AutoTester ONE |Offre des tests fonctionnels, de régression et d'intégration pour |

| | |environnements Windows, applications client / server ou Web. |

| | |Compatible Windows 3.x, 95/98, NT, 2000, XP. |

|Compuware |QACenter Enterprise Edition|Supporte les environnements client / serveur, L4G, Java et Web. |

|IBM |Rational Robot |Automatisation de tests de régression, de tests fonctionnels et de |

| | |tests de configuration pour applications e-commerce, client/serveur |

| | |et ERP. |

|iRise |iRise Application Simulator|Plate-forme permettant la définition, les tests et la validation des|

| | |fonctionnalités de solutions Web avant tout développement. |

|Mercury Interactive |Mercury Business Process |Permet aux spécialistes métier et aux équipes assurance qualité de |

| |Testing |valider les processus métier automatisés. |

|Radview |TestView, WebFT |Solution permettant de définir des plans de test automatisés |

| | |d'applications Web tout en centralisant les scripts de ces tests. |

|Seapine |Seapine SQA |Suite logicielle composée de 3 outils permettant d'automatiser les |

| | |tests fonctionnels, de gérer les défauts et les changements de |

| | |configurations. |

|Segue |SilkTest |Tests fonctionnels et de régression automatisés. Support des |

| | |applications Web, Java, client/server d'entreprise. |

|Softbees |Visual WebTester |Outil de tests automatisés : tests fonctionnels, de régression et de|

| | |facilité d'utilisation pour applications Web. |

|Software Research |eValid |Vérifie la conformité aux spécifications fonctionnelles des sites |

| | |Web. Multiples modes de synchronisation possibles. HTTP / HTTPS, |

| | |Javascript, XML, Applets Java , Flash, ASP, JSP, ActiveX supportés. |

|TestSmith |Quality Forge |Automatisation de tests fonctionnels et de régression pour Windows. |

| | |Les tests concernent les sites et des applications Web. Les langages|

| | |supportés sont Java et C++. |

|Worksoft |Certify |Plate-forme permettant l'automatisation de tests fonctionnels pour |

| | |applications Web, client/server et mainframe |

| | | |

|Tests de performance |

|Editeur |Solution |Caractéristiques |

|Embarcadero |Extreme Test |Mesure et analyse les performances des applications Web d'entreprise|

| | |sur une multitude de plates-formes. |

|Empirix |Gamme e-Test |Gamme pour tests d'applications Web, de Web services ou |

| | |d'applications .Net. |

|Facilita |Gamme Forecast |Les tests permettent d'enregistrer les interactions utilisateurs et |

| | |de générer des scripts immédiatement. Windows 2000, XP, NT, Linux |

| | |Red Hat, Novell/Suse, Debian, AIX 5+ supportés. |

|Open Source |JMeter |Outil de test de performance pour ressources statiques ou dynamiques|

|(Apache) | |(fichiers, CGI, Servlets, scripts Perl). Peut simuler de lourdes |

| | |montées en charge sur une application serveur ou sur un réseau. Codé|

| | |100% en Java, interface graphique en Swing. |

|Open Source |Siege |Outil HTTP de test de performance et de régression. Supporte |

|(Jeffrey Fulmer) | |l'authentification basique, les cookies, les protocoles HTTP et |

| | |HTTPS. |

|SoftLogica |WAPT |Outil de test de charge pour applications Web et intranet. |

| | |Nombreuses fonctionnalités proposées. |

|Technovations |WebSizr |Tests de performance pour applications et serveurs Web. Une suite |

| | |complète de produits vient compléter cette solution. Elle est |

| | |disponible sous forme de modules distincts. |

| | | |

Pour éviter que l’automatisation des tests ne s’avère un exercice coûteux, il est essentiel de bien comprendre les besoins auxquels on désire répondre. Il faut aussi comprendre la technologie utilisée par les outils, leur fonctionnement et leurs contraintes. Chaque outil a ses propres limitations : ainsi, certains seront spécialisés pour les pages Web, d’autres pour le multimédia et d’autres pour les bases de données.

La majorité de ces outils sont onéreux. Il en existe des gratuits, mais ceux-ci sont rares et le soutien technique parfois inexistant. Un aspect non négligeable avec l’automatisation est le temps d’apprentissage. En effet, un outil de test demeure un logiciel et il faut prendre le temps d’apprendre à le connaître et à le maîtriser.

4 Les développements spécifiques.

Dans le secteur de l’informatique industrielle, certaines applications pilotent des équipements (robots, chaînes de montage, ponts téléphoniques). Ces applications sont elles aussi soumises au test. De la même manière que pour les applications avec interface graphique elles doivent être testées. Il faut donc mettre en place un système ou automate de test.

1 Les conditions du développement spécifique

• Incompatibilité du système d'exploitation. S'il a été déterminé qu'aucun outil du marché n'est compatible avec les OS utilisés, on optera forcément pour un développement.

• Incompatibilité de l'application. L'application à tester peut contenir un élément, ou plusieurs, qui posent un problème de compatibilité avec l'outil. Il n'est pas toujours possible de tester la compatibilité avec tous les composants du système, il faut s'interroger sur l'opportunité d'utiliser un automate, avec le risque potentiel de non-fonctionnement sur des parties de l'application. Une solution mixte, automatique et manuelle, dont les proportions ne sont pas mesurables, doivent conduire à privilégier une approche 100% manuelle.

• Besoins de tests spécifiques. Dans bon nombre de cas, certains besoins spécifiques ne sont pas couverts par les outils standards, obligeant à développer des modules en interne. C'est en tenant compte du volume agrégé de l'ensemble de ces développements que l'on doit s'interroger sur la pertinence de réaliser son propre outil.

Si la décision s'oriente vers un développement spécifique, il faudra :

• Déterminer les ressources, budgets et plannings requis pour l'élaboration d'un outil de test

• Obtenir l'accord de la direction pour ces décisions.

• Englober le développement de l'outil dans l'effort de développement global.

• Gérer le code source de l'outil avec des numéros de version pour contrôle, comme le reste du système.

• Les meilleures méthodes de développement doivent être utilisées afin que l'outil créé soit fiable, facile à maintenir et évolutif.

• Il faut vérifier que l'outil soit bien en accord avec les pré-requis.

2 L’évaluation du budget

Cette tâche est primordiale dans la conduite du projet d’automatisation. En effet, elle permet de délimiter le seuil de rentabilité de l’investissement représenté par l’automatisation. L’investissement moyen dans un outil de test avoisine les 30 000€ (deux licences WinRunner). Ce prix permet d’avoir un point de départ pour évaluer le budget d’un développement spécifique.

Comme toutes les applications informatiques les outils de test automatique ont un cycle de vie. Ce dernier dispose d’une phase de maintenance. En effet, on peut imaginer que certaines anomalies pourront être trouvées ou que l’on souhaite lui apporter quelques révisions. Le coût de cette maintenance ne doit pas être négligé. 

Enfin, de la même manière que pour les outils de test grand public, les développements spécifiques nécessitent des formations utilisateurs pour transmettre le savoir-faire indispensable aux testeurs. Il ne faudra pas négliger les coûts de formation non plus.

3 Mise en place de l’architecture

La première étape dans le cadre de l’automatisation des tests d’applications industrielles est de rechercher les outils matériels qui vont permettre d’étudier l’état de l’équipement qui est piloté. Ainsi il faudra se munir de systèmes capables d’observer les résultats des équipements testés. Pour tester des ponts téléphoniques, il faudra impérativement trouver un équipement capable d’effectuer des appels téléphoniques (pour simuler des utilisateurs audio) ainsi que d’interpréter les messages joués par le pont.

Une fois que l’équipement de test est judicieusement sélectionné, il est nécessaire de l’intégrer dans une architecture de test qui respectera les différentes étapes de la démarche de test automatique : création de script ou scenarii de test, exécution et rapport de test.

4 Développement de l’applicatif

Pour être à même de créer des scénarii de test il est donc nécessaire de développer une application à cet effet. Pour ce faire, une étude approfondie des tests manuels déjà en vigueur est indispensable. Cette étude permettra de mettre en évidence les actions élémentaires permettant de composer des scénarii. Il est également nécessaire de répertorier l’ensemble des résultats possibles a l’issu des tests pour être à même par la suite à faire les comparaisons avec les résultats obtenus.

Dans un second temps, on développera une application capable d’exécuter ces scénarii. Cette exécution pourra être programmée pour être effectuée à dans des tranches horaires judicieusement choisies.

Une fois les tests exécutés, les résultats devront être exposés dans un rapport permettant l’analyse rapide en vue d’une reproduction manuelle pour comprendre l’origine des erreurs. Par ailleurs, pour accroitre la qualité et la pertinence des tests, il est important de mettre en place un système d’archivage des rapports afin de garder une trace des tests réalisés.

Pour l’ensemble de ces développements il est possible d’atteindre différents degrés d’ergonomie, tout dépend de l’investissement (temps, ressources) qui leur est dédié. Il est évident que plus les outils sont ergonomiques plus les tests automatiques seront efficaces.

Enfin, comme tous les produits issus d’un processus de développement informatique, ces applications devront également être soumises à des tests de validation, pour s’assurer que les échecs relevés lors des tests automatiques ne soient pas dus à des anomalies de l’outil de test lui-même.

5 Cas Pratique : A2T2, ma réalisation au sein de Genesys

Pour illustrer la théorie présentée jusqu’ici je vais m’appuyer sur les travaux que j’ai réalisés au sein de Genesys Conferencing à travers le projet A2T2 (Audio Automated Test Tool) mené dans le cadre de mes deux derniers stages.

1 Présentation

Dans le cadre de l’automatisation des tests du service de téléconférence audio, Genesys a besoin d’un outil capable de simuler les utilisateurs audio du service de téléconférence. Le projet A2T2 a donc été initié avec pour objectif : proposer un outil capable d’effectuer des tests automatiques de la plateforme de téléconférence de Genesys TLM (TeLeMeeting).

Il est important de noter que l’outil automatique ne fait que simuler la présence d’utilisateurs et leurs actions. En aucun cas nous ne simulerons l’application de téléconférence elle-même.

La cible de notre automate est donc un pont téléphonique bien réel, connecté au serveur de téléconférence (l’intelligence du pont) lui aussi bien réél.

1 Le principe de la téléconférence à Genesys

Pour bien comprendre A2T2, il est indispensable de cerner le fonctionnent de la téléconférence à Genesys. La téléconférence est basée sur le principe de la mise en relation téléphonique de plusieurs participants par le mixage de leurs voies. Cette mise en relation se fait par l’intermédiaire de ponts téléphoniques. Ces derniers sont pilotés par une application serveur : TLM (TeLeMeeting), développée par Genesys et qui constitue l’ « intelligence » du pont. En effet le pont ne possède pas d’intelligence propre, il ne fait que recevoir les ordres du serveur TLM pour mixer les voies entre elles, déconnecter une ligne, la mettre sous silence, etc. C’est donc TLM qui assure la gestion de l’interconnexion entre les participants ainsi que la diffusion des messages d’annonces (message de bienvenue, invite de code confidentiel, etc.).

Une téléconférence se subdivise en plusieurs salles : la salle principale (Main Room), la salle de sous-conférence (Breakout Room), la salle d’attente (Waiting Room) et la salle d’accueil (Greeting Room).

Il existe deux types de participants : l’animateur (Chair Person) et le participant. Une téléconférence n’a qu’un animateur à la fois et ce dernier dispose d’une liste de commandes lui permettant de gérer l’intégralité de la conférence, il pourra par exemple donner la parole à un participant en particulier, exclure un participant, etc.

De son coté, le participant dispose aussi d’une liste réduite de commandes lui permettant entre autre de se rendre muet. Chacune de ces commandes (environ une trentaine de commandes au total) est matérialisée par une suite de touches du clavier téléphonique. En effet, chaque touche du téléphone correspond à une tonalité (DTMF : Dual Tone Multiple Frequency) et de ce fait le pont téléphonique est capable d’indiquer au TLM quelle commande a été joué. Ainsi le TLM peut indiquer au pont le comportement à adopter.

.

[pic]

Figure 8 : Exemple de fonctionnement d’une téléconférence

Dans cet exemple, l’animateur appelle son numéro de téléconférence, il arrive alors en salle d’attente (waiting room), un message lui demande de taper son code secret ou pin code. Une fois son pin code tapé, il passe alors dans la salle principale. Ensuite, les autres participants peuvent à leur tour appeler la conférence et se trouver en salle d’attente. Si la porte de la salle principale est ouverte ils rentrent directement en salle principale (la gestion de la porte est réservée à l’animateur).

A partir de cet instant les participants s’entendent. L’animateur peut inviter un participant ; pour ce faire, il se déplace dans la salle d’accueil grâce à la commande « *0* » qu’il tape sur le clavier de son téléphone, puis il compose le numéro de téléphone encadré d’étoiles du participant qu’il souhaite inviter. Ce dernier se trouve alors en salle d’accueil à son tour, puis ils repassent ensemble dans la salle principale grâce à la commande *0*.

2 L’architecture d’A2T2

A2T2 se subdivise en trois modules : A2T2Builer, A2T2Player et A2T2Serveur.

[pic]

Figure 9 : Architecture A2T2

3 Intel Dialogic D/240PCI-E1 et ADL

La carte Dialogic D/240PCI-E1 qui a été mise à ma disposition permet d’émuler jusqu'à 30 lignes (trunks) téléphoniques. Cette carte se branche sur une ligne de type E1 (version européenne de la T1), elle est ensuite reliée au PABX (Private Automatic Branch Exchanger) de l’entreprise, ce dernier permet d’affecter des numéros internes à chaque ligne de la carte. Ainsi, en appelant le 5130 depuis n’importe quel téléphone de l’entreprise on appelle la première ligne (trunk) de la carte. Puis, pour le 5131 : la seconde, etc. De plus, cette carte permet de jouer des DTMF ainsi que de les reconnaître lorsqu’on les joue sur une de ces lignes. A titre d’exemple, cette carte est fréquemment utilisée pour créer des serveurs vocaux.

La carte Dialogic est livrée avec un environnement de développement : ADL Studio. Ce dernier permet d’écrire des programmes en ADL, de les précompiler, et de les débuguer. En effet, le langage ADL s’exécute dans une machine virtuelle (run-time), à la manière de java. Le langage ADL met à disposition du développeur des primitives permettant de manipuler l’ensemble des fonctionnalités de la carte.

Voici quelques exemples de primitives proposées par ADL :

TrunkMakeCall( TrunkId , number ) : Cette fonction permet d’effectuer un appel sur le numéro passé en paramètre depuis la ligne TrunkId.

TrunkUse( TrunkId ) : cette fonction permet d’affecter à la ligne courante (Current Trunk) la ligne numéro TrunkId.

TrunkDisconnect() : cette fonction permet de raccrocher la ligne courante

4 Le protocole DTMF

Lors du passage d’un Test Plan, les testeurs sont capables d’entendre les messages provenant du pont. Cette faculté n’est pas évidente quand on remplace l’homme par une carte. Certes la carte dialogique, grâce à certains modules (RLL), est capable de faire de la reconnaissance vocale, mais ce dispositif paraît complexe à mettre en œuvre et pas toujours efficace.

Pour palier à ce manque, nous avons décidé de concevoir un protocole de communication entre le pont et la carte Dialogic à base de DTMF. En effet, comme nous l’avons vu précédemment, la carte Dialogic est capable nativement de percevoir une série de DTMF émis sur une des ces lignes.

Nous avons donc codé sur cinq DTMFs chaque message envoyé par le pont. Ce dernier dispose de cartes messages qui stockent les messages vocaux. Les messages vocaux sont organisés par langues (Anglais, Français, etc.). Nous avons donc créé une langue spécifique au test : DTMF_TEST. Comme les DTMF sont des tonalités, le pont n’a aucun mal à les stocker puisqu’il ne fait pas la différence entre la voix humaine et les tonalités du téléphone.

Les messages sont codés de la manière suivante : 3 DTMFs correspondant à un identifiant encadré du DTMF « # ».  Voici quelques exemples :

Message de bienvenue (Welc_Service) : #400#

Invite de Pin Code (Chair_Pin)  : #403#

Message d’entée en conference (Conf_Enter) : #412#

Etc. (une liste exhaustive est donnée en annexe).

Grâce à ce protocole, les fonctions peuvent récupérer les messages envoyés par le pont et les retourner au plug-in, ce qui était une fonctionnalité primordiale des commandes. Ainsi les commandes composant les scénarii retourneront les messages reçus par le pont en les séparant par « : ».

Exemple :

Welc_Service : Chair_Pin

5 Mécanisme de gestion des erreurs

Le langage ADL ne maîtrise pas le mécanisme des exceptions, nous avons donc mis en place un système d’erreurs, afin de contrôler le déroulement du scénario. De plus, sachant que nous travaillons dans une architecture à plusieurs niveaux, il est indispensable en cas d’erreur de remonter la pile de messages (à la manière des exceptions java).

Nous avons donc établi un code pour les erreurs. Toute fonction dont la sortie est en erreur, retournera 0: suivi du message d’erreur terminé par un retour chariot. Puis chaque appel de fonction dans le code sera encapsulé dans un if. De cette manière en cas d’erreur, on pourra récupérer la pile des erreurs et déceler plus facilement d’où elles proviennent.

6 A2T2 Server

A2T2 Server est un service écrit en ADL dont l’objectif est d’exécuter une à une les commandes du scénario en pilotant la carte dialogique. Ce processus doit être constamment lancé pour répondre à toutes les attentes. Il ne supporte qu’une connexion à la fois et refusera toute autre connexion pendant l’exécution d’un scénario. Cette application se charge également de transmettre le résultat de chaque command au Player. Il est muni d’un système de trace permettant de repérer les anomalies survenues lors de l’exécution d’une commande.

Voici la forme graphique du service (application console) :

[pic]

A2T2Server dispose également de fichiers de paramétrage permettant l’encodage et le décodage des messages du pont (cf. 4.5).

7 A2T2Player

A2T2Player est une application permettant d’exécuter les scénarii (fichier .a2t2). Ce programme se charge de :

• Lire le scénario

• Mettre à jour la base de données des téléconférences (TDB).

• Exécuter les commandes une à une.

• Générer le rapport de test

Lors de la lecture du fichier scénario A2T2Player charge en mémoire le modèle (l’arbre) de la téléconférence. Une fois le modèle chargé, il va se connecter à la base de données du serveur de téléconférence. Si cette connexion s’effectue sans anomalies, il va pourvoir supprimer de la base le numéro de la salle de téléconférence qui va servir pour notre test puis la recréer avec les paramètres fournis en entête du scénario.

Une fois la salle de test créée dans la base, le scénario peut être joué en envoyant les commandes du scenario une a une au serveur (A2T2Serveur) qui va ensuite lui transmettre le résultat de chaque commande. Lorsque ce dernier est un succès le scénario continue, en revanche dans le cas d’un échec le Player incrémente un compteur d’erreurs successives, et dès que le ce dernier arrive au seuil prédéfini (fichier .ini) le scénario s’arrête. Ce mécanisme a été mis en place pour éviter que le Player ne déroule l’ensemble du scénario alors qu’une erreur critique est survenue au départ du test.

Parallèlement à la lecture du scénario, le Player alimente un fichier de logs ainsi qu’un fichier de rapport. Ce dernier ayant pour objectif, une fois le test terminé, d’obtenir un rapport détaillé de l’exécution du scénario et ainsi faciliter l’analyse des anomalies. Nous verrons par la suite dans le détail le format de ces rapports.

Voici un aperçu d’A2T2player lors de l’exécution du scénario.

[pic]

Phase d’initialisation : Lecture du scénario, mise à jour BDD (TDB)

Phase d’exécution : Envoi des commandes une a une, réception du résultat (1 : succès, 0 : échec + message d’erreur).

Ce programme est une application console, ce qui permet de la lancer grâce à une tâche planifiée (pendant la nuit par exemple).

8 A2T2Builder

A2T2Builder est une application graphique permettant la construction manuelle des scenarii de test. Cette application permet de :

• Mettre à jour la base de données du serveur des téléconférences (TDB)

• Créer, modifier un scénario à partir des commandes proposées

• Exécuter un scénario

[pic]

Pour gérer l’ensemble de ces données, A2T2Builder s’appuie sur un modèle arborescent. Ce dernier se compose des éléments suivant :

• MoConference : Objet dédié à la conférence et à ses paramètres

• MoScenario : Objet dédié au scénario, conteur de participants

• MoParticipant : Objet dédié aux informations du participant

• MoCommand : Objet désignant la commande avec ces paramètres

Voici un exemple de modèle :

[pic]

Figure 10 : Instance du modèle A2T2

On peut observer que les commandes sont numérotées pour assurer leur l’ordonnancement. On peut ainsi obtenir la liste des commandes et la liste des participants. Chaque participant correspond donc à une ligne sur le panneau scénario et chaque commande à une boite noire (cf. A2T2Builder)

Voici une partie du modèle que nous avons utilisé pour matérialiser cet arbre :

[pic]

Figure 11 : Diagramme de classe

Tous les éléments du modèle sont des nœuds (MoNode), une conférence peut être liée à plusieurs scénarii, en revanche un scenario n’est rattaché qu’à une conférence. Nous avons mis en place la même relation entre scenario et participant ainsi que le couple participant et commande. Une commande dérivera de la classe MoCommandBase, à laquelle s’ajouteront les différents paramètres propres à chaque commande.

9 Le module de rapport de test

Tout au long de l’exécution du scénario, A2T2Player alimente un fichier de rapport. Ce dernier à pour vocation d’éclairer le testeur en cas d’erreur durant l’exécution du scénario A2T2. Ce fichier est en XML. Il est associé à un fichier XSL, visant à le formater directement en HTML.

Le fichier XML s’organise de la manière suivante :

• Une balise racine « scénario » qui contient les dates d’exécution

• Une balise « ConfigTDB » contenant l’ensemble des informations à envoyer a la base de données (TDB)

• Une balise « CmdList » contenant la liste des commandes

• Les informations relatives aux commandes (paramètres + résultats) sont contenues dans les balises « Cmd ».

• Enfin une balise « FinalResult » contenant des informations relatives au déroulement du test.

Voici l’en-tête des rapports, elle contient les informations relatives à l’exécution du scénario (temps, nombres d’erreurs) ainsi que la configuration TDB envoyé à la base de données.

[pic]

A la suite de cet en-tête on trouvera la liste des commandes avec les informations liées à leur exécution : le nom de la commande, la date d’exécution, les messages attendus, les messages reçus, les paramètres, le résultat et enfin si nécessaire, le message d’erreur

[pic]

Le format du rapport étant l’XML il est tout à fait possible de le transformer grâce aux feuilles de style XSL en PDF en vu d’un archivage.

PARTIE III : Les répercutions de l’automatisation dans le génie logiciel.

1 Les métriques de l’automatisation

L'utilisation de métriques permet au chef de projet de disposer d'indicateurs clef en termes de Qualification :

• Couverture des tests

• Progression des tests

• Qualité de l'effort de tests

Il existe de très nombreuses métriques, c'est pourquoi il est important de déterminer celles qui sont importantes par rapport à l'organisation. Cette analyse devant se faire conjointement à l'étude de l’outil.

Il existe des métriques tournées sur l'analyse du code et qui concernent l'aspect couverture et d’autres qui représentent la profondeur de l'effort de test. Il existe enfin des métriques qui évaluent la qualité.

1 Métriques de couverture

Couverture des tests : Nombre total de procédures de tests / Nombre total d'exigences de tests.

Couverture fonctionnelle : Nombre d'exigences de tests couvertes par des procédures de test / Nombre d'exigence de test

2 Métriques de progression

Statut des Procédures de test : Nombre de procédures de tests exécutées / Nombre total de procédures de test.

Ratio des anomalies par procédure : Nombre d’anomalies découvertes / le nombre de procédures de tests exécutées.

Age des Anomalies : Mesure le temps qui s'écoule entre la découverte d’une anomalie (CR) et sa correction.

Analyse de l'évolution du nombre d’anomalie : Cette métrique permet de suivre la tendance des anomalies par procédure testée

3 Métriques Qualité

Taux de succès des tests : Nombre de tests positifs sur le nombre de tests exécutés

Qualité des correctifs : Taux d’anomalies redécouvert / Taux d’anomalies corrigées.

Densité d'erreurs : Nombre d’anomalies découvertes / Nombre de procédures de test exécutées pour une fonctionnalité particulière

Exactitude des tests : Permet de juger de la pertinence des tests mis en œuvre. Une valeur trop faible peut la remettre en cause. Il est important de solliciter l'intervention des utilisateurs pour la juger.

L’ensemble de ces métriques pourrait également s’appliquer à des tests manuels, seulement ce serait beaucoup plus fastidieux à mettre en œuvre. Elles permettent d’évaluer les bénéfices issus de l’automatisation des tests.

2 Les bénéfices de l’automatisation des tests

L’automatisation permet d’effectuer des tâches de tests plus efficacement que lorsqu’elles sont effectuées à la main.

1 Le répercutions sur la qualité

Le test est l’activité gardienne de la qualité logicielle, c’est donc en ce sens qu’elle doit se focaliser sur les méthodes permettant de d’accroître cette qualité. L’automatisation fait partie des méthodes permettant l’amélioration de la qualité car elle permet :

• D’effectuer des tests sur des fonctionnalités qui existaient déjà, partant d’une nouvelle version du programme (test de régression). C’est certainement l’avantage le plus évident de l’automatisation, particulièrement dans les environnements ou les programmes sont régulièrement modifiés. L’effort consacré à l’exécution de tests de régression devient alors minimal. Ceci grâce au fait que les tests existent déjà et ont été automatisés pour la version précédente.

• D’effectuer certains tests qu’il aurait été difficile voir impossible d’effectuer manuellement. Par exemple, faire un test qui mettrait en évidence la capacité d’un système en ligne (serveur web) à recevoir la connexion de 200 utilisateurs simultanément serait impossible à mettre en place manuellement. En revanche, il tout à fait possible de simuler ces 200 connexions grâce à un outil de test automatique. Parfois lors de tests, il faut être capable de récupérer un message renvoyé par l’IHM (Interface Homme Machine) du logiciel. Il arrive parfois que ce message ne soit pas visible à l’œil nu (trop rapide, trop petit, etc.), l’outil de test automatique quant à lui pourra aisément le récupérer.

• D’exécuter plus de tests et plus souvent. Un bénéfice évident de l’automatisation est la capacité à effectuer plus de tests en moins de temps et donc plus souvent. Ceci permet d’accroître la confiance en un système.

2 Les répercutions économiques

Hors mis le fait que la qualité à des répercutions économiques, l’automatisation permet de faire certaines économies directes grâce à :

• La réutilisation des tests. Une fois automatisée, un test (ou une partie) peut être réutilisé pour en concevoir d’autre. Ceci est également vrai pour les tests manuels, mais semble être encore plus efficace pour les tests automatiques car ils se matérialisent la plupart du temps sous forme de scénarii programmés.

• Une accélération notable lors du passage en production. En effet, comme nous l’avons vu précédemment le gain de temps est un bénéfice principal du test automatique. Il est donc évident qu’en automatisant le test le produit se retrouvera plus rapidement sur le marché.

3 Les répercutions sur les ressources humaines

Dans la démarche d’automatisation, la machine remplace le testeur, ce choix a donc des répercutions sur ce dernier :

• Meilleure utilisation des ressources. L’automatisation des tâches fastidieuses, comme entrer inlassablement la même valeur dans un programme, permet d’accroître la précision tout en améliorant le moral de l’équipe de test, qui aura ainsi plus de temps pour concevoir de meilleurs tests. De plus, les machines qui restent souvent allumées durant la nuit pourront exécuter des tests plutôt que de consommer de l’énergie pour rien.

• Cohérence dans la répétition des tests. Les tests qui sont répétés automatiquement, le seront exactement de la même manière à chaque fois (ainsi pour les mêmes entrées on devrait les mêmes sorties et ce pour chaque répétition). Ceci donne une constance au test qu’il est très difficile d’obtenir manuellement.

• Augmentation de la confiance. En sachant qu’un large panel de tests automatiques a été réalisé avec succès, l’équipe de test et de développement acquièrent une plus large confiance sur la robustesse et la performance de leurs applications.

3 Les problèmes courants liés à l’automatisation des tests

Il existe une multitude de problèmes issus de l’automatisation des tests. Certains d’entre eux peuvent apparaître de manière très surprenante et sont généralement beaucoup plus difficiles à maîtriser. En voici quelques-uns à prendre en considération.

1 Les répercutions sur la qualité

Quand la mise en place de l’automatisation ne se fait pas dans de bonnes conditions il arrive qu’il y ait des répercutions sur la qualité.

• Expectatives irréalistes. L’industrie moderne est connue pour se focaliser sur les nouvelles solutions technologiques en pensant qu’elles vont résoudre l’ensemble des problèmes. L’automatisation des tests n’y fait pas exception. Ainsi, l’espoir de se délester des problèmes les plus lourds en investissant dans de nouveaux outils (parfois très onéreux), conjugué aux arguments de vente des éditeurs, ont pour effet de fixer des objectifs irréalistes.

• Impression de sécurité. Ce n’est pas parce qu’un test est passé sans erreurs à plusieurs reprises qu’il n’y a pas de défauts dans le logiciel. Le test peut être incomplet ou peut contenir lui-même des défauts. Si les résultats du test sont valides, son automatisation ne va rien faire de plus que de présenter ces résultats valides plus rapidement.

• 2 Les conséquences économiques

Sachant que l’automatisation représente un investissement important pour l’entreprise, il existe des risques dans le cas d’une mauvaise gestion de l’automatisation.

• La maintenance des tests automatiques. Lors de modifications dans le logiciel, il est souvent nécessaire de mettre à jour quelques tests. Ceci est d’autant plus vrai pour les tests automatiques. Cependant on a pu observer que cette mise à jour peut être plus coûteuse que le fait de les passer manuellement. C’est pour quoi, il est impératif de rendre les tests automatiques les plus évolutifs possibles.

• Manque d’expérience dans le métier du test. Si l’expérience liée au test est faible, avec des tests peu organisés, peu documentés, inefficaces dans la détection de défauts, alors l’automatisation n’est pas une bonne idée. En effet, comme le dit Mark Fewster : « Automating chaos just gives chaos ».

• Les problèmes techniques. Les outils de test automatiques payants ou libres sont des programmes à part entière. Ce qui sous-entend qu’ils sont soumis aux mêmes risques de défaillances que d’autres programmes. Cela peut être une double déception qu’un outil de test ait lui-même été mal testé, malheureusement cela arrive. En effet, l’interopérabilité entre l’application à tester et l’outil peut parfois s’avèrer compliquée.

• Limitation dans la découverte de nouveaux défauts. Lorsque l’on passe un test pour la énième fois, il est fort probable que l’on ne trouve pas de nouveaux défauts (en partant du principe que les défauts déjà découverts ont été corrigés). Or, les outils d’automatisation ne sont en réalité que des outils de rejeu (« replay »), ce qui sous-entend une constance parfaite dans la procédure (pas de variante possible). On ne trouvera donc a priori pas plus de défauts par rapport à des tests exécutés manuellement.

4 L’avenir de l’automatisation dans le génie logiciel

Cette démarche a largement été éprouvée dans de nombreuses entreprises. Il paraît évident que l’évolution et l’émergence de solutions professionnelles tend à promouvoir le test automatique et lui prépare un bel avenir. Cet avenir est tout d’abord assuré par une communauté particulièrement active.

1 Une communauté active

Les activités du test logiciel sont reconnues depuis longue date par l’ensemble de la communauté informatique. Décideurs et directions informatiques connaissent aujourd’hui le prix de la non-qualité et acceptent plus volontiers d’investir dans le processus de test logiciel.

Cependant, le retard accumulé et les plus petits budgets alloués au test en France, comparés à ceux des pays anglo-saxons, montrent qu’un important travail d’information reste à effectuer. La réticence de certaines entreprises à adopter une démarche d’automatisation en est la preuve.

Pour communiquer sur l’activité du test, un certain nombre d’acteurs, principalement des industriels (Editeurs de logiciels et SSII) aidés par les directions informatiques, veulent contribuer au développement des activités du test logiciel (automatique et manuel) ainsi qu’à l’adoption et la généralisation de meilleures pratiques (normalisation).

Ces acteurs s’adressent à l’ensemble des personnes intéressées directement ou indirectement par le test logiciel :

• Aux professionnels du test, pour parvenir à imposer l’idée que leur savoir-faire relève d’un véritable métier, avec ses apprentissages et ses techniques. Rompant ainsi avec l’idée trop largement répandue qu’un développeur inoccupé fait automatiquement un bon testeur.

• Aux directions informatiques, aux éditeurs et sociétés de conseil spécialisé dans le test pour sensibiliser et former les personnels aux enjeux de la qualification.

Pour répondre à l’ensemble de ces objectifs, cette communauté organise des conférences, séminaires, crée des méthodologies, des guides, des forums et teste les dernières évolutions et technologies de pointe (Outils, automate de test, moteur de workflow et travail collaboratif).

2 Les outils de mesure des performances applicatives

On assiste à l'avènement d'outils de supervision des performances applicatives et de suivi de la qualité de service. Ces solutions se démarquent des solutions traditionnelles de supervision, en prenant comme référence l'expérience de l'utilisateur final.

Alors que la supervision technique s'adresse principalement aux équipes d'exploitation, la supervision métiers s'adresse aux : maîtrises d’ouvrage, maîtrises d’œuvre, directions qualité (analyse de la qualité de service). Ces outils proposent la production de rapports de résultats (« reporting ») et des études de solutions d’optimisation à moyen et long terme.

Ces outils répondent aux souhaits de l'utilisateur, qui ne s'exprime pas en termes de saturation mémoire ou de surcharge des processeurs, mais qui veut savoir s'il peut exercer son métier dans de bonnes conditions :

• De fiabilité des informations

• De performances des applications

• De disponibilité des transactions

Cette supervision métiers est donc complémentaire à la supervision technique et elle permet de mettre en place de véritables contrats de services en donnant les moyens de leur suivi.

La majorité des logiciels de gestion des performances applicatives mettent à disposition les fonctionnalités suivantes :

• Exécution périodique des transactions

• Archivage des résultats

• Consultation des informations

Un module permet donc d'enregistrer les transactions qui vont faire l'objet d'une surveillance. Pour chacune d'elles, on peut paramétrer la fréquence d’exécution, ainsi que les jours et heures de fonctionnement.

L’application ré-exécute ensuite l'ensemble de ces transactions et stocke les informations de performance (temps de réponse) et de disponibilité dans une base de données.

Enfin, l'ensemble de ces informations sont consultables au travers d'un site Intranet, qui se nourrit des informations de la base de données, et qui permet une mise à disposition des données agrégées, de façon ergonomique.

3 Les répercutions de l’automatisation à Genesys Conferencing

Genesys souhaite s’adapter aux nouvelles technologies du test et donc à l’automatisation. Ce choix aura des répercutions sur les processus mis en place à Genesys, depuis la phase de conception jusqu'à la validation.

4 La régression : première motivation de l’automatisation

Genesys Conferencing a depuis plusieurs mois investit dans l’automatisation des tests. Cet investissement est issu d’un constat évident : les tests de régression occupent une part trop importante dans l’activité de test global. Ces tests sont particulièrement lourds et donc deviennent très fastidieux pour les testeurs, qui préfèrent naturellement se tourner vers le test des nouvelles fonctionnalités du produit. 

Figure 12 : Répartition de l’activité de test par type de tests

L’objectif principal est donc la réduction des tests de régression manuels. Pour ce faire, le service SET doit automatiser les plans de tests utilisés lors de la régression. Grace à cette démarche, il est aussi envisageable de mettre à la disposition des développeurs quelques scripts/scenarii pour la vérification des fonctionnalités basiques de l’application. Ainsi, lors de la sortie d’une nouvelle version, les quelques anomalies directement détectées dans les premières heures de tests pourront être largement réduites.

1 Modification des processus de validation

Le processus de validation classique est le suivant :

[pic]

Figure 13 : Processus de validation actuel

Le processus de validation débute par la livraison d’une nouvelle version de l’application (Build). Cette nouvelle version donne lieu à la création de nouveaux plans de tests destinés à valider les nouvelles fonctionnalités. Il s’accompagne également d’anciens plans de tests pour la validation des fonctionnalités déjà existantes (non-regression). L’ensemble de ces plans de tests doit en théorie être exécuté, en pratique, par manque de temps les tests de régression ne sont pas toujours effectués de manière exhaustive. Une fois exécutés, si certaines anomalies ont été trouvées, les testeurs peuvent créer de nouveaux « Change Request » (CRs) dans l’outil d’archivage des défaults constatés (StarTeam). Ces CRs seront également intégrés aux plans de test pour que lors de la prochaine itération de test (lors d’une nouvelle livraison), on s’attache à vérifier si ces defaults ont bien été corrigés ou pas.

En intégrant l’automatisation au processus de validation on obtient le schéma suivant :

[pic]

Figure 14 : Processus de validation avec automatisation

Ici la création de Plan de tests ne sera pas remise en cause, en revanche elle donnera lieu, lorsque cela est possible, à la création d’un script/scénario correspondant. Ainsi dans la phase d’exécution, les plans de tests liés à la régression seront effectués automatiquement et les autres (nouvelles fonctionnalité) manuellement.

Conclusion

Le génie logiciel regroupe l’ensemble des activités permettant l’élaboration dans les meilleures conditions d’un produit informatique. La maîtrise de ce processus est primordiale pour concevoir des applications fiables. En effet, comme dans toutes les industries, le procédé de fabrication est essentiel pour garantir la qualité, la fiabilité et un résultat en adéquation avec les besoins du client. Ainsi, le perfectionnement de la qualité des logiciels passe par l’amélioration du procédé de fabrication.

Au sein du génie logiciel le test est une activité qui à pour rôle de garantir la qualité des logiciels. On peut donc évaluer la performance du test en observant la qualité des logiciels. Pour accroître la performance des tests il existe une série de techniques et procédés parmi lesquels l’Automatisation. Cependant pour garantir la qualité des tests, nous avons vu qu’il ne suffit pas de disposer de techniques performantes et sophistiquées, il faut être à même de les mettre en œuvre efficacement. Pour ce faire, il est indispensable de mettre en place un véritable processus avec planification, coordination, analyse et suivi des non-conformités décelées au cours du processus.

Pour être efficace cette démarche doit être intégrée et soutenue par l’ensemble des protagonistes du développement : chefs de projet, développeurs, testeurs, etc. Cette démarche doit également être une véritable volonté des dirigeants permettant un investissement suffisant (humain et matériel) à la mise en place d’un tel processus. Quand le besoin est établi, il est essentiel que les cadres soutiennent l’introduction du processus d’automatisation des tests dans leur entreprise en prenant en considération les coûts liés aux mauvaises pratiques de test.

Dans le premier chapitre, il est apparu que la mise en place de processus de test au sein d’une organisation aide celle-ci à atteindre des objectifs, à préciser la valeur ajoutée de ses activités, à rendre ses processus plus performants, à former, et informer ses équipes. Ainsi, le test permet de mobiliser des équipes, de les sensibiliser à la performance des processus, à l'aide d'outils efficaces.

Le marché des outils de tests est vaste, il met à la disposition des services de test une multitude d’outils classés en différentes catégories. Chacune d’entre elle se distingue en fonction du type de test que l’on souhaite effectuer (fonctionnel, intégration, etc.). Pour faire ce choix il est nécessaire de réaliser une étude détaillée capable de déceler les fonctions précises qui requièrent une automatisation. Dans un deuxième temps, il faudra faire un choix parmi les outils proposés, en tenant compte de leur complexité pouvant entraîner des frais annexes de formation. Enfin il sera nécessaire de planifier la mise en place d’un tel outil dans le processus de test.

Nous avons également remarqué que dans certains cas il était difficile voire impossible de trouver sur le marché un outil correspondant a nos besoins, par exemple lorsque l’interface du produit que l’on souhaite tester n’est pas graphique. Dans ce genre de cas un développement spécifique sera nécessaire. Pour effectuer ce dernier il est primordial de connaître le budget alloué au développement d’un tel outil. Il est important par ailleurs de maîtriser l’environnement de l’application que l’on souhaite tester (interface, architecture, etc.). Par ailleurs, une application de test issue d’un développement interne doit intégrer sensiblement les mêmes fonctionnalités que celles fourni par les outils du marché, à savoir : la notion de script ou scénario, l’exécution automatique (différée) et l’édition d’un rapport de test permettant l’analyse approfondie d’un test. Enfin, de même que pour le développement d’applications traditionnelles, il faudra impérativement inscrire le développement de l’outil dans une démarche qualité en intégrant les phases de test, d’intégration, etc.

Apres avoir acheté ou développé un outil de test, il est nécessaire de l’intégrer dans le processus de test. Cette intégration s’accompagnera parfois d’une formation adéquate. Dés lors, certaines métriques devront être mises en place pour connaître les répercutions de l’introduction de l’outil sur la performance du test. Ainsi, le chef de projet devra être à même de visualiser la couverture, la progression et la qualité des tests automatiques. De cette manière il sera à même d’évaluer le retour sur investissement de sa démarche ainsi que les points sur lesquels il est important d’insister et ceux qui sont à revoir.

Une fois l’outil mis en place, on peut observer différentes répercutions sur le processus de test. En premier lieu, on observe que la qualité est améliorée de manière significative. Ceci venant du fait que le gain de temps obtenu grâce au test automatique est systématiquement réinvesti dans la conception de cas de test de plus en plus complexes. De ce fait la couverture des tests augmente de manière significative, entraînant un réel gain de qualité. On observe alors que cette amélioration a des répercutions économiques issues d’une conséquence évidente de la qualité : plus les applications sont de qualité moins le coût de maintenance est important. Il existe également un gain de temps et donc économique lié à la réutilisabilité des scénarii de test. Enfin, on peut observer un impact sur les ressources humaines investies dans le test. En effet, l’automatisation permet dans un premier temps de réduire l’effort fastidieux à fournir pour les tests de régression. Cette réduction d’effort a des répercutions visibles sur la motivation des équipes.

Il arrive parfois que toutes les conditions de mise en place ne soient pas réunies. Ceci entraîne alors des répercutions sur le plan économique à cause du retard, de la baisse de qualité, etc. Il est donc nécessaire d’être vigilant quant aux efforts investis dans le déploiement d’outils de test automatique.

L’ensemble de cette étude m’a permis de me faire une idée sur les répercutions de l’automatisation des tests dans le génie logiciel. Il en est ressorti que l’automatisation des tests est un passage obligatoire dans le processus de développement informatique. En effet on a pu observer à quel point cette démarche affectait profondément les ressources (humaines et matérielles) allouées à un projet informatique, en essayant de maximiser l’analyse humaine et minimiser les tâches répétitives des testeurs. En contre partie, il faudra faire preuve d’un maximum de vigilance en ce qui concerne l’efficacité et la fiabilité des tests automatiques.

Le service de test de Genesys Conferencing, a pris en compte toutes ces exigences pour concevoir l’outil de test automatique du service de téléconférence (A2T2 : automated audio test tool). La première version de cet outil a vu le jour à la fin de ma période de stage. Elle nous a permis de fixer des objectifs à court et à long terme sur la couverture des tests automatiques possibles. Ainsi nous sommes arrivés à la conclusion suivante : l’objectif principal dans un premier temps est l’automatisation de 40% des tests audio. Cet objectif semble tout à fait réaliste au vu des tests fonctionnels réalisés sur l’application. Dans un deuxième temps, il serait intéressant de compléter les capacités de l’outil en ajoutant de nouvelles caractéristiques et améliorer ainsi la couverture. A l’heure actuelle, A2T2 est une application à part entière intégrée au processus de test du service et nous travaillons sur une nouvelle version prévue pour la fin de l’année.

Le test automatique a un avenir certain au sein des entreprises de développement et particulièrement chez Genesys. En effet, la qualité reste la préoccupation principale des concepteurs d’applications informatiques et l’automatisation s’avère être un considérable allié pour aller dans ce sens. On observe également l’évolution des outils qui sont proposés pour le test, de plus en plus perfectionnés, permettant une analyse plus approfondie des disfonctionnements, avec des interfaces plus ergonomiques.

Bibliographie

• « Effective Software Test Automation: Developing an Automated Software Testing Tool » de Kanglin Li et Mengqi Wu. Sybex Inc, Février 2004, 408 pages. Cet ouvrage expose plusieurs techniques utilisables pour développer un outil de test spécifique.

• « Test logiciel en pratique » de John Watkins. Vuibert septembre 2002, 315 pages. Ce livre couvre tous les aspects du test logiciel les différentes approches et leur nécessité, les techniques de test, la planification et la gestion de projets de test, les rôles et responsabilités des acteurs, les phases de test, l’amélioration du processus de test, l’usage de métriques, etc.

• « Software Test Automation » de Mark Fewster & Dorothy Graham, ACM Press, 2001, 562 pages. Ce manuel expose plusieurs méthodes d’automatisation des tests. Il présente également différentes techniques de Scripting ainsi que quelques outils du marché.

Netographie

• Introduction au génie logiciel (coût des erreurs, qualité logicielle, facteurs de qualité) :



Auteur : A.Beugnard

• Introduction au génie logiciel, la non qualité des systèmes informatiques :



• Les phases de tests :



Auteurs : Valérie Ménissier-Morain et Philippe Ayrault

• Introduction au test du logiciel (Qu'est-ce que tester un logiciel ?)



• Les outils de test :



Auteur : Anne-Marie Hugues, Professeur Associée à Polytech’Nice

• le marché des outils de tests :



• Descriptif sur les tests, les techniques de tests et les outils de tests :



Table des figures

Figure 1 Modèle en V 11

Figure 2 :L’arbre de qualité (ISO) 17

Figure 3 : Comparaison test manuel / Automatique 24

Figure 4 : Organigramme du service SET 25

Figure 5 : Processus de validation de SET 30

Figure 6 : Démarche ATLM 34

Figure 7 : La démarche de test automatique 37

Figure 8 : Exemple de fonctionnement d’une téléconférence 50

Figure 9 : Architecture A2T2 52

Figure 10 : Instance du modèle A2T2 60

Figure 11 :Diagramme de classe 61

Figure 12 :Répartition de l’activité de test par type de tests 75

Figure 13 : Processus de validation actuel 76

Figure 14 : Processus de validation avec automatisation 77

Glossaire

AFNOR (Association Française de Normalisation) : organisme officiel français de normalisation. Il est membre de l’Organisation internationale de normalisation. L’AFNOR a été créée en 1926. Elle est placée sous la tutelle du ministère de l’industrie. Elle compte environ 3 000 entreprises adhérentes.

ADL (Application developement language) : Langage de programmation ayant remplacé le VOS. Il permet de programmer la carte Dialogic, c’est un langage précompilé à la manière java. Il s’appuie sur les appels système C++ proposés par Dialogic.

API (Application Programming Interface) : Bibliothèque de fonctions permettant de faire l’interface entre deux couches logicielles ou matérielles.

DTMF (Dual Tone Multi-Frequency) : Tonalité correspondant à une touche du téléphone. En Europe il en existe 12 : 0123456789*#.

Génie logiciel : Discipline de l’informatique qui regroupe un ensemble de connaissances, de procédés et des acquis scientifiques pour l’analyse, la conception, la mise en œuvre, la vérification et la documentation de logiciels dans le but d’en optimiser la production, le support et la qualité.

ISO (International Organization for Standardization) : Organisation internationale de normalisation créée en 1947, composée de représentants des organismes de normalisation nationaux d’environ 150 pays, qui produit des normes internationales dans les domaines industriels et commerciaux.

Métriques : c’est un indicateur qui appartient à la métrologie, la science de la mesure associée à l’évaluation de son incertitude. Appliquée à la production logicielle, une métrique est un indicateur d'avancement ou de qualité des développements logiciels.

Outsourcing : L’outsourcing consiste en l’externalisation d’un service ou d’une fonction de l’entreprise.

Plan de test : Document contenant les objectifs, les contraintes, les risques, les hypothèses, les critères de départ et d’arrêt, le suivi, un plan pour compléter le test.

Pont Téléphonique : Armoire contenant une série de cartes permettant d’interconnecter des lignes téléphoniques.

Scénario de test : Document détaillant la procédure de test, les entrées, le fonctionnement attendu de l’élément testé. Il contient également plusieurs jeux d’essai.

Scénario de test automatique : Séries d’instructions contenu dans un format spécifique, qui permet à un outil de test automatique de reproduire l’utilisation et les points de contrôle programmés pour tester une application.

TLM (TeLeMeeting) : Application permettant de gérer l’ensemble des téléconférences d’un pont téléphonique.

Annexes

1 Plan de test Access-Disconnection

Voici une partie d’un plan de test utilise par Genesys pour tester les phases d’accès.

|# |Purpose |Action |Test |Result |

| | | | |(Pass/Fail) |

| |Global access |Dial a global access number. This |You should get the “WELC_SERVICE” message played. | |

| | |number is in service (created in TDB)| | |

| |Dial_Room Message |No action (wait for next messages) |You will get the “DIAL_ROOM” message recurring | |

| | | |every 30 secs. | |

| |No action for 5 min |Do not enter any room number for 5 |After 5 min of recurring “DIAL_ROOM” messages, you| |

| | |min. |get disconnected from the TLM. | |

| |Call again |Dial a global access number. This |You get the “WELC_SERVICE” message played. | |

| | |number is in service (created in TDB)| | |

| |Invalid room number |Enter an invalid room number (not |The “ROOM_NOT_ASSIGNED” is played then” DIAL_ROOM”| |

| | |created in TDB) |again. | |

| |2nd invalid number |Enter again invalid room number 2nd |The “ROOM_NOT_ASSIGNED” is played then” DIAL_ROOM”| |

| | |time. |again. | |

| |3rd invalid number |Enter again invalid room number 3rd |The “ROOM_NOT_ASSIGNED” is played then you get | |

| | |time. |disconnected. | |

| |Call again |Dial a global access number. This |The “DIAL_ROOM” is played. | |

| | |number is in service (created in | | |

| | |TDB). | | |

| |Inactivity |You do not enter any room number for |The “DIAL_ROOM” is played every 30 secs. | |

| | |a while. | | |

| | | |After 5 minutes, you get “ROOM_NOT_ASSIGNED” and | |

| | | |you are disconnected right away. | |

| |Call again |Dial a global access number. This |You get the “WELC_SERVICE” message played. | |

| | |number is in service (created in TDB)| | |

| |Room in service |Enter a valid room number (created in|As room number is valid, you go directly to the | |

| | |TDB) |‘Access’ Phase (chap. 3) | |

| |Call again |Dial a global access number. This |You get the “WELC_SERVICE” message played. | |

| | |number is NOT in service (NOT created| | |

| | |in TDB) | | |

| |Global Access Number|No action (wait for next messages) |As this global access number is not in service, | |

| |NOT in service | |you get “ROOM_NOT_ASSIGNED” and are hang up. | |

Context: “Digicode=ON” in TDB, “Door Closed after CP entry = No” in TDB, Mod is connected, door is opened

PSC = 1111 (create a member with pincode = 1111 on this room)

CSC = 0000 (set Conference security code = 0000 on this room)

❑ Correct PSC

|# |Purpose |Action |Test |Result |

| | | | |(Pass/Fail) |

| |Access phase |As a participant, you have called a |After the WELCOME phase, you are now in the access| |

| | |room in service. |phase | |

| | | | | |

| | |MOD is connected both on Audio and | | |

| | |Web. | | |

| |PSC |Door is opened/ digicode ON/ MOD IN |As digicode is ON and MOD IN, you are requested a| |

| | |(no action required here) |security code with “PART_PIN” message | |

| |Wrong PSC |Enter a wrong PSC *2222* that is not |You get no notification of wrong PIN ( NO failure | |

| | |defined for this room |jingle). | |

| | | |PART_PIN just keeps being played. | |

| |Close door |Close the door. |The participants should now get the WAIT message | |

| | | |played recurrently every 30 secs. | |

| |Open Door |Open the door again |The participants should now get the PART_PIN | |

| | | |message played recurrently every 30 secs. | |

| |Correct PSC |Enter the correct CSC to this room |You get “WAITING_EXIT” played, then “CONF_ENTER” | |

| | |*0000*. |and you enter the meeting as a participant (2 bips| |

| | | |are played)) | |

| | | | | |

| | | |Check that on MOD GenMC Web you are displayed with| |

| | | |your ANI number (or “partXX” if no ANI) and NOT as| |

| | | |“GLOBAL_PINCODE” | |

| |Pincode |Once in the meeting try *PIN* |You get nothing played to you (no bips, no | |

| | | |message). You can’t be the CHAIR cause CHAIR is | |

| | | |already connected. | |

2 Documentation de A2T2

1. A2T2 Builder

The Builder is a Graphical Windows based executable, used to graphically create A2T2 scenarios. A scenario is a sequential list of TLM commands( i.e. from left to right : Cmd Id 0, Cmd Id 1 , Cmd Id2 , … ). Each command is attached to a participant (Part 0 , Part 1, … ) who is corresponding to a real line on the dialogic board ( Line1, Line2, ….).

1.1. Global builder view

1.2. Room configuration panel

The "Room configuration panel" contains all data concerning the room setting in TDB, in next a2t2 version it will be used to create(if non exist) or to update a room at the beginning of the scenario, in the TDB.

It will also allows to reflect the change made by a command (e.g. *74* -> record on). For now this panel is only indicative for the tester.

1.3. Commands panel

The "Commands panel" is use to add command to the current scenario. You only need to drag and drop a command from this panel to the scenario panel at the right position, in an existing participant or in the white empty are. If no participant exists it will be automatically created.

1.4. Scenario panel

The "Scenario panel" allows to arrange and update the added commands or participants. Actions on a command or a participant is made thanks to a right click popup menu on the right item(command or participant) .

Participant popup menu(right click in a participant area):

- Add new : add a new empty participant to the list of participant, useful if we need a participant used with a multi participant command ( DialoutPart : moderator dial-out a participant)

- Edit : Open the modification windows for the selected participant

- Erase : Remove the participant and all its commands

Command popup menu(right click in a command area)::

- Edit: : Open the modification windows for the selected command

- Erase Delete the selected command

- Move XXX: mode the command in the scenario line

1.5. Command Properties windows

Each command can be configured thanks to a generic dialog box which is in charge of load all the parameters of a specific command.

We can divided the dialog box In 3 part:

1) Participant Waited Messages Area : Each command is made by a participant and the majority of this commands wait a messaye played by the bridge ( play cmdEnterPinCode (*2651* ) receive messages: CONF_ENTER, CHAIR

2) Tester Participant Area: This other participant of the scenario allows to double verify the command action or allows to provide another participant for the outgoing call(with a specific call status( answer, not responding, busy )

3) The Parameters Area: This zone specifi all the command paramater needed( i.g. Phone number , pincode, … )

Depending on the command , some of the 3 area are used or not , in the following page we will see some different possibility for this properties window.

3 Extrait des rapports XML et feuille de style XSL

Voici le contenu du rapport Access-Disconnection_4.1.10.a2t2.xml

Voici un extrait de la feuille de style A2T2Report.xsl

Report of

Date :

Total time :

Number of errors :

-

-

TDB Configuration

Subscription ConfigMemberGroup

Subscrition Number

Pin Code

[pic]

-----------------------

Direct access as Moderator/Participant

|# |Purpose |Action |Test |Result |

| | | | |(Pass/Fail) |

| |Direct access to a |Dial a direct access number. This |You should get the “WELC_SERVICE” message played. |Pass |

| |number in service |number is in service (created in TDB)| | |

| |Access phase |No action (wait for next messages) |As room is in service, you go directly to the |Pass |

| | | |‘Access’ Phase (chap. 3) | |

| |Direct access to |Dial a direct access number. This |You should get the “WELC_SERVICE” message played. |Pass |

| |number not in |number is NOT in service (NOT created| | |

| |service |in TDB, but reaches the bridge) | | |

| |Disconnection |No action (wait for next messages) |As room is not in service, you get |Fail |

| | | |“ROOM_NOT_ASSIGNED” and are hang up. | |

| |Direct access to |Dial a direct access number. This |You should get the “WELC_SERVICE” message played. | |

| |number not in |number is NOT in service (NOT created| | |

| |service |in TDB, but reaches the bridge) | | |

Premier lancement

du test automatique

Test Automatique

(après plusieurs utilisations)

Test manuel

Efficace

Complet

Evolutif

Economique

Configuration de téléconférence TDB

*

MoParticipant

1

1

*

Scénario

Liste des commandes

*

MoCommandBase

MoScenario

MoConference

MoNode

1

Le génie logiciel est la discipline regroupant la conception et la mise en œuvre des produits et procédures tendant à réaliser la production du logiciel et son suivi. Une des activités du génie logiciel est le test, elle intervient en phase de validation. Le test est le garant de la qualité au sein du génie logiciel. Quel sont les processus à mettre en place pour accroître l’efficacité du test ?

Le processus d’automatisation des tests s’inscrit dans une stratégie qualité d’envergure. Il nécessite une étude préalable et le respect de différentes étapes telles que : l’évaluation des coûts et délais, le choix d’un outil du marché ou d’un développement interne spécifique, la conception des scénarii de test, l’exécution et l’analyse des résultats.

Pour être à même d’évaluer les différentes répercussions de l’automatisation sur les tests il est nécessaire d’avoir des métriques et des repères pour en évaluer l’impact.

Les répercutions des tests automatiques sur le développement informatique peuvent s’observer sous plusieurs angles : qualité, humain, économique…Pour chacun de ces aspects il conviendra d’en étudier les bénéfices et les risques. Enfin nous verrons les perspectives de l’automatisation dans l’activité du génie logiciel

IL FAUT REDUIRE LA PORTION «  REGRESSION »

[pic]

% of SET testing time

1st iteration

2nd iteration

New Test Plan

Old Test Script

MANUAL

AUTOMATION

NewTest Case

CRs

BUILD XX

NewTest Case

New Build Delivered

(Contains for ex. 3 New features)

Execute New Test Plan

(New features)

Execute Old Test Scripts

(REGRESSION)

New Test Plans created

Old Test Scripts updated

STARTEAM

MANUAL

MANUAL

New Test Plan

NewTest Case

CRs

BUILD XX

NewTest Case

New Build Delivered

(Contains for ex. 3 New features)

Execute New Test Plan

(New features)

Execute Old Test Plans

(REGRESSION)

New Test Plans created

Old Test Plans updated

Old Test Plan

Old Test Case

Old Test Case

OldTest Case

STARTEAM

Matthieu Tardivel – Mémoire 2006 25

Matthieu Tardivel – Mémoire 2006 63

Matthieu Tardivel – Mémoire 2006 29

The participant "tester" n°0 wait a message from the bridge witch confirm the command

Want the participant 1 (the "tester" part) have his line status busy

Waited bridge messages for the participant who own this command

Command Parameters

Command and Participant Popup menu

Room Configuration panel

Commands panel

Scenario Panel

Septembre 2006

E.P.S.I

CSII3B

New

Test Script

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download