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 ServiceNow les tables système ou les tables étendant le fichier d’application [sys_metadata] susceptibles de modifier le comportement du système. Évitez d’utiliser ou de modifier des enregistrements existants pour éviter des résultats inattendus entre les tests. Voici quelques-uns des exemples courants de changements de données système qui peuvent entraîner des résultats inattendus.

• Emprunter l’identité d’un compte existant
• Supprimer 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

Test parallèle

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.

Prévention des conflits de ressources entre les tests parallèles

Évitez 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’exécuter en parallèle d’autres tests qui requièrent les mêmes données.

Remarque :

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

Test paramétré

Exécutez 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 la section Composants de test paramétrés pour plus d’informations.

• 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 des 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é incluant 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 les interfaces utilisateur personnalisées telles que les pages d’interface utilisateur et les 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 les composants de page disponibles pour les tests d’interface utilisateur personnalisés. 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 de 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 ou <section> . La zone aide les concepteurs de tests à distinguer les composants en fournissant l’emplacement dans la mise en page.

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

Cela Framework de tests automatisés empêche les tests d’interface utilisateur personnalisés des Now Platform fonctionnalités. Par exemple, vous ne pouvez pas tester les tableaux de bord ou les graphistes. Au lieu de cela, créez 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 des attributs HTML pour remplacer les propriétés de test des composants de la page

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

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

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

Cloner les tests à 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 concernant les considérations relatives à la conception de test.	Créez un nouvel utilisateur pour garantir les rôles et les groupes appropriés et éviter 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 concernant les considérations relatives à la conception de test.	Évitez d’exécuter un test avec une table qui étend le fichier d’application, car cela pourrait affecter d’autres tests. Consultez Test parallèle 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 concernant les considérations relatives à la conception de test.	Évitez d’utiliser une table système, car cela pourrait affecter d’autres tests exécutés en parallèle. Consultez Test parallèle pour plus d'informations.
L’utilisation d’un enregistrement existant peut provoquer un comportement inattendu pour ce test. Consultez la documentation concernant les considérations relatives à la conception de test.	Évitez d’utiliser les enregistrements existants, car ils peuvent ne pas avoir l’état et les valeurs attendus par le test. Utilisez les enregistrements créés pendant le test pour garantir un état et des valeurs 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 concernant les considérations relatives à la conception de test.	Évitez d’utiliser des 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 « --Aucun-- » peut provoquer un comportement inattendu pour les actions d’interface utilisateur du 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 concernant les considérations relatives à la conception de test.	Les actions d’interface utilisateur du serveur entraînent l’envoi 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 du 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 Aucun se configure automatiquement sur Formulaire soumis au serveur.

Test de séparation en domaines

Lorsque vous testez Séparation de domaine, vous devez d’abord définir le domaine. Cela devrait 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 en matière de séparation de domaine, consultez Pratiques recommandées en matière de séparation de domaine pour les fournisseurs de services.