AutoIT, ou bouton User32 en cliquant sporadiquement

J’essaie d’automatiser le test d’une application et je suis bloqué sur un problème que j’ai du mal à résoudre.

L’application dispose de boutons Windows standard, et j’ai essayé avec AutoIT et la DLL User32 de cliquer sur certains de ces boutons. Parfois, les boutons sont cliqués correctement (yay!) Et parfois ils échouent (boo!) – mais ce qui est pire, AutoIT est convaincu qu’il a cliqué sur le bouton (double-boo!) Qui génère alors des faux positifs (sortingple-boo!). Quand j’ai vu que c’était convaincu, je veux dire que cela revient à dire que le clic a été réussi alors que ce n’était pas le cas.

J’exécute l’application sur Win Server 2K8, il n’y a rien de particulier à propos de cette application, si ce n’est qu’elle utilise des fenêtres MDI, et certains des boutons sont contenus dans des fenêtres MDI. Certains ne sont cependant pas dans les fenêtres MDI (fenêtre de connexion, par exemple, avant que la fenêtre parente ne soit créée).

Voici mon ordre de commandes:

Trouver le bouton dans la fenêtre (succès, toujours) Apporter la fenêtre au premier plan (succès) Activer la fenêtre (succès) Activer le bouton (succès) Focaliser le bouton (succès) Si le bouton est activé et que le bouton est activé cliquez dessus. (Succès / échec, comportement imprévisible. Je ne peux pas préciser pourquoi il réussit parfois, et pourquoi cela échoue parfois…)

Autres détails:

Le bouton est parfois cliqué sur la commande, ce qui devrait ouvrir une autre fenêtre. Cette fenêtre est fermée, puis le bouton est à nouveau cliqué – et cette fois-ci, rien ne se passe. D’autres fois, cela fonctionne comme prévu.

Je cours en tant qu’administrateur et UAC est complètement désactivé.

À ma connaissance, ce n’est pas un problème de synchronisation, car je m’assure que le bouton est bien centré et qu’il est activé avant d’essayer de cliquer dessus, et je constate que le bouton attire l’attention.

Et comme je l’ai mentionné, j’ai également essayé ceci avec un simple appel User32 / SendMessage, et cela échoue également.

Enfin, cela ne se produit pas lorsque j’interagis manuellement avec l’application. J’ai toujours eu des clics sur les boutons.

Des pensées?

METTRE À JOUR

Voici une autre variable à l’équation que j’aurais dû mentionner – cela se passe sur une VM (parce que c’est là que j’ai besoin de l’exécuter). Je peux faire des tests limités sur ma propre machine, mais pour obtenir de vrais tests, cela doit être sur la machine virtuelle. En cliquant sur ma propre boîte de développement, cela semble fiable, ce qui est d’autant plus surprenant.

J’ai essayé ceci sur une autre VM, et ça semble aussi fonctionner là-bas. En ce qui concerne les deux machines virtuelles, elles exécutent la même version de Windows, la même version de mon application, la même version d’AutoIT, etc.

Je l’ai réduit à un détail – qui, comme par hasard, je ne suis pas en mesure de me configurer et de mettre un ticket pour modifier une configuration. La différence de configuration est la suivante:

Sur la machine virtuelle qui ne fonctionne pas , le gestionnaire de périphériques affiche une souris qui est une souris vmware. Sur la machine virtuelle qui fonctionne, le gestionnaire de l’appareil affiche une souris utilisant la souris PS / 2. De toute évidence, les deux sont des souris logicielles, mais je me demande maintenant si la souris VMWare peut agir différemment et que les clics sur les boutons ne fonctionnent pas toujours. Je ne suis pas sûr de la probabilité que cela soit la solution, car à ma connaissance, l’utilisation de l’appel User32 SendMessage n’utilise pas la souris, mais envoie le même message que celui que la souris aurait envoyé, mais cela vaut le coup. …

Vous dites que vous avez réussi à mettre le bouton en mode Focus , alors avez-vous essayé d’envoyer un événement MouseClick plutôt qu’un MouseClick ?

 Send("{SPACE}") 

(Je pense que c’est la syntaxe. Je ne suis pas vraiment un habitué d’AutoIt)

La barre d’espace peut généralement être utilisée pour interagir avec la plupart des contrôles cliquables, tels que les boutons et les cases à cocher. Dans mon expérience, les clics de souris simulés, et même les ControlClicks , sont beaucoup moins fiables que les frappes de touches pour des raisons étranges et incohérentes. Mes condoléances.

En ce qui concerne le fait de cliquer sur le bouton, la chose la plus facile à faire serait de faire en sorte que le bouton modifie le formulaire que AutoIT peut détecter. Par exemple, une étiquette de statut indiquant Ready jusqu’à ce que l’utilisateur appuie sur le bouton. Lorsque l’utilisateur appuie sur le bouton, le texte devient Processing . Si nécessaire, vous pouvez rendre l’étiquette invisible (ou positionnée en dehors des limites du formulaire), de sorte que l’utilisateur ne puisse pas le voir, mais AutoIt le peut.

Vous avez probablement réussi à résoudre ce problème au moment où vous avez posté cette question, mais il n’ya pas encore de bonne réponse, alors je posterai la mienne:

J’avais le même problème sur une machine virtuelle exécutant Windows Server 2008 R2: je ne pouvais pas envoyer de séquence de touches ni faire quoi que ce soit via SendMessage de l’API Win32 vers un programme particulier (et sa fenêtre principale).

Selon ce Q / R , il s’agit d’un problème UIPI (qui existe depuis Windows Vista). Vous devez simplement désactiver votre UAC pour résoudre ce problème. Je l’ai testé et ça marche. Vous trouverez plus d’alternatives dans le lien que j’ai fourni.

J’ai simulé votre cas et cela fonctionne à 100% sur Windows 7 :

 using System.Runtime.InteropServices; [DllImport("user32.dll", SetLastError = true)] static extern void keybd_event(byte bVk, byte bScan, uint dwFlags, UIntPtr dwExtraInfo); void ClickFocusedControl() { const uint KEYEVENTF_EXTENDEDKEY = 0x1; const uint KEYEVENTF_KEYUP = 0x2; keybd_event(13, Convert.ToByte(0), KEYEVENTF_EXTENDEDKEY, UIntPtr.Zero); //Generates a KEY_DOWN keybd_event(13, Convert.ToByte(0), KEYEVENTF_KEYUP, UIntPtr.Zero); // Generates a KEY_UP }