Cette page vous a-t-elle été utile ?
Votre avis sur ce contenu est important. N'hésitez pas à nous faire part de vos commentaires.
Vous avez d'autres commentaires ?
1500 caractères restants
Exporter (0) Imprimer
Développer tout

Test de globalisation

Visual Studio .NET 2003

L'objectif du test de globalisation est de déceler les éventuels problèmes dans le design d'une application qui pourraient entraver la globalisation. Ce test garantit que le code peut gérer toute la prise en charge internationale sans endommager la fonctionnalité et éviter ainsi des pertes de données ou des problèmes d'affichage. Le test de globalisation vérifie le bon fonctionnement du produit avec les paramètres culturels et régionaux définis, à l'aide de chaque type d'entrée internationale possible.

Une fonctionnalité correcte du produit suppose à la fois un composant stable fonctionnant conformément aux spécifications de design (quels que soient les paramètres d'environnement internationaux, les cultures et les paramètres régionaux) et une représentation correcte des données.

Les étapes suivantes doivent faire partie de votre plan de test de globalisation :

Décision de la priorité de chaque composant

Pour rendre les tests de globalisation plus efficaces, assignez une priorité de test à tous les composants testés. Les composants dont la priorité doit être la plus élevée sont les suivants :

  • les composants prenant en charge des données de texte dans le format ANSI (American National Standards Institute) ;
  • les composants gérant de nombreuses chaînes (par exemple, les composants contenant de nombreux contrôles de modification) ;
  • les composants utilisant des fichiers pour un stockage ou un échange de données (par exemple, les métafichiers Windows, les outils de configuration de la sécurité et les outils Web) ;
  • les composants ayant rencontré de nombreux problèmes de globalisation dans le passé.

Sélection d'une plate-forme de test

Quel système d'exploitation devez-vous utiliser comme plate-forme de test internationale ? Vous devez d'abord utiliser votre version locale de Windows 2000 sous laquelle est installé un groupe de langues. Par exemple, si vous utilisez la version américaine de Windows 2000, installez le groupe de langues d'Asie orientale. Cette combinaison vous fournit une prise en charge internationale complète pour la langue sélectionnée sans nécessiter que les testeurs possèdent des connaissances de cette langue.

Même si vous ciblez une plus large variété de systèmes d'exploitation, Windows 2000 doit être votre plate-forme de test principale. Les anciens systèmes d'exploitation ne vous offrent pas la même flexibilité concernant une prise en charge native et des paramètres régionaux pour la plus large gamme de langues, de cultures et de paramètres régionaux.

Vous pouvez également utiliser des plates-formes distinctes de votre version locale de Windows 2000 :

  • Version multilingue de l'interface utilisateur Windows 2000 : cette version est particulièrement utile si votre code implémente une interface utilisateur multilingue et doit s'adapter aux paramètres de l'interface utilisateur du système d'exploitation. Cette approche représente une alternative facilement implémentée pour installer plusieurs versions localisées du système d'exploitation. Pour améliorer davantage la prise en charge multilingue, Microsoft propose une version multilingue distincte de Windows 2000, qui fournit jusqu'à 24 versions linguistiques localisées de l'interface utilisateur Windows. Pour plus d'informations, consultez Multilanguage User Interface (MUI).
  • Version localisée du système d'exploitation cible : l'allemand et le japonais sont recommandés. Rappelez-vous que leur utilisation est plus difficile si vous ne connaissez pas la langue de l'interface utilisateur du système d'exploitation. Cette approche ne présente pas d'avantages significatifs par rapport aux solutions décrites ci-dessus.

La plupart des problèmes de globalisation rencontrés lors du test se produisent lorsque la prise en charge des langues d'Asie orientale est active ou lorsque la page de codes OEM diffère de la page de codes ANSI pour des cultures/paramètres régionaux donnés. Par exemple, vous pouvez sélectionner les cultures/paramètres régionaux suivants dans la version américaine de Windows 2000 afin de tester les éventuels problèmes de globalisation :

  • Japonais
  • Allemand
  • Une combinaison de ces deux langues (l'une sélectionnée pour les paramètres régionaux système et l'autre pour les paramètres régionaux utilisateur) lorsqu'il est possible d'assurer une prise en charge multilingue

Vous pouvez assurer la couverture la plus étendue si vous installez tous les groupes de langues, permutez les cultures/paramètres régionaux et exécutez les tests « globalisés » décrits ci-dessous.

Création de l'environnement de test

Pour effectuer un test de globalisation, vous devez installer plusieurs groupes de langues et vérifier que les paramètres régionaux ne sont pas vos paramètres régionaux locaux. Comme indiqué précédemment, l'exécution de tests dans les environnements allemands et japonais, ainsi que dans une combinaison de ces deux langues, permet de traiter la majorité des problèmes de globalisation.

Principalement, les étapes permettant de créer un environnement de test universel via les environnements japonais et allemands sont les suivantes :

  1. Installez, le cas échéant, la prise en charge de la langue japonaise (ou une autre langue d'Asie orientale) et de la langue allemande sur votre version locale de Windows 2000 (la version américaine de Windows 2000 installe la prise en charge de la langue allemande par défaut).
  2. Définissez sur l'ordinateur de test des cultures/paramètres régionaux (japonais ou allemand) différents de vos paramètres locaux.
  3. Configurez un réseau distribué avec un environnement mixte de systèmes exécutant la version locale de Windows 2000 et configurés les uns avec les cultures/paramètres régionaux japonais, les autres avec les cultures/paramètres régionaux allemands.

Un test exécuté avec le japonais comme culture/jeu de paramètres régionaux par défaut du système vérifie la gestion du jeu de caractères DBCS dans les composants ANSI (non Unicode). Un test exécuté avec l'allemand comme culture/jeu de paramètres régionaux par défaut du système vérifie que les pages de code ANSI et OEM sont traitées correctement lorsqu'une conversion de texte est requise. Un environnement réseau mixte distribué vérifie que les données peuvent être transmises correctement entre des cultures/paramètres régionaux différents.

Exécution de tests

Après que l'environnement a été configuré pour le test de globalisation, vous devez être particulièrement attentif aux éventuels problèmes de globalisation lors de l'exécution de vos scripts de test ordinaires :

  • Accordez une importance particulière aux scripts de test qui traitent de l'entrée et de la sortie de chaînes, directement ou indirectement.
  • Les données de test doivent contenir des caractères mixtes provenant des langues d'Asie orientale, de l'allemand, des caractères d'écriture complexe (arabe, hébreu, thaï) et éventuellement de l'anglais. Il existe parfois des limitations, telles que l'acceptation de caractères qui correspondent uniquement à la culture ou aux paramètres régionaux. Il peut s'avérer difficile d'entrer manuellement toutes ces entrées de test si vous ne connaissez pas les langues dans lesquelles les données de test sont préparées. Un générateur de texte Unicode simple peut être très utile à ce stade.

Reconnaissance des problèmes

Le problème le plus grave lié à la globalisation est la perte de fonctionnalité, soit immédiate (lorsque la culture/le jeu de paramètres régionaux sont modifiés), soit ultérieure lors de l'accès aux données d'entrée (entrée de caractères non américains).

Certains problèmes de fonctionnalité sont décelés comme des problèmes d'affichage :

  • Les points d'interrogation (?) apparaissant à la place du texte affiché indiquent des problèmes de conversion Unicode en ANSI.
  • Les caractères ANSI étendus aléatoires (par exemple, ¼, †, ‰, ‡, ¶) apparaissant à la place du texte lisible indiquent des problèmes dans le code ANSI utilisant la mauvaise page de codes.
  • L'apparence des zones, des barres verticales ou des tildes (glyphes par défaut) [□, |, ~] indique que la police sélectionnée ne peut pas afficher certains caractères.

Il peut être difficile de découvrir les problèmes dans les résultats d'affichage ou d'impression nécessitant des connaissances en matière de mise en forme, de disposition ou d'écriture. Ce test est spécifique à la langue et, dans la plupart des cas, il ne peut pas être exécuté sans une connaissance de la langue. En revanche, votre test peut être limité à un examen du code. Si les mécanismes de gestion de texte standard sont utilisés pour composer et afficher le texte de sortie, cette zone peut être considérée comme une zone sûre.

Une autre zone de problèmes potentiels se manifeste lorsque le code ne réussit pas à suivre les conventions locales définies par la culture/le jeu de paramètres régionaux en cours. Vérifiez que votre application affiche des données respectant la culture/les paramètres régionaux (par exemple, les nombres, les dates, l'heure, la monnaie et les calendriers) en fonction des paramètres régionaux actuels de votre ordinateur.

Les Options régionales du Panneau de configuration ne couvrent pas toutes les fonctionnalités spécifiques aux cultures/paramètres régionaux. Par exemple, l'ordre de tri en cours n'est pas visible à cet endroit. Il est donc important de disposer d'un plan de test qui couvre tous les aspects des fonctionnalités relatives aux cultures/paramètres régionaux avant de commencer le test.

Voir aussi

Test de globalisation et de localisation

Afficher:
© 2015 Microsoft