Considérations relatives à la conception d’Automated Test Framework

Créez des tests fiables, évolutifs et efficaces en suivant ces considérations de conception.

Tests d'ordre général

Évitez de modifier les ServiceNow tables système ou les tables qui étendent le fichier d’application [sys_metadata] qui peuvent potentiellement modifier le comportement du système. Évitez d’utiliser ou de modifier des enregistrements existants afin d’obtenir des résultats inattendus entre les tests. Voici quelques-uns des exemples courants de modifications des données système qui peuvent entraîner des résultats inattendus.

• Emprunter l’identité d’un compte existant
• Supprimez un enregistrement existant.
• Exécuter un test qui désactive une règle métier ou une propriété système
• Valider avec un enregistrement existant

Tests parallèles

Réduisez le temps de conception des tests en exécutant plusieurs tests et suites de tests en parallèle. Concevez des tests à exécuter en parallèle en évitant les conflits de ressources et les dépendances de données.

Éviter les conflits de ressources entre les tests parallèles

Prévenez les conflits de ressources en exécutant des tests qui créent leurs propres données. Les tests qui s’exécutent avec des données existantes empêchent d’autres tests qui nécessitent les mêmes données de s’exécuter en parallèle.

Remarque :

Si vous avez deux tests en conflit de ressources ou plus, consultez Marquer les tests comme mutuellement exclusifs pour créer une règle d’exclusion mutuelle afin de les empêcher de s’exécuter en parallèle.

Tests paramétrés

Exécuter un test plusieurs fois avec des données de test différentes pour chaque exécution. Créez des paramètres pour stocker les données de test pour chaque exécution de test. Consultez Composants de test paramétrés pour en savoir plus.

• Créez des paramètres pour stocker les données de test pour chaque exécution de test.
• Assurez-vous que les tests paramétrés prennent en charge les fonctionnalités standard d’Automated Test Framework (ATF), telles que les rapports, les suites de tests et la restauration de données. La copie d’un test paramétré copie tous les paramètres, les jeux de données d’exécution de test et les étapes de test.
  Remarque :

  Si un test paramétré comprenant des étapes de test d’interface utilisateur personnalisées est créé, le système utilise uniquement le premier ensemble de données pour récupérer les composants.

Test d’interface utilisateur personnalisé

Testez des interfaces utilisateur personnalisées telles que des pages d’interface utilisateur et des macros d’interface utilisateur en récupérant leurs composants de page HTML et JavaScript et en identifiant les actions de test qu’elles prennent en charge.

Utiliser l’inspecteur de page pour identifier les composants de page pouvant être testés

L’inspecteur de page détermine quels composants de page sont disponibles pour le test d’interface utilisateur personnalisé. Les composants de page qui ne sont pas disponibles pour l’inspecteur de page ne sont pas disponibles pour les tests d’interface utilisateur personnalisés.

Accédez à l’interface utilisateur personnalisée que vous souhaitez tester

Utilisez les étapes de test existantes pour accéder à l’interface utilisateur personnalisée cible. Par exemple, pour tester un article de la base de connaissances, utilisez les étapes de test existantes pour accéder à un module ou pour ouvrir un enregistrement existant. La plupart des tests d’interface utilisateur personnalisés nécessitent l’utilisation des catégories d’étapes de test existantes dans le cadre du test.

Utiliser la zone de composant pour identifier les composants de la page

La zone de composant décrit l’élément de mise en page HTML contenant le composant, tel qu’un <div> élément or <section> . Cette zone aide les concepteurs de tests à distinguer les composants en indiquant l’emplacement dans la mise en page.

Tester votre interface utilisateur personnalisée plutôt que l’interface Now Platform utilisateur

Le Infrastructure de tests automatisés empêche le test d’interface utilisateur personnalisée des Now Platform fonctionnalités. Par exemple, vous ne pouvez pas tester les tableaux de bord ou les concepteurs graphiques. Créez plutôt des tests pour valider vos pages et éléments d’interface utilisateur personnalisés, car vous avez un contrôle direct sur ces interfaces utilisateur.

Utiliser les attributs HTML pour remplacer les propriétés de test du composant de page

Modifiez les propriétés de test d’un composant de page particulier à l’aide d’attributs Infrastructure de tests automatisés HTML spécifiques à . Reportez-vous à Remplacer les actions de test du composant.

Récupérer à nouveau les composants de la page lorsque vous déplacez des tests vers une autre instance

Les étapes de test d’interface utilisateur personnalisées ne stockent pas les composants d’interface utilisateur en tant que métadonnées. Les testeurs doivent à nouveau récupérer manuellement les composants de la page lors du déplacement des tests entre les instances.

Tests de clones à partir du système de production

Déplacez vos tests vers le système de production pour cloner les instances les plus récentes à des fins de test. Accélérez le temps de test en copiant ou en clonant directement un test du système de production vers une instance de sous-production.

Remarque :

Par défaut, la propriété système utilisée pour exécuter des tests automatisés est désactivée pour vous empêcher d'exécuter accidentellement ces tests sur un système de production. Pour éviter toute panne ou endommagement des données, exécutez des tests uniquement sur les instances de développement, de test et autres instances de non-production.

Messages d’avertissement pour tous les tests

Messages d'avertissement	Considérations relatives à la conception
Prendre l’identité d’un utilisateur existant peut provoquer un comportement inattendu pour ce test. Évitez les problèmes potentiels en ajoutant une étape « Créer un utilisateur » à la place. Consultez la documentation pour connaître les considérations relatives à la conception de tests.	Créez un nouvel utilisateur pour vous assurer que les rôles et les groupes sont appropriés et évitez d’utiliser les enregistrements existants. Consultez Tests d'ordre général pour plus d'informations.
L’utilisation d’une table qui étend le fichier d’application [sys_metadata] peut provoquer un comportement inattendu pour d’autres tests exécutés en parallèle. Consultez la documentation pour connaître les considérations relatives à la conception de tests.	Évitez d’exécuter un test avec une table qui étend le fichier d’application, car cela pourrait affecter d’autres tests. Consultez Tests parallèles pour plus d'informations.
L’utilisation d’une table système peut provoquer un comportement inattendu pour d’autres tests exécutés en parallèle. Consultez la documentation pour connaître les considérations relatives à la conception de tests.	Évitez d’utiliser une table système, car cela pourrait affecter d’autres tests exécutés en parallèle. Consultez Tests parallèles pour plus d'informations.
L’utilisation d’un enregistrement existant peut provoquer un comportement inattendu pour ce test. Consultez la documentation pour connaître les considérations relatives à la conception de tests.	Évitez d’utiliser des enregistrements existants, car ces enregistrements peuvent ne pas avoir l’état et les valeurs attendus par le test. Utilisez les enregistrements créés pendant le test pour garantir que l’état et les valeurs sont corrects. Consultez Tests d'ordre général pour plus d'informations.
La modification d’un enregistrement existant peut provoquer un comportement inattendu pour d’autres tests exécutés en parallèle. Consultez la documentation pour connaître les considérations relatives à la conception de tests.	Évitez d’utiliser les enregistrements existants, car cela pourrait affecter d’autres tests. Utilisez les enregistrements créés pendant le test. Consultez Tests d'ordre général pour plus d'informations.
L’utilisation du type de déclaration « --Aucune-- » peut provoquer un comportement inattendu pour les actions d’interface utilisateur de serveur. Évitez les problèmes potentiels en définissant le type de déclaration et en utilisant un délai d’expiration. Consultez la documentation pour connaître les considérations relatives à la conception de tests.	Les actions d’interface utilisateur du serveur entraînent la soumission du formulaire actuel et le rechargement de la page. Sélectionnez un type de déclaration autre que Aucun pour éviter tout comportement inattendu pour les actions d’interface utilisateur de serveur. définissez un délai d’expiration pour vous assurer que votre test attend que le formulaire soit soumis ou non avant de passer à l’étape suivante. Lors du test des actions d’interface utilisateur du serveur, le type de déclaration Aucune se configure automatiquement en Formulaire soumis au serveur.

Test de Domain Separation

Lorsque vous testez Domain Separation, vous devez d’abord définir le domaine. Cela doit faire partie de la première étape d’emprunt d’identité de chacune des étapes de test ATF lorsqu’elles dépendent d’un domaine défini. Pour en savoir plus sur les pratiques recommandées de séparation de domaine, consultez Pratiques recommandées de séparation de domaine pour les fournisseurs de services.