Notre société développe un framework avec Selenium, POM, Maven et Java pour une application Web et nous avons environ 35 cas de test. Lorsque nous exécutons testng.xml , il y a au moins 4 à 5 cas de test qui échouent de manière aléatoire en raison d'une exception d'élément périmé ou d'un élément non cliquable à ce stade, etc.
Est-il courant que certains cas de test échouent lorsque nous exécutons testng.xml ? Combien de cas de test sont exécutés dans votre organisation et quelle est l'estimation du nombre d'échecs?
5 Réponses :
Les échecs dus à des éléments périmés, à un élément non cliquable à un moment donné, à des problèmes de synchronisation, etc. doivent être traités et traités dans votre cadre d'automatisation - les méthodes que vous créez et utilisez pour construire le cas.
Ils ne doivent pas se propager et conduire à des échecs de cas - ce sont des problèmes techniques, pas un problème de produit ou un cas de test. En tant que tels, ils doivent être pris en compte (blocs try / catch par exemple) et traités (mécanismes de relance, ou réobtention d'un élément Web) rapidement.
Dans le même temps - et pour parler simplement de mon expérience - les cas traitant de données en direct / dynamiques peuvent parfois échouer de manière aléatoire.
Par exemple, un SUT sur lequel je travaille affiche des métriques et des agrégations basées sur des données et des actions hors de mon contrôle (trafic de vie des systèmes en amont). Il y a des cas vérifiant qu'un artefact généré particulier se comporte selon les attentes définies (imaginez un graphique mensuel par exemple, qui n'a tout simplement pas un certain nombre de points de données - il n'y avait tout simplement aucune activité ces jours-là) - les cas où cela échouera, non pas parce qu'ils ont été construits de manière incorrecte, et certainement pas parce qu'il y a un bogue du produit - mais à cause de la combinaison du temps d'exécution et du jeu de données.
Au fil du temps, j'en suis venu à la conclusion que ces échecs étaient acceptables, les «réparer» - resélectionner des ensembles de données, contourner ces fluctuations extérieures, etc. est une activité dont la valeur diminue et le retour sur investissement est discutable. Sur les quelque 10 000 cas actuels pour ce système, environ 1,5% échouent à cause de cela (avertissement: le SUT travaille exclusivement avec des données en direct / de production).
Ce n’est guère une règle empirique - c’est juste un nombre que j’ai jugé acceptable compte tenu du contexte.
Et note importante - si j'avais eu le contrôle total de ces mêmes données, je me serais débarrassé de ces échecs "aléatoires" également . J'ai choisi d'utiliser délibérément les données réelles - ainsi mes cas vérifient également leur intégrité; avec cet effet secondaire négatif.
Merci Todor, ces erreurs disparaîtront dans mon cadre
Il vous suffit d'ajouter un peu d'attente avant votre driver.findElement (). Selenium fonctionne très rapidement et c'est pourquoi vous obtenez cet élément périmé ou cet élément non visible des exceptions. L'ajout de wait devrait résoudre le problème.
L'automatisation des tests est liée à la répétabilité des tests et à la vitesse à laquelle les tests peuvent être exécutés. Il existe un certain nombre d'outils commerciaux et open source disponibles pour aider au développement de Test Automation et Selenium est probablement la solution open source la plus largement utilisée parmi eux.
Cette matrice peut varier d'une organisation à l'autre ou selon les Exigences du Client spécifiques. Toutefois, Critères de sortie doit tenir la clé de cette limite. Cela dit, comme l ' automatisation des tests via Selenium automatise les tests de régression , il devrait donc idéalement y avoir zéro échecs. Je connais une organisation adhérant à la politique Zero Defect .
Les erreurs que vous avez mentionnées ne sont donc pas des erreurs en tant que telles, mais peuvent survenir lors de l ' exécution du test pour les raisons suivantes:
Ces erreurs peuvent être facilement résolues en suivant les meilleures pratiques mentionnées ci-dessus.
Exceptions d'élément périmé - Cette exception peut apparaître lorsque l'élément n'est plus dans le DOM. Le principal contributeur à ce problème est la page qui se charge lorsque l'élément est recherché. La meilleure façon de gérer cela est d'attraper l'exception. Comme suggéré précédemment, il devrait être conçu dans le cadre du cadre pour gérer ces cas
Élément non cliquable au point - Ce problème peut survenir pour plusieurs raisons
Meilleure approche La meilleure façon de résoudre les défauts dans les tests est de capturer les captures d'écran en cas d'échec et de travailler dessus. Un cadre de test doit être conçu pour gérer tous ces scénarios de cas extrêmes
Merci les gars, je pourrais résoudre le problème
Étapes suivies 1) Exception d'élément périmé: Scénario: Sur la base d'un critère de recherche, la table des matières se chargerait avec le bouton Modifier et supprimer. La recherche était lente et le bouton des éléments à modifier devenait obsolète Solution: utiliser l'exemple de code d'attente personnalisé ci-dessous à partir d'articles précédents et le mettre en veille a fonctionné
public void getVisibilityAllTableAddressBook()
{
WebDriverWait wait = new WebDriverWait(driver, 10);
wait.until(ExpectedConditions.visibilityOfAllElements(driver.findElements(By.cssSelector("#data-table-items"))));
}
Le code ci-dessous a été utilisé précédemment mais n'a pas fonctionné
public static void customewait(int seconds)
{ Date start = new Date();
Date end = new Date();
while(end.getTime() - start.getTime() < seconds * 1000){
end = new Date();
}
}
Si le test échoue, cela signifie soit que votre code testé ne fonctionne pas comme prévu, soit que votre test est mauvais. Il ne devrait pas y avoir de tests ratés du tout