How-To

Si vous souhaitez utiliser les données d’un fichier MS Excel dans vos tests QF-Test ou souhaitez écrire les résultats des tests dans des fichiers MS Excel, continuez la lecture.

Les systèmes d’intégration continue (CI-Systems) soutiennent les équipes dans leur travail constant sur les différentes sous-étapes du processus de développement logiciel.  L’objectif principal étant l’amélioration de la qualité des logiciels.

Il n’y a pas de moyen d’éviter d’utiliser des variables si une suite de tests doit être flexible, réutilisable et élégante. Mais où sont définies les variables ? Quelle valeur de variable est utilisée si j’en ai défini plusieurs à différentes positions ? Et comment puis-je le découvrir ? Cet article vise à répondre à ces questions.

Si vous travaillez avec les nœuds de script QF-Test, peu importe que vous préfériez Jython, Groovy ou JavaScript, vous rencontrerez le module QF tôt ou tard. Ce module, accessible dans tous les nœuds de script et les terminaux de script via la variable qf, contient un tas de méthodes d’aide conçues pour faciliter la vie d’un programmeur de script.

Vous travaillez avec QF-Test et quelque chose ne fonctionne pas comme prévu ? Ensuite, vous pouvez (comme d’habitude) faire une recherche sur Internet ou faire des recherches sur StackOverflow… Un moyen plus rapide est d’utiliser nos canaux…

Il y a quelques jours, j’ai eu le plaisir de visiter un lieu de rencontre ici à Leipzig, en Allemagne. Le sujet était très intéressant – « Expérience avec l’introduction de l’automatisation des tests ». Beaucoup de participants considèrent les tests d’interface utilisateur Web très fragiles et fastidieux à maintenir dans un état « Tests OK », c’est pourquoi j’ai décidé d’écrire cette série avec le sujet : Pas d’événements basés sur les coordonnées et pas de vérifications basées sur l’image ! QF-Test est plus intelligent que cela !

Afin de simplifier l’édition des suites de tests, il est possible d’assigner des marques colorées aux nœuds. Cette fonctionnalité est particulièrement (mais pas seulement) utile dans le contexte d’opérations de recherche et remplacement complexes – dans ce cas, les marqueurs de couleur peuvent par exemple être utilisés pour indiquer qu’un nœud a encore besoin de révision ou qu’un nœud a été édité avec succès.

QF-Test utilise les événements semi-durs par défaut (en fonction du cadre web, du navigateur et de la version du navigateur, du système d’exploitation, etc.), mais pas dans tous les cas. Il y a trois types d’événements disponibles.

Dans certains cas, il est utile de désactiver temporairement les nœuds. Voici un court article sur comment faire.

Lors du test d’une application, l’une des étapes les plus importantes est de vérifier que l’état réel de l’application est correct.

Dans la plupart des cas, nous traitons des composants d’interface utilisateur plus ou moins simples, tels que les boutons et les champs de texte. Néanmoins, nous devons souvent traiter également des composants d’interface utilisateur plus complexes comme les arbres, les tables et les listes. Ces composants d’interface utilisateur ont des sous-éléments.

Les informations sensibles comme les mots de passe doivent être traitées avec précaution. Cependant, il arrive souvent que les tests doivent remplir un formulaire de connexion et qu’ils nécessitent donc de connaître le mot de passe.

Via le run log, QF-Test fournit un journal détaillé des actions exécutées pendant un test. Les résultats globaux de ce journal peuvent être résumés dans d »autres rapports comme le rapport HTML/XML/Junit.

Les procédures (également appelées fonctions ou sous-routines) peuvent être utilisées pour résoudre des défis qui se posent souvent (à nouveau).

Even in early stages of development Capture & Replay offers a easy way to create tests. An early start of such regression tests and the assignment of unique names / IDs are the most important bases for efficient (due to stable recognition) test automation.

Parfois, il est nécessaire d’effectuer des calculs mathématiques dans QF-Test, par exemple pour calculer la hauteur attendue d’un élément d’interface utilisateur en fonction de la taille complète de la fenêtre ou la position exacte du clic pour un clic de souris.

Un pourcentage élevé de code exécuté indique une faible probabilité de bogues logiciels non détectés.