Nous avons une application où certains fichiers sont en cours de chargement et l'application cesse de répondre pendant un certain temps lors du chargement du fichier. Au cours de l'automatisation des tests, nous avons le scénario dans lequel le chargement du fichier est automatisé, mais qtp doit attendre que l'application commence à répondre à nouveau. Comment coder ceci? Toute propriété est là comme "Attendre"?Attendez que l'application ait commencé à répondre - comment coder ceci en qtp?
Répondre
Aucune propriété n'est présente, comme «Patientez?
Si oui, alors il est spécifique à l'application, pour ainsi répondre qu'il faudrait jeter un oeil à la conception technique de l'interface graphique de votre application.
D'une manière générale, considérez comment un utilisateur humain pourrait comprendre que l'application "répond" à nouveau. Habituellement, il y a un indice visuel, comme un bouton apparaissant, ou un contrôle qui n'est plus grisé. Synchronisez sur cet état en utilisant un point de synchronisation. Si tout échoue (si vous ne pouvez pas identifier un contrôle qui apparaît, disparaît ou change ses propriétés lorsque le traitement de l'application est terminé), tenez-vous à un point de contrôle bitmap qui chercherait le même indice visuel qu'un humain interpréterait.
Souvent, le point de synchronisation ou l'indice visuel arrive un peu trop tôt, avant que l'application soit prête à accepter à nouveau l'entrée. Ensuite, si votre application efface le tampon du clavier avant la prochaine entrée de l'utilisateur (un exemple de mauvaise conception largement répandu ...), vous aurez du mal à synchroniser correctement. Les frappes de touches et les clics de souris seront perdus. Dans ce cas, a) contournez le problème en insérant un délai (appel de fonction wait) avant l'entrée suivante, b) établissez que l'application ne vide jamais sa file d'entrée, c) faites en sorte que l'indice visuel soit fait seulement après l'application VRAIMENT est prêt à accepter l'entrée. Bien sûr, b) et c) nécessitent du travail du côté du développeur et peuvent être difficiles à mettre en œuvre sur le plan organisationnel. Si le problème se produit dans des contextes différents ou même dans tous les contextes, communiquez-le à la direction de test et laissez-les amener les développeurs à implémenter un signal "Ready" personnalisé uniquement pour votre robot de test. Ensuite, vous pouvez interroger ce signal de QTP. Il peut s'agir d'un sémaphore, d'une propriété de chaîne Windows (appel d'API Set/GetPropEx), d'une existance de fichier (idée de baaad ..) ou d'une autre manière de communiquer l'état «Ready» de l'application au robot de test. Tout cela semble fou, mais j'ai fait tout ce qui précède, avec généralement de bons résultats.
Insérez un point de synchronisation sur l'un des objets de l'application, tel qu'un bouton, étant activé. Le point de synchronisation vous permet de spécifier la période d'expiration.
Vous pouvez utiliser une attente générique (secondes) si vous voulez un correctif rapide et sale. Par exemple, si vous savez que votre application sera prête à être utilisée en moins d'une minute. Cependant, si elle varie en fonction de la quantité de données, vous pouvez essayer d'utiliser la propriété 'Existe' d'un contrôle sur votre application qui est chargé une fois que toutes les données ont été traitées. ie.
while not loaded
wait(1)
loaded = Window.Control.Exist
Wend
À mon avis, la solution la plus simple et fiable serait d'invoquer WinAPI de IsHungAppWindow de user32.dll directement. QTP vous permet de déclarer facilement des fonctions externes.
Héhé ... alors que devrait-il attendre - pour la fonction IsHungAppWindow retournant vrai pour la fenêtre de son application? Ou fausse? Cela vous permet simplement de savoir si Windows considère que cette application ne répond pas. Toutes les applications qui n'interrogent pas leur file d'attente sont considérées comme "ne répondant pas". Cela ne signifie pas qu'une application qui ne répond pas ne soit pas prête à accepter et traiter les entrées du point de vue du robot de test ... Ce fait, et les délais d'attente impliqués, font que IsHungAppWindow n'est pas une bonne recommandation. – TheBlastOne
vous semblez compliquer les choses. Le démarreur de sujet a décrit la situation dans laquelle une application ne répond pas (lire - ne gère pas les messages) lors de certaines opérations. IsHungAppWindow identifierait exactement cette situation. Cette solution est assez facile à mettre en œuvre dans les outils de test automatique, il suffit d'appeler une fonction dll. – Andrey
Nous pouvons utiliser While pour attendre l'écran de la page d'application pour être visible, une fois chargé le script doit procéder à l'écran suivant
Supposons que votre application prend au maximum 2 min pour commencer. Utilisez la fonction ci-dessous pour savoir si votre application est existe ou non ...
fonction checkWindowExistance()
dim i
i = 0
pour i = 0 à 120
si Window.Dialog.Exist
{
exit for
}
attente (1) « wait_for_1_second
Suivant
si i = 120 puis
checkWindowExistance = false
autre
checkWindowExistance = true
fonction fin
Wait WaitProperty Sync ces trois propriétés sont principales ou des méthodes qui permet de rester dans la page Synchronisé
Wait « ll être utilisé par la plupart des programmeurs.
Mais Alors que la page complète doivent être snchronized mieux utiliser « .Sync » ça va vérifier que le temps de synchronisation hors et il passe à l'étape suivante si des charges avec succès
Mais attendez Attend laps de temps donné que objet trouvé intime
Remarque Exists a quelques bons bugs dans 10h00, ce qui revient toujours vrai pour des contrôles spécifiques. Utilisez GetProperty ("micclass") = "" dans de tels cas. –
TheBlastOne